<html>
<head>
</head>
<body text="#000000" bgcolor="#ffffff">
Matt and all,<br>
<br>
<ol>
<li>
<pre wrap="">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.
</pre>
</li>
</ol>
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.<br>
<br>
<blockquote><small>------------------------------------------------------------------------<br>
r6860 | zihlmann | 2010-10-30 17:06:02 -0400 (Sat, 30 Oct 2010)
| 4 lines<br>
<br>
modify slightly when to declare secondaries primaries to get<br>
independent track number. When in calorimeter volume only make<br>
primaries if the secondaries were generated in HADR reaction.<br>
<br>
------------------------------------------------------------------------<br>
r6849 | zihlmann | 2010-10-29 08:39:15 -0400 (Fri, 29 Oct 2010)
| 8 lines<br>
<br>
add line<br>
iflgk(i) = 1<br>
before the call to gsking(i) to give each secondary particle<br>
a unique tracking number. basically making it a primary
particle.<br>
In this way hits in the detector can be unambiguously identified<br>
to which particle track it belongs.<br>
</small></blockquote>
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.<br>
<br>
Thank you for catching this one.<br>
<br>
-Richard J.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 3/27/2011 1:55 PM, Matthew Shepherd wrote:
<blockquote type="cite" cite="mid:CC84377C-3A45-4736-943C-CDD6CEDF3D48@indiana.edu">
<pre wrap="">
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
</pre>
</blockquote>
<br>
</body>
</html>