MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000103Hall D OfflineGeneralpublic2011-06-29 11:102011-07-18 09:36
Reporterdavidl 
Assigned Topmatt 
PrioritynormalSeveritymajorReproducibilitysometimes
StatusresolvedResolutionfixed 
PlatformOSOS Version
Summary0000103: Reconstructed number of particles non-deterministic
DescriptionFrom 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
Additional InformationBeni 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.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000146)
davidl (administrator)
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.

- Issue History
Date Modified Username Field Change
2011-06-29 11:10 davidl New Issue
2011-06-29 14:44 pmatt Status new => assigned
2011-06-29 14:44 pmatt Assigned To => pmatt
2011-07-18 09:36 davidl Note Added: 0000146
2011-07-18 09:36 davidl Status assigned => resolved
2011-07-18 09:36 davidl Resolution open => fixed


Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker