1. 10.05.2004CBM Software Meeting 1 CBM Simulation & Analysis Framework M. Al-Turany, D. Bertini

2. 10.05.2004CBM Software Meeting 2 Outline Motivations Requirements Features & Design The Virtual Monte Carlo concept Base Steering classes –CBMRun –CBMMCApplication Data Level structure –CBMRootManager –Simulation Data Objects: CBMMCPoints CBMMCDoublePoints –Reconstruction Data Object CBMHit

3. 10.05.2004CBM Software Meeting 3 Motivations : Simulation Which simulation engine to choose? –Need to move to modern and maintained MC: GEANT4 –Need for Working fast ! ( LOI, TDR deadlines … ) Making reliable simulation –Usually: better knowledge of “old” MC’s: GEANT3, FLUKA … –A cross-check of simulation results between different MC is needed Better understanding of GEANT4 ( intrinsic cuts / physics list …) Preparing for full simulation Use of VMC (Virtual Monte Carlo ) : an interface between MCs –With the same code, the user can switch between different MCs –Use of a “a la Geant3” API Same function names Same parameter definition

4. 10.05.2004CBM Software Meeting 4 Motivations : Analysis Usage of ROOT services: – Optimized data structure: TClonesArray TRefArray, TRef … – IO : Ntuple-like structure for the event store: TTree TTree Splitting mechanism => data vizualisation (TBrowser) Partial IO Merging of different input files : friend TTree mechanism Schema evolution for ROOT based Object – TTask create complex hierarchy (tree-like) of tasks(algorithms) Tasks execution done recursively –Geometry Modeler (TGeoManager) for geometry definition Can run as navigation system ( Geant3, Fluka, Geant4?) Boolean operations on volume now supported.

5. 10.05.2004CBM Software Meeting 5 Requirements The geometrical modularity –reflected in the data structures and reconstruction algorithms. – CBM consists of several detector components: RICH, STS, TOF, TRD, … – Detector components contains sub-divisions : layers, cells … The algorithms modularity: – Each reconstruction step is executed by an algorithm or modular procedure and delivers one data level. – At execution time, the user can define the algorithms' selection and sequencing. The number of partially elaborated data levels is detector dependant, even algorithm dependant. –Upper levels in the reconstruction process can combine data from different detectors in order to obtain the identification (charge, mass) and 4-momentum of all particles of interest.

6. 10.05.2004CBM Software Meeting 6 Requirements Besides the data analysis itself, the system must be able to be used for a number of other tasks, for example: –Technical analysis of detectors; –Detector digitization, calibration; –Alignment of detector components; –Optimization of the reconstruction algorithms; –Merging of different input files (simulation and analysis) –… The system requires several inputs in order to operate: –Geant3/ Geant4 configuration file in order to generate simulated events –Simulated events, which are generated and can be stored (disk or tape files. ) –Partially reconstructed events. Generated by the reconstruction program itself, so that if different reconstruction methods are to be tested one does not need to start the analysis from the first data level. –Merged partially reconstructed events

7. 10.05.2004CBM Software Meeting 7 CBM Framework: Features Fully ROOT based: –VMC for simulation –Geometry Modeller (TGeoManager) for geometry definition –IO scheme (TTree, friend TTrees, TFolders ) for persistency –TTask to organize analysis data flow Easy to maintain (only ROOT standard services are used) The same framework can be used for Simulation and Analysis System completely configurable via ROOT macros –Simulation mode : Geant3/Geant4 config macros Simulation macro to produce/store simulated events –Analysis mode Analysis macro to analyze simulated events using TTask

8. 10.05.2004CBM Software Meeting 8 The Virtual Monte Carlo (VMC) The Virtual Monte Carlo (VMC) has been developed in order to –Run the same user application with all supported transport Monte Carlos –Run different transport Monte Carlo programs without changing the user code and therefore the geometry definition, the detector response simulation, or input and output formats VMC decouples the dependence of a user code from a concrete MC

9. 10.05.2004CBM Software Meeting 9 VMC Interface

10. 10.05.2004CBM Software Meeting 10 Virtual Monte Carlo (VMC) User Code VMC Virtual Geometrical Modeller G3 G3 transport G4 transport G4 FLUKA transport FLUKA Geometrical Modeller Reconstruction Visualisation Geant4_mc.tar.gz includes the TVirtualMC Geant4 interface classes Geant3.tar.gz includes an upgraded Geant3 with a C++ interface

11. 10.05.2004CBM Software Meeting 11 TGeant3 implementation Provided within a single package together with Geant321 (FORTRAN) Straightforward implementation –VirtualMC was largely inspired by Geant3 –Functions/parameter “a la Geant3” ROOT Geometry Modeler works as navigation system –''Where am I ?'' => up to 2000% performance gain compared to GEANT3 –Computing the distance to next boundary => up to 800% gain; –Safety => computed when needed –Normals to crossed surfaces => on demand (ongoing work) –Support for Boolean operation

12. 10.05.2004CBM Software Meeting 12 TGeant4 implementation Geant4 VMC provides a default physics list Modular physics list composed of physics constructors from Geant4 novice examples N04, N06: EM, Hadronic, Optical, Special cuts Possibility to switch on/off some physics constructors via G4 commands User own physics list User can include his own physics list using the CBMRunConfiguration class

13. 10.05.2004CBM Software Meeting 13 TGeant4 implementation Special cuts –Possibility to set cuts in G3 style (cuts in kinetic energy per material) Not by default, activated by invoking the command /mcPhysics/setSpecialCuts true –Implementation via a special cuts process and user limits Cuts applied as tracking cuts, not threshold –2 nd implementation using “cuts per material” Cuts applied as threshold Not included in distribution will require a move to “cuts per region”

14. 10.05.2004CBM Software Meeting 14 ROOT Run Manager Virtual MC G3G4FLUKA Pluto Ion Generator Particle Generator ASCII PIPE Target STS TRD Cave TOF Magnet RICH Generators Mixed Generator Urqmd Magnetic Field Module Detector Geometry Manager IO Manager Tasks List Delta Tracking Field Map CBM Analysis and Simulation Framework digitizers

15. 10.05.2004CBM Software Meeting 15 CBMRun interface –The main Run Manager class (singleton) –Can steer Simulation Run (Geant3/Geant4) –Init of MCs(Geant config macro) –Readers (Materials/Geometry) –Field/Generators setup Analysis –Merging transported events –Merging several analysis data levels –Setting list of TTasks –Analysis initialisation –Non persistent Methods for Merging Input data (sim+analysis) Methods for Accessing Geometry Methods for Accessing Materials Methods for Building Modules/TTasks Methods For Initialising MC/Analysis CBMRun CBMRun: Connect Input data Build output data Methods For setting Generators/Field

16. 10.05.2004CBM Software Meeting 16 CBMMCApplication CBMMCApplication Derives from TVirtualMCApplication –Interface to standard MC functions –Defines user actions at each stage of a simulation run –Configurable via the CBMRun manager class. –Persistent : Stores the simulation Run Info –Geometry/Materials (TGeo) –New Particles definition –Field settings ConstructGeometry InitGeometry GeneratePrimaries DefineNewParticle BeginEvent BeginPrimary PreTrack Stepping PostTrack FinishPrimary FinishEvent CBMMCApplication

17. 10.05.2004CBM Software Meeting 17 CBMStack Interface to a user defined particles stack Simulation: –Used as an External Stack for MC engine –No intrinsic stack size limitation Analysis: –CBMStack is Persistent: Stores the list of MC particles ( primaries + secondaries ) TClonesArray of TParticles (ROOT base class for particle definition) TParticle trackID correspond to the TParticle slot position (index) Full Decay history – Int_t TParticle::GetFirstMother(); – Int_t TParticle::GetSecondMother(); TParticle creation process stored using TMCProcess class CBMStack : public TVirtualMCStack { // … virtual void PushTrack (Int_t toBeDone, Int_t parent, Int_t pdg, Double_t px, Double_t py, Double_t pz, Double_t e, Double_t vx, Double_t vy, Double_t vz, Double_t tof, Double_t polx, Double_t poly, Double_t polz, TMCProcess mech, Int_t& ntr, Double_t weight, Int_t is) ; virtual TParticle* PopNextTrack (Int_t& track); virtual TParticle* PopPrimaryForTracking (Int_t i); virtual void SetCurrentTrack(Int_t track); // get methods virtual Int_t GetNtrack(); const; virtual Int_t GetNprimary() const; virtual TParticle* GetCurrentTrack(); const; virtual Int_t GetCurrentTrackNumber() const; virtual Int_t GetCurrentParentTrackNumber() const; TParticle* GetParticle(Int_t id) const; ….}

18. 10.05.2004CBM Software Meeting 18 CBMStack : TMCProcess enum TMCProcess { kPPrimary, // Primary interaction kPMultipleScattering, // multiple scattering kPEnergyLoss, // continuous energy loss kPMagneticFieldL, // bending in mag. field kPDecay, // particle decay kPPair, // photon pair production or // muon direct pair production kPCompton, // Compton scattering kPPhotoelectric, // photoelectric effect kPBrem, // bremsstrahlung kPDeltaRay, // delta-ray production kPAnnihilation, // positron annihilation kPHadronic, // hadronic interaction kPEvaporation, // nuclear evaporation kPNuclearFission, // nuclear fission kPNuclearAbsorption, // nuclear absorption kPPbarAnnihilation, // antiproton annihilation kPNCapture, // neutron capture kPHElastic, // hadronic elastic incoherent scattering kPHInhelastic, // hadronic inelastic scattering kPMuonNuclear, // muon nuclear interaction kPTOFlimit, // exceeded time of flight cut kPPhotoFission, // nuclear photofission kPRayleigh, // Rayleigh scattering kPNull, // no mechanism is active, usually at the entrance // of a new volume kPStop, // particle has fallen below energy threshold // and tracking stops kPLightAbsorption, // Cerenkov photon absorption kPLightScattering, // Cerenkov photon reflection/refraction kStepMax, // step limited by STEMAX kPCerenkov, // Cerenkov photon generation kPFeedBackPhoton, // Feed back photon in RICH -- kPLightReflection, // Cerenkov photon reflection kPLightRefraction, // Cerenkov photon refraction kPSynchrotron, // synchrotron radiation generation kPTransportation, // Transportation kPNoProcess // unknown process };

19. 10.05.2004CBM Software Meeting 19 CBMDetector –The Detector base class –Added in the CBMRun Active/Inactive: –CBMDetector(const char * Name, Bool_t Active); –Active=kTRUE, kFALSE. ConstructGeometry() –TGeoMCGeometry (TGeo) –Defines: »Shapes, positions ProcessHits(CBMVolume *v) –Define hits for corresponding CBMVolume –Store the selected hits in event store Initialize() Create corresponding data level Register the new Data level in event store ProcessHit( CBMVolume *v) Hit Definition Hit storage CBMDetector CBMDetector: Method to Construct the Geometry -Using TGeoMCGeometry (TGeo) -- Shape defs, position defs. --Material definition

20. 10.05.2004CBM Software Meeting 20 Hit production The CBMMCApplication stepping function is called by MC at each step The CBMMCApplication forward this call to the corresponding sensitive detector The corresponding CBMDetector gets the properties of the tracked particle by calls to TVirtualMC and saves them in their own hits objects void CBMDetector:: ProcessHit(CBMVolume *v) { // Get track position Double_t x, y, z; gMC->TrackPosition(x, y, z); // Get energy deposit Double_t edep = gMC->Edep(); // Create detector hit if ( edep) mySD->AddHit(x, y, z, edep); } ConstructGeometry InitGeometry GeneratePrimaries BeginEvent BeginPrimary PreTrack Stepping PostTrack FinishPrimary FinishEvent CBMMCApplication

21. 10.05.2004CBM Software Meeting 21 Analysis organisation: Tasks TMainTask Exec() TTask Exec() ExecuteTasks() TTask TTask1 Exec() TTask TTask22 Exec() TTask TTask11 Exec() TTask TTask2 Exec() TTask TTask21 Exec() TTask TTask211 Exec() TTask TTaskN Exec() TList

22. 10.05.2004CBM Software Meeting 22 Data Level Structure CBMTask2 input output Det 2 CBMTask1 input output Det 1 CBMTask3 input output filter CBMRun: TMainTask Input TTree TClonesArray of MCPoints Output TTree TClonesArray of Det 1 Hits Output TTree TClonesArray of Det 1 Hits TClonesArray of Det 2 Hits TClonesArray of Filtered Hits Output TTree TClonesArray of Det 1 Hits TClonesArray of Det 2 Hits Number of partially elaborated data levels is detector dependant, even algorithm dependant.

23. 10.05.2004CBM Software Meeting 23 CBMROOTManager –Central repository where to access/ register data from Simulation Analysis Task –Input Data Manipulation Merging of transported event Merging of Data levels Method to store TObject Register(name,folder,TObject* obj) Register(name,folder,TCollection* obj) Input Data Manipulation AddFriend( ) AddAndMerge() CBMRootManager Holds event store: Method to access Data From file: ActivateBranch( brname) From Memory: GetRegisteredObject( brname)

24. 10.05.2004CBM Software Meeting 24 Storage of Data Objects Use of TClonesArray –Specialization of TObjArray for holding Data Objects having the same size. Advantages: –Performance: Memory for all objects will be allocated once for the entire array, rather than a per-object allocation. ( same size object) –IO: In Standard TCollection, each object is written sequentially. In TClonesArray: –each object is split one level deep into its base class and data members –Each data member is written sequentially for all objects before the next member is written. –Greater compression if similar data is consecutive. –Full Splitting of data members-> branch -> direct access to Data members ( TBrowser)

25. 10.05.2004CBM Software Meeting 25 Simulation output Data Object : MCPoints/MCDoublePoint class CBMMCDoublePoint : public TObject { protected: Int_t fTrackID[2]; Int_t fDetectorID[2]; Double_t fEtot[2]; Double_t fEloss[2]; Double_t fTime[2]; Double_t fLength[2]; TVector3 fPosition_in; TVector3 fPosition_out; TVector3 fMomentum_in; TVector3 fMomentum_out; …} class CBMMCPoint : public TObject { protected: Int_t fTrackID; Int_t fDetectorID; Double_t fEtot; Double_t fEloss; Double_t fTime; Double_t fLength; TVector3 fPosition; TVector3 fMomentum; …}

26. 10.05.2004CBM Software Meeting 26 First Analysis Output Data Level: CBMHit CBMDoubleHit class CBMHit : public TObject { protected: Int_t fRefIndex; Int_t fDetectorID; TVector3 fPosition; TVector3 fPositionError; …} class CBMDoubleHit : public TObject { protected: Int_t fRefIndex; Int_t fDetectorID; TVector fPosition_in; TVector3 fPositionError_in; TVector3 fPosition_out; TVector3 fPositionError_out; …}

27. 10.05.2004CBM Software Meeting 27 Connecting Data Levels Every Analysis tasks produces detector/algorithm dependant Data Levels Problem: we don’t want to copy always all Data Levels in one BIG TTree –Not optimized ( IO, mass storage) –Not suitable in code development period Solution: –CBM_VMC support usage of friend TTree Mechanism