Bug #1849
NaN in tracker recon
100%
Description
Following some emailage... I am getting a NaN during the energy loss calculation in
HelicalPropagator::_calculateBasePropagator
Almost certainly (I haven't quite checked) this arises at the line
momentum = sqrt(energy*energy - _muon_mass_sq);
where we are getting sqrt of a negative number.
So a few issues here:
(a) Well, we should throw an exception instead of trying to find sqrt of negative number
(b) The automagic "turn off helical tracks" is broken. I see in src/map/MapCppTrackerRecon.cc:
else if (user_up_helical_pr_on == 0 && fabs(up_field) < 0.00001) // 10 Gaus
well, this is not correct - 10 Gauss is far too small a tolerance. We know tracker helical fit/pz recon does not work with field below 2 T, so this tolerance should be much more generous, more like 0.1-1 T. A feature of my reconstruction job is that I have FC switched on but nothing else. Probably the fringe field from the FC is causing the automagic to fail.
Related issues
Updated by Hunt, Christopher over 7 years ago
Thanks for nailing down the cause of that one, I hadn't had time to find it properly.
I'll put some exception handling around it for the next release.
I disagree with the "automagic" function though. I think its correct in that the tracker can reconstruct fine in less than 1T - as long as it is uniform. The predominant effect is that the momentum acceptance is appalling. I chose 10 gaus as that was (I believe) around the level where a distinct field become inseparable from background fields.
If you are using a geometry where you know there is a fringe field, above background, in the tracker you should use the following flags to control which types of track are reconstructed.
SciFiPRHelicalTkUSOn = 0 # TkUS helical pattern recognition: 0 = auto, 1 = off, 2 = on SciFiPRHelicalTkDSOn = 0 # TkDS helical pattern recognition: 0 = auto, 1 = off, 2 = on SciFiPRStraightTkUSOn = 0 # TkUS straight pattern recognition: 0 = auto, 1 = off, 2 = on SciFiPRStraightTkDSOn = 0 # TDUS straight pattern recognition: 0 = auto, 1 = off, 2 = on
If you think there is a nicer implementation please let me know - not many people have come accross this yet.
Updated by Rogers, Chris over 7 years ago
Great. Hmm, not quite sure how to proceed on the Bz cutoff point. I guess the argument is that there is a sliding scale whereby pz resolution is worse but pt resolution is better than simply assuming straight tracks. Not sure how that works out.
Updated by Hunt, Christopher over 7 years ago
Yeh its not a nice grey area. Adam and I focussed on have the baseline geometries work without a hitch, which is how we ended up here.
We could put a cut off on the variance of the field. The tracker uses only the mean field inside the tracking volume for the fit, but it records the variance and range just in case. I haven't performed a full field stability verses reconstruction study, but we could do something simple to guess at what point the helical fit becomes pointless, and use that instead of a mean field value.
Updated by Dobbs, Adam over 7 years ago
Tricky. About 1T would be my guess for an initial value of cut off, but it a study would be best...
Updated by Dobbs, Adam over 6 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Should be fixed in 2.9.0.