cbm simulation & analysis framework

10.05.2004 CBM Software Meeting 1

CBM Simulation & Analysis FrameworkCBM Simulation & Analysis Framework

M. Al-Turany, D. Bertini


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


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


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.


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.


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


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


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


VMC InterfaceVMC Interface


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


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



• 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



• 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”


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


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


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


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; ….}


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};


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


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


Analysis organisation: TasksAnalysis organisation: Tasks

TMainTaskExec()

TTaskExec()ExecuteTasks()

TTask

TTask1Exec()

TTask

TTask22Exec()

TTask

TTask11Exec()

TTask

TTask2Exec()

TTask

TTask21Exec()

TTask

TTask211Exec()

TTask

TTaskNExec()

TList

TList


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


of Det 1 Hits

• TClonesArray of Det 2 Hits

• TClonesArray of Filtered Hits


of Det 1 Hits

• TClonesArray of Det 2 Hits

• Number of partially elaborated data levels is detector dependant, even algorithm dependant.


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)


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)


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;

…}


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;

…}


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

cbm simulation & analysis framework

Documents

data analysis

data structures

reconstruction algorithms

optimized data structure

elaborated data levels

ttree ttree

different detectors

reliable simulation