Dear Alexander,
Thank you for the comments. Please find the response below.
Dear Grigory,
thanks for your comments to my comments.
By default, primary tracks (vertex constrained fitted) are not produced during the reconstruction, but this can be done and there will be an extra track branch in the MpdDst stored.
It is not very clear what do you mean. What do you mean when say that primary tracks are not produced? As for storing primary tracks to the separated branch in MpdDst, it would be great if you could do it. Really, we need just (px, py, pz) and index of the corresponding kalman (global) track.
Also there is no need to create extra branch because one can use already existing PrimaryTracks branch, which is currently empty.
It means what it meant, that tracks with primary vertex constraint are not produced during the reconstruction. But this option can be activated and an additional reconstructed branch with vertex constrained tracks which pass close enough to the primary vertex will be written. If somebody wants to pass the relevant information form reconstructed tracks to the DST fields, he or she (not me) can do this.
As for the following comments, as long as the MpdDst is kept, what is stored in MiniDst is mostly the developer’s business. So, I will comment only for the case when the MpdDst is going to be dropped.
From my part (track reconstruction): there should be the information from hits on tracks to do the further processing (like track refitting). Also, a possibility to recreate a track object should exist (corresponding track constructor from MiniDst).
Since the current approach is to convert MpdDst to MpdMiniDst then TPC hits certainly will not be stored, because people do not need them. What people need is the information about the reconstructed tracks (kalman or global) and the momentum of the tracks that were fitted to the primary vertex. Long-lived particles, such as V0s, Kinks, Omegas, J/psi, etc can be reconstructed either using helix parameterization or track fitting using covariance matrix.
The possibility to do track refitting should be preserved (in order, for example, to do the fit with particle ID hypothesis). It means that track hits should be kept.
The ability to create a track (not sure which track do you mean?) could be written in the class that you want to have. MpdMiniTrack must not depend on external packages. The idea is that one can simply analyze data not only using MpdRoot environment, but also with simple small library that we provide (standalone or vanilla ROOT mode).
Here again - as long as MpdDst is not dropped, then it’s OK.
As for the Monte Carlo tracks: keeping only the generator tracks is definitely not enough - weak decays (hyperon decays) happen during the particle transport.
Which information is needed and for what?
Information about hyperon decay products - to evaluate effect of feeddowns, for example.
General comment: now the MpdDst is basically collections of reconstructed objects (stored in Trees) with some additional information (which is a DST in fact and which is not well supported by anybody). So, if Grigory is willing and feels capable of doing this, i.e. to support and develop the DST part (in the format of MiniDst) and to keep track and implement possible changes from the reconstructed objects (when necessary), then the MpdDst can eventually be dropped (after proper testing, of course).
As it was mentioned by Adam today, there should be different levels of information. MpdDst allows one to perform calibrations, check reconstruction procedure and other things. Thus, we propose MpdMiniDst for the physics analysis level where only the essential information is stored.
Again, if the MiniDst is not positioned as a full replacement of the MpdDst, then requirements to it can be relaxed.
Summary
This text will be hidden