0000103: Reconstructed number of particles non-deterministic - MantisBT

MantisBT

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

ID

Project

Category

View Status

Date Submitted

Last Update

0000103

Hall D Offline

General

public

2011-06-29 11:10

2011-07-18 09:36

Reporter

davidl

Assigned To

pmatt

Priority

normal

Severity

major

Reproducibility

sometimes

Status

resolved

Resolution

fixed

Platform

OS

OS Version

Summary

0000103: Reconstructed number of particles non-deterministic

Description

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

Additional Information

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.

Tags

No tags attached.

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 - 2024 MantisBT Team