1) is completely normal…don’t worry. 2) not normal…worry. I’ll take a look at the lhe_tridents converter and see what’s going wrong. 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 <tm.sh><tm_17mm_9048events_rev1000_RECON.root><z_vtx.pdf> ######################################################################## 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