Could a MadGraph/Stdhep expert help resolve something?


I am using a shell script modified from mock.xml to generate A' signal events, and two issues arise:

1.) When requesting a large number of events (>10,000), {MadGraph_dir}/.../generate_events cannot complete that many. 100,000 requested events yielded only 4591, for example, and this exact number was generated for two consecutive runs, which doesn't seem like it should be the case either. Is there a limiting factor to how many events generate_events can handle, and a way to get around that limit? I attached the script with the settings used. 20 iterations did not even come close to what was requested:

SubProcess/Channel     kept   read   xsec
P1_e-n+_f+f-e-n+/G1.001/       0    8647 0.000E+00
P1_e-n+_f+f-e-n+/G2.001/    5356   14003 0.230E+15
 Iteration  1 too large truncation   0.948 5356
 Iteration  2 too large truncation   0.9324 5356
 Iteration  3 too large truncation   0.91212 5356
 Iteration  4 too large truncation   0.885756 5356
 Iteration  5 too large truncation   0.8514828 5356
 Iteration  6 too large truncation   0.80692764 5356
 Iteration  7 too large truncation   0.749005932 5356
 Iteration  8 too large truncation   0.673707712 5356
 Iteration  9 too large truncation   0.575820025 5356
 Iteration  10 too large truncation   0.448566033 5356
 Iteration  11 too large truncation   0.283135842 5356
 Iteration  12 too large truncation   0.0680765951 5356
 Iteration  13 too few events   0.00475554934 4396
 Iteration  14 too few events   0.00584224568 4610
 Iteration  15 too few events   0.00706645175 4887
 Iteration  16 too few events   0.00841083167 5100
 Iteration  17 too large truncation   0.0132253308 5356
 Iteration  18 too few events   0.00375604353 4140
 Iteration  19 too few events   0.00464394363 4394
 Iteration  20 too few events   0.0057078081 4591
 Unable to get  100000 events. Writing  4591
 Unweighting selected  4591 events.
Truncated  0.57% of cross section

2.) Whenever the decay length is applied during the conversion to stdhep (with {stdhep_dir}/.../lhe_tridents.cc), the displaced vertex does not appear to show up during analysis. Initially, I was thinking this may have something to do with the procedure only expecting 1000 events, and so not all the signals were being displaced, but this is the case even if 1000 events were generated.

The generated stdhep file should have signal events with a displaced vertex of 1.7cm, if everything was correct. I attached  the .root file after reconstruction and a representative distribution of the vtx_z positions of the unconstrained vertexed particles, apparently centered at zero. I used hps_trunk revision 1000, since that appeared to fix the track assignment problem that was previously discussed, v8 detector, standard readout and recon with no pileup, and 9048 stdhep events (1994 readout triggers). I can provide the exact readout information as well, if wanted, or you can run through the procedure on your own system. If everything appears to be correct, then this could also be due to incorrect analysis on my part, in which case I need to quickly rectify that as well.

-Bradley


Use REPLY-ALL to reply to list

To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1