[Halld-offline] trying to remember why it was there, but just deleting it is not the answer....

[Richard Jones]

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:
> It looks like revision 9349, ~142 days ago.
>
> 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
>
>   - Paul
>
> On Nov 30, 2012, at 11:55 AM, Richard Jones wrote:
>
>> 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:
>>> 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:
>>>
>>>> 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, Hall-D.SVN.Repository at jlab.org wrote:
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3232 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20121202/63588158/attachment.p7s>