Introduction
The STAR VMC application will be based on the virtual Monte Carlo
as developed by the ROOT and Alice teams, and in particular on the
Alice implementation
of the relevant classes.
The reader is also referred to the description of the
Alice Event structure.
Review of Classes in AliRoot
The following description of classes presents a combination of code inspection
and interpretation of comments in the code, where available. For the most part,
the comments are scarce. Keep in mind that the current version of this software
is work work in progress, and contains a few archeological layers. The relationship
among the various classes and their use are subject to change. Some of the methods
spread across classes appear to be redundant. There are
approximately 869 classes located in 75 directories.
Below are listed some
of the most important ones. An extremely simplified diagram showing the
relation between three core classes is shown on the bottom of this page.
If the complexity of what's happening in this framework was to be summarized
in one sentence, that would be: the stepping method in AliMC interfaces
the hit creation and digitization facilities specific for each detector.
The energy depositions and other relevant informatin for the hit being
created are extracted from the
underlying MC engine via the TVirtualMC methods.
- AliSimulation is the class for running generation, simulation and digitization.
The following is an illustration of its functionality.
Hits, and digitizations (commonly called digits throughout the code)
are created for all detectors by typing:
AliSimulation sim;
sim.Run();
The Run method returns kTRUE in case of successful execution. The number of events can be
given as argument to the Run method or it can be set by
sim.SetNumberOfEvents(n);
The name of the configuration file can be passed as argument to the
AliSimulation constructor or can be specified by
sim.SetConfigFile("...");
The generation of particles and the simulation of detector hits can be switched on or off by
sim.SetRunGeneration(kTRUE); // generation of primary particles
sim.SetRunSimulation(kFALSE); // but no tracking
Digitization for particular detectors can be steered by
sim.SetMakeSDigits("ALL"); // make sdigits for all detectors
sim.SetMakeDigits("ITS TPC"); // make digits only for ITS and TPC
The argument is a (case sensitive) string with the names of the
detectors separated by a space. An empty string ("") can be used to
disable the creation of digits. The special string "ALL"
selects all available detectors. This is the default.
The RunSimulation is the core method, as it is
setting the various parameters of the AliGenerator
object and then calls gMC->Run() method (see below).
This is mapped to the RunMC , which in turn calls
ProcessRun() .
- AliRun is the run manager, which allows to unload
the run control functionality from the user application. It is
therefore a layer between the user application and TVirtualMC-based
object (see diagram).
It is available anywhere via a golobal
pointer,
gAlice . It assigns itself to that pointer in its own
constructor, which is called from the user's small "main" program (AliSimulation class).
This important class calls the ProcessRun method
of TVirtualMC, thus actuating the run, and its method FinishRun
which properly handles I/O such as closing files etc.
AliRun also contains
- Various initializations, including that of the histograms
- Query facilities which find detectors and modules by name
- Setting method for the magnetic field
- Facilities to steer the translation of hits into digits, and reformatting
of the latter into a tree to be submitted to reconstruction, if necessary
- Facilities to generate what is called Lego Plots, in this case this being
maps of radiation length, interaction length etc binned in eta and phi
- Accessor to the magnetic field map
- Calls to event reconstruction
Its data members are listed here in full:
protected:
virtual void Tree2Tree(Option_t *option, const char *detector=0);
Int_t fRun; //! Current run number
Int_t fEvent; //! Current event number (from 1)
Int_t fEventNrInRun; //! Current unique event number in run
Int_t fEventsPerRun; // Number of events per run
Int_t fDebug; // Debug flag
TObjArray *fModules; // List of Detectors
TGeometry *fGeometry; // Pointer to geometry
AliMC *fMCApp; // Pointer to virtual MC Application
AliDisplay *fDisplay; //! Pointer to event display
AliMagF *fField; // Magnetic Field Map
TVirtualMC *fMC; //! Pointer to MonteCarlo object
Int_t fNdets; // Number of detectors
Bool_t fInitDone; //! True when initialisation done
AliLego *fLego; //! Pointer to aliLego object if it exists
TDatabasePDG *fPDGDB; // Particle factory object
TString fConfigFunction; // Configuration file to be executed
TRandom *fRandom; // Pointer to the random number generator
TString fBaseFileName; // Name of the base root file
-
AliRunLoader contains a collection of AliLoaders, which
are I/O managers. The AliRunLoader is reponsible for all of the
I/O happening in the run, loading and saving the detector
parameters, hits, digits etc.
In addition, AliRunLoader governs the creation of TTree objects
representing the kinematics (tracks) data (TreeK), track references (TreeTR) and event headers (TreeE).
Contains the Event Folder
There are predefined names for some of the objects
to be stored:
const TString AliRunLoader::fgkHeaderBranchName("Header");
const TString AliRunLoader::fgkHeaderContainerName("TE");
const TString AliRunLoader::fgkKineContainerName("TreeK");
const TString AliRunLoader::fgkTrackRefsContainerName("TreeTR");
const TString AliRunLoader::fgkKineBranchName("Particles");
const TString AliRunLoader::fgkDefaultKineFileName("Kinematics.root");
const TString AliRunLoader::fgkDefaultTrackRefsFileName("TrackRefs.root");
const TString AliRunLoader::fgkGAliceName("gAlice");
-
AliConfig is a singleton. It contains BuildEventFolder method. The significance
of this class is in that it defines the folder structure for the event, i.e.
defines the topology of the event tree. It also stores the predefined
names for the individual folders making up the tree. The general layout of the data
thus created is presented in the diagrams on top of this page.
-
AliDataLoader a subsidiary class used AliRunLoader to actually
handle loading of data at more basic level. For instance, there
is a
AddToBoard method which adds an object lifted from a file,
to the tree.
This class contains a TObjArray of 4 elements, for the so-called "base loaders".
In the constructor, the AliTreeLoader objects are created and added to that
collection.
- AliLoader is not a part of the inheritance hierarchy of
loaders described above. Rather, it is responsible for handling data of individual
detectors. TObjArray of those objects, detector-specific,
is contained in the AliRunLoader. In addition, the AliLoader does
have a collection of AliDataLoader objects.
-
AliModule abstracts a detector component, called a "module".
Contains a medley of methods and containers such as
- Building of the module's geometry
- Creation of rotation matrices
- Contaners for materials and media used in the module
- Parsing a Euclid format external geometry file
- Handling of the so called "Track References", which means
hits associated with a particular track. Iteration over those.
-
AliMC inherits from TVirtualMCApplication and
represents the actual "User Application", i.e. what actually
gets the job done. Contains:
- Building of the overall geometry by iterating over modules
- General initialization, defintion of the material parameters (such as cuts),
building physics, building media table, importing the transport parameters
file
- Setting and Resetting the event generator object reference
- Generation of primaries and putting them on stack
- Magnetic field calculation
- Steering at many levels:
-
Begin event: cleaning up after the possible previous event, resets deposited
energy, creates ROOT-based data structures to serve as data recipients during
the event simulation.
-
Pre and post-track operations for each primary track
-
Pre and post-track operations for tracks other than primary
-
Core function: Stepping (the actual method name) is called at every step via
a callback from TVirtualMC (subclassed into TGeant3 or Tgeant4).
Here, the energy deposited during each step is added to the
current volume. "Step Managers" specific for each detector are called from here.
The crucial determination of the current material and detector is done,
and then the StepManager (subclassed in each detector) is called.
-
Finish Primary.
-
Finish Event: summing up of the energy depostits, updating the event header
- Service functions such as returning the number of the primary that generated
the track, stack interface
The FinishEvent and FInishPrimary methods are (among others) callbacks from
TVirtualMC.
-
AliGenerator is a parent of many event generator classes. Its core function
is to push the simulated primary particles on stack. In addition, it sets limits
for various kinematic parameters. In practice, there are many subclasses of this
basic class, for the availble event generators.
-
AliHit is a small class storing coordinates of a point
where the track left an energy deposit; associated with
that track by keeping its number. Other contents is added
in subclassed objects.
-
AliDetector abstracts the detector. Contains a TClonesArray
of AliHits (see above), as well as methods for setting
and getting those. Stubs for the
StepManager as well
as methods for hits creation. Here is concentrated the complete control over the
hits manipulation, specific for this detector. Their digitization is done
by the AliDigitizer class.
Besides that, material pertaining to a particular detector
are created here.
-
AliDigitizer abstracts the digitization process for a detector.
-
AliHeader is the event header, contains data such as number of primaries,
vertices, run number etc. It is written out, along with kinematics data,
when the event is finished and is being persisted.
Contains a pointer to the AliStack.
-
AliStack is a complex subclass of the
TVirtualMCStack
It has a TTree representing "particle stack", as well as TClonesArray
containing the list of particles. In general, the storage of data in this class
has a degree of redundance (confer trees and lists) and as such has a few accessors
ans synchronization methods. Also has the following:
-
PushTrack method, which either push the prepared data representing a track,
on stack. Pop method.
- facility to flag those tracks that are to be kept
- various methods for the stack traversal (next particle, parent, etc)
- "Purify" method to compress the stack after the tracking of a given primary
particle is finished, removing particles not flagged for keeping
- the particle buffer update, which happens at the event's end -- those particles
still on stack (because they we flagged appropriately) will be transferred to
the buffer
- stack management such as setting size
- "Dump" methods which print out the contents of the stack as well as
individual particles in the stack.
Consider the following internal structures representing the stack:
TClonesArray *fParticles; //! Pointer to list of particles
TObjArray *fParticleMap; //! Map of particles in the supporting TClonesArray
TArrayI fParticleFileMap; // Map for particle ids
TParticle *fParticleBuffer; //! Pointer to current particle for writing
TParticle *fCurrentTrack; //! Pointer to particle currently transported
TTree *fTreeK; //! Particle stack
Principal components of the Alice VMC system
|