class ParameterisedScintillator : public G4VPVParameterisation{private:

G4Box aBox;G4Tubs aTubs;G4Sphere aSphere;

public:ParameterisedScintillator ():

aBox("a box",10.,10.,10.),aTubs("a tubs",0.,10.,10.,0.,45.*deg),aSphere("a sphere",0.,10.,0.,360.*deg,0.,180.*deg)

{}

virtual G4VSolid* ComputeSolid(const G4int n, G4VPhysicalVolume* pRep)

{if (n%2==0)

return &aBox;else if (n%3==0)

return &aTubs;else

return &aSphere;}

virtual void ComputeTransformation(const G4int m, G4VPhysicalVolume* pRep) const

{G4ThreeVector position(m*30.*cm,0.,0.);pRep->SetTranslation(position);

// pRep->SetRotation(rm);}

virtual void ComputeDimensions(G4Box &pBox, const G4int n, const G4VPhysicalVolume* pRep) const

{G4double delx=n*2*cm;G4double dely=n*.5*cm;G4double delz=n*1.*cm;

pBox.SetXHalfLength(delx); pBox.SetYHalfLength(dely);

pBox.SetZHalfLength(delz); }

virtual void ComputeDimensions(G4Tubs &pTubs, const G4int n, const G4VPhysicalVolume* pRep) const

{pTubs.SetInnerRadius(0.*cm);pTubs.SetOuterRadius(n*2*cm);pTubs.SetZHalfLength(10*cm);

}virtual void ComputeDimensions(G4Sphere &pSphere,

const G4int n, const G4VPhysicalVolume* pRep) const

{pSphere.SetInsideRadius(0.*cm);pSphere.SetOuterRadius(n*2*cm);

}

parameterisation

• The aim of the exercise is again to build a lead-scintillator calorimeter, this time though the calorimeter will be a trapezoid (wedge) and one must position scintillator plates into it made out of boxes

• use the parameterisation which is already provided (ParameterisedScintillator.hh), figure out how many parameters do you need for doing the job, fill up the ComputeTransformation() and ComputeSolid()

Touchables

Touchables

• Touchable Volumes provide a way of uniquely identifying a detector element in the geometrical hierarchy– for navigating in the geometry tree for storing hits

– for providing a geometry description alternative to the one used by the Geant4 tracking system

– for parameterised geometries

• A touchable is a geometrical volume (solid) which has a unique placement in a detector description

• In Geant4, touchables are implemented as solids associated to a transformation matrix in the global reference system or as a hierarchy of physical volumes

G4VTouchable

• All G4VTouchable implementations must respond to at least two requests:– GetTranslation() and GetRotation() that return the components and the volume’s

transformation– GetSolid() that gives the solid associated to the touchable

• additional requests can be satisfied by touchables keeping a physical volume– GetVolume() which returns a physical volume– GetReplicaNumber() which returns the copy nr. (if set)

• Touchables that store a complete stack of parent volumes, thus it is possible to add more functionality– GetHistoryDepth() to retrieve how many levels are there in the tree– MoveUpHistory(n) allows to navigate in the tree

Touchable History

• A logical volume represents unpositioned detector elements, even a physical volume can represent multiple detector elements

• Touchables provide a unique identification for a detector element– Transportation and tracking exploit the implementation of touchables

implemented via the TouchableHistory

• TouchableHistory is the minimal set of information required to build the full genealogy on top of a given physical volume up to the root of the geometrical tree

• Touchables are made available to the user at every step during tracking by means of a G4Step object

Touchable History (2)

• To create a G4TouchableHistory you must ask the navigator– G4TouchableHistory* CreateTouchableHistory() const;

• to navigate in the geometrical tree you can use– G4int GetHistoryDepth() const;

– G4int MoveUpHistory(G4int num_levels=1);

• The first method tells you how many level deep in the current tree the volume is, the second asks the touchable to eliminate its deepest level

• The MoveUpHistory significantly modifies the state of the touchable

Hits

G4Step

• The information about what happened in the last step can be gathered from an object of type G4Step, for instance in the stepping action– pointers to PreStep and PostStepPoint– Geometrical step length– True step length– delta of position/time between PreStep and PostStepPoint– Delta of momentum/energy between PreStep and PostStepPoint– pointer to a G4Track– Total energy deposited during the step. This is the sum of:

• Energy deposited by energy loss process• Energy loss by secondaries which have not been generated because their

energies were below the cut threshold

G4Step (2)

• The information in G4StepPoint (PreStep and PostStepPoint) is:– (x,y,z,t)– (px,py,pz,Ek)– momentum direction– Pointers to the physical volumes– Safety– Beta, Gamma– Polarization– Step status– Pointer to the physics process for the current step– Pointer to the physics process for the previous step– Total track length– Global time– Local time– Proper time

calorimeter (1)• Example based on the Replica example (10x10 cells this time,

in an array)

• compile the example, verify that it works

• add a stepping action (get it from the calorimeter/util directory)

• print out the G4Step contents, step by step (but use a geantino!!!)

• get the physical volume – astep->GetPreStepPoint()->GetPhysicalVolume();

• go back to the logical volume by using the physical volume methods (have a look to the G4PhysicalVolume definition to discover how to do it), get its name, its material...

calorimeter (1)

• Get the TouchableHistory– (G4TouchableHistory*)(aStep->GetPreStepPoint()->GetTouchable()

• get the scintillator identifier and the cell nr. by navigating through the TouchableHistory

• calculate the amount of energy lost in the scintillator, the thickness in r.l. of the calorimeter, whatever you want…

• in calorimeter/util there is an HBookManager for helping you with histograms (Hbook), use it!

Hit

• A Hit is a snapshot of a physical interaction of a track in a sensitive region of the detector

• One can store various informations associated with a G4Step object, like:– Position and time of the step

– momentum of the track

– energy deposition of the step

– geometrical information

G4VHit• G4VHit is an abstract class which represents a hit

• The User has to inherit from this base class and derive his/her own concrete class

• The data members in particulare (I.e. the information that the hit will carry along) must be chosen by the user

• G4VHit has two virtual methods, Draw() and Print() which must be implemented to hae the hits drawn and printed

• Hits are associated to the current event by means of a concrete class derived from G4VHitsCollection, which represents a vector of user-defined hits

• G4THitsCollection is a template class derived from G4VHitsCollection which can contain a particular concrete class derived from G4VHit

ExN04TrackerHit#ifndef ExN04TrackerHit_h

#define ExN04TrackerHit_h

#include “G4VHit.hh”

#include “G4THitsCollection.hh”

#include “G4ThreeVector.hh”

class ExN04TrackerHit: public G4VHit

{

public:

ExN04TrackerHit();

~ExN04TrackerHit();

ExN04TrackerHit(const ExN04TrackerHit &right);

const ExN04TrackerHit& operator=(const ExN04TrackerHit &right);

int operator==(const ExN04TrackerHit &right) const;

void Draw() const;

void Print() const;

private:

G4double edep;

G4ThreeVector pos;

ExN04TrackerHit (2)

public:

inline void SetEdep(G4double de)

{edep=de;}

inline G4double GetEdep() const

{return edep;}

inline void SetPos(G4ThreeVector xyz)

{pos=xyz;}

inline G4ThreeVector GetPos() const

{return pos;}

};

#endif

G4VSensitiveDetector

• G4VSensitiveDetector is an abstract base class which represents a detector

• The principal mandate of a sensitive detector is the construction of one or more hit objects using the information given in the G4Step object and an optional G4TouchableHistory class object for the ReadOut geometry: these object are the arguments of the method ProcessHits()

• The concrete sensitive detector class should be instanciated with the unique name of a detector. The name can be associated with one or more global names for categorizing the detectorsmyEMcal = new myEMcal(“/myDet/myCal/myEMcal”);

• The pointer to the sensitive detector must be set to one or more G4LogicalVolume object and registered with G4SDManager

G4VSensitiveDetector (2)• G4VSensitiveDetector has three major virtual methods:

– Initialize()

• This method is invoked at the beginning of each event. The argument of this method is an object of G4HCofThisEvent class. Hits collections, where hits produced in this particular event are stored, can be associated to G4HCofThisEvent

– ProcessHits()

• This method is invoked by G4SteppingManager when a step takes place in the G4LogicalVolume which point to this sensitive detector. The first argument of this method is a G4Step object for the current step. The second argument is a G4TouchableHistory object for the ReadOut geometry, if described. In this method, one or more G4VHit objects should be constructed if the current step has to be registered

– EndOfEvent()

• This method is invoked at the end of each event, again to associate hits collections to G4HCofThisEvent

ReadOut Geometry

• The ReadOut geometry is a virtual, parallel geometry which can be used for describing the read-out configuration of the detector– The accordion calorimeter has a very complicated geometry. However, the

readout will be performed by grouping electrodes together to form cells which can be described with a much simpler geometry

• Tracks will be traced in the tracking geometry (the real oneand the sensitive detector will have its own geometry that Geant4 will message to find out which “readout” cell the current hit belongs to

• The Sensitive Detector will be associated to the tracking geometry in the normal way. Then, an object of type G4VReadoutGeometry will be associated to the sensitive detector

ReadOut Geometry (2)

• At tracking time, the class G4VReadoutGeometry will provide the sensitive detector with the G4TouchableHistory in the readout geometry at the beginning of the step, and at this position only

• The G4TouchableHistory object is given to the sensitive detector code by means of the G4VSensitiveDetector method:G4bool processHits(G4Step *aStep, G4TouchableHistory *Rohist)

in this way, one can make use at the same time of the information coming from the step (G4Step) and from the readout geometry (via the G4TouchableHistory)

• Since the association is done through a sensitive detector object, it is possible to have several RO geometries in parallel

Definition of a virtual geometry setup• The base class for the implementation of a readout geometry is

G4VReadoutGeometry. This class has a pure virtual method:virtual G4VPhysicalVolume* build()=0;

which one must define in the concrete class, in order to return the physical World volume for the readout geometry

• The step-by-step procedure for constructing a readout geometry is the following:– inherit from G4VReadoutGeometry to define a “MyROGeom” class– implement the RO geometry in the build() method, returning the physical World volume fom

this geometry• in this geometry you have to declare the sensitive parts in the same way as in the tracking

geometry; the pointer to the sensitive detector needs to be there but it willnot be used. You will have to use well defined materials for describing the volumes, but these will not be seen by tracking

Definition of a virtual geometry setup (2)

– In the construct() method of the concrete G4VUserDetectorConstruction class you must

• instanciate the readout geometry:

MyROGeom *ROGeom = new MyROGeom(“ROName”);

• build it:

ROGeom->build();

• Instanciate the sensitive detector which will receive the ROGeom pointer, MySensitive, and add this sensitive detector to the G4SDManager. Associate this sensitive detector to the volume(s) of the tracking as usual. Associate the readout geometry to the sensitive detector

MySensitive->set_ROGeometry(ROGeom);

Access to the hits collections

• Hits collections are accessed for various purposes– Digitization– Event Filtering in G4VUserStackingAction– “End of Event” simple analysis– Drawing/printing hits

• To access the hits collections one must go through the SD ManagerG4SDManager* fSDM=G4SDManager::GetSDMpointer();

G4RunManager* fRM=G4RunManager::GetRunManager();

G4int collectionID=fSDM->GetCollectionID(“collection name”);

const G4Event* currentEvent=fRM->GetCurrentEvent();

G4HCofThisEvent *HCofEvent=currentEvent->GetHCofThisEvent();

MyHitsCollection *myCollection=

(MyHitsCollection *)(HCofEvent->GetHC(collectionID));

calorimeter (2)

• Create a sensitive detector in the detector construction and assign it to the scintillator logical volumeG4SDManager *sdman=G4SDManager::GetSDMpointer();

CalorimeterSensitiveDetector *CaloSd=

new CalorimeterSensitiveDetector(“Calorimeter”);

sdman->AddSensitiveDetector(CaloSd);

scin_log->SetSensitiveDetector(CaloSD)

• See that you can accumulate energy from within the ProcessHits method of the sensitive detector

• create hits from within the ProcessHits() method– CalorimeterHit* caloHit=new CalorimeterHit(CellID,ScinID,e);

• create a hit collection by booking a name in the constructor of the sensitive detector

calorimeter (2)

collectionName.insert(“CalorimeterCollection”);

• …and by creating the collection in the Initialize method of the sensitive detectorcaloHitsCollection=new CalorimeterHitsCollection

(SensitiveDetectorName,collectionName[0]);

• insert the hits in the collection– int icell=caloHitsCollection->insert(caloHit);

• insert the collection in the hits collections of the eventstatic G4int HCID=-1;

if (HCID<0) HCID=GetCollectionID(0);

HCE->AddHitsCollection(HCID,caloHitsCollection);

Run and Event

G4Run and G4RunManager

• In Geant4, the Run is the largest unit of simulation and it consist of a series of events

• Within a Run, the detector geometry, the setup of the sensitive detectors and the physics processes cannot be modified

• A Run is represented by an object of the G4Run class

• A Run begins when the beamOn() method of the G4RunManager class is invoked

G4Run

• G4Run contains a run identification number which should be set by the user and the number of events to be simulated during that Run

• The Run identification number is not used by the Geant4 kernel and it is then an arbitrary number which is provided for the convenience of the user

• G4Run contains pointers to the name tables of G4VHitsCollection’s and G4VDigiCollection’s which are associated in case Sensitive Detectors and Digitizers are implemented

G4RunManager

• The G4RunManager class manages the procedures of a run. In the G4RunManagerConstructor, all the Geant4 manager classes are constructed. These managers are then deleted in the G4RunManager destructor

• G4RunManager is a singleton, only one run manager can exist throughout the whole program. A pointer to this object can be obtained by invoking the G4RunManager’s method GetRunManager()

• All user initialization classes and user action classes should be assigned to G4RunManager before the initialization of the Geant4 kernel by using the SetUserInitialization() and the SetUserAction() methods

G4RunManager’s public methods

• Initialize()– construction of the detector geometry and setup of the sensitive detectors/digitizers

– construction of particles and physics processes

– calculation of cross-section tables

• beamOn(G4int numberOfEvents)– triggers the actual simulation of a run (event loop). It takes an integer argument,

the number of events to be simulated

• GetRunManager()– returns the pointer to the G4RunManager singleton object

• GetCurrentEvent()– returns a pointer to the G4Event object currently being simulated. This method is

only available while events are being produced (EventProc state). A const pointer is returned (read-only)

G4RunManager’s public methods (2)

• SetNumberOfEventsToBeStored(G4int nPrevious)– For the case of piling up more than one event, it is essential to

access more than one event at the same moment. By invoking this method, G4RunManager keeps nPrevious G4Event objects in memory. This method must be invoked before beamOn()

• GetPreviousEvent(G4int i_thPrevious)– Returns a pointer to the i_thPrevious G4Event object stored. The

pointer returned is const, hence the G4Event returned cannot be modified

G4UserRunAction

• G4UserRunAction is one of the user action classes one can derive his/her concrete class from

• The G4UserRunAction class has two virtual methods the user must implement– BeginOfRunAction()

• invoked at the beginning of the beamOn() method but after confirming the conditions of the Geant4 kernel. To be used for setting the run identification number, book histograms, setup run-specific conditions, etc..

– EndOfRunAction()• invoked at the very end of the beamOn() method. It can be used

to store histograms, manipulate run summaries, etc...

Geant4 is a state machine• Geant4 is designed as a state machine. Certain methods are only available in certain states.

G4RunManager controls the state changes.

– PreInit state• The application starts in this state. Geant4 need to be initialized. The application comes back to this state if

geometry, physics or cut-off have been modified

– Init state• G4RunManager initialize() is being invoked

– Idle state• The application is ready to process a run

– GeomClosed state• beamOn() has been invoked

– EventProc state• An event is being processed. GetCurrentEvent() and GetPreviousEvent() are only available at this state

– Quit state• G4RunManager’s destructor has been invoked. The application is dead

Aborting a run

• To abort a Geant4 run being processed (for whichever reason) the AbortRun() method of G4RunManager must be invoked

• AbortRun() is only available in the GeomClosed and EventProc states

• AbortRun() safely stops the run processing even when a particular event is being simulated

• The last event of the aborted run is incomplete and it should not be used for further analysis

Customizing G4RunManager

• G4RunManager, still being a concrete class, has a complete set of virtual functions. The user may decide to inherit his/her own manager class and re-implement part or most of the functionality of the G4RunManager

public: virtual void initialize(); main entry point of GEANT4 kernel initializationvirtual void DefineWorldVolume(G4VPhysicalVolume * worldVol); Set the world volume to G4Navigatorvirtual void AbortRun(); Run abortionvirtual void beamOn(G4int n_event) main entry point of the event loop

protected: virtual void InitializeGeometry(); Geometry constructionvirtual void InitializePhysics(); physics processes constructionvirtual void InitializeCutOff(); Build cross-section tablesvirtual G4bool ConfirmBeamOnCondition(); Check the kernel conditions for the event loopvirtual void RunInitialization(); Prepare a runvirtual void DoEventLoop(G4int n_events); Manage an event loopvirtual G4Event* GenerateEvent(G4int i_event); Generation of G4Event objectvirtual void AnalyzeEvent(G4Event* anEvent); Storage/analysis of an eventvirtual void RunTermination(); Terminate a run

Changing the detector geometry

• The detector geometry defined in G4VUserDetectorConstruction class can be changed during the run break (between two runs)– In the case one wants to delete the entire structure and set up a completely new

structure, one has to register the new World volume with G4RunManager

– More likely, one may want to modify his/her geometry only slightly (e.g. rotate a testbeam setup wrt the beam line or modify the thickness of the active layers of a calorimeter). This action does generally not require a complete redefinition of the geometry and can normally be implemented by calling some function at the beginning of each run.

• In any case, G4RunManager must be notified that the geometry must be re-built

G4RunManager* runManager = G4RunManager::GetRunManager();MyNewGeometry newGeometry;G4VPhysicalVolume* newWorldPhys=newGeometry.Construct();runManager->DefineWorldVolume(newWorldPhys);

runManager->GeometryHasBeenModified()

Events

• An Event in Geant4 is represented by the class G4Event, which contains all quantities needed to characterize the simulated event

• A G4Event object is constructed by the G4RunManager and sent to the G4EventManager

• The event being processed can be gotten at any moment by means of the GetCurrentEvent() method of G4RunManager

G4Event

• An G4Event object contains four major pieces of information which are available via get methods– Primary vertexes and primary particles

– Trajectories

• Stored in an object of type G4TrajectoryContainer, which can can be accessed from G4Event

– Hits collections

• Generated by Sensitive Detectors, they are kept in an object of type G4HCofThisEvent, whose pointer is kept in G4Event

– Digits collections

• Generated by Digitizers, they are kept in an object of type G4DCofThisEvent, whose pointer is kept by G4Event

G4EventManager

• G4EventManager is the manager class which takes care of the Event. Its main tasks are– to convert G4PrimaryVertex and G4PrimaryParticle objects associated with

the current G4Event object to G4Track objects. All G4Track objects are sent to G4StackManager

– Pop one track object from G4StackManager and send it to G4TrackingManager. The current G4Track object is deleted by G4EventManager after the track is simulated by G4TrackingManager, if the track is marked as “killed”

– In case the primary track is “suspended” or “postponed to the next event”, it is sent back to the G4StackManager. Secondary G4Track object returned by G4TrackingManager are also sent to G4StackManager

– When G4StackManager returns NULL to the pop request, G4EventManager terminates the current event processing

G4UserEventAction

• G4UserEventAction is one of the user action classes

• G4UserEventAction has two virtual method which are invoked for each event and which can be implemented by the user– BeginOfEventAction()

• Invoked before converting the primary particles to G4Track objects. Used for initialization and/or histogram booking for one particular event

– EndOfEventAction()

• Invoked at the very end of the event processing. Used for simple analysis of the current event