270 const double kPIMASS = 0.13957;
271 const double kKMASS = 0.49368;
272 const double kK0MASS = 0.49767;
273 const double kMUMASS = 0.105658389;
275 const int kpdg_nue = 12;
276 const int kpdg_nuebar = -12;
277 const int kpdg_numu = 14;
278 const int kpdg_numubar = -14;
280 const int kpdg_muplus = -13;
281 const int kpdg_muminus = 13;
282 const int kpdg_pionplus = 211;
283 const int kpdg_pionminus = -211;
284 const int kpdg_k0long = 130;
285 const int kpdg_k0short = 310;
286 const int kpdg_k0mix = 311;
287 const int kpdg_kaonplus = 321;
288 const int kpdg_kaonminus = -321;
290 const double kRDET = 100.0;
298 double parent_mass = kPIMASS;
299 switch ( fluxentry.
ptype ) {
302 parent_mass = kPIMASS;
306 parent_mass = kKMASS;
311 parent_mass = kK0MASS;
315 parent_mass = kMUMASS;
323 double parentp2 = ( fluxentry.
pdpx*fluxentry.
pdpx +
326 double parent_energy = TMath::Sqrt( parentp2 +
327 parent_mass*parent_mass);
328 double parentp = TMath::Sqrt( parentp2 );
330 double gamma = parent_energy / parent_mass;
331 double gamma_sqr = gamma * gamma;
332 double beta_mag = TMath::Sqrt( ( gamma_sqr - 1.0 )/gamma_sqr );
335 double enuzr = fluxentry.
necm;
337 double rad = TMath::Sqrt( (xpos-fluxentry.
vx)*(xpos-fluxentry.
vx) +
338 (ypos-fluxentry.
vy)*(ypos-fluxentry.
vy) +
339 (zpos-fluxentry.
vz)*(zpos-fluxentry.
vz) );
341 double costh_pardet = ( fluxentry.
pdpx*(xpos-fluxentry.
vx) +
342 fluxentry.
pdpy*(ypos-fluxentry.
vy) +
343 fluxentry.
pdpz*(zpos-fluxentry.
vz) )
345 if ( costh_pardet > 1.0 ) costh_pardet = 1.0;
346 if ( costh_pardet < -1.0 ) costh_pardet = -1.0;
347 double theta_pardet = TMath::ACos(costh_pardet);
351 double emrat = 1.0 / ( gamma * ( 1.0 - beta_mag * costh_pardet ));
357 cout << setprecision(15);
358 cout <<
"ptype " << fluxentry.
ptype <<
" m " << parent_mass
359 <<
" p " << parentp <<
" e " << parent_energy <<
" gamma " << gamma
360 <<
" beta " << beta_mag << endl;
362 cout <<
" enuzr " << enuzr <<
" rad " << rad <<
" costh " << costh_pardet
363 <<
" theta " << theta_pardet <<
" emrat " << emrat
364 <<
" enu " <<
enu << endl;
366 partials.parent_mass = parent_mass;
367 partials.parentp = parentp;
368 partials.parent_energy = parent_energy;
369 partials.gamma = gamma;
370 partials.beta_mag = beta_mag;
371 partials.enuzr = enuzr;
373 partials.costh_pardet = costh_pardet;
374 partials.theta_pardet = theta_pardet;
375 partials.emrat = emrat;
379 double sangdet = ( kRDET*kRDET / ( (zpos-fluxentry.
vz)*(zpos-fluxentry.
vz)))/4.0;
382 wgt_xy = sangdet * ( emrat * emrat );
384 partials.sangdet = sangdet;
385 partials.wgt = wgt_xy;
386 partials.ptype = fluxentry.
ptype;
391 if ( fluxentry.
ptype == kpdg_muplus || fluxentry.
ptype == kpdg_muminus) {
392 double beta[3], p_dcm_nu[4], p_nu[3], p_pcm_mp[3], partial;
395 beta[0] = fluxentry.
pdpx / parent_energy;
396 beta[1] = fluxentry.
pdpy / parent_energy;
397 beta[2] = fluxentry.
pdpz / parent_energy;
398 p_nu[0] = (xpos-fluxentry.
vx)*
enu/rad;
399 p_nu[1] = (ypos-fluxentry.
vy)*
enu/rad;
400 p_nu[2] = (zpos-fluxentry.
vz)*
enu/rad;
402 (beta[0]*p_nu[0] + beta[1]*p_nu[1] + beta[2]*p_nu[2] );
403 partial =
enu - partial/(gamma+1.0);
404 p_dcm_nu[0] = p_nu[0] - beta[0]*gamma*partial;
405 p_dcm_nu[1] = p_nu[1] - beta[1]*gamma*partial;
406 p_dcm_nu[2] = p_nu[2] - beta[2]*gamma*partial;
407 p_dcm_nu[3] = TMath::Sqrt( p_dcm_nu[0]*p_dcm_nu[0] +
408 p_dcm_nu[1]*p_dcm_nu[1] +
409 p_dcm_nu[2]*p_dcm_nu[2] );
411 partials.betanu[0] = beta[0];
412 partials.betanu[1] = beta[1];
413 partials.betanu[2] = beta[2];
414 partials.p_nu[0] = p_nu[0];
415 partials.p_nu[1] = p_nu[1];
416 partials.p_nu[2] = p_nu[2];
417 partials.partial1 = partial;
418 partials.p_dcm_nu[0] = p_dcm_nu[0];
419 partials.p_dcm_nu[1] = p_dcm_nu[1];
420 partials.p_dcm_nu[2] = p_dcm_nu[2];
421 partials.p_dcm_nu[3] = p_dcm_nu[3];
424 double particle_energy = fluxentry.
ppenergy;
425 gamma = particle_energy/parent_mass;
426 beta[0] = fluxentry.
ppdxdz * fluxentry.
pppz / particle_energy;
427 beta[1] = fluxentry.
ppdydz * fluxentry.
pppz / particle_energy;
428 beta[2] = fluxentry.
pppz / particle_energy;
429 partial = gamma * ( beta[0]*fluxentry.
muparpx +
432 partial = fluxentry.
mupare - partial/(gamma+1.0);
433 p_pcm_mp[0] = fluxentry.
muparpx - beta[0]*gamma*partial;
434 p_pcm_mp[1] = fluxentry.
muparpy - beta[1]*gamma*partial;
435 p_pcm_mp[2] = fluxentry.
muparpz - beta[2]*gamma*partial;
436 double p_pcm = TMath::Sqrt ( p_pcm_mp[0]*p_pcm_mp[0] +
437 p_pcm_mp[1]*p_pcm_mp[1] +
438 p_pcm_mp[2]*p_pcm_mp[2] );
445 partials.muparent_px = fluxentry.
muparpx;
446 partials.muparent_py = fluxentry.
muparpy;
447 partials.muparent_pz = fluxentry.
muparpz;
448 partials.gammamp = gamma;
449 partials.betamp[0] = beta[0];
450 partials.betamp[1] = beta[1];
451 partials.betamp[2] = beta[2];
452 partials.partial2 = partial;
453 partials.p_pcm_mp[0] = p_pcm_mp[0];
454 partials.p_pcm_mp[1] = p_pcm_mp[1];
455 partials.p_pcm_mp[2] = p_pcm_mp[2];
456 partials.p_pcm = p_pcm;
458 const double eps = 1.0e-30;
459 if ( p_pcm < eps || p_dcm_nu[3] < eps ) {
463 double costh = ( p_dcm_nu[0]*p_pcm_mp[0] +
464 p_dcm_nu[1]*p_pcm_mp[1] +
465 p_dcm_nu[2]*p_pcm_mp[2] ) /
466 ( p_dcm_nu[3]*p_pcm );
467 if ( costh > 1.0 ) costh = 1.0;
468 if ( costh < -1.0 ) costh = -1.0;
470 double wgt_ratio = 0.0;
471 switch ( fluxentry.
ntype ) {
474 wgt_ratio = 1.0 - costh;
478 double xnu = 2.0 * enuzr / kMUMASS;
479 wgt_ratio = ( (3.0-2.0*xnu ) - (1.0-2.0*xnu)*costh ) / (3.0-2.0*xnu);
484 wgt_xy = wgt_xy * wgt_ratio;
486 partials.ntype = fluxentry.
ntype;
487 partials.costhmu = costh;
488 partials.wgt_ratio = wgt_ratio;
Actions and Circumstances Relevant to Incomplete Log Problem The some of the LogInfo messages issued at the end involving branch information are failing to emerge This necessitates re running the for a net loss of up to of the work done The problem can t be happening based on what the logger but it is Dave Evans worte a stand along program to issue huge bunches of messages to try to provoke a repeatable version of the bad which we could hope to debug
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
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 cerr