Updates tracks

[siilieva]

• some cosmetics for tracks in the 2d event display
• update track direction method in the sndRecoTrack class
• update storage of measurement times, now per channel, for sndRecoTrack objects
• setting of geofile and detector objects initialization via EventHeader when running with the HT tracking manager (shipLHC/run_muonRecoSND.py)

[ThomasRuf]

Maybe I am overlooking something. Do we talk about track persistency WITHOUT normally saving all the digitized data? But also in this case, one can easily go back to the associated raw event for a an event with a persistent track. My preferred solution would be to get the times by knowing the hits with contributed to the measurement. Any duplication of the raw data will run the risk to get out of date. But, as I said, if you want to go along this path, I can merge your pull request.

[siilieva]

Maybe I am overlooking something. Do we talk about track persistency WITHOUT normally saving all the digitized data? But also in this case, one can easily go back to the associated raw event for a an event with a persistent track. My preferred solution would be to get the times by knowing the hits with contributed to the measurement. Any duplication of the raw data will run the risk to get out of date. But, as I said, if you want to go along this path, I can merge your pull request.

The raw digi hits are saved to output as well, in the usual DigiHit object, but those are all hits in an event. The snd track object keeps the detIDs and raw time(s) per track point. Saving the raw hit times per point allows implementing track direction method directly in the class, not your preferred way. I find this way faster.

Any duplication of the raw data will run the risk to get out of date.

How does raw data get out of date? If somehow there is an issue with raw hits, the whole tracking should be re-done and the track object will re-populate with the new data items. For example, after an iteration of detector alignment, tracking has to be re-run.