I'm using SLIC 3.1.5
That is the same thing that I had in the .lcio file, decay at zero via JAS3
-Brad
What version of SLIC is being used?
I ran slic over the stdhep file generated from this script and I see same as you see..in the output slcio it says the A’s are decaying at (0,0,0). It seems like that for some reason slic isn’t using the correct start & endpoints from the stdhep event. This used to work, but it’s been a while since we’ve done this….
On Mar 28, 2015, at 2:48 PM, Graham, Mathew Thomas <[log in to unmask]> wrote:
I ran your script and looked at the output stdhep events and they definitely have a displaced A’ decay; it actually looks like it’s traveling too far for a 17mm lifetime—we should check that the script is calculating this properly. I’ll try running these events through the simulation, readout recon chain and compare to what you see.
Looking at the root file you sent…HPS_Event->Draw("mc_particles.endpt_z","mc_particles.pdg==622”)…gives all zeros, saying the the A’ decay wasn’t displaced which agrees with the plot you sent. So…that’s weird. Can you send me the .slcio file you made from the stdhep?
Thanks, Matt
On Mar 28, 2015, at 10:36 AM, Graham, Mathew Thomas <[log in to unmask]> wrote:
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 listTo unsubscribe from the HPS-SOFTWARE list, click the following link:<tm.sh><tm_17mm_9048events_rev1000_RECON.root><z_vtx.pdf>
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1