<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi All,<br>
see the last slide in
<a class="moz-txt-link-freetext" href="https://halldweb1.jlab.org/talks/2010-11/gluex_MC.pdf">https://halldweb1.jlab.org/talks/2010-11/gluex_MC.pdf</a><br>
of your November 2nd meeting last year. I apologize if I did not
make myself<br>
clear enough about the consequences at the time. Rather then
commenting<br>
out the line <small>iflgk(i) = 1 </small>one could disable it only
for calorimeter volumes which<br>
was my original idea because of the following:<br>
It is necessary to put secondary particles back on the stack if we
want to retain<br>
their information properly for later identification. I needed to do
this to be able<br>
to identify a given hit in the tracking chambers with a given true
particle track.<br>
In the case of the calorimeters this does not make sense of course
regarding<br>
the many many particles in a shower. At the time I thought it might
be a good<br>
idea to at least keep particles from nuclear reactions because we
were pondering<br>
about the issue of too many reconstructed photon clusters due to
hadronic reactions<br>
in the calorimeters that can result in more than one cluster center
for a given particle. <br>
However I never got around to actually use this feature to
investigate this particular problem.<br>
<br>
<br>
cheers,<br>
Beni<br>
<br>
<blockquote cite="mid:4D91A93E.7010201@uconn.edu" type="cite"> 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>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Halld-offline mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Halld-offline@jlab.org">Halld-offline@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-offline">https://mailman.jlab.org/mailman/listinfo/halld-offline</a></pre>
</blockquote>
<br>
</body>
</html>