You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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 doing Track-Cluster matching 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, so more investigation is needed. 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