[Halld-offline] Clarification of "primary"

[Richard Jones]

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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/halld-offline/attachments/20110329/70042de6/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4092 bytes
Desc: S/MIME Cryptographic Signature
Url : https://mailman.jlab.org/pipermail/halld-offline/attachments/20110329/70042de6/attachment.bin