Some comments on MiniDst presentation and concept

MPD Software
1

During the presentation there was a question from Arkadiy about primary tracks in MpdDst (something like that - my session got frozen at that time). 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.

As for the MiniDst - whether or not the information stored now is sufficient should be determined from tests (and added if necessary - this is not an issue). 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).

As for the Monte Carlo tracks: keeping only the generator tracks is definitely not enough - weak decays (hyperon decays) happen during the particle transport.

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).

This is my vision.
Alexander

2

Dear coleagues,
While looking through the code of MiniMcTrack I noticed this:
UShort_t firstChildIndex() const { return fChild[0]; }
UShort_t lastChildIndex() const { return fChild[1]; }
Just a heads up that this data is currently not being stored while MpdMCTracks are created.
These indexes can be found with loops on MCtracks. But maybe it will be more convenient to store in the default MpdMCTracks, as well.
Also I would like to ask why parent indexes are commented out? I think those are required in many analyses and correspond to MpdMCTrack->GetMotherID()

3

Dear Alexander,

Thank you for the comments. Please find the response below.

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.

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 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).

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?

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.

Best regards,
Grigory

4

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

5

Hi Grigory,
It is bvious that the filtering, which is the essence of the miniDST production, reduces the flexibility. The larger the suppression factor the smaller the scope of the produced miniDST files including the physics analyses. There are tens of examples when tracks fitted to the primary vertex are not enough, although I agree that such tracks are indeed required: track matching to external detectors with filtering for track and TOF/EMC-hit qualities, reconstruction of secondary vertexes from week decays and conversion, track refits with PID hypothesis etc. If one tries to make an universal miniDST file it will turn to the original DST. So I would stick to the needs of yuor PWG when you consider internal structure of the filtered files.
Others may decide to join you or produce their own structures.

6

Dear Alexander and Victor, All,

Thank you for you comments and sorry for the late reply. Please find responses below.

Responses to Alexander:

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

Could you please point to the codes that should be used? I think we would like to add those with your help.

The possibility to do track refitting should be preserved (in order, for example, to do the fit with particle ID hypothesis).

Could you give a talk about the track finding and fitting at the MPD seminar? I think all of us would benefit from learning the details of tracking in MPD.

Information about hyperon decay products - to evaluate effect of feeddowns, for example.

I see. Is there any flag that could be used to select MC tracks that were produced by GEANT by decaying particles, like Lambdas, but not produced in the material?

Responses to Victor:

There are tens of examples when tracks fitted to the primary vertex are not enough, although I agree that such tracks are indeed required: track matching to external detectors with filtering for track and TOF/EMC-hit qualities, reconstruction of secondary vertexes from week decays and conversion, track refits with PID hypothesis etc.

That is true, BUT. MpdMiniDst stores ALL reconstructed tracks (Kalman/global) as well as hits in outer detectors, like TOF. Thus, one can (re)run TOF-matching (or any other) procedure if needed as afterburner. We use this approach in STAR often.

So I would stick to the needs of yuor PWG when you consider internal structure of the filtered files.

To be clear. Once again. I DO NOT FILTER any reconstructed tracks. So I do not see the reason for your comment. Please try the format and provide your feedback.

Best regards,
Grigory