[Halld-offline] Clarification of "primary"

[Matthew Shepherd]

Hi Beni,

It seems desirable to restore the data contained in the field "primary" to mean:  is this the primary particle?  Is there a way to do this easily?  As it is now, I believe the data structure is a little misleading.

When you say "track" can you clarify whether this is charged or neutral?  I'm generating single photon events, so every event has zero tracks (at least by my definition of "track").

Thanks!

Matt


On Mar 29, 2011, at 10:07 AM, Beni Zihlmann wrote:

> Hi Matt,
> in order to identify if the DBCALTruthShower came from an originally primary particle you can check the 
> value of the track number "DBCALTruthShower.track". If that number is larger then the number of initially
> generated tracks,which you can get from DMCThrown.size(), then this track is a secondary particle.
> Note the counting of tracks in geant starts at 1.
> 
> cheers,
> Beni
>> Matt and all,
>> 
>> 	•
>> 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
> 
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline