<html>
<head>
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Paul,<br>
<br>
Ah, now I am beginning to remember. I added this comment #if 0
... #endif because the code that was there was not able to do what
it was advertised as doing. It was not that it was causing
problems that broke other code. Here is what it does, at present.<br>
<ul>
<li>setting iflgk(i)=1 tells gsking() to keep a permanent record
of the birth of the new secondary, which is part of what you
want to do, so far so good...</li>
<li>however, it does not keep track of the identity of the
parent track. That information is lost. It seems that Beni
thought that the JKINE structure element IPART was saving the
id of the parent track. However IPART is the geant particle
type of the parent, 3 for electrons, 7 for a pi0, 14 for
protons, and so on. As I understand it, what you want is to
save a serial number for each particle in the event, and to
have each secondary remember the serial number of the parent
that created it. Having the particle type of parent particle
is helpful, but not definitive, especially since the parent
may itself be a secondary and not one of the original
particles in the event. As it is, you have no way of knowing
that.<br>
</li>
</ul>
<p>If I am on the wrong track, stop reading here and let me know.
If having unique particle identifiers is what you want, please
read on.<br>
</p>
<ul>
<li>to accomplish what you want to do you need to uncomment the
section I commented out with #if 0 ... #endif. This you have
already done in your working code, I guess.</li>
<li>inside the loop over the secondaries in which iflgk(i) is
set to 1 or 0, as the case may be, you see the call to
gsking(i) where the new secondary is registered in the JSTAK
and selectively in the JKINE/JVERT stacks. Right now this is
where the loop ends.</li>
<li>after the call to gsking(i), you need to check the value of
iflgk(i). If you set it to 0 earlier, it will stay 0, but if
you set it to 1, it will return with a new id for the new
secondary. It will be a number larger than the number of
particles seen so far in the event, so that each particle gets
its own id. Now you want the new particle to remember the id
of its parent, so you need to write the value of ITRAK (the id
of the particle you are currently tracking) into the data
structure for the new secondary.<br>
</li>
<li>Here is a snippet of code to add right after the call to
gsking:</li>
<ul>
<ul>
<ul>
<ul>
<li>nt = iflgk(i)</li>
<li>if (nt.gt.0) then</li>
<ul>
<li>ubuf = itrak</li>
<li>nubuf = 1</li>
</ul>
<ul>
<li>iadr = 0</li>
<li>call gskinu(nt,nubuf,ubuf,iadr)</li>
</ul>
<li>endif</li>
</ul>
</ul>
</ul>
</ul>
</ul>
<p>This will store the track index ITRAK of the parent track as a
user word attached to the new secondary in the JKINE stack for
retrieval later. Later when you are writing out the event
summary information you need to call GFKINE for each track in
the JKINE structure. The parent index for each track will be
returned in the ubuf. The type of ubuf is real, so you are
saving an integer index in a real variable, but that is ok for
small integers of this kind. <br>
</p>
-Richard Jones<br>
<br>
<br>
<br>
<br>
On 12/2/2012 10:29 PM, Paul Mattione wrote:<br>
</div>
<blockquote cite="mid:4F6DB850-7218-49CE-B151-DA3839EE4C87@jlab.org" type="cite">
<pre wrap="">OK. Well, in the output (i.e. DMCThrown) we need to know what each particle directly decayed from. How would we go about restoring that information? I am (obviously) not very familiar with the intricacies of hdgeant code...
- Paul
On Dec 2, 2012, at 9:31 PM, Richard Jones wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Paul,
Yes, I remember now. The code that I commented how was trying to accomplish what you want to do by setting the flag IFLGK(i) to zero. The geant tracking uses this flag to tell where the particle came from in the internal stacks, whether from the primary track list JTRAK or the secondaries stack JSTAK. This is an important piece of information that travels with the track, downstream in the code. It is needed when we need to look back at the ancestry of the track later in the code. The change broke that logic in my saveoutputs stage.
The IFLGK flag is defined in the geant documentation and has a useful and well-understood meaning. Please don't make it mean something else. If you need new functionality, then it should be added without breaking core behavior in the package.
-Richard J.
On 11/30/2012 12:24 PM, Paul Mattione wrote:
</pre>
<blockquote type="cite">
<pre wrap="">It looks like revision 9349, ~142 days ago.
<a href="http://clasweb.jlab.org/websvn/prod/log.php?repname=GlueX&path=%2Ftrunk%2Fsim-recon%2Fsrc%2Fprograms%2FSimulation%2FHDGeant%2Fgustep.F&rev=0&sc=0&isdir=0">http://clasweb.jlab.org/websvn/prod/log.php?repname=GlueX&path=%2Ftrunk%2Fsim-recon%2Fsrc%2Fprograms%2FSimulation%2FHDGeant%2Fgustep.F&rev=0&sc=0&isdir=0</a>
- Paul
On Nov 30, 2012, at 11:55 AM, Richard Jones wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Paul,
I don't remember exactly. Can you go back through the logs and find the place where I put it in? That would also be a time marker where I can look back in the email record for the discussion that surrounded it.
-Richard J.
On 11/28/2012 10:28 PM, Paul Mattione wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Well, I checked it into the trunk over a month ago, I just put it in the branch when I noticed it was missing. I didn't realize that this was causing a problem though.
The reason I need it is for determining what the actual final state particles are. For example, if bggen generates a phi meson which decays to kaons, and the kaons decay to pions, and the pions to muons, then with that code commented out it looks like all of those particles decayed directly from the phi meson. This makes sorting out the generated final state track topology for each event a huge mess. But knowing this topology is really important for these PID studies.
Is there another way we can fix the problem this was causing? What was the problem exactly?
- Paul
On Nov 28, 2012, at 6:45 PM, Richard Jones wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Paul,
I put that in there to fix a more serious problem than the one you are correcting. Doing something like this right at the end before a major production might not be the best time.
-Richard J.
On 11/28/2012 3:37 PM, <a href="mailto:Hall-D.SVN.Repository@jlab.org">Hall-D.SVN.Repository@jlab.org</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Author: pmatt
Date: 2012-11-28 15:37:19 -0500 (Wed, 28 Nov 2012)
New Revision: 10036
Modified:
branches/sim-recon-dc-1.1/src/programs/Simulation/HDGeant/gustep.F
Log:
Removed "#if 0" and associated "#endif" which prevented the program from properly matching tertiary (or higher) particles to their parents.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>