Print

Print


Hi Jeremy,

Thanks a lot for finding this.
We could probably just replace the mass value in the copy of 'particle.tbl' with an awk command in the script as needed, the way it is done in the MadGraph runcards. I'll try to work it into the standard procedure.

Brad

________________________________________
From: McCormick, Jeremy I. <[log in to unmask]>
Sent: Friday, January 8, 2016 8:16 PM
To: Bradley T Yale; Omar Moreno
Cc: Graham, Mathew Thomas; Uemura, Sho; Nathan Baltzell; hps-software
Subject: RE: Pass4 MC

Hi, Bradley.

I figured out what is going on with this, so let me explain for future reference.

Geant4 has trouble with particles that it does not know about e.g. the PDG 622 particle in your stdhep events representing the A prime is not something in G4's particle database.  Since this particle is marked as INTERMEDIATE, SLIC will create a G4PrimaryParticle for it, but the primary will be immediately decayed into its assigned products via the G4UnknownDecay process.  This is because it does not know how to track this particle in the simulation.

I'm able to hack around this by using the particle.tbl input to SLIC which is designed for introducing new particle definitions into the simulation.

I copied and then modified slic/HEAD/data/particle.tbl and added a row for the A prime:

622 A_prime                 0      0.05        0.0       99999999999

This has an infinite lifetime assigned with the mass and charge from the stdhep file, but the actual lifetime will be set through the preassigned decay and overrides this dummy value.

So then when I run slic with the new particle definition...

slic -P particle.tbl [...]

I can see the particle then travels properly before it decays...

*********************************************************************************************************
* G4Track Information:   Particle = not defined,   Track ID = 1,   Parent ID = 0
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0        0        0        0       676        0        0         0 tracking_volume initStep
    1   0.0658    -0.25     7.82       676        0     7.82      7.82 tracking_volume Decay

And the daughters both have the proper displacement...

*********************************************************************************************************
* G4Track Information:   Particle = e-,   Track ID = 3,   Parent ID = 1
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0   0.0658    -0.25     7.82       371        0        0         0 tracking_volume initStep
    1     98.3    -27.4 1.32e+03       371 2.42e-23 1.31e+03  1.31e+03 world_volume Transportation
    2      187    -51.9  2.5e+03       371 2.18e-23 1.19e+03   2.5e+03  OutOfWorld Transportation

*********************************************************************************************************
* G4Track Information:   Particle = e+,   Track ID = 4,   Parent ID = 1
*********************************************************************************************************

Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
    0   0.0658    -0.25     7.82       355        0        0         0 tracking_volume initStep
    1    -80.1    -57.5 1.32e+03       355 2.41e-23 1.31e+03  1.31e+03 world_volume Transportation
    2     -152     -109  2.5e+03       355 2.17e-23 1.19e+03   2.5e+03  OutOfWorld Transportation

This is something we dealt with in ILC studies, and there is an extension in SLIC that is activated which will read additional particle definitions, but you have to provide this supplemental table on the command line for it to work.

I'm not sure how to solve this properly in all generality, as each StdHep record can potentially define a different mass and charge for some unknown PDG ID.  But Geant4 (from what I know) needs to have a fixed G4ParticleDefinition before event processing starts.

Hope that helps somewhat.

--Jeremy


-----Original Message-----
From: Bradley T Yale [mailto:[log in to unmask]]
Sent: Friday, January 08, 2016 11:16 AM
To: McCormick, Jeremy I.; Omar Moreno
Cc: Graham, Mathew Thomas; Uemura, Sho; Nathan Baltzell; hps-software
Subject: Re: Pass4 MC

The A' samples are finished, but the daughters which are supposed to have displaced vertices still do not appear to:

~/hps_soft/lcio/trunk/bin/dumpevent /cache/mss/hallb/hps/production/pass4/slic/ap/1pt05/50/apsignalv2_displaced_HPS-EngRun2015-Nominal-v4-4-fieldmap_4.slcio 5000





The ct was set to be 1 mm, so applying the boost to the A' in the above example should have given (E/m)*ct = (0.931/0.05)*1 mm = 18.62 mm for the daughters.





As usual, they appear to still be correctly displaced in both vertex and creation time at the stdhep level.


See the attached plots, where only the daughter electrons are shown.




Representative stdhep file:


/work/hallb/hps/mc_production/lhe/ap/1pt05/50/apsignalv2_displaced_4.stdhep




Could there still be a problem with the stdhep file that makes SLIC unable to handle this properly?



________________________________

From: [log in to unmask] <[log in to unmask]> on behalf of Bradley T Yale <[log in to unmask]>
Sent: Thursday, January 7, 2016 2:27 AM
To: Omar Moreno
Cc: Mathew Thomas Graham; Uemura, Sho; Nathan Baltzell; [log in to unmask]
Subject: Re: Pass4 MC

A' samples are in progress.
These are being made using the version of 'lhe_tridents' that displaces the creation time of the daughters as well as the vertex.


Also, I'm making two different versions in this batch: one which decays at the target, and one that is supposed to have ct=1 mm (before the boost).


________________________________

From: [log in to unmask] <[log in to unmask]> on behalf of Omar Moreno <[log in to unmask]>
Sent: Wednesday, January 6, 2016 5:05 PM
To: Bradley T Yale
Cc: Omar Moreno; Mathew Thomas Graham; Uemura, Sho; Nathan Baltzell; [log in to unmask]
Subject: Re: Pass4 MC

Are there pure A' samples as well?


On Wed, Jan 6, 2016 at 1:26 PM, Bradley T Yale <[log in to unmask]> wrote:


        Cc'ing the software list...



        Samples of everything are here:

        /mss/hallb/hps/production/pass4/





        which used the same jar as pass4 data (hps-distribution-3.5-20151218.205540-15-bin.jar)




        Everything was made with dst_maker v0.10, and there are also some tritrig made with v0.9 for comparison, labeled 'OLDDST'.


        Let me know if you need anything else. I'll be traveling tomorrow, so will try to submit things tonight.


        Brad




________________________________

        From: [log in to unmask] <[log in to unmask]> on behalf of Omar Moreno <[log in to unmask]>
        Sent: Wednesday, January 6, 2016 4:05 PM
        To: Bradley T Yale; Mathew Thomas Graham; Uemura, Sho; Nathan Baltzell
        Subject: Pass4 MC

        Hi Bradley,


        Are you planning to run pass 4 MC? Both the recon output and DST structure have changed so we will need pass4 MC files soon.


        Thanks,


        --Omar Moreno




________________________________

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