Are you sure something hasn't changed in the StdHep events?
Because I don't know why this would stop working, given that we have used that version of SLIC for quite a long time.
Can we test some older StdHep files which are known good with a similar displaced vertex to see if the same problem happens?
-----Original Message-----
From: Sho Uemura [mailto:[log in to unmask]]
Sent: Monday, March 30, 2015 6:59 PM
To: Bradley T Yale
Cc: Graham, Mathew Thomas; McCormick, Jeremy I.; hps-software
Subject: Re: Signal Generation Issue
OK, then I agree it's a SLIC problem. All I saw in the e-mail thread was that the 622 endpoint was 0.
I'll let Jeremy look at it, I doubt I could do anything beyond re-confirming the problem.
On Tue, 31 Mar 2015, Bradley T Yale wrote:
> Looking at any .slcio file in JAS3, the daughter particles of 662 also appear to begin at 0, despite having displaced vertices in the stdhep file, and I think Matt confirmed this. Something appears to (not) be happening with SLIC, at least with the version I used (3.1.5). I'll try updating tomorrow if not current, but someone could see if it is properly working on their version, if not too much trouble.
>
> No need to displace 662 as well.
>
> -Brad
>
> ________________________________________
> From: Sho Uemura <[log in to unmask]>
> Sent: Monday, March 30, 2015 9:15 PM
> To: Graham, Mathew Thomas
> Cc: McCormick, Jeremy I.; Bradley T Yale; hps-software
> Subject: Re: Signal Generation Issue
>
> lhe_tridents looks for the A' (PDGID 622), gets the momentum,
> calculates gamma*ct (the input parameter is ct, not gamma*ct) and
> rolls the dice to determine a distance, and displaces all the child
> particles in the direction of the momentum. It does not displace the
> A' - stdhep only lets you define one position per particle, and I
> think (stdhep docs are not very clear on this point) the position is
> supposed to be where the particle is created, not destroyed.
>
> So the endpoint of the 622 will always be zero, but the decay products
> will start at the displaced vertex. If you want to move the 622 to the
> vertex, I can do that.
>
> If the reconstructed vertex position is centered at 0 as Bradley said
> in his first e-mail, that does indicate a problem. But maybe the
> problem is that the muon vertices are not being reconstructed because
> they're too far downstream and the decay products miss layer 1 - these
> are boosted to gamma ~20, so gamma*ct is tens of cm. Then the vertex
> distribution you see is something else - background?
>
> On Sat, 28 Mar 2015, Graham, Mathew Thomas wrote:
>
>>
>> On the slac machines:
>>
>> ~mgraham/hps/tm_17mm.stdhep
>> HPS-Proposal2014-v8-6pt6
>>
>>
>> On Mar 28, 2015, at 3:47 PM, McCormick, Jeremy I. <[log in to unmask]<mailto:[log in to unmask]>> wrote:
>>
>> 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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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>
>>
>>
>>
>>
>>
>>
>> #####################################################################
>> ###
>> 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
>>
>
> ######################################################################
> ##
> 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
>
########################################################################
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
|
