Recently there was some issues with XYZ tracks reported by @DavidDiezIb , and addressed also in #39.

It is a bit strange for me that in the following code lines

Indeed, this is likely producing XYZ observables out of XZ and YZ hits. However, the pure XYZ hits might require dedicated attention. Also, the TrackAnalysis process is becoming too wide.

I think we should favor smaller and more atomic processes that target a reduced problem.

We could for instance have TRestTrack3DAnalysisProcess that will target only pure XYZ tracks produced with pixel readouts or pure MC simulation output. This process would serve only for those events that contain pure XYZ tracks, so there should be some error output in case we find other track types inside the input event.

Also, we may think to split into TRestTrackBasicAnalysisProcess and TRestTrack2DAnalysisProcess, etc.

I think atomic processes should be favored.

This issue is created to follow up a problem discussed on the following forum post

http://rest-forum.unizar.es/t/pandaxiii-mc-pipeline-at-development-v2-3/410/15

The problem is that normally TRestTrackReconnectionProcess should shift the order of hits so that the longer edge is suppressed (minimising the total track length). In other words, just re-ordering in the array so that hit_0 and hit_N correspond with the long edge.

Also the reconnection routine, such as breaking tracks and find an optimum reconnection should solve the problem observed on the track observed at the forum post. This last, fixing reconnection through sub-tracks, might just need optimisation of fNSigmas parameter.

TRestTrackAnalysisProcess is huge and it has too many observables to maintain (76). The idea is to split this process according to the type of track (XYZ or XZ-YZ) keeping all observables but segmented into several processes. Also naming convention will be homogenised.

• TRestTrack3DAnalysisProcess -> For XYZ tracks. In case XZ-YZ tracks are provided, they will be merged.
• TRestTrack2DAnalysisProcess -> For XZ-YZ tracks
• TRestTrackBasicAnalysisProcess -> Most elemental observables taking into account all tracks
• Max track and second max track analysis. Could be inside previous processes or in dedicated ones (I tend to prefer the second option)