StStrangeMuDstMaker
The Micro-DST
Structure
Components
Usage
Structure of the Micro-DST
The Micro-DST is built using a Root
TTree,
a class designed specifically for DSTs. The TTree is organized
such that event-wise structure is maintained. For every event
on the micro-DST, there exist between one and eleven component types,
described in the next subsection. While the event information is kept
for each event on the micro-DST, the user may select which other
components the DST will have during the creation process, selecting
any combination of the components desired (see
Creating Micro-DSTs).
Each component has several sub-components - these are the actual data
members of the component classes. Thus, for every event on the micro-DST,
the structure appears something like this:
TTree---
|
|---previous event...
|
|
|--------------...---------...---------------...----------...
| | | | |
| Event V0 Xi Kink
| | | | |
| |---------... |-----... |---------... |----------...
| | | | | | | | | | | |
| e1 e2 e3 v1 v2 x1 x2 x3 k1 k2 k3
|
|
|---next event...
|
...
In the above, e1, e2, etc. would be data members of the
Event component class.
A possible goal is to have some components written to
separate files. This would allow someone interested in looking at
V0's to need only the Event and V0 files available to them, as TTrees
support the ability to read only the tree branches requested without
reading in the entire tree. However, due to a possible bug in Root,
all branches are currently stored in one file.
Components of the Micro-DST
Useful information on what member functions are provided by the
component classes is found easily by looking at the St*I.hh
header files of the component types in the package directory.
More detailed information on what is stored in the component classes, and
what member functions are provided by the classes is best learned by looking
at the *.h header files of each class in the package directory.
It should be noted that all St*MuDst and St*Mc classes listed below inherit
from the class StStrangeMuDst.
- Event Information (StStrangeEvMuDst)
- This component stores information associated with the event which may
be of import to a vertex component class, but only needs one instance for
the event. For example, the event number and primary vertex position
coordinates are stored here, as storing this information with every component
class would be redundant and inefficient.
- V0 Information
(StV0MuDst, see interface
StV0I)
- Information about the V0 daughter tracks are stored along with parameters
of the vertex itself. Member functions are provided to get more detailed
information such as the mass of the V0 under the lambda hypothesis.
- Xi Information
(StXiMuDst, see interfaces
StXiI and
StV0I)
- Similar to the V0, information about the bachelor track and vertex
parameters are stored. The class also inherits from StV0MuDst to
store all the information about the associated V0.
- Kink Information
(StKinkMuDst, see interface
StKinkI)
- This class keeps data on kink parent and daughter tracks and parameters
of the kink decay vertex.
- Event Monte Carlo Information
(StStrangeEvMuDst)
- The event-wise Monte Carlo information is stored using the same
class as the reconstructed event-wise information.
- V0 Monte Carlo Information
(StV0Mc, see interface
StV0I)
- This class is for Monte Carlo V0 vertex information. There may be
a different number of these than reconstructed V0 vertices.
- Xi Monte Carlo Information
(StXiMc, see interfaces
StXiI and
StV0I and
StKinkI)
- Monte Carlo storage class for Xi vertices, inheriting all functionality
from the StODMc class which it shares with StKinkMc.
- Kink Monte Carlo Information
(StKinkMc, see interface
StKinkI)
- Monte Carlo storage class for Kink vertices, also inheriting all
functionality from StODMc.
- Monte Carlo Association Information
(StStrangeAssoc)
- The StStrangeAssoc class links matching reconstructed and
Monte Carlo vertices, and there exist only as many as the number of
matches between the two sets. There will be an association component
for each Monte Carlo component
- Cut Information
(TCut, see also
StStrangeCuts)
- Cuts are stored in a generic Root class called TCut. Each
cut has a name and value (using the title data member of TCut).
Usage of the cuts is discussed here.
Usage of the Micro-DST
The micro-DST can be used in one of two primary modes:
- As a generic TTree
- As a fully-described TTree
The difference between the two modes is significant:
- In the generic TTree mode,
nothing is known about the actual component classes - their libraries
need not be loaded into Root, and no actual instances of the component
classes are created. Technically speaking, the member functions of the
component classes are not available. The result is that only the
functionality of the TTree is present. However, this has significant
advantages in terms of speed and efficiency for studying the data in
the TTree. And the functionality of member functions can, for the most
part, be emulated with TTreeFormulas. Please see the documentation for
strangeFormulas.C to learn more about
using this mode.
- In the fully-described TTree mode, the TTree is read using the
StStrangeMuDstMaker library package. This means that the library code
must be loaded into Root, and that a chain is set up to run the maker.
The advantages are full use of the component classes, at the drawback
of significantly slower access to the data. See
Reading Micro-DSTs
for more information on using this mode.