1. AliRoot survey: Reconstruction P.Hristov 11/06/2013

2. Are you involved in reconstruction activities?(39.3% Yes, 60.7% No) 2

3. Which detector are you working for? 3 Other: AD, MFT, CPV

4. Relative importance of reconstruction inputs (1 – lowest, 5 – highest) 4  Digits: 4  DATE subdirectories: 2.2  DATE file: 2.6  Rootified raw file: 4.7

5. Do you have suggestions for the development of the reconstruction framework? (Yes: 28.6%, No: 31.4%, No answer: 40%) 5

6. Suggestions 6  Reduce the memory consumption  Documentation  More parallelization, no runloader  Build small working group with AliRoot/root/c++ experts together with detector people, benchmark and improve the reconstruction performance  Remove the overhead due to Loaders...  The AliReconstructor interface does a good job for modularization, the supported data exchange however is limited too much. More flexible data exchange between different layers and modules would avoid data duplication.  Make the intermediate trees (TreeS,TreeD,TreeR, which we delete anyway at the end) optional by default

7. Suggestions 7  Relation/inheritance/access level of different track and cluster classes is not optimal, which leads to unnecessary conversions, unused data members of base classes. The way clusters are accessed (at least in ITS) leads to necessity to duplicate them in memory. If we go for event-level parallelism, the possibility to have standalone containers and their queuing for sequential IO should be foreseen  Tracks and clusters different classes inheritance/members/access is not optimal, which leads to unused data members, unnecessary conversions etc.  Use shorter types, only calculations may go in double prec.  The clusters are currently doubled.  If we go for event level parallelism, the we need possibility of having the independent cluster containers for multiple events and mechanism for queuing them for sequential IO  A good global tracking working group with automatized global QA rather than more standalone working of detector experts

8. Suggestions 8  Should be more centralized. I think "detector expert" approach did not work in the past.  Standard components to be used by default, for the reconstruction/QA/performance benchmark. This is currently very week point.

9. Suggestions for new reconstruction algorithms (7 out of 35 participants) 9  Hough transform for seeding  Adaptive Vertex Fitter (AVF), parallel Kalman Filter  Common highly optimized clustering (if possible)  In Run3 the ITS reconstruction should rely on standalone tracking. Primary candidate currently is Cellular Automata.  For the ITS upgrade TDR a more flexible version of track following from TPC to ITS is prepared. In principle, could be used for Run2, but will require lot of work for porting to current ITS detectors.  Make sets of the standard algorithms to be used by different sub-detectors: 1. cluster containers with optimized navigation 2. seeding 3. optimized material budget queries 4. optimized magnetic field queries (maybe it is already good)

10. Priority of technical tasks (1 –very low, 5 – very high) 10  Improvements in memory consumption: 4.2  Improvements in CPU consumption: 4.0  Debugging of run-time problems: 4.1  Development of parallel reconstruction algorithms: 4.2  Development of GPU enabled algorithms: 3.1  Improvements in the momentum resolution of tracks: 3.6  Improvements in the energy resolution of clusters: 3.5  Improvements in the fraction of fake tracks: 3.9  Improvements in the reconstruction efficiency: 3.9  Improvements in PID: 4.1  Development of more detailed QA for the reconstruction: 4.0  Improvements in energy loss accounting: 3.6

11. Possible improvements in the current reconstruction algorithms 11  Switch to HLT tracking in offline  Rewrite the clustering (and pre-clustering) in a cleaner manner  Space of improvements in:  local reconstruction  ITS standalone at high multiplicity  Current ITS/TPC matching algo can be probably spead up by some factor (<2) but the code is almost unmanageable.  TPC algorithm was tuned before data taking. New developments after 2009 was not tuned except of the TEST of the HLT algorithm as pre-seeding.

12. Alternative algorithms to speed up the reconstruction 12  For current T0 detector geometry - no speed up. But for upgrade geometry with much more channels algorithm will be changed  In principle improvements come with a price. With enough man- power it would be worthwhile having more than one tracking algo in the barrel for benchmarking and having a choice  An alternative could be porting of the algo. developed for the ITSupg TDR, but this would require either manpower to port detectors of current ITS to simpler layout of ITSupg.  Current ITS standalone reconstruction is too slow and produces too much fakes in PbPb. One could try to implement CA tracker also for current ITS  For the standalone ITS tracking the alternative is CA.  Combine the functionality of the current HLT and current OFFLINE software. Current HLT is faster but less performing (I think therefore faster).

13. Reducing memory consumption 13

14. Possibility for parallelization 14  Can you detector code be modified in such a way that it would allow multiple instances of trackers, clusterizers etc running in parallel, if the IO provided by the framework would permit it?  Yes: 8  No: 3

15. Conclusions 15  Several interesting ideas came from the survey  The development of the reconstruction algorithms requires special knowledge and expert skills => proposal for centralized group  The present reconstruction can be improved both for memory and CPU consumption  Such improvements require significant effort