Introduction

The reader is also referred to the description of the Alice Event structure.

Review of Classes in AliRoot

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