Agenda:

Agenda:

  1. Track-Cluster Matching with New TrackStates@ECal   — Miriam
  2. The DST - what do we actually want for a DST?            — All
    1. Overview of current Tuple maker.                         — Matt S. / Miriam
    2. How to get to something better.                            — All
  3. Questions?                                                            -- All

Notes:

Miriam noted that using an extrapolation from the last tracker plane gives very different results compared to the old way where the extrapolation started at the interaction point. This is not understood (especially why the difference can be of order 10mm in y but only 3mm in x), so more investigation is needed. The track-cluster matching is unaffected, because the matching cuts are so loose.  See her slides.

There was quite a lively discussion about the merits and issues surrounding the tuple-maker. 

In general, it is recognized that there are benefits to having an easy access "flat" NTuple. The vertexing searches are build on this data model, and it would be too much effort to re-tool that analysis chain to use the DST. However, some discipline will be needed to make sure the tuple-maker adheres to some more strict standards:

  1. The tuples should be created from existing numbers in the LCIO files, or in the DST output. No new calculations or tweaks, or re-calculations, are done in the tuple-maker.
  2. You can add to the tuples, but you cannot change the meaning of the existing variables, unless this is fully agreed upon in the software group.

Omar suggested that a much better model for creating the flat NTuples would be to run a script over the DST output and extract the needed information from there. This would run much faster, since there is no need to go back to the LCIO files, and all the information for the NTuples should be in the DST output. If the information is not in the DST, then it should be added to the DST.

 

  • No labels