MantisBT - Hall D Offline
View Issue Details
0000103Hall D OfflineGeneralpublic2011-06-29 11:102011-07-18 09:36
davidl 
pmatt 
normalmajorsometimes
resolvedfixed 
0000103: Reconstructed number of particles non-deterministic
From e-mail by Will Levine on 6/28:
----------------------------------


Hi,
I noticed recently that I've been getting different results when running reconstruction multiple times on the same file. It seems like that for a small number of events, the number of particles reconstructed varies. I think this problem will occur with any input, but I've uploaded one particular hddm file where I've seen the problem (http://www-meg.phys.cmu.edu/wilevine/hdgeant_smeared.hddm [^] ). I think the simplest way to see the problem is to run the reconstruction with the phys_tree plugin twice (i.e.
hd_root -PPLUGINS=phys_tree hdgeant_smeared.hddm -o output.1.root
hd_root -PPLUGINS=phys_tree hdgeant_smeared.hddm -o output.2.root
) and compare the output. In particular, differences should be seen in the Npip, Nphoton, etc. histograms.

For the record I'm using svn revision 7974 and the problem seems to occur in both SIMD and non-SIMD builds.

If anyone can confirm or diagnose this issue, that would be helpful.

Will
Beni reproduced the issue and sent this email:
----------------------------------

Hi Will, David,
I duplicated what you see. I look for each event how many photons are reconstructed. the result is
shown in the two attached files. The diff_sidebyside.dat file shows for each event the number of
reconstructed photons on the left for the first reconstruction on the right for the second reconstruction.
the diff.dat file contains only those event where a difference is found. This should help for further
debuging.
No tags attached.
Issue History
2011-06-29 11:10davidlNew Issue
2011-06-29 14:44pmattStatusnew => assigned
2011-06-29 14:44pmattAssigned To => pmatt
2011-07-18 09:36davidlNote Added: 0000146
2011-07-18 09:36davidlStatusassigned => resolved
2011-07-18 09:36davidlResolutionopen => fixed

Notes
(0000146)
davidl   
2011-07-18 09:36   
This was fixed with revision 8077. The problem was caused by the following:

The DReferenceTrajectory class is used to swim tracks through material and magnetic fields and can then be used to identify points of closest approach to wires, intersections with planes or intersections with cylinders. When matching tracks to showers in the BCAL, this was used. For historical reasons, the DistToRT method is used to calculate the distance, but certain parameters, including the angular extent of the partial step to take to the desired point between recorded points, are stored locally and must be retrieve via GetLastDOCAPoint.

The DistToRT method was overloaded and the particular version used by MatchToBCAL in the DParticleID class was not setting this "last_phi" parameter. The exact value was therefore left to whatever happened to be in the memory location of the DReferenceTrajectory object when it was created.

Two similar methods were used to try and track down this problem:

1.) Use hd_dump to dump ASCII of all objects to a file and then do a diff on the files.
2.) Use the janaroot plugin to put this same info into a ROOT file.

Both methods rely on information obtained through the data object's ToStrings method.