StraightLineTrack::getState(detectorID) returned the state at z=0, not the state at the z-pos of the detector for which it was requested. In contradiction to the documentation in the header file, where it's written that this functions returns the "XYZPoint state at detector layer".
This is in contrast to
GblTracks::getState, which does return the state at the detector z-postion.
The intention behind this merge request is to adapt the same behaviour for StraightLineTrack.
As far as I can tell, this also makes all the position/direction calculations in
PixelDetector::getIntercept(const Track* track) unnecessary - or am I overlooking something here - line some global/local conversion issue when the plane origin is not at x=0,y=0?
Two more questions that came up while I looked into changing this:
- GblTrack and Multiplet only return a position for GetState if the track is fitted and has a fitted track point at the detector plane you ask for. Is this behaviour also desired for StraightLineTrack ? I've just implemented it like that for now.
But then the tests fail. E.g.
|10:09:44.963| (FATAL) [R:Tracking4D] Fatal internal error Track Object StraightLineTrack does not have any entry for detector W0013_E03 Cannot continue...
- At some point @simonspa commented that maybe it would be nicer if
getStatewasn't a public method, but rather
getIntercept()should be used by other classes, Thoughts on that? (currently getState is used by PixelDetector.cpp, AlignmentMillepede.cpp, AnalysisDUT.cpp and AnalysisTracks.cpp) One difference in replacing those would be that in the current implementation, getIntercept() will always return something, and as stated above
getStaterequires the track to have an entry for the detector for which you are calling it; so that "check" would get lost.
Bonus question: I stumbled across a "fixme" in
"cluster->global.z() is only an approximation for the plane intersect. Can be fixed after !115 (merged)". That merge request has been merged 2 years ago, so I guess now would be a nice time to fix the fixme :-)
But I had a look at it and couldn't figure out quite how the changes in !115 (merged) impact this function (or is it rather the other way around?).