Functions | Variables
client_test.C File Reference

Go to the source code of this file.

Functions

gROOT Reset ()
 
bool handshake (void)
 
void configure (string particle_list)
 
void request_xsec (string opt)
 
void request_event (string opt)
 
void shutdown (void)
 
void client_test ()
 

Variables

int port = 9090
 
TSocket * sock = 0
 

Function Documentation

void client_test ( )

Definition at line 20 of file client_test.C.

21 {
22  // handhake with genie event server
23  //
24  bool is_alive = handshake();
25  assert(is_alive);
26 
27  // configure genie event server
28  //
29  configure("load-splines neutrino-list=14,-14,12,-12 target-list=1000260560");
30 
31  // request total cross section data (sum for all enabled channels) for
32  // some initial state
33  //
34  request_xsec("14 1000260560");
35 
36  // request the generation of some events
37  //
38  request_event("14011011 1 14 1.849474 0.740705 53.184013 14 1000260560 0.012129 -0.941614 16.443062");
39  request_event("14011011 2 14 2.187474 0.362736 22.218212 14 1000260560 0.120932 0.239200 3.212121");
40  request_event("14011011 3 14 1.094340 0.127128 18.210291 14 1000260560 0.239001 -0.129101 8.029121");
41 
42  // shutdown the genie event server
43  //
44  shutdown();
45 }
shutdown
void shutdown(void)
Definition: client_test.C:148
request_event
void request_event(string opt)
Definition: client_test.C:116
handshake
bool handshake(void)
Definition: client_test.C:47
request_xsec
void request_xsec(string opt)
Definition: client_test.C:86
configure
void configure(string particle_list)
Definition: client_test.C:65
void configure ( string  particle_list)

Definition at line 65 of file client_test.C.

66 {
67 // Sytnax:
68 // mesg sent:
69 // CONFIG: load-splines neutrino-list=comma_separated_list_of_pdg_codes target_list=comma_separated_list_of_pdg_codes
70 //
71  cout << "Configuring the GENIE event server" << endl;
72 
73  string cmd = "CONFIG: " + particle_list;
74 
75  sock->Send(cmd.c_str());
76  cout << "Sent: " << cmd << endl;
77 
78  char mesg[2048];
79  sock->Recv(mesg,2048);
80  cout << "Received: " << mesg << endl;
81 
82  bool is_configured = (strcmp(mesg,"CONFIG COMPLETED") == 0);
83  assert(is_configured);
84 }
sock
TSocket * sock
Definition: client_test.C:11
generate_CCQE_events.cmd
list cmd
Definition: generate_CCQE_events.py:42
cout
the ParameterSet object passed in for the configuration of a destination should be the only source that can affect the behavior of that destination This is to eliminate the dependencies of configuring a destination from multiple mostly from the defaults It suppresses possible glitches about changing the configuration file somewhere outside of a destination segament might still affect the behavior of that destination In the previous configuration for a specific the value of a certain e may come from following and have been suppressed It the configuring ParameterSet object for each destination will be required to carry a parameter list as complete as possible If a parameter still cannot be found in the ParameterSet the configuration code will go look for a hardwired default directly The model is a great simplicity comparing with the previous especially when looking for default values Another great advantage is most of the parameters now have very limited places that allows to appear Usually they can only appear at one certain level in a configuration file For in the old configuring model or in a default ParameterSet object inside of a or in a category or in a severity object This layout of multiple sources for a single parameter brings great confusion in both writing a configuration and in processing the configuration file Under the new the only allowed place for the parameter limit to appear is inside of a category which is inside of a destination object Other improvements simplify the meaning of a destination name In the old a destination name has multiple folds of meanings the e cout and cerr have the special meaning of logging messages to standard output or standard error the name also serves as the output filename if the destination is a file these names are also references to look up for detailed configurations in configuring the MessageFacility The multi purpose of the destination name might cause some unwanted behavior in either writing or parsing the configuration file To amend in the new model the destination name is now merely a name for a which might represent the literal purpose of this or just an id All other meanings of the destinations names now go into the destination ParameterSet as individual such as the type parameter and filename parameter Following is the deatiled rule for the new configuring Everything that is related with MessageFacility configuration must be wrapped in a single ParameterSet object with the name MessageFacility The MessageFacility ParameterSet object contains a series of top level parameters These parameters can be chosen a vector of string listing the name of debug enabled models Or use *to enable debug messages in all modules a vector of string a vector of string a vector of string a ParameterSet object containing the list of all destinations The destinations ParameterSet object is a combination of ParameterSet objects for individual destinations There are two types of destinations that you can insert in the destinations ParameterSet ordinary including cout
Definition: MessageFacilityAsStandAlonePackage.txt:82
bool handshake ( void  )

Definition at line 47 of file client_test.C.

48 {
49  sock = new TSocket("localhost", port);
50  if(!sock) return false;
51 
52  cout << "Pinging the GENIE event server" << endl;
53 
54  sock->Send("RUB GENIE LAMP");
55  cout << "Sent: RUB GENIE LAMP" << endl;
56 
57  char mesg[2048];
58  sock->Recv(mesg,2048);
59  cout << "Received: " << mesg << endl;
60 
61  bool is_alive = (strcmp(mesg,"YOU HAVE 3 WISHES!") == 0);
62  return is_alive;
63 }
sock
TSocket * sock
Definition: client_test.C:11
cout
the ParameterSet object passed in for the configuration of a destination should be the only source that can affect the behavior of that destination This is to eliminate the dependencies of configuring a destination from multiple mostly from the defaults It suppresses possible glitches about changing the configuration file somewhere outside of a destination segament might still affect the behavior of that destination In the previous configuration for a specific the value of a certain e may come from following and have been suppressed It the configuring ParameterSet object for each destination will be required to carry a parameter list as complete as possible If a parameter still cannot be found in the ParameterSet the configuration code will go look for a hardwired default directly The model is a great simplicity comparing with the previous especially when looking for default values Another great advantage is most of the parameters now have very limited places that allows to appear Usually they can only appear at one certain level in a configuration file For in the old configuring model or in a default ParameterSet object inside of a or in a category or in a severity object This layout of multiple sources for a single parameter brings great confusion in both writing a configuration and in processing the configuration file Under the new the only allowed place for the parameter limit to appear is inside of a category which is inside of a destination object Other improvements simplify the meaning of a destination name In the old a destination name has multiple folds of meanings the e cout and cerr have the special meaning of logging messages to standard output or standard error the name also serves as the output filename if the destination is a file these names are also references to look up for detailed configurations in configuring the MessageFacility The multi purpose of the destination name might cause some unwanted behavior in either writing or parsing the configuration file To amend in the new model the destination name is now merely a name for a which might represent the literal purpose of this or just an id All other meanings of the destinations names now go into the destination ParameterSet as individual such as the type parameter and filename parameter Following is the deatiled rule for the new configuring Everything that is related with MessageFacility configuration must be wrapped in a single ParameterSet object with the name MessageFacility The MessageFacility ParameterSet object contains a series of top level parameters These parameters can be chosen a vector of string listing the name of debug enabled models Or use *to enable debug messages in all modules a vector of string a vector of string a vector of string a ParameterSet object containing the list of all destinations The destinations ParameterSet object is a combination of ParameterSet objects for individual destinations There are two types of destinations that you can insert in the destinations ParameterSet ordinary including cout
Definition: MessageFacilityAsStandAlonePackage.txt:82
port
int port
Definition: client_test.C:9
void request_event ( string  opt)

Definition at line 116 of file client_test.C.

117 {
118 // Syntax:
119 // mesg sent:
120 // EVTVTX: irun ievt ipdgnunosoc vtx_x vtx_y vtx_z ipdgnu ipdgtgt px_nu py_nu pz_nu
121 // mesg recv:
122 // EVTREC: irun ievt ipdgnunosoc vtx_x vtx_y vtx_z
123 // ipdgnu ipdgtgt px_nu py_nu pz_nu
124 // int_type iaction nucleon struck-quark xbj_int ybj_int w2_int q2_int
125 // total-xsection diff-xsection ihadmod
126 // STDHEP: nlines
127 // indx ist ipdg jmo1 jmo2 jda1 jda2 px py pz E mass vx vy vz time
128 // ...
129 // indx ist ipdg jmo1 jmo2 jda1 jda2 px py pz E mass vx vy vz time
130 //
131  string cmd = "EVTVTX: " + opt;
132 
133  sock->Send(cmd.c_str());
134  cout << "Sent: " << cmd << endl;
135 
136  while(1) {
137  char mesg[2048];
138  sock->Recv(mesg,2048);
139  cout << "Received: " << mesg << endl;
140 
141  bool exit_loop = (strcmp(mesg,"FAILED")==0) ||
142  (strcmp(mesg,"EVENT GENERATED")==0);
143 
144  if(exit_loop) break;
145  }
146 }
sock
TSocket * sock
Definition: client_test.C:11
generate_CCQE_events.cmd
list cmd
Definition: generate_CCQE_events.py:42
cout
the ParameterSet object passed in for the configuration of a destination should be the only source that can affect the behavior of that destination This is to eliminate the dependencies of configuring a destination from multiple mostly from the defaults It suppresses possible glitches about changing the configuration file somewhere outside of a destination segament might still affect the behavior of that destination In the previous configuration for a specific the value of a certain e may come from following and have been suppressed It the configuring ParameterSet object for each destination will be required to carry a parameter list as complete as possible If a parameter still cannot be found in the ParameterSet the configuration code will go look for a hardwired default directly The model is a great simplicity comparing with the previous especially when looking for default values Another great advantage is most of the parameters now have very limited places that allows to appear Usually they can only appear at one certain level in a configuration file For in the old configuring model or in a default ParameterSet object inside of a or in a category or in a severity object This layout of multiple sources for a single parameter brings great confusion in both writing a configuration and in processing the configuration file Under the new the only allowed place for the parameter limit to appear is inside of a category which is inside of a destination object Other improvements simplify the meaning of a destination name In the old a destination name has multiple folds of meanings the e cout and cerr have the special meaning of logging messages to standard output or standard error the name also serves as the output filename if the destination is a file these names are also references to look up for detailed configurations in configuring the MessageFacility The multi purpose of the destination name might cause some unwanted behavior in either writing or parsing the configuration file To amend in the new model the destination name is now merely a name for a which might represent the literal purpose of this or just an id All other meanings of the destinations names now go into the destination ParameterSet as individual such as the type parameter and filename parameter Following is the deatiled rule for the new configuring Everything that is related with MessageFacility configuration must be wrapped in a single ParameterSet object with the name MessageFacility The MessageFacility ParameterSet object contains a series of top level parameters These parameters can be chosen a vector of string listing the name of debug enabled models Or use *to enable debug messages in all modules a vector of string a vector of string a vector of string a ParameterSet object containing the list of all destinations The destinations ParameterSet object is a combination of ParameterSet objects for individual destinations There are two types of destinations that you can insert in the destinations ParameterSet ordinary including cout
Definition: MessageFacilityAsStandAlonePackage.txt:82
void request_xsec ( string  opt)

Definition at line 86 of file client_test.C.

87 {
88 // Syntax:
89 // mesg sent:
90 // XSEC: ipdgnu ipdgtgt
91 // mesg recv (E in GeV, Sig in 1E-38 cm^2):
92 // XSECSPL: npoints
93 // knot(0) E(0) Sig(0)
94 // knot(1) E(1) Sig(1)
95 // knot(2) E(2) Sig(2)
96 // ....
97 //
98 
99  string cmd = "XSEC: " + opt;
100 
101  sock->Send(cmd.c_str());
102  cout << "Sent: " << cmd << endl;
103 
104  while(1) {
105  char mesg[2048];
106  sock->Recv(mesg,2048);
107  cout << "Received: " << mesg << endl;
108 
109  bool exit_loop = (strcmp(mesg,"FAILED")==0) ||
110  (strcmp(mesg,"XSEC SENT")==0);
111 
112  if(exit_loop) break;
113  }
114 }
sock
TSocket * sock
Definition: client_test.C:11
generate_CCQE_events.cmd
list cmd
Definition: generate_CCQE_events.py:42
cout
the ParameterSet object passed in for the configuration of a destination should be the only source that can affect the behavior of that destination This is to eliminate the dependencies of configuring a destination from multiple mostly from the defaults It suppresses possible glitches about changing the configuration file somewhere outside of a destination segament might still affect the behavior of that destination In the previous configuration for a specific the value of a certain e may come from following and have been suppressed It the configuring ParameterSet object for each destination will be required to carry a parameter list as complete as possible If a parameter still cannot be found in the ParameterSet the configuration code will go look for a hardwired default directly The model is a great simplicity comparing with the previous especially when looking for default values Another great advantage is most of the parameters now have very limited places that allows to appear Usually they can only appear at one certain level in a configuration file For in the old configuring model or in a default ParameterSet object inside of a or in a category or in a severity object This layout of multiple sources for a single parameter brings great confusion in both writing a configuration and in processing the configuration file Under the new the only allowed place for the parameter limit to appear is inside of a category which is inside of a destination object Other improvements simplify the meaning of a destination name In the old a destination name has multiple folds of meanings the e cout and cerr have the special meaning of logging messages to standard output or standard error the name also serves as the output filename if the destination is a file these names are also references to look up for detailed configurations in configuring the MessageFacility The multi purpose of the destination name might cause some unwanted behavior in either writing or parsing the configuration file To amend in the new model the destination name is now merely a name for a which might represent the literal purpose of this or just an id All other meanings of the destinations names now go into the destination ParameterSet as individual such as the type parameter and filename parameter Following is the deatiled rule for the new configuring Everything that is related with MessageFacility configuration must be wrapped in a single ParameterSet object with the name MessageFacility The MessageFacility ParameterSet object contains a series of top level parameters These parameters can be chosen a vector of string listing the name of debug enabled models Or use *to enable debug messages in all modules a vector of string a vector of string a vector of string a ParameterSet object containing the list of all destinations The destinations ParameterSet object is a combination of ParameterSet objects for individual destinations There are two types of destinations that you can insert in the destinations ParameterSet ordinary including cout
Definition: MessageFacilityAsStandAlonePackage.txt:82
gROOT Reset ( )
void shutdown ( void  )

Definition at line 148 of file client_test.C.

149 {
150  sock->Send("SHUTDOWN");
151  cout << "Sent: SHUTDOWN" << endl;
152 
153  char mesg[2048];
154  sock->Recv(mesg,2048);
155  cout << "Received: " << mesg << endl;
156 
157  sock->Close();
158 }
sock
TSocket * sock
Definition: client_test.C:11
cout
the ParameterSet object passed in for the configuration of a destination should be the only source that can affect the behavior of that destination This is to eliminate the dependencies of configuring a destination from multiple mostly from the defaults It suppresses possible glitches about changing the configuration file somewhere outside of a destination segament might still affect the behavior of that destination In the previous configuration for a specific the value of a certain e may come from following and have been suppressed It the configuring ParameterSet object for each destination will be required to carry a parameter list as complete as possible If a parameter still cannot be found in the ParameterSet the configuration code will go look for a hardwired default directly The model is a great simplicity comparing with the previous especially when looking for default values Another great advantage is most of the parameters now have very limited places that allows to appear Usually they can only appear at one certain level in a configuration file For in the old configuring model or in a default ParameterSet object inside of a or in a category or in a severity object This layout of multiple sources for a single parameter brings great confusion in both writing a configuration and in processing the configuration file Under the new the only allowed place for the parameter limit to appear is inside of a category which is inside of a destination object Other improvements simplify the meaning of a destination name In the old a destination name has multiple folds of meanings the e cout and cerr have the special meaning of logging messages to standard output or standard error the name also serves as the output filename if the destination is a file these names are also references to look up for detailed configurations in configuring the MessageFacility The multi purpose of the destination name might cause some unwanted behavior in either writing or parsing the configuration file To amend in the new model the destination name is now merely a name for a which might represent the literal purpose of this or just an id All other meanings of the destinations names now go into the destination ParameterSet as individual such as the type parameter and filename parameter Following is the deatiled rule for the new configuring Everything that is related with MessageFacility configuration must be wrapped in a single ParameterSet object with the name MessageFacility The MessageFacility ParameterSet object contains a series of top level parameters These parameters can be chosen a vector of string listing the name of debug enabled models Or use *to enable debug messages in all modules a vector of string a vector of string a vector of string a ParameterSet object containing the list of all destinations The destinations ParameterSet object is a combination of ParameterSet objects for individual destinations There are two types of destinations that you can insert in the destinations ParameterSet ordinary including cout
Definition: MessageFacilityAsStandAlonePackage.txt:82

Variable Documentation

int port = 9090

Definition at line 9 of file client_test.C.

TSocket* sock = 0

Definition at line 11 of file client_test.C.

Generated by   doxygen 1.8.11