That version's pretty ancient at this point....

Can you point me to some stdhep files and tell me what detector model you're running?  I can test this out on Monday.

On Mar 28, 2015, at 12:44 PM, Graham, Mathew Thomas <[log in to unmask]> wrote:

[PPA-PC91391:~] % slic -v

Sat Mar 28 15:43:10 2015 :: OKAY :: SlicApplication :: SLIC is starting.

Simulation for the Linear Collider 3.1.5

Geant4 9.6.1

…I think Bradley probably used the one at JLAB which is 3.1.4.  I know it’s old and we should move to something newer at some point.  

On Mar 28, 2015, at 3:42 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:

What version of SLIC is being used?

On Mar 28, 2015, at 12:34 PM, Graham, Mathew Thomas <[log in to unmask]> wrote:

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 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>