Hey,
I finally was able to get my "fake" hit code to work for HelicalTrackHits. It took a lot of sweat and tears and made me go through the entire tracking code pretty much :(
Especially for Norman who might not be updated on this work (and has his name on some of the relevant classes mentioned below): I have written some code that allows us to generate a helix, trace it through the detector and add hits at any given point, in particular at the points where the helix and sensor plane intercept. What I'm talking about below is the generation of "fake" HelicalTrackHits. I also have code to generate strip hits but that has some unsolved problems I need to get back to. Omar has offered to implement a version that created SimTrackerHits. All this is to be able to debug and verify that our software chain is working as expected. It might come in handy for the Kalman fitter once that is up and running!?
Anyway, the last of the many issues I had was the fact that the circle fitter has the opposite sign convention for d0 which I didn't realize at first. The way I spotted that was actually that the line fitter sometimes gave a chi2 contribution of order 10. Going through some specific examples where that happened and actually fit a straight line myself in manually I realized that it wasn't that the hits where at the wrong place it was the path length calculation which differed slightly. I checked the circle fit part of the track parameters was identical and so I knew that they should be the same. The difference was of the order of a few microns in path length which sounds ridiculous but I assign a 1nm error on the hits so anything is important which is the reason I do this in the end :)
Anyway, when I compared the methods used to calculate the path lengths in the code there are a few variations, and these are all in "org.lcsim.fit.helicaltrack.HelixUtils.java":
1. In the lcsim HelicalTrackFitter where the actual fit is done we use : public static double PathLength(CircleFit cfit, HelicalTrackHit hit)
2. In general in hps-java we typically use: public static List<Double> PathToXPlane(HelicalTrackFit helix, double x,double smax, int mxint)
Internally both of them compute a couple of helix parameters and then call the *same* function to calculate the path length via:
private static double PathCalc(double xc, double yc, double RC, double x1, double y1, double x2, double y2)
This is all good. However, the d0 convention of the circle fit doesn't seem to be reflected in the formulas in the lcsim HelixUtils? If you look at line 564-570:
-------
private static double xc(CircleFit cfit) {
return cfit.xref() + (RC(cfit) - cfit.dca()) * Math.sin(cfit.phi());
}
private static double yc(CircleFit cfit) {
return cfit.yref() - (RC(cfit) - cfit.dca()) * Math.cos(cfit.phi());
}
-------
you can see that this has the same definition as the "normal L3" sign convention.
I think this can be a problem as all the path lengths that are saved with the HelicalTrackFit (in the member Map "_smap") is done using the circle fitter at the point of the fit (in the HelicalTrackFitter) and is never changed as far as I understand. So this means that if one uses the HelicalTrackFit.PathMap() function the path lengths are calculated with the wrong sign for DCA. I think.
Note that the sign of d0 is flipped only when the HelicalTrackFit is saved from the combination of the circle fit and straight line fit, but again, the path length maps are not updated as far as I can tell.
I implemented a new method in the lcsim HelixUtils that turns the circle fit into a HelicalTrackFit with the correct d0 sign convention and I then I get perfect agreement for the generated and fitted result, not only in track parameters but the residuals look as expected.
This is not exciting stuff but I'd be good if someone can sit down (with me) and help me verify what I'm saying above at some point.
/Pelle
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
