CBM Simulation & Analysis Framework

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

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 Outline CBM Software Meeting

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 Motivations : Simulation CBM Software Meeting

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. Motivations : Analysis CBM Software Meeting

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. Requirements CBM Software Meeting

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 Requirements CBM Software Meeting

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 CBM Framework: Features CBM Software Meeting

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 The Virtual Monte Carlo (VMC) CBM Software Meeting

VMC Interface CBM Software Meeting

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

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 TGeant3 implementation CBM Software Meeting

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 CBM Software Meeting

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 2nd implementation using “cuts per material” Cuts applied as threshold Not included in distribution will require a move to “cuts per region” TGeant4 implementation CBM Software Meeting

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

CBMRun: CBMRun interface CBMRun Connect Input data Build output data Methods for Merging Input data (sim+analysis) • 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 Accessing Geometry Methods for Accessing Materials Methods for Building Modules/TTasks Methods For setting Generators/Field Methods For Initialising MC/Analysis CBM Software Meeting

CBMMCApplication CBMMCApplication • ConstructGeometry • InitGeometry • GeneratePrimaries • DefineNewParticle • 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 • BeginEvent • BeginPrimary • PreTrack • Stepping • PostTrack • FinishPrimary • FinishEvent CBM Software Meeting

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 CBMStack 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; ….} CBM Software Meeting

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 CBMStack : TMCProcess 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 }; CBM Software Meeting

CBMDetector: CBMDetector CBMDetector • Method to Construct the Geometry • Using TGeoMCGeometry (TGeo) • - Shape defs, position defs. • -Material definition • 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 CBM Software Meeting

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 Hit production voidCBMDetector:: 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); } CBMMCApplication ConstructGeometry InitGeometry GeneratePrimaries BeginEvent BeginPrimary PreTrack Stepping PostTrack FinishPrimary FinishEvent CBM Software Meeting

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

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

Holds event store: CBMROOTManager CBMRootManager Method to access Data From file: ActivateBranch( brname) From Memory: GetRegisteredObject( brname) • 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() CBM Software Meeting

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) Storage of Data Objects CBM Software Meeting

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; …} Simulation output Data Object : MCPoints/MCDoublePoint 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; …} CBM Software Meeting

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

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 Connecting Data Levels CBM Software Meeting

CBM Simulation & Analysis Framework