Major upgrade of TofEstimators with new track length calculation and bug fixes

[dudarboh]

BEGINRELEASENOTES

• Major upgrade of TOFEstimators with bug fixes and updates that are not backward compatible
  • Track length calculation is significantly improved by refitting the track and iterating over the track states on each tracker hit
  • Fixed bugs with phi coordinate flip and wrong abs() instead of std::abs()
  • Output in the PIDHandler is changed to the minimal set of required three parameters for the PID (momentum, track length, TOF)
  • Input steering parameters adjusted
  • Removed TOFPlots processor. General clean up of the files and the code
  • Detailed documentation is added

ENDRELEASENOTES

Additional notes

Removed TOFPlots processor which was producing ROOT file with TOF related histograms.
In the near future, higher quality histograms should be produced by the newer dEdxAndToFAnalyzer processor

Removed all files which seemed like personal analysis scripts unrelated to the processor's main purpose

Performance

~ x13 times slower than version used for the IDR production

Check list

• Update / cleanup TOFEstimator code

• Optimize / check for mem. leaks

• Write documentation

[dudarboh]

I fixed memory leak by deleting marlinTrk
But is this nice, as I don't allocate it myself with new. Isn't is a good practice to delete it in the same code where it is allocated.
I assume it is something not easy to do in this context without breaking a lot of things

[tmadlener]

~ x13 times slower than version used for the IDR production

Is this still here, or has this been resolved by fixing the memory leak?

[dudarboh]

@tmadlener

~ x13 time slow compared to IDR is there.
Mem. leaks are fixed now and they didn't affect much avg. time per event.

I think this is something expected, no? As in the IDR, there was one simple formula using only track information.
And now we go deeper to the hit level and refitting the tracks. So it must take more time. I just decided to note it quantitatively.

[tmadlener]

That makes sense. Thanks for the clarification.

[airqui]

That makes sense. Thanks for the clarification.

Hi, I think that this also motivates to consider the possibility to include this information (track length, etc) in the reconstructed MarlinTrks produced during the "standard" reconstruction. However, I believe that this is a topic for the future.

[tmadlener]

I have a few smaller comments / questions inline.

Regarding the questions on how to better handle things in getSubTrack, I have no clear better solution either. From the overall looks of it, it seems like the goal is to collect all hits from a track and then get all TrackStates associated to these hits. However, it looks like the different subtracks are still necessary for the fitting that is done in getTrackStatesPerHit. I assume this is due to the presence of curlers and the fit not being able to handle that(?).

[dudarboh]

Hi @tmadlener,

I made some optimization/style corrections as you proposed.
I wrote some more comments on your comments, please see inline and mark resolved what is resolved...

[dudarboh]

Here are some final test plots that show that distributions look reasonable (but not identical) compared to the previous default TOFEstimators version.

I also checked non-default methods with different smearings, to see if everything looks as expected and it does:

[tmadlener]

Thanks a lot for this. To me this looks good.

Pinging @gaede for another set of eyes.