[Halld-offline] Fwd: r8088 - trunk/sim-recon/src/libraries/PID

[Paul Mattione]

I found a small bug that was still causing non-deterministic  
behavior.  Basically, for ~1% of the events the figure-of-merit of at  
least one of the DTrackTimeBased objects was calculated incorrectly  
(see below for more details).  Using hd_dump to print the objects from  
all factories and diff to compare the results, I don't see any more  
non-deterministic behavior.

However, there are other locations where DistToRT is used and there  
are no checks for NaN, so those still need to be looked into.  I'm not  
entirely convinced that the function should be returning NaN (see  
below for more details), but I don't really understand the intricacies  
of the track swimming routines.

  - Paul

Begin forwarded message:

From: Hall-D.SVN.Repository at jlab.org
Date: July 20, 2011 3:13:23 PM EDT
To: davidl at jlab.org, brash at pcs.cnu.edu, wolin at jlab.org,  
zisis at uregina.ca, mashephe at indiana.edu, remitche at indiana.edu, zihlmann at jlab.org 
, somov at jlab.org, staylor at jlab.org, kmoriya at indiana.edu, pmatt at jlab.org
Subject: r8088 - trunk/sim-recon/src/libraries/PID

Author: pmatt
Date: 2011-07-20 15:13:22 -0400 (Wed, 20 Jul 2011)
New Revision: 8088

Modified:
   trunk/sim-recon/src/libraries/PID/DParticleID.cc
Log:
Added checks for NaN on the DReferenceTrajectory::DistToRT call in  
DParticleID::GetdEdx.  Without these checks, the figure-of-merit of  
the DTrackTimeBased objects is sometimes (non-deterministically)  
calculated incorrectly.  This is because the point on the trajectory  
for the given DCDCTrackHit is then calculated (in  
DReferenceTrajectory::GetLastDOCAPoint) using the swim-step from the  
previous DCDCTrackHit because it was never updated by the DistToRT  
function.

The DistToRT function returns NaN because the first swim-step on the  
reference trajectory is the closest to the wire hit.  I don't know  
what the cause of this is, and whether or not it's a bad thing, but  
the function returns NaN nonetheless.

This process was non-deterministic because the vector of DCDCTrackHit  
objects grabbed in GetdEdx are in random order.  They are in random  
order because they are associated objects, and are stored in a map  
with their pointer address as the key.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20110720/504e0a26/attachment-0002.html>