Evaluation of MF during tracking

The initial worry was that we evaluate it too often for any given rec-hit. However, as parametrized version of the field is used the overall performance hit isn't too bad -- all MF evaluations take ~3.5% of total running time of all CkfTrackCandidateMaker module instances. CkfTrackCandidateMaker instances make about the same number of MF evaluations per event as TrackProducer instances but they evaluate the same point much more often so gain from clearing this up would be more pronounced there.

• Probability distribution of a MF being evaluated only once on exactly the same 3D point during a single module execution for all CkfTrackCandidateMaker and TrackProducer instances. This is on 1000 ttbar events, each instances of the algorithm makes a separate histogram entry.
  single_use_TCMvsTP.png:
  
  1 - x is the probability of a 3D point to be evaluated more than once ... so this looks pretty bad for CkfTrackCandidateMaker.

• Two further questions: a) How is this distributed over various instances of the algorithm? b) How many points are evaulated two / three / four times (and more)? This is shown on this set of plots, seq is the module number and hit_count[N] gives the number of points on which MF was evaluated N times. Some points are evaluated more than 10 times (but very few). Already at 4 evaluations we get to about 1% of points.
  use_1-4_TCM.png:
  

• Next, I wanted to see what happens if the exact equality for points is relaxed to 5 microns or 25 microns. There is some change, the point-counts migrate from lower counts to higher ones. I wanted to check if the points get evaluated at slightly different locations due to cluster splitting or a different trajectory/surface intersection. Here are the plots:
  • 5 microns use_1-4_TCM_5mu.png
  • 25 microns use_1-4_TCM_25mu.png

• I'm not exactly sure what to think about this, what I had in mind was:
  • calculating the MF once for a rec-hit (not trajectory state);
  • storing derivatives together with the field value so it gets cheap to evaluate it at a nearby location -- this could be done for each detector module (if the field does not change too wildly and we do not need more precision).

Appendix for MF evaluations

Table of modules / labels that evaluate MF

• count_vs_seqid.png: