[Halld-offline] Clarification of "primary"

[Beni Zihlmann]

Hi All,
see the last slide in https://halldweb1.jlab.org/talks/2010-11/gluex_MC.pdf
of your November 2nd meeting last year. I apologize if I  did not make 
myself
clear enough about the consequences at the time. Rather then commenting
out the line iflgk(i) = 1 one could disable it only for calorimeter 
volumes which
was my original idea because of the following:
It is necessary to put secondary particles back on the stack if we want 
to retain
their information properly for later identification. I needed to do this 
to be able
to identify a given hit in the tracking chambers with a given true 
particle track.
In the case of the calorimeters this does not make sense of course regarding
the many many particles in a shower. At the time I thought it might be a 
good
idea to at least keep particles from nuclear reactions because we were 
pondering
about the issue of too many reconstructed photon clusters due to 
hadronic reactions
in the calorimeters that can result in more than one cluster center for 
a given particle.
However I never got around to actually use this feature to investigate 
this particular problem.


cheers,
Beni

> Matt and all,
>
>   1.
>       My previous understanding was that there is one DBCALTruthShower for every photon that entered the BCAL detector volume.  Only photons originating from the primary vertex were tagged "primary."  This is done in hitBCAL by checking that stack == 0 .  (I have no idea what that means.)  . . .    My experience about the previous behavior is based off of work done several years ago -- has the mechanism for tagging primary photons changed recently?  I have a hard time tracking the code backward once I get to hitBcal.c.
>
> That was my design.  However when I went in to remind myself how it 
> works, I discovered that it no longer does! I have traced the problems 
> back to two changes checked in by Beni a few months back.  At least we 
> have the svn record to look to!  The changes are documented as 
> follows.  In an ideal world, I would scrutinize every change that 
> people check into core routines (like gustep), but this one got by 
> me.  Unless someone flags me on a change, I tend to assume that they 
> know what they are doing.
>
>     ------------------------------------------------------------------------
>     r6860 | zihlmann | 2010-10-30 17:06:02 -0400 (Sat, 30 Oct 2010) |
>     4 lines
>
>     modify slightly when to declare secondaries primaries to get
>     independent track number. When in calorimeter volume only make
>     primaries if the secondaries were generated in HADR reaction.
>
>     ------------------------------------------------------------------------
>     r6849 | zihlmann | 2010-10-29 08:39:15 -0400 (Fri, 29 Oct 2010) |
>     8 lines
>
>     add line
>     iflgk(i) = 1
>     before the call to gsking(i) to give each secondary particle
>     a unique tracking number. basically making it a primary particle.
>     In this way hits in the detector can be unambiguously identified
>     to which particle track it belongs.
>
> To test if this was the culprit, I commented out these changes, and 
> the geant3 stacking logic started working properly again.  What would 
> work best in a case like this would be, if someone has a new feature 
> they would like to introduce, ask me how it can be introduced without 
> breaking what already exists.  The problem you and Irena have run into 
> is a case of someone adding a feature that broke prior existing 
> functionality in a bad way.
>
> Thank you for catching this one.
>
> -Richard J.
>
>
>
>
>
>
>
> On 3/27/2011 1:55 PM, Matthew Shepherd wrote:
>> Hi Richard,
>>
>> I'm trying to study the properties of a new BCAL reconstruction routine and I'm questioning my understanding the properties of the truth showers.  (This also relates to a question that Irina asked me.)
>>
>> My previous understanding was that there is one DBCALTruthShower for every photon that entered the BCAL detector volume.  Only photons originating from the primary vertex were tagged "primary."  This is done in hitBCAL by checking that stack == 0 .  (I have no idea what that means.)
>>
>> This would mean that if I wanted to select single photon events where I didn't have a conversion I could require that the number of true showers be 1 (and it should be primary).
>>
>> When I generate photons with a particle gun uniform in energy from 0 - 2 GeV and uniform in z down the BCAL, I see much fewer single, primary, true shower events than expected.  If I plot the energy distribution for primary true showers it is also not uniform but strongly peaked at low energies.  It seems that more than the original particle gun photon are being as primary.
>>
>> My experience about the previous behavior is based off of work done several years ago -- has the mechanism for tagging primary photons changed recently?  I have a hard time tracking the code backward once I get to hitBcal.c.
>>
>> Thanks,
>>
>> Matt
>>
>>
>
>
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/halld-offline/attachments/20110329/95b3e39e/attachment-0001.html