<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">QUite a catch! Curtis<br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><div>---------</div><div>Curtis A. Meyer<span class="Apple-tab-span" style="white-space: pre; ">                        </span>MCS Associate Dean for Faculty and Graduate Affairs</div><div>Wean: (412) 268-2745<span class="Apple-tab-span" style="white-space: pre; ">        </span>Professor of Physics</div><div>Doherty: (412) 268-3090<span class="Apple-tab-span" style="white-space: pre; ">        </span>Carnegie Mellon University</div><div>Fax: (412) 681-0648<span class="Apple-tab-span" style="white-space: pre; ">        </span>Pittsburgh, PA 15213</div><div><a href="mailto:curtis.meyer@cmu.edu">curtis.meyer@cmu.edu</a><span class="Apple-tab-span" style="white-space: pre; ">        </span>http://www.curtismeyer.com/</div></div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br><div style=""><div>On Mar 19, 2014, at 10:50 PM, Paul Mattione <<a href="mailto:pmatt@jlab.org">pmatt@jlab.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I've found the source of the inconsistency we've been seeing: it's ultimately due to the fact that the associated-object map JObject::associated uses the object pointer as the key for the map. This means that the objects are stored in the map in a random order (they are stored in the order returned by the less-than-operator, which for pointers uses the (random) memory address). In the long run we may want to consider a modification to this, but for now, whenever you're getting associated objects, you need to be very careful that your results are not dependent on the order of the objects. <br><br>Fortunately, this is normally not the case. However, in DTrackCandidate_factory::MatchMethod4(), when the DFDCPseudo* hits associated with the DTrackCandidate* object are grabbed, their random order is a problem. In this case, there is a sort routine applied to these hits, FDCHitSortByLayerincreasing, which normally removes the randomness. However, when the hits are on the exact same layer and wire, they remain in a random order with respect to each other. There is a similar sort routine for the CDC, which has the same problem. <br><br>These FDC hits are added along with CDC hits to a DHelicalFit object which is used to try to link the hits together and get an improved estimate for the tracking parameters. Inside the fit function, DHelicalFit::FitLineRiemann(), there is another sort routine that sorts the hits by hit-z (DHFProjection_cmp). This still doesn't fix the problem though, since although the FDC hits on the same wire have different x & y, they have the same z. Thus when the linear-regression fit is performed, and the distances between the xy-projections are taken between hits, you get inconsistent results. <br><br>I've checked in modifications to these sort routines so that the results are more deterministic in case of ties (tie-breakers: in DTrackCandidate_factory, sort CDC and FDC hits by energy, and in DHelicalFit, sort by the projection distance from the beamline). All 32 of my single-threaded jobs analyzing this 5k-event file give identical results. This bug did not result from any uninitialized values, memory errors, from reading past the end of an array/vector, etc, and so was very difficult to track down. It hasn't been a fun few weeks, but hopefully most of the bugs have been stamped out now. <br><br> - Paul<br><br><br>_______________________________________________<br>Halld-offline mailing list<br><a href="mailto:Halld-offline@jlab.org">Halld-offline@jlab.org</a><br>https://mailman.jlab.org/mailman/listinfo/halld-offline<br></blockquote></div><br></body></html>