Project

General

Profile

Bug #1849

NaN in tracker recon

Added by Rogers, Chris about 6 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Category:
Tracker
Target version:
-
Start date:
18 May 2016
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

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

Related to MAUS - Bug #1915: Still inf/nan tracks in tracker reconClosedHunt, Christopher23 February 2017

Actions
Related to MAUS - Bug #1862: NaN in tracker recoClosedKyberd, Paul09 August 2016

Actions
#1

Updated by Hunt, Christopher about 6 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.

#2

Updated by Rogers, Chris about 6 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.

#3

Updated by Hunt, Christopher about 6 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.

#4

Updated by Dobbs, Adam about 6 years ago

Tricky. About 1T would be my guess for an initial value of cut off, but it a study would be best...

#5

Updated by Dobbs, Adam about 5 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

Should be fixed in 2.9.0.

Also available in: Atom PDF