[Halld-offline] r10078 - branches/sim-recon-dc-1.1/src/programs/Simulation/HDGeant

[Paul Mattione]

There are many tracks in DMCThrown with PID = 0 ("Unknown") from pythia data because it generates a lot of "weird" intermediate states that then decay (e.g. diquarks) (you can see this by looking at the pdg id's in DMCThrown).  So maybe choosing 0 wouldn't be a good idea.  

I tested these changes and things appear to working OK at CMU.  I'm re-launching our data challenge here until something else comes up.  

 - Paul

On Dec 4, 2012, at 8:56 AM, Richard Jones wrote:

> David and all,
> 
> I agree, 48 is not the best choice, but it is safe and we are gearing up for a major production.  I was tempted to simply use particle code=0, but was not sure where that might jump up and bite me.  Should be possible, but needs to be tested.  My first choice would be particle number 0, second choice particle number 9999.
> 
> -Richard J.
> 
> On 12/4/2012 7:30 AM, David Lawrence wrote:
>> 
>> Hi Richard,
>> 
>>  I'm wondering if instead of the geantino id (48) we should use an unused
>> particle id (e.g. 99). The reason is that we do sometimes use geantinos when doing
>> radiation length scans as described here:
>> 
>> https://halldweb1.jlab.org/wiki/index.php/HOWTO_do_a_Radiation_Length_Scan
>> 
>> Regards,
>> -David
>> 
>> On 12/4/12 1:39 AM, Hall-D.SVN.Repository at jlab.org wrote:
>>> Author: jonesrt
>>> Date: 2012-12-04 01:39:20 -0500 (Tue, 04 Dec 2012)
>>> New Revision: 10078
>>> 
>>> Modified:
>>> branches/sim-recon-dc-1.1/src/programs/Simulation/HDGeant/gustep.F
>>> branches/sim-recon-dc-1.1/src/programs/Simulation/HDGeant/hddmInput.c
>>> Log:
>>> * hddmInput.c [rtj]
>>>    - when reading events from the bggen generator, the former behavior was to
>>>      ignore any particles listed in the final state that are decayed in place
>>>      by the generator itself.  These are often partonic fragments that Geant
>>>      knows nothing about anyway.  This had the unintended consequence that the
>>>      track number in the JTRAK list that Geant uses to enumerate the primaries
>>>      in an event came out of sync with the "id" fields in the MC record.  The
>>>      new behavior is to copy all final-state particles reported by bggen into
>>>      the JTRAK list, but assign to any unphysical particles a pseudo-particle
>>>      type of "Geantino" (code 48).  A check is made for this particle type in
>>>      gustep (see below) and they are immediately stopped, and never tracked.
>>>      This restores the correspondence between the "id" fields in the MC
>>>      record and the ITRA index into the JTRAK list.  This correspondence is
>>>      assumed in function savenewvertex() which extends the MC record to
>>>      include decay vertices that are simulated during tracking, where the
>>>      ITRA index of the parent track is assigned to the "parentId" field
>>>      of the decay products for displaced vertices.
>>> * gustep.F [rtj]
>>>    - add a check for dummy particle type 48 (Geantino) at the entrance to
>>>      gustep, and stop these particle dead without a trace.
>>> 
>>> 
>>> 
>> 
> 
> 
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline