Gabriele Cosmo
203 lines
8.7 KiB
Plaintext
203 lines
8.7 KiB
Plaintext
-------------------------------------------------------------------
|
|
|
|
=========================================================
|
|
Geant4 - an Object-Oriented Toolkit for Simulation in HEP
|
|
=========================================================
|
|
|
|
Example B3
|
|
----------
|
|
|
|
This example simulates schematically a Positron Emitted Tomography system.
|
|
|
|
1- GEOMETRY DEFINITION
|
|
|
|
The support of gamma detection are scintillating crystals. A small number
|
|
of such crystals are optically grouped in a matrix of crystals. In
|
|
this example, individual crystals are not described; only the matrix of
|
|
crystals is and it is still called 'Crystal' hereafter.
|
|
|
|
Crystals are circularly arranged to form a ring. Few rings make up the full
|
|
detector (gamma camera). This is done by positionning Crystals in
|
|
Ring with an appropriate rotation matrix. Several copies of Ring are
|
|
then placed in the full detector.
|
|
|
|
The head of a patient is schematised as a homogeneous cylinder of brain
|
|
tissue, placed at the center of full detector.
|
|
|
|
The Crystal material, Lu2SiO5, is not included in the G4Nist database.
|
|
Therefore, it is explicitly built in DefineMaterials().
|
|
|
|
2- PHYSICS LIST
|
|
|
|
The physics list contains standard electromagnetic processes and the
|
|
radioactiveDecay module for GenericIon. It is defined in the B3::PhysicsList
|
|
class as a Geant4 modular physics list with registered physics builders
|
|
provided in Geant4:
|
|
- G4DecayPhysics - defines all particles and their decay processes
|
|
- G4RadioactiveDecayPhysics - defines radioactiveDecay for GenericIon
|
|
- G4EmStandardPhysics - defines all EM standard processes
|
|
|
|
This physics list requires data files for:
|
|
- low energy electromagnetic processes which path is defined via
|
|
the G4LEDATA envirnoment variable
|
|
- nuclides properties which path is defined via
|
|
the G4ENSDFSTATEDATA envirnoment variable
|
|
- radioactive decay hadronic processes which path is defined via
|
|
the G4RADIOACTIVEDATA envirnoment variable.
|
|
|
|
See more on installation of the datasets in Geant4 Installation Guide,
|
|
Chapter 3.3: Note On Geant4 Datasets:
|
|
http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides
|
|
/InstallationGuide/html/ch03s03.html
|
|
3- ACTION INITALIZATION
|
|
|
|
B3[a,b]::ActionInitialization class instantiates and registers to Geant4 kernel
|
|
all user action classes.
|
|
|
|
While in sequential mode the action classes are instatiated just once,
|
|
via invoking the method:
|
|
B3[a,b]::ActionInitialization::Build()
|
|
in multi-threading mode the same method is invoked for each thread worker
|
|
and so all user action classes are defined thread-local.
|
|
|
|
A run action class is instantiated both thread-local
|
|
and global that's why its instance is created also in the method
|
|
B3[a,b]::ActionInitialization::BuildForMaster()
|
|
which is invoked only in multi-threading mode.
|
|
|
|
4- PRIMARY GENERATOR
|
|
|
|
The default particle beam is an ion (F18), at rest, randomly distributed
|
|
within a zone inside a patient and is defined in
|
|
B3::PrimaryGeneratorAction::GeneratePrimaries().
|
|
The type of a primary particle can be changed with G4ParticleGun commands
|
|
(see run2.mac).
|
|
|
|
5- DETECTOR RESPONSE: scorers
|
|
|
|
A 'good' event is an event in which an identical energy of 511 keV is
|
|
deposited in two separate Crystals. A count of the number of such events
|
|
corresponds to a measure of the efficiency of the PET system.
|
|
The total dose deposited in a patient during a run is also computed.
|
|
|
|
Scorers are defined in B3::DetectorConstruction::ConstructSDandField(). There are
|
|
two G4MultiFunctionalDetector objects: one for the Crystal (EnergyDeposit),
|
|
and one for the Patient (DoseDeposit)
|
|
|
|
The scorers hits are saved in form of ntuples in a Root file using Geant4
|
|
analysis tools. This feature is activated in the main () function with instantiating
|
|
G4TScoreNtupleWriter.
|
|
|
|
Two variants of accumulation event statistics in a run are demonstrated
|
|
in this example:
|
|
|
|
B3a:
|
|
|
|
At the end of event, the values acummulated in B3a::EventAction are passed
|
|
in B3a::RunAction and summed over the whole run (see B3a::EventAction::EndOfevent()).
|
|
In multi-threading mode the data accumulated in G4Accumulable objects per
|
|
workers is merged to the master in B3a::RunAction::EndOfRunAction() and the final
|
|
result is printed on the screen.
|
|
|
|
G4Accumulable<> type instead of G4double and G4int types is used for the B3a::RunAction
|
|
data members in order to facilitate merging of the values accumulated on workers
|
|
to the master. Currently the accumulables have to be registered to G4AccumulablesManager
|
|
and G4AccumulablesManager::Merge() has to be called from the users code. This is planned
|
|
to be further simplified with a closer integration of G4Accumulable classes in
|
|
the Geant4 kernel next year.
|
|
|
|
B3b:
|
|
|
|
B3b::Run::RecordEvent(), called at end of event, collects informations
|
|
event per event from the hits collections, and accumulates statistic for
|
|
B3b::RunAction::EndOfRunAction().
|
|
In addition, results for dose are accumulated in a
|
|
standard floating-point summation and using a new lightweight statistical
|
|
class called G4StatAnalysis. The G4StatAnalysis class records four values:
|
|
(1) the sum, (2) sum^2, (3) number of entries, and (4) the number of entries
|
|
less than mean * machine-epsilon (the machine epsilon is the difference
|
|
between 1.0 and the next value representable by the floating-point type).
|
|
From these 4 values, G4StatAnalysis provides the mean, FOM, relative error,
|
|
standard deviation, variance, coefficient of variation, efficiency, r2int,
|
|
and r2eff.
|
|
|
|
In multi-threading mode the statistics accumulated per workers is merged
|
|
to the master in B3b::Run::Merge().
|
|
|
|
6- STACKING ACTION
|
|
|
|
Beta decay of Fluor generates a neutrino. One wishes not to track this
|
|
neutrino; therefore one kills it immediately, before created particles
|
|
are put in a stack.
|
|
The function B3::StackingAction::ClassifyNewTrack() is invoked by G4 kernel
|
|
each time a new particle is created.
|
|
|
|
The following paragraphs are common to all basic examples
|
|
|
|
A- VISUALISATION
|
|
|
|
The visualization manager is set via the G4VisExecutive class
|
|
in the main() function in exampleB3.cc.
|
|
The initialisation of the drawing is done via a set of /vis/ commands
|
|
in the macro vis.mac. This macro is automatically read from
|
|
the main function when the example is used in interactive running mode.
|
|
|
|
By default, vis.mac opens an OpenGL viewer (/vis/open OGL).
|
|
The user can change the initial viewer by commenting out this line
|
|
and instead uncommenting one of the other /vis/open statements, such as
|
|
HepRepFile or DAWNFILE (which produce files that can be viewed with the
|
|
HepRApp and DAWN viewers, respectively). Note that one can always
|
|
open new viewers at any time from the command line. For example, if
|
|
you already have a view in, say, an OpenGL window with a name
|
|
"viewer-0", then
|
|
/vis/open DAWNFILE
|
|
then to get the same view
|
|
/vis/viewer/copyView viewer-0
|
|
or to get the same view *plus* scene-modifications
|
|
/vis/viewer/set/all viewer-0
|
|
then to see the result
|
|
/vis/viewer/flush
|
|
|
|
The DAWNFILE, HepRepFile drivers are always available
|
|
(since they require no external libraries), but the OGL driver requires
|
|
that the Geant4 libraries have been built with the OpenGL option.
|
|
|
|
For more information on visualization, including information on how to
|
|
install and run DAWN, OpenGL and HepRApp, see the visualization tutorials,
|
|
for example,
|
|
http://geant4.slac.stanford.edu/Presentations/vis/G4[VIS]Tutorial/G4[VIS]Tutorial.html
|
|
(where [VIS] can be replaced by DAWN, OpenGL and HepRApp)
|
|
|
|
The tracks are automatically drawn at the end of each event, accumulated
|
|
for all events and erased at the beginning of the next run.
|
|
|
|
B- USER INTERFACES
|
|
|
|
The user command interface is set via the G4UIExecutive class
|
|
in the main() function in exampleB3.cc
|
|
The selection of the user command interface is then done automatically
|
|
according to the Geant4 configuration or it can be done explicitly via
|
|
the third argument of the G4UIExecutive constructor (see exampleB4a.cc).
|
|
|
|
C- HOW TO RUN
|
|
|
|
- Execute exampleB3a in the 'interactive mode' with visualization
|
|
% ./exampleB3a
|
|
and type in the commands from run1.mac line by line:
|
|
Idle> /control/verbose 2
|
|
Idle> /tracking/verbose 2
|
|
Idle> /run/beamOn 1
|
|
Idle> ...
|
|
Idle> exit
|
|
or
|
|
Idle> /control/execute run1.mac
|
|
....
|
|
Idle> exit
|
|
|
|
- Execute exampleB3a in the 'batch' mode from macro files
|
|
(without visualization)
|
|
% ./exampleB3a run2.mac
|
|
% ./exampleB3a exampleB3.in > exampleB3.out
|
|
|
|
|