STAR  Computing  Simulation  
VMC Event Structure for STAR


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:

  1. STAR VMC Event Model Proposal
  2. Requirements for the STAR VMC Event Object
  3. 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


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.


Contains the event serial number within a MC run, the run number, impact parameter etc.


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.


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.


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:

TrackCollection of hits producedStart,Stop
Vertex Parent, Collection of daughter tracks


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.

Last updated by Maxim Potekhin on 05/27/2004