10.05.2004 CBM Software Meeting 1
CBM Simulation & Analysis FrameworkCBM Simulation & Analysis Framework
M. Al-Turany, D. Bertini
10.05.2004 CBM Software Meeting 2
OutlineOutline
• 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
10.05.2004 CBM Software Meeting 3
Motivations : SimulationMotivations : 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
10.05.2004 CBM Software Meeting 4
Motivations : AnalysisMotivations : 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.
10.05.2004 CBM Software Meeting 5
RequirementsRequirements
• 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.
10.05.2004 CBM Software Meeting 6
RequirementsRequirements
• 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
10.05.2004 CBM Software Meeting 7
CBM Framework: FeaturesCBM 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
10.05.2004 CBM Software Meeting 8
The Virtual Monte Carlo (VMC)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
10.05.2004 CBM Software Meeting 9
VMC InterfaceVMC Interface
10.05.2004 CBM Software Meeting 10
Virtual Monte Carlo (VMC)Virtual Monte Carlo (VMC)
User Code
VMC
Virtual Geometrical
Modeller
G3 G3 transport
G4 transportG4
FLUKA transportFLUKA
Geometrical Modeller
Reconstruction
Visualisation
Geant4_mc.tar.gz includesthe TVirtualMC <--> Geant4
interface classes
Geant3.tar.gz includesan upgraded Geant3
with a C++ interface
10.05.2004 CBM Software Meeting 11
TGeant3 implementationTGeant3 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
10.05.2004 CBM Software Meeting 12
TGeant4 implementationTGeant4 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
10.05.2004 CBM Software Meeting 13
TGeant4 implementationTGeant4 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
– 2nd implementation using “cuts per material”• Cuts applied as threshold
• Not included in distribution will require a move to “cuts per region”
10.05.2004 CBM Software Meeting 14
ROOT
Run Manager
Virtual MC
G3 G4 FLUKA
Pluto
Ion Generator
Particle Generator
ASCIIPIPE
Target
STS
TRD
Cave
TOF
Magnet
RICH
Generators
Mixed Generator
Urqmd
Magnetic
Field
Module
Detector
GeometryManager
IO Manager
Tasks ListDelta
Tracking
Field Map
CBM Analysis and Simulation FrameworkCBM Analysis and Simulation Framework
digitizers
10.05.2004 CBM Software Meeting 15
CBMRun interface 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
10.05.2004 CBM Software Meeting 16
CBMMCApplicationCBMMCApplication
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
ConstructGeometryInitGeometryGeneratePrimariesDefineNewParticle
BeginEventBeginPrimaryPreTrackSteppingPostTrackFinishPrimaryFinishEvent
CBMMCApplication
10.05.2004 CBM Software Meeting 17
CBMStackCBMStack
• 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; ….}
10.05.2004 CBM Software Meeting 18
CBMStack : TMCProcessCBMStack : 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};
10.05.2004 CBM Software Meeting 19
CBMDetectorCBMDetector
– 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
10.05.2004 CBM Software Meeting 20
Hit productionHit 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 hitif ( edep) mySD->AddHit(x, y, z, edep);}
ConstructGeometryInitGeometryGeneratePrimaries
BeginEventBeginPrimaryPreTrackSteppingPostTrackFinishPrimaryFinishEvent
CBMMCApplication
10.05.2004 CBM Software Meeting 21
Analysis organisation: TasksAnalysis organisation: Tasks
TMainTaskExec()
TTaskExec()ExecuteTasks()
TTask
TTask1Exec()
TTask
TTask22Exec()
TTask
TTask11Exec()
TTask
TTask2Exec()
TTask
TTask21Exec()
TTask
TTask211Exec()
TTask
TTaskNExec()
TList
TList
10.05.2004 CBM Software Meeting 22
Data Level StructureData Level Structure
CBMTask2
input
outputDet 2
CBMTask1
input
outputDet 1
CBMTask3
input
outputfilter
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.
10.05.2004 CBM Software Meeting 23
CBMROOTManagerCBMROOTManager
– 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 TObjectRegister(name,folder,TObject* obj)Register(name,folder,TCollection* obj)
Input Data ManipulationAddFriend( )
AddAndMerge()
CBMRootManager
Holds event store: Method to access Data
From file: ActivateBranch( brname)From Memory: GetRegisteredObject( brname)
10.05.2004 CBM Software Meeting 24
Storage of Data ObjectsStorage 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)
10.05.2004 CBM Software Meeting 25
Simulation output Data Object : Simulation output Data Object : MCPoints/MCDoublePointMCPoints/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;
…}
10.05.2004 CBM Software Meeting 26
First Analysis Output Data Level:First Analysis Output Data Level:CBMHit CBMDoubleHitCBMHit 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;
…}
10.05.2004 CBM Software Meeting 27
Connecting Data LevelsConnecting 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