Introduction
The STAR VMC application will need a class to contain the
Monte Carlo Event Data.
We have considerered two prototypes that can be potentially used,
and present the findings in the Appendix.
We are developing the requirements for the STAR VMC event object,
and the actual object model. The text is organized as follows:
- STAR VMC Event Model Proposal
- Requirements for the STAR VMC Event Object
- Appendix:
STAR VMC Event Model Proposal
Opting to use the Alice event model has the advantage
of moving towards the implementation rather quickly, however
it is not optimal from the point of view of integration with
the rest of the STAR software complex. We note, however, that
the Alice model has a well thought out layout for the
configuration data etc, which we would like to implement as
well.
Having concluded that the StMcEvent has adequate basic
functionality, and has associated software that works
with StEvent, we propose the following:
- we shall adopt it as a rough template
for the VMC event object model, aiming to preserve the API
where possible and changing implementation where necessary
- The event object will be persistent
- At this stage, we do not plan to break up the persisted
event object into parts
- We choose to use g2t tables as the API for feeding the
Monte Carlo data to digitization software (and subsequent reconstruction).
This will allow us
to build the interface to reconstruction with minimal
changes in the latter part.
That would, however, require
the creation of the translation layer StMcEvent->g2t. Since
this already workds in one direction, it should not be
problematic
- We shall make provisions for keeping the "Monte Carlo truth"
throughout the reco chain, i.e. track-hit association produced in
the simulation will be propagated to, and used by, the StEvent
object. This will change the way association currently works.
Requirements for the STAR VMC Event Object
Naming conventions used in this document
- VmcEvent: In the following, we shall use this name to
designate the main object being designed.
- VmcEventHeader: The object that contains data
characterizing the conditions in which the current Monte Carlo event
was produced
- VmcTrack: represents a simulated particle
- VmcHit: represents an energy deposited in a detector element
- VmcVertex: represents a vertex, i.e. the points where one
particle may have ceased to exist and others may have originated. Contains
the coordinates of such transition, and references to the track that
created the vertex as well as the daughters emanating from it
- VmcRun: an object representing a single Monte Carlo run.
It will have the Conditions and Configuraion. For example,
the latter can contain all the necessary data describing the magnetic
field used in the run (which in many cases may be just one parameter,
however it's not restricted to that).
The content of various objects in VmcEvent
VmcEvent
The main purpose of the VmcEvent existence is to represent
a single Monte Carlo event data in the form that (a) can be
persisted (b) can be interfaced to other parts of the STAR
software in a reasonably easy manner. It is the outmost
layer of data representation, containing the other
etntities listed below.
As such, it shall include:
- the VmcEventHeader
- Collection of VmcTracks
- Collection of VmcHits
- A mechanism for the association of tracks and hits
The VmcEvent instance would be created in the beginning of each
event, and filled when the Virtual MC application receives a
stepping callback from TVirtualMC.
VmcEventHeader
Contains the event serial
number within a MC run, the run number, impact parameter etc.
VmcTrack
Contains it's
particle ID (in PDG numbering scheme), its 4-momentum, as well as information
on start and stop vertices. Also contains references to hits generated
by the particle (see below). Since there are multiple tracks in one
event, there needs to be a collection object, VmcTracks.
VmcHit
Contains a 3-vector of the spatial location of the hit, the
energy released, and some data specific to TPC if necessary (such as
the track length covering the padrow). Also contains a reference to
the track with which it is associated
Since there are multiple hits in one
event, there needs to be a collection object, VmcHits.
VmcVertex
Contains a 3-vector of the spatial location of the vertex, a
reference to the parent track, and a reference to the collection of
daughter tracks.
Since there are multiple vertices in one
event, there needs to be a collection object, VmcVertices.
Object association in VmcEvent
In order to carry the intended functionality, the objects inside the event need
to be related via association, and thus will contain references to each other.
The pattern of such association is presented in brief table format below:
| Objects | Hit | Track | Vertex |
| Hit | ♦ | Originator | |
| Track | Collection of hits produced | ♦ | Start,Stop |
| Vertex | | Parent, Collection of daughter tracks | ♦ |
Appendix
Alice Event Review
We have previously analyzed the Alice MC Event Structure.
Summary: The Event model used in Alice MC is feature rich and carries
a lot of functionality pertaining to handling hits, digitizations, and performing
reconstruction of the simulated data. In the context of STAR, a large part of such
functionality is located elswhere, such as in the slow response simulators and
reconstruction software. It would appear then that the Alice model is largely
redundant for our application.
StMcEvent Review
This class was created expressly as an add-on to the StEvent and
an accessability layer for the MC data. There is no persistency
built into this object, and it's role is in big part in
supporting the assciation-making mechanism, i.e. be used in
conjunction with the StEvent.
This class is well documented
on a separate page.
The StMcEvent in some ways is "inspired" by
StEvent,
in particular in the area of detector specific data organization.
Data members representing the header-like type of event information:
unsigned long eventGeneratorEventLabel() const;
unsigned long eventNumber() const;
unsigned long runNumber() const;
unsigned long type() const;
unsigned long zWest() const;
unsigned long nWest() const;
unsigned long zEast() const;
unsigned long nEast() const;
unsigned long numberOfPrimaryTracks() const;
float impactParameter() const;
float phiReactionPlane() const;
float triggerTimeOffset() const;
Accessors for tracks and hits objects:
StMcVertex* primaryVertex();
StSPtrVecMcVertex& vertices();
StSPtrVecMcTrack& tracks();
StMcTpcHitCollection* tpcHitCollection();
StMcSvtHitCollection* svtHitCollection();
StMcFtpcHitCollection* ftpcHitCollection();
The hits in this scheme are subclassed from StHit which in
turn is derived from StObject.
The collections listed above, on the other hand, are not related by inheritance,
and have a russian doll kind of structure, where a particular collection
contains sector-specific subcollections, as a flat array, which in turn
contain layer-specific subcollections.
An important object in the event structure is the StMcTrack,
which stores the 4-momentum of the track plus contains the hit mapping
for this track, for each individual detector. It also contains a pointer
to the track that is considered its parent, and a host of methods for
accessing and manipulating the hits and other data. It obviously also
has to contain handles for vertices and hit collections.
const StLorentzVectorF& fourMomentum() const;
const StThreeVectorF& momentum() const;
float energy() const;
float pt() const;
float rapidity() const;
float pseudoRapidity() const;
StMcVertex* startVertex();
StMcVertex* stopVertex();
StPtrVecMcVertex& intermediateVertices();
StPtrVecMcTpcHit& tpcHits();
StPtrVecMcSvtHit& svtHits();
StPtrVecMcFtpcHit& ftpcHits();
StParticleDefinition* particleDefinition();
int isShower() const; // 1 = yes, 0 = no
long geantId() const;
Comment: the most universally used container type in this software
is a STL vector, implemented via templating. Various hit collection are not
subclassed from a base hit collection class.
|