[Halld-offline] hdgeant modifications

[Beni Zihlmann]

HIi Key,

answer to point 1) in line 439 of gustep.F there is an if statment that 
checks if the newly created
particle is a neutrino. If so it is not put back on JSTACK for save 
keeping till the end of geant and
therefore will not receive a id number and mypid will be zero. That is 
what I mean by making a
secondary particle a primary (so neutrinos are not made primary). The 
neutrinos that are decay
products will however show up in the new vertex  which is saved in line 
472 of gustep.F. But their
myid will be zero.
How why there are some neutrinos that do have myid other than zero but 
still come from a decay
I do not understand. I need some more time to investigate that.

cheers,
Beni

>
> Hi Beni, Paul,
>
> I have been analyzing the new output from bggen and hdgeant,
> and here are my thoughts:
>
> 1. As advertised, eta', phi, omega are decayed in hdgeant, not bggen
>
> 2. All unphysical single quarks, diquarks have myid=0.
>
> 3. I don't find any rho's in bggen output, I find rho's only from
>    phi -> pi0 rho0 and eta' -> gamma rho0 in hdgeant output,
>    and find all rho's in the REST output.
>
> 4. Decay chain of eta' is OK, all particles have correct parentid.
>
> I have the hd_dump output for eta', phi decays at
> http://dustbunny.physics.indiana.edu/~kmoriya/GlueX/2013-09-27-bggen/
>
> Just in case you want them, I have the full hd_dump logs
> also, but they are quite heavy.
>
> Problems:
>
> 1. There are particles, mostly neutrinos where the myids are messed up.
> If you look at EtaPrime.txt or phiMeson.txt in the above link,
> you will find particles with XXX at the end of the line.
> These particles have a myid that is less than the myid of previous
> entries. This does not mean that they are wrong, but for most neutrino
> cases you will see that there is a problem.
>
> For example in phiMeson.txt, if you look at event 1082,
> a mu+ neutrino pair are created, but the neutrino has myid 0.
>
> Event 1552 is another case, where a mu+ neutrino pair are created
> from parentid 281 (does not exist), and the mu+ (myid 327)
> decays to e+ nu nu, with the 2 nu's having strange myids.
>
> Out of 50k events, there were more than 15k neutrinos that had
> myid 0, but 34k that had myid not 0. Maybe you guys know what
> the distinction is (maybe if 2 neutrinos are produced in a mu
> decay, only one is tagged with the correct myid? for charged pi
> to mu nu, the nu is never tagged correctly?)
>
> 2. The attached plots are created by analyzing Paul's Thrown_Tree.
> I take the particles with Thrown__ParentID[i]==-1, and
> add the 4-momenta. The file p4_bggen.pdf is when I run
> the plugin on the bggen output, p4_REST.pdf is when I run
> on the REST output. The situation is much better than before,
> but there are still events that are not reconstructing the
> generated information correctly, presumably because of 1. above.
>
> Notice also that there is a humongous spike at pz = 0 for
> the REST output.
>
> There are also some events with total pz between 0 and 7 GeV.
> This seems like most of the generated particles are missing.
> The attached file lowPz.txt shows the event numbers for
> events with 0 < pz < 7 (75 events) if you are interested in
> looking at what they are.
>
> Any input is very welcome.
>
>     Kei
>
> On 9/26/13 1:15 PM, Beni Zihlmann wrote:
>> Hi Kei,
>>
>> I committed a few changes to hdgeant and bggen. Now I hope the relation
>> between parent
>> and daugther particles is more or less restored. The initial thrown
>> particles have an myid
>> number which is the track number of the particle and parentid is zero.
>> All intermittent
>> particles from bggen have myid number zero and parentid zero. If
>> parentid is not zero
>> than that number is the track id number of the parent which is myid.
>> However if you
>> can not find a parent particle with that myid that means the parent
>> particle was
>> generated inside the calorimeters. You will find that rather often you
>> see two photons
>> being associated with a parent particle that does not show up in the
>> list. That means
>> the parent pizero was generated inside the calo or just at the edge but
>> the decay
>> vertex is outside. I think this is an edge effect were in gustep the
>> particles being saved
>> into an new vertex is slightly different than particles being made
>> primary. I will check
>> on that. The upshut is at the moment that you will find some particles
>> that you can
>> not associate with a parent.
>>
>> cheers,
>> Beni
>>
>>
>>