Import Geant4 11.0.0 source tree
This commit is contained in:
Gabriele Cosmo
@@ -0,0 +1,56 @@
|
||||
|
||||
///\file "basic/.README.txt"
|
||||
///\brief Geant4 Basic Examples README page
|
||||
|
||||
/*! \page README_basic Basic Examples
|
||||
|
||||
The set of basic examples is oriented to "novice" users and covering many
|
||||
basic general use-cases typical of an "application"-oriented kind of
|
||||
development.
|
||||
|
||||
- \ref ExampleB1
|
||||
- Simple geometry with a few solids
|
||||
- Geometry with simple placements (G4PVPlacement)
|
||||
- Scoring total dose in a selected volume user action classes
|
||||
- Using G4Accumulable for automatic merging of scored values in multi-threading mode
|
||||
- Geant4 physics list (QBBC)
|
||||
|
||||
- \ref ExampleB2
|
||||
- Simplified tracker geometry with global constant magnetic field
|
||||
- Geometry with simple placements (G4PVPlacement) and parameterisation
|
||||
(G4PVParameterisation)
|
||||
- Scoring within tracker via G4 sensitive detector and hits
|
||||
- Geant4 physics list (FTFP_BERT) with step limiter
|
||||
- Started from novice/N02 example
|
||||
|
||||
- \ref ExampleB3
|
||||
- Schematic Positron Emitted Tomography system
|
||||
- Geometry with simple placements with rotation (G4PVPlacement)
|
||||
- Radioactive source
|
||||
- Scoring within Crystals via G4 scorers
|
||||
- Using G4Accumulable for automatic merging of scored values in multi-threading mode (a)
|
||||
and G4StatAnalysis for accumulating statistics (b)
|
||||
- Modular physics list built via builders provided in Geant4
|
||||
|
||||
- \ref ExampleB4
|
||||
- Simplified calorimeter with layers of two materials
|
||||
- Geometry with replica (G4PVReplica)
|
||||
- Scoring within layers in four ways: via user actions (a), via user own
|
||||
object (b), via G4 sensitive detector and hits (c) and via scorers (d)
|
||||
- Geant4 physics list (FTFP_BERT)
|
||||
- Histograms (1D) and ntuple saved in the output file
|
||||
- Started from novice/N03 example
|
||||
|
||||
- \ref ExampleB5
|
||||
- A double-arm spectrometer with wire chambers, hodoscopes and calorimeters
|
||||
with a local constant magnetic field
|
||||
- Geometry with placements with rotation, replicas and parameterisation
|
||||
- Scoring within wire chambers, hodoscopes and calorimeters via
|
||||
G4 sensitive detector and hits
|
||||
- Geant4 physics list (FTFP_BERT) with step limiter
|
||||
- UI commans defined using G4GenericMessenger
|
||||
- Histograms (1D, 2D) and ntuple saved in two output files
|
||||
- Plotting of histograms with visualization drivers
|
||||
- Started from extended/analysis/A01
|
||||
|
||||
*/
|
||||
@@ -0,0 +1,197 @@
|
||||
|
||||
///\file "B1/.README.txt"
|
||||
///\brief Example B1 README page
|
||||
|
||||
/*! \page ExampleB1 Example %B1
|
||||
|
||||
This example demonstrates a very simple application where an energy
|
||||
deposit is accounted in user actions and their associated objects
|
||||
and a dose in a selected volume is calculated.
|
||||
|
||||
\section B1_s1 GEOMETRY DEFINITION
|
||||
|
||||
The geometry is constructed in the B1::DetectorConstruction class.
|
||||
The setup consists of a an envelope of box shape containing two
|
||||
volumes: a spherical cone and a trapezoid.
|
||||
|
||||
In this example we use some common materials materials for medical
|
||||
applications. The envelope is made of water and the two inner volumes
|
||||
are made from tissue and bone materials.
|
||||
The materials are created with the help of the G4NistManager class,
|
||||
which allows to build a material from the NIST database using their
|
||||
names. Available materials and their compositions can be found in
|
||||
<a href="http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides
|
||||
/ForApplicationDeveloper/html/apas10.html">
|
||||
the Geant4 User's Guide for Application Developers, Appendix 10:
|
||||
Geant4 Materials Database
|
||||
</a>.
|
||||
|
||||
\section B1_s2 PHYSICS LIST
|
||||
|
||||
The particle's type and the physic processes which will be available
|
||||
in this example are set in the QBBC physics list. This physics list
|
||||
requires data files for electromagnetic and hadronic processes.
|
||||
See more on installation of the datasets in
|
||||
<a href="http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides
|
||||
/InstallationGuide/html/ch03s03.html">
|
||||
Geant4 Installation Guide, Chapter 3.3: Note On Geant4 Datasets </a>.
|
||||
The following datasets: G4LEDATA, G4LEVELGAMMADATA, G4NEUTRONXSDATA,
|
||||
G4SAIDXSDATA and G4ENSDFSTATEDATA are mandatory for this example.
|
||||
|
||||
In addition the build-in interactive command:
|
||||
\verbatim
|
||||
/process/(in)activate processName
|
||||
\endverbatim
|
||||
allows to activate/inactivate the processes one by one.
|
||||
|
||||
\section B1_s3 ACTION INITALIZATION
|
||||
|
||||
A newly introduced class, B1::ActionInitialization, 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:
|
||||
B1::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
|
||||
B1::ActionInitialization::BuildForMaster()
|
||||
which is invoked only in multi-threading mode.
|
||||
|
||||
\section B1_s4 PRIMARY GENERATOR
|
||||
|
||||
The primary generator is defined in the B1::PrimaryGeneratorAction class.
|
||||
The default kinematics is a 6 MeV gamma, randomly distributed in front
|
||||
of the envelope across 80% of the transverse (X,Y) envelope size.
|
||||
This default setting can be changed via the Geant4 built-in commands
|
||||
of the G4ParticleGun class.
|
||||
|
||||
\section B1_s5 DETECTOR RESPONSE
|
||||
|
||||
This example demonstrates a simple scoring implemented directly
|
||||
in the user action classes. Alternative ways of scoring via Geant4 classes
|
||||
can be found in the other examples.
|
||||
|
||||
The energy deposited is collected step by step for a selected volume
|
||||
in B1::SteppingAction and accumulated event by event in B1::EventAction.
|
||||
|
||||
At end of event, the value acummulated in B1::EventAction is added in B1::RunAction
|
||||
and summed over the whole run (see B1::EventAction::EndOfevent()).
|
||||
|
||||
Total dose deposited is computed at B1::RunAction::EndOfRunAction(),
|
||||
and printed together with informations about the primary particle.
|
||||
In multi-threading mode the energy accumulated in G4Accumulable objects per
|
||||
workers is merged to the master in B1::RunAction::EndOfRunAction() and the final
|
||||
result is printed on the screen.
|
||||
|
||||
G4Accumulable<G4double> type instead of G4double type is used for the B1::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.
|
||||
|
||||
An example of creating and computing new units (e.g., dose) is also shown
|
||||
in the class constructor.
|
||||
|
||||
<hr>
|
||||
|
||||
The following paragraphs are common to all basic examples
|
||||
|
||||
\section B1_A VISUALISATION
|
||||
|
||||
The visualization manager is set via the G4VisExecutive class
|
||||
in the main() function in exampleB1.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
|
||||
\verbatim
|
||||
/vis/open DAWNFILE
|
||||
\endverbatim
|
||||
then to get the same view
|
||||
\verbatim
|
||||
/vis/viewer/copyView viewer-0
|
||||
\endverbatim
|
||||
or to get the same view *plus* scene-modifications
|
||||
\verbatim
|
||||
/vis/viewer/set/all viewer-0
|
||||
\endverbatim
|
||||
then to see the result
|
||||
\verbatim
|
||||
/vis/viewer/flush
|
||||
\endverbatim
|
||||
|
||||
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.
|
||||
|
||||
From Release 9.6 the vis.mac macro in example B1 has additional commands
|
||||
that demonstrate additional functionality of the vis system, such as
|
||||
displaying text, axes, scales, date, logo and shows how to change
|
||||
viewpoint and style. Consider copying these to other examples or
|
||||
your application. To see even more commands use help or
|
||||
ls or browse the available UI commands in the Application
|
||||
Developers Guide, Section 7.1.
|
||||
|
||||
For more information on visualization, including information on how to
|
||||
install and run DAWN, OpenGL and HepRApp, see the visualization tutorials,
|
||||
for example,\n
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4OpenGLTutorial/G4OpenGLTutorial.html">
|
||||
OpenGL Tutorial </a>
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4DAWNTutorial/G4DAWNTutorial.html">
|
||||
DAWN Tutorial </a>
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4HepRAppTutorial/G4HepRAppTutorial.html">
|
||||
HepRApp Tutorial </a>
|
||||
|
||||
The tracks are automatically drawn at the end of each event, accumulated
|
||||
for all events and erased at the beginning of the next run.
|
||||
|
||||
|
||||
\section B1_B USER INTERFACES
|
||||
|
||||
The user command interface is set via the G4UIExecutive class
|
||||
in the main() function in exampleB1.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).
|
||||
|
||||
\section B1_C HOW TO RUN
|
||||
|
||||
- Execute exampleB1 in the 'interactive mode' with visualization
|
||||
\verbatim
|
||||
% exampleB1
|
||||
and type in the commands from run1.mac line by line:
|
||||
Idle> /control/verbose 2
|
||||
Idle> /tracking/verbose 1
|
||||
Idle> /run/beamOn 10
|
||||
Idle> ...
|
||||
Idle> exit
|
||||
\endverbatim
|
||||
or
|
||||
\verbatim
|
||||
Idle> /control/execute run1.mac
|
||||
....
|
||||
Idle> exit
|
||||
\endverbatim
|
||||
|
||||
- Execute exampleB1 in the 'batch' mode from macro files
|
||||
(without visualization)
|
||||
\verbatim
|
||||
% exampleB1 run2.mac
|
||||
% exampleB1 exampleB1.in > exampleB1.out
|
||||
\endverbatim
|
||||
|
||||
*/
|
||||
|
||||
|
||||
@@ -0,0 +1,172 @@
|
||||
-------------------------------------------------------------------
|
||||
|
||||
=========================================================
|
||||
Geant4 - an Object-Oriented Toolkit for Simulation in HEP
|
||||
=========================================================
|
||||
|
||||
Example B1
|
||||
-----------
|
||||
|
||||
This example demonstrates a very simple application where an energy
|
||||
deposit is accounted in user actions and their associated objects
|
||||
and a dose in a selected volume is calculated.
|
||||
|
||||
|
||||
1- GEOMETRY DEFINITION
|
||||
|
||||
The geometry is constructed in the B1::DetectorConstruction class.
|
||||
The setup consists of a an envelope of box shape containing two
|
||||
volumes: a spherical cone and a trapezoid.
|
||||
|
||||
In this example we use some common materials materials for medical
|
||||
applications. The envelope is made of water and the two inner volumes
|
||||
are made from tissue and bone materials.
|
||||
The materials are created with the help of the G4NistManager class,
|
||||
which allows to build a material from the NIST database using their
|
||||
names. All available materials can be found in the Geant4 User's Guide
|
||||
for Application Developers, Appendix 10: Geant4 Materials Database.
|
||||
|
||||
2- PHYSICS LIST
|
||||
|
||||
The particle's type and the physic processes which will be available
|
||||
in this example are set in the QBBC physics list. This physics list
|
||||
requires data files for electromagnetic and hadronic processes.
|
||||
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
|
||||
The following datasets: G4LEDATA, G4LEVELGAMMADATA, G4NEUTRONXSDATA,
|
||||
G4SAIDXSDATA and G4ENSDFSTATEDATA are mandatory for this example.
|
||||
|
||||
In addition the build-in interactive command:
|
||||
/process/(in)activate processName
|
||||
allows to activate/inactivate the processes one by one.
|
||||
|
||||
3- ACTION INITALIZATION
|
||||
|
||||
A newly introduced class, B1::ActionInitialization, 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:
|
||||
B1::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
|
||||
B1::ActionInitialization::BuildForMaster()
|
||||
which is invoked only in multi-threading mode.
|
||||
|
||||
4- PRIMARY GENERATOR
|
||||
|
||||
The primary generator is defined in the B1::PrimaryGeneratorAction class.
|
||||
The default kinematics is a 6 MeV gamma, randomly distributed in front
|
||||
of the envelope across 80% of the transverse (X,Y) envelope size.
|
||||
This default setting can be changed via the Geant4 built-in commands
|
||||
of the G4ParticleGun class.
|
||||
|
||||
5- DETECTOR RESPONSE
|
||||
|
||||
This example demonstrates a simple scoring implemented directly
|
||||
in the user action classes. Alternative ways of scoring via Geant4 classes
|
||||
can be found in the other examples.
|
||||
|
||||
The energy deposited is collected step by step for a selected volume
|
||||
in B1::SteppingAction and accumulated event by event in B1::EventAction.
|
||||
|
||||
At end of event, the value acummulated in B1::EventAction is added in B1::RunAction
|
||||
and summed over the whole run (see B1::EventAction::EndOfevent()).
|
||||
|
||||
Total dose deposited is computed at B1::RunAction::EndOfRunAction(),
|
||||
and printed together with informations about the primary particle.
|
||||
In multi-threading mode the energy accumulated in G4Accumulable objects per
|
||||
workers is merged to the master in B1::RunAction::EndOfRunAction() and the final
|
||||
result is printed on the screen.
|
||||
|
||||
G4Parameter<G4double> type instead of G4double type is used for the B1::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.
|
||||
|
||||
An example of creating and computing new units (e.g., dose) is also shown
|
||||
in the class constructor.
|
||||
|
||||
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 exampleB1.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.
|
||||
|
||||
From Release 9.6 the vis.mac macro in example B1 has additional commands
|
||||
that demonstrate additional functionality of the vis system, such as
|
||||
displaying text, axes, scales, date, logo and shows how to change
|
||||
viewpoint and style. Consider copying these to other examples or
|
||||
your application. To see even more commands use help or
|
||||
ls or browse the available UI commands in the Application
|
||||
Developers Guide, Section 7.1.
|
||||
|
||||
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 exampleB1.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 exampleB1 in the 'interactive mode' with visualization:
|
||||
% ./exampleB1
|
||||
and type in the commands from run1.mac line by line:
|
||||
Idle> /control/verbose 2
|
||||
Idle> /tracking/verbose 1
|
||||
Idle> /run/beamOn 10
|
||||
Idle> ...
|
||||
Idle> exit
|
||||
or
|
||||
Idle> /control/execute run1.mac
|
||||
....
|
||||
Idle> exit
|
||||
|
||||
- Execute exampleB1 in the 'batch' mode from macro files
|
||||
(without visualization)
|
||||
% ./exampleB1 run2.mac
|
||||
% ./exampleB1 exampleB1.in > exampleB1.out
|
||||
|
||||
|
||||
@@ -0,0 +1,230 @@
|
||||
|
||||
///\file "B2/.README.txt"
|
||||
///\brief Example B2 README page
|
||||
|
||||
/*! \page ExampleB2 Example %B2
|
||||
|
||||
This example simulates a simplified fixed target experiment.
|
||||
|
||||
\section B2_s1 GEOMETRY DEFINITION
|
||||
|
||||
The setup consists of a target followed by six chambers of increasing
|
||||
transverse size at defined instances from the target. These chambers are
|
||||
located in a region called the Tracker region.
|
||||
Their shape are cylinders, constructed as simple cylinders
|
||||
(in B2a::DetectorConstruction) and as parametrised volumes
|
||||
(in B2b::DetectorConstruction), see also B2b::ChamberParameterisation class.
|
||||
|
||||
In addition, a global, uniform, and transverse magnetic field can be
|
||||
applied using G4GlobalMagFieldMessenger, instantiated in
|
||||
B2a::DetectorConstruction::ConstructSDandField with a non zero field value,
|
||||
or via interactive commands.
|
||||
For example:
|
||||
\verbatim
|
||||
/globalField/setValue 0.2 0 0 tesla
|
||||
\endverbatim
|
||||
An instance of the B2::TrackerSD class is created and associated with each
|
||||
logical chamber volume (in B2a) and with the one G4LogicalVolume associated
|
||||
with G4PVParameterised (in B2b).
|
||||
|
||||
One can change the materials of the target and the chambers
|
||||
interactively via the commands defined in B2a::DetectorMessenger
|
||||
(or B2b::DetectorMessenger). For example:
|
||||
\verbatim
|
||||
/B2/det/setTargetMaterial G4_WATER
|
||||
/B2/det/setChamberMaterial G4_Ar
|
||||
\endverbatim
|
||||
|
||||
\section B2_s2 PHYSICS LIST
|
||||
|
||||
The particle's type and the physic processes which will be available
|
||||
in this example are set in the FTFP_BERT physics list. This physics list
|
||||
requires data files for electromagnetic and hadronic processes.
|
||||
See more on installation of the datasets in
|
||||
<a href="http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/InstallationGuide/html/ch03s03.html">
|
||||
Geant4 Installation Guide, Chapter 3.3: Note On Geant4 Datasets </a>.
|
||||
The following datasets: G4LEDATA, G4LEVELGAMMADATA, G4SAIDXSDATA and
|
||||
G4ENSDFSTATEDATA are mandatory for this example.
|
||||
|
||||
In addition, the build-in interactive command:
|
||||
\verbatim
|
||||
/process/(in)activate processName
|
||||
\endverbatim
|
||||
allows the user to activate/inactivate the processes one by one.
|
||||
|
||||
\section B2_s3 ACTION INITALIZATION
|
||||
|
||||
A newly introduced class, B2::ActionInitialization,
|
||||
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:
|
||||
B2::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
|
||||
B2::ActionInitialization::BuildForMaster()
|
||||
which is invoked only in multi-threading mode.
|
||||
|
||||
\section B2_s4 PRIMARY GENERATOR
|
||||
|
||||
The primary generator action class employs the G4ParticleGun.
|
||||
The primary kinematics consists of a single particle which starts at the world boundary
|
||||
and hits the target perpendicular to the entrance face. The type of the particle
|
||||
and its energy can be changed via the G4 built-in commands of
|
||||
the G4ParticleGun class.
|
||||
Note that this particular case of starting a primary particle on the world boundary
|
||||
requires shooting in a direction towards inside the world.
|
||||
|
||||
\section B2_s5 RUNS and EVENTS
|
||||
|
||||
A run is a set of events.
|
||||
|
||||
The user has control:
|
||||
- at Begin and End of each run (class B2::RunAction)
|
||||
- at Begin and End of each event (class B2::EventAction)
|
||||
- at Begin and End of each track (class TrackingAction, not used here)
|
||||
- at End of each step (class SteppingAction, not used here)
|
||||
|
||||
The event number is written to the log file every requested number
|
||||
of events in B2::EventAction::BeginOfEventAction() and
|
||||
B2::EventAction::EndOfEventAction().
|
||||
Moreover, for the first 100 events and every 100 events thereafter
|
||||
information about the number of stored trajectories in the event
|
||||
is printed as well as the number of hits stored in the G4VHitsCollection.
|
||||
|
||||
The run number is printed at B2::RunAction::BeginOfRunAction(), where the
|
||||
G4RunManager is also informed how to SetRandomNumberStore for storing
|
||||
initial random number seeds per run or per event.
|
||||
|
||||
\section B2_s6 USER LIMITS
|
||||
|
||||
This example also illustrates how to introduce tracking constraints
|
||||
like maximum step length, minimum kinetic energy etc. via the G4UserLimits
|
||||
class and associated G4StepLimiter and G4UserSpecialCuts processes.
|
||||
See B2a::DetectorConstruction (or B2b::DetectorConstruction).
|
||||
|
||||
The maximum step limit in the tracker region can be set by the interactive
|
||||
command (see B2a::DetectorMessenger, B2b::DetectorMessenger classes).
|
||||
For example:
|
||||
|
||||
\verbatim
|
||||
/B2/det/stepMax 1.0 mm
|
||||
\endverbatim
|
||||
|
||||
\section B2_s7 DETECTOR RESPONSE
|
||||
|
||||
A HIT is a step per step record of all the information needed to
|
||||
simulate and analyse the detector response.
|
||||
|
||||
In this example the Tracker chambers are considered to be the detector.
|
||||
Therefore, the chambers are declared 'sensitive detectors' (SD) in
|
||||
the B2a::DetectorConstruction (or B2b::DetectorConstruction) class.
|
||||
They are associated with an instance of the B2::TrackerSD class.
|
||||
|
||||
Then, a Hit is defined as a set of 4 informations per step, inside
|
||||
the chambers, namely:
|
||||
- the track identifier (an integer),
|
||||
- the chamber number,
|
||||
- the total energy deposit in this step, and
|
||||
- the position of the energy deposit.
|
||||
|
||||
A given hit is an instance of the class B2::TrackerHit which is created
|
||||
during the tracking of a particle, step by step, in the method
|
||||
B2::TrackerSD::ProcessHits(). This hit is inserted in a HitsCollection.
|
||||
|
||||
The HitsCollection is printed at the end of each event (via the method
|
||||
B2::TrackerSD::EndOfEvent()), under the control of the command:
|
||||
\verbatim
|
||||
/hits/verbose 2
|
||||
\endverbatim
|
||||
|
||||
<hr>
|
||||
|
||||
The following paragraphs are common to all basic examples
|
||||
|
||||
\section B2_A VISUALISATION
|
||||
|
||||
The visualization manager is set via the G4VisExecutive class
|
||||
in the main () function in exampleB2a.cc (or exampleB2b.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
|
||||
\verbatim
|
||||
/vis/open DAWNFILE
|
||||
\endverbatim
|
||||
then to get the same view
|
||||
\verbatim
|
||||
/vis/viewer/copyView viewer-0
|
||||
\endverbatim
|
||||
or to get the same view *plus* scene-modifications
|
||||
\verbatim
|
||||
/vis/viewer/set/all viewer-0
|
||||
\endverbatim
|
||||
then to see the result
|
||||
\verbatim
|
||||
/vis/viewer/flush
|
||||
\endverbatim
|
||||
|
||||
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,\n
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4OpenGLTutorial/G4OpenGLTutorial.html">
|
||||
OpenGL Tutorial </a>
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4DAWNTutorial/G4DAWNTutorial.html">
|
||||
DAWN Tutorial </a>
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4HepRAppTutorial/G4HepRAppTutorial.html">
|
||||
HepRApp Tutorial </a>
|
||||
|
||||
The tracks are automatically drawn at the end of each event, accumulated
|
||||
for all events and erased at the beginning of the next run.
|
||||
|
||||
\section B2_B USER INTERFACES
|
||||
|
||||
The user command interface is set via the G4UIExecutive class
|
||||
in the main () function in exampleB2a.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 exampleB2a.cc).
|
||||
|
||||
\section B2_C HOW TO RUN
|
||||
|
||||
- Execute exampleB2a in the 'interactive mode' with visualization
|
||||
\verbatim
|
||||
% exampleB2a
|
||||
and type in the commands from run1.mac line by line:
|
||||
Idle> /tracking/verbose 1
|
||||
Idle> /run/beamOn 1
|
||||
Idle> ...
|
||||
Idle> exit
|
||||
\endverbatim
|
||||
or
|
||||
\verbatim
|
||||
Idle> /control/execute run1.mac
|
||||
....
|
||||
Idle> exit
|
||||
\endverbatim
|
||||
|
||||
- Execute exampleB2a in the 'batch' mode from macro files
|
||||
(without visualization)
|
||||
\verbatim
|
||||
% exampleB2a run2.mac
|
||||
% exampleB2a exampleB2.in > exampleB2.out
|
||||
\endverbatim
|
||||
|
||||
*/
|
||||
@@ -0,0 +1,205 @@
|
||||
-------------------------------------------------------------------
|
||||
|
||||
=========================================================
|
||||
Geant4 - an Object-Oriented Toolkit for Simulation in HEP
|
||||
=========================================================
|
||||
|
||||
Example B2
|
||||
----------
|
||||
|
||||
This example simulates a simplified fixed target experiment.
|
||||
|
||||
1- GEOMETRY DEFINITION
|
||||
|
||||
The setup consists of a target followed by six chambers of increasing
|
||||
transverse size at defined instances from the target. These chambers are
|
||||
located in a region called the Tracker region.
|
||||
Their shape are cylinders, constructed as simple cylinders
|
||||
(in B2a::DetectorConstruction) and as parametrised volumes
|
||||
(in B2b::DetectorConstruction), see also B2b::ChamberParameterisation class.
|
||||
|
||||
In addition, a global, uniform, and transverse magnetic field can be
|
||||
applied using G4GlobalMagFieldMessenger, instantiated in
|
||||
B2[a,b]::DetectorConstruction::ConstructSDandField with a non zero field value,
|
||||
or via interactive commands.
|
||||
For example:
|
||||
|
||||
/globalField/setValue 0.2 0 0 tesla
|
||||
|
||||
An instance of the B2::TrackerSD class is created and associated with each
|
||||
logical chamber volume (in B2a) and with the one G4LogicalVolume associated
|
||||
with G4PVParameterised (in B2b).
|
||||
|
||||
One can change the materials of the target and the chambers
|
||||
interactively via the commands defined in B2a::DetectorMessenger
|
||||
(or B2b::DetectorMessenger). For example:
|
||||
|
||||
/B2/det/setTargetMaterial G4_WATER
|
||||
/B2/det/setChamberMaterial G4_Ar
|
||||
|
||||
2- PHYSICS LIST
|
||||
|
||||
The particle's type and the physic processes which will be available
|
||||
in this example are set in the FTFP_BERT physics list. This physics list
|
||||
requires data files for electromagnetic and hadronic processes.
|
||||
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
|
||||
The following datasets: G4LEDATA, G4LEVELGAMMADATA, G4SAIDXSDATA and
|
||||
G4ENSDFSTATEDATA are mandatory for this example.
|
||||
|
||||
In addition, the build-in interactive command:
|
||||
/process/(in)activate processName
|
||||
allows the user to activate/inactivate the processes one by one.
|
||||
|
||||
3- ACTION INITALIZATION
|
||||
|
||||
A newly introduced class, B2::ActionInitialization,
|
||||
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:
|
||||
B2::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 has is created also in the method
|
||||
B2::ActionInitialization::BuildForMaster()
|
||||
which is invoked only in multi-threading mode.
|
||||
|
||||
4- PRIMARY GENERATOR
|
||||
|
||||
The primary generator action class employs the G4ParticleGun.
|
||||
The primary kinematics consists of a single particle which starts at the world boundary
|
||||
and hits the target perpendicular to the entrance face. The type of the particle
|
||||
and its energy can be changed via the G4 built-in commands of
|
||||
the G4ParticleGun class.
|
||||
Note that this particular case of starting a primary particle on the world boundary
|
||||
requires shooting in a direction towards inside the world.
|
||||
|
||||
5- RUNS and EVENTS
|
||||
|
||||
A run is a set of events.
|
||||
|
||||
The user has control:
|
||||
- at Begin and End of each run (class B2::RunAction)
|
||||
- at Begin and End of each event (class B2::EventAction)
|
||||
- at Begin and End of each track (class TrackingAction, not used here)
|
||||
- at End of each step (class SteppingAction, not used here)
|
||||
|
||||
The event number is written to the log file every requested number
|
||||
of events in B2::EventAction::BeginOfEventAction() and
|
||||
B2::EventAction::EndOfEventAction().
|
||||
Moreover, for the first 100 events and every 100 events thereafter
|
||||
information about the number of stored trajectories in the event
|
||||
is printed as well as the number of hits stored in the G4VHitsCollection.
|
||||
|
||||
The run number is printed at B2::RunAction::BeginOfRunAction(), where the
|
||||
G4RunManager is also informed how to SetRandomNumberStore for storing
|
||||
initial random number seeds per run or per event.
|
||||
|
||||
6- USER LIMITS
|
||||
|
||||
This example also illustrates how to introduce tracking constraints
|
||||
like maximum step length, minimum kinetic energy etc. via the G4UserLimits
|
||||
class and associated G4StepLimiter and G4UserSpecialCuts processes.
|
||||
See B2a::DetectorConstruction (or B2b::DetectorConstruction).
|
||||
|
||||
The maximum step limit in the tracker region can be set by the interactive
|
||||
command (see B2a::DetectorMessenger, B2b::DetectorMessenger classes).
|
||||
For example:
|
||||
|
||||
/B2/det/stepMax 1.0 mm
|
||||
|
||||
7- DETECTOR RESPONSE
|
||||
|
||||
A HIT is a step per step record of all the information needed to
|
||||
simulate and analyse the detector response.
|
||||
|
||||
In this example the Tracker chambers are considered to be the detector.
|
||||
Therefore, the chambers are declared 'sensitive detectors' (SD) in
|
||||
the B2a::DetectorConstruction (or B2b::DetectorConstruction) class.
|
||||
They are associated with an instance of the B2::TrackerSD class.
|
||||
|
||||
Then, a Hit is defined as a set of 4 informations per step, inside
|
||||
the chambers, namely:
|
||||
- the track identifier (an integer),
|
||||
- the chamber number,
|
||||
- the total energy deposit in this step, and
|
||||
- the position of the energy deposit.
|
||||
|
||||
A given hit is an instance of the class B2::TrackerHit which is created
|
||||
during the tracking of a particle, step by step, in the method
|
||||
B2::TrackerSD::ProcessHits(). This hit is inserted in a HitsCollection.
|
||||
|
||||
The HitsCollection is printed at the end of each event (via the method
|
||||
B2::TrackerSD::EndOfEvent()), under the control of the command:
|
||||
/hits/verbose 2
|
||||
|
||||
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 exampleB2a.cc (or exampleB2b.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 exampleB2a.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 exampleB2a in the 'interactive mode' with visualization
|
||||
% exampleB2a
|
||||
and type in the commands from run1.mac line by line:
|
||||
Idle> /tracking/verbose 1
|
||||
Idle> /run/beamOn 1
|
||||
Idle> ...
|
||||
Idle> exit
|
||||
or
|
||||
Idle> /control/execute run1.mac or run2.mac
|
||||
....
|
||||
Idle> exit
|
||||
|
||||
- Execute exampleB2a in the 'batch' mode from macro files
|
||||
(without visualization)
|
||||
% exampleB2a run2.mac
|
||||
% exampleB2a exampleB2.in > exampleB2.out
|
||||
|
||||
@@ -0,0 +1,221 @@
|
||||
|
||||
///\file "B3/.README.txt"
|
||||
///\brief Example B3 README page
|
||||
|
||||
/*! \page ExampleB3 Example %B3
|
||||
|
||||
This example simulates schematically a Positron Emitted Tomography system.
|
||||
|
||||
\section B3_s1 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().
|
||||
|
||||
\section B3_s2 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
|
||||
- data files for 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
|
||||
<a href="http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides
|
||||
/InstallationGuide/html/ch03s03.html">
|
||||
Geant4 Installation Guide, Chapter 3.3: Note On Geant4 Datasets </a>.
|
||||
|
||||
\section B3_s3 ACTION INITALIZATION
|
||||
|
||||
B3a::ActionInitialization class (see also B3b::ActionInitialization) 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:
|
||||
B3a::ActionInitialization::Build()
|
||||
(see also B3b::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
|
||||
B3a::ActionInitialization::BuildForMaster()
|
||||
(see also B3b::ActionInitialization::Build)
|
||||
which is invoked only in multi-threading mode.
|
||||
|
||||
\section B3_s4 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).
|
||||
|
||||
\section B3_s5 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().
|
||||
|
||||
\section B3_s6 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.
|
||||
|
||||
<hr>
|
||||
|
||||
The following paragraphs are common to all basic examples
|
||||
|
||||
\section B3_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
|
||||
\verbatim
|
||||
/vis/open DAWNFILE
|
||||
\endverbatim
|
||||
then to get the same view
|
||||
\verbatim
|
||||
/vis/viewer/copyView viewer-0
|
||||
\endverbatim
|
||||
or to get the same view *plus* scene-modifications
|
||||
\verbatim
|
||||
/vis/viewer/set/all viewer-0
|
||||
\endverbatim
|
||||
then to see the result
|
||||
\verbatim
|
||||
/vis/viewer/flush
|
||||
\endverbatim
|
||||
|
||||
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,\n
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4OpenGLTutorial/G4OpenGLTutorial.html">
|
||||
OpenGL Tutorial </a>
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4DAWNTutorial/G4DAWNTutorial.html">
|
||||
DAWN Tutorial </a>
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4HepRAppTutorial/G4HepRAppTutorial.html">
|
||||
HepRApp Tutorial </a>
|
||||
|
||||
The tracks are automatically drawn at the end of each event, accumulated
|
||||
for all events and erased at the beginning of the next run.
|
||||
|
||||
\section B3_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).
|
||||
|
||||
\section B3_C HOW TO RUN
|
||||
|
||||
- Execute exampleB3a in the 'interactive mode' with visualization
|
||||
\verbatim
|
||||
% ./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
|
||||
\endverbatim
|
||||
or
|
||||
\verbatim
|
||||
Idle> /control/execute run1.mac
|
||||
....
|
||||
Idle> exit
|
||||
\endverbatim
|
||||
|
||||
- Execute exampleB3a in the 'batch' mode from macro files
|
||||
(without visualization)
|
||||
\verbatim
|
||||
% ./exampleB3a run2.mac
|
||||
% ./exampleB3a exampleB3.in > exampleB3.out
|
||||
\endverbatim
|
||||
|
||||
*/
|
||||
@@ -0,0 +1,202 @@
|
||||
-------------------------------------------------------------------
|
||||
|
||||
=========================================================
|
||||
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
|
||||
|
||||
|
||||
@@ -0,0 +1,322 @@
|
||||
|
||||
///\file "B4/.README.txt"
|
||||
///\brief Example B4 README page
|
||||
|
||||
/*! \page ExampleB4 Example %B4
|
||||
|
||||
This example simulates a simple Sampling Calorimeter setup.
|
||||
To demonstrate several possible ways of data scoring, the example
|
||||
is provided in four variants: %B4a, %B4b, %B4c, %B4d.
|
||||
(See also examples/extended/electromagnetic/TestEm3)
|
||||
|
||||
\section B4_s1 GEOMETRY DEFINITION
|
||||
|
||||
The geometry is constructed in B4::DetectorConstruction class
|
||||
(see also
|
||||
\link B4c::DetectorConstruction B4c \endlink,
|
||||
\link B4d::DetectorConstruction B4d \endlink variants).
|
||||
The calorimeter is a box made of a given number of layers. A layer
|
||||
consists of an absorber plate and of a detection gap. The layer is
|
||||
replicated.
|
||||
|
||||
Four parameters define the geometry of the calorimeter :
|
||||
- the thickness of an absorber plate,
|
||||
- the thickness of a gap,
|
||||
- the number of layers, and
|
||||
- the transverse size of the calorimeter (the entrance face is a square).
|
||||
|
||||
In addition, a global, uniform, and transverse magnetic field can be
|
||||
applied using G4GlobalMagFieldMessenger, instantiated in
|
||||
B4::DetectorConstruction::ConstructSDandField()
|
||||
(see also
|
||||
\link B4c::DetectorConstruction::ConstructSDandField() B4c \endlink,
|
||||
\link B4d::DetectorConstruction::ConstructSDandField() B4d \endlink variants)
|
||||
with a non zero field value, or via interactive commands.
|
||||
For example:
|
||||
|
||||
\verbatim
|
||||
/globalField/setValue 0.2 0 0 tesla
|
||||
\endverbatim
|
||||
|
||||
<pre>
|
||||
|<----layer 0---------->|<----layer 1---------->|<----layer 2---------->|
|
||||
| | | |
|
||||
==========================================================================
|
||||
|| | || | || | ||
|
||||
|| | || | || | ||
|
||||
beam || absorber | gap || absorber | gap || absorber | gap ||
|
||||
======> || | || | || | ||
|
||||
|| | || | || | ||
|
||||
==========================================================================
|
||||
|
||||
</pre>
|
||||
|
||||
A more general version of this geometry can be found in:
|
||||
examples/extended/electromagnetic/TestEm3
|
||||
where all the geometry parameters, the absorber and gap materials
|
||||
can be modified interactively via the commands defined in the DetectorMessenger
|
||||
class.
|
||||
|
||||
\section B4_s2 PHYSICS LIST
|
||||
|
||||
The particle's type and the physic processes which will be available
|
||||
in this example are set in the FTFP_BERT physics list. This physics list
|
||||
requires data files for electromagnetic and hadronic processes.
|
||||
See more on installation of the datasets in
|
||||
<a href="http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/InstallationGuide/html/ch03s03.html">
|
||||
Geant4 Installation Guide, Chapter 3.3: Note On Geant4 Datasets </a>.
|
||||
The following datasets: G4LEDATA, G4LEVELGAMMADATA, G4SAIDXSDATA and
|
||||
G4ENSDFSTATEDATA are mandatory for this example.
|
||||
|
||||
In addition the build-in interactive command:
|
||||
\verbatim
|
||||
/process/(in)activate processName
|
||||
\endverbatim
|
||||
allows to activate/inactivate the processes one by one.
|
||||
|
||||
\section B4_s3 ACTION INITALIZATION
|
||||
|
||||
A newly introduced class, B4a::ActionInitialization, (see also
|
||||
\link B4b::ActionInitialization B4b \endlink,
|
||||
\link B4c::ActionInitialization B4c \endlink,
|
||||
\link B4d::ActionInitialization B4d \endlink variants),
|
||||
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:
|
||||
B4a::ActionInitialization::Build()
|
||||
(see also
|
||||
\link B4b::ActionInitialization::Build() B4b \endlink,
|
||||
\link B4c::ActionInitialization::Build() B4c \endlink,
|
||||
\link B4d::ActionInitialization::Build() B4d \endlink variants),
|
||||
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
|
||||
B4a::ActionInitialization::BuildForMaster()
|
||||
(see also
|
||||
\link B4b::ActionInitialization::BuildForMaster() B4b \endlink,
|
||||
\link B4c::ActionInitialization::BuildForMaster() B4c \endlink,
|
||||
\link B4d::ActionInitialization::BuildForMaster() B4d \endlink variants),
|
||||
which is invoked only in multi-threading mode.
|
||||
|
||||
\section B4_s4 PRIMARY GENERATOR
|
||||
|
||||
The primary beam consists of a single particle which hits the
|
||||
calorimeter perpendicular to the input face. The type of the particle
|
||||
and its energy are set in the B4::PrimaryGeneratorAction class, and can
|
||||
be changed via the G4 built-in commands of the G4ParticleGun class (see
|
||||
the macros provided with this example).
|
||||
|
||||
\section B4_s5 RUNS and EVENTS
|
||||
|
||||
A run is a set of events.
|
||||
|
||||
The user can choose the frequency of printing via the Geant4 interactive
|
||||
command, for example:
|
||||
\verbatim
|
||||
/run/printProgress 100
|
||||
\endverbatim
|
||||
|
||||
\section B4_s6- DETECTOR RESPONSE
|
||||
|
||||
The energy deposit and track lengths of the charged particles are recorded on
|
||||
an event by event basis in the Absober and Gap layers.
|
||||
|
||||
In order to demonstrate several possible ways of data scoring,
|
||||
the example is provided in four variants:
|
||||
|
||||
\subsection s6a Variant a: User Actions
|
||||
|
||||
These 4 quantities are data members of the B4a::EventAction class.
|
||||
They are collected step by step in
|
||||
B4a::SteppingAction::UserSteppingAction(), and passed to the event action
|
||||
via two methods: B4a::EventAction::AddAbs() and B4a::EventAction::AddGap().
|
||||
|
||||
In B4a::EventAction::EndOfEventAction(), these quantities are printed and
|
||||
filled in H1D histograms and ntuple to accumulate statistic and compute
|
||||
dispersion.
|
||||
|
||||
\subsection s6b Variant b: User data object
|
||||
|
||||
In order to avoid dependencies between action classes, a user object
|
||||
B4b::RunData, derived from G4Run, is defined with data members needed
|
||||
for the accounted information.
|
||||
In order to reduce the number of data members a 2-dimensions array
|
||||
is introduced for each quantity.
|
||||
Then the quantities are collected step by step in user action classes:
|
||||
B4b::SteppingAction::UserSteppingAction() and
|
||||
B4b::EventAction::EndOfEventAction() in a similar way as in variant a.
|
||||
|
||||
\subsection s6c Variant c: Hits and Sensitive detectors
|
||||
|
||||
In this option, the physics quantities are accounted using the hits
|
||||
and sensitive detectors framework defined in the Geant4 kernel.
|
||||
The physics quantities are stored in B4c::CalorHit via two B4c::CalorimeterSD
|
||||
objects, one associated with the Absorber volume and another one with Gap
|
||||
in B4c::DetectorConstruction::ConstructSDandField().
|
||||
|
||||
In contrary to the B2 example (Tracker) where a new hit is created
|
||||
with each track passing the sensitive volume (in the calorimeter), only one
|
||||
hit is created for each calorimeter layer and one more hit to account for
|
||||
the total quantities in all layers. In addition to the variants a and b,
|
||||
the quantities per each layer are also available in addition to the total
|
||||
quantities.
|
||||
|
||||
\subsection s6d Variant d: Scorer
|
||||
|
||||
In this option, the Geant4 scorers which are defined on the top of hits
|
||||
and sensitive detectors Geant4 framework are used.
|
||||
In practice this means that the user does not need to define hits and sensitive
|
||||
detector classes but rather uses the classes already defined
|
||||
in Geant4. In this example, the G4MultiFunctionalDetector with
|
||||
G4PSEnergyDeposit and G4PSTrackLength primitive scores are used (see
|
||||
B4d::DetectorConstruction::ConstructSDandField()).
|
||||
|
||||
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.
|
||||
|
||||
Also with this approach, the quantities per each layer are available
|
||||
in addition to the total quantities.
|
||||
|
||||
\section B4_s7 HISTOGRAMS
|
||||
|
||||
The analysis tools are used to accumulate statistics and compute the dispersion
|
||||
of the energy deposit and track lengths of the charged particles.
|
||||
H1D histograms are created in B4::RunAction::RunAction() (see also
|
||||
\link B4b::RunAction::RunAction() B4b \endlink variant) for the
|
||||
following quantities:
|
||||
- Energy deposit in absorber
|
||||
- Energy deposit in gap
|
||||
- Track length in absorber
|
||||
- Track length in gap
|
||||
|
||||
The same values are also saved in an ntuple.
|
||||
|
||||
The histograms and the ntuple are saved in the output file in a format
|
||||
according to a specified file extension, the default in this example
|
||||
is ROOT.
|
||||
|
||||
The accumulated statistic and computed dispersion is printed at the end of
|
||||
run, in B4::RunAction::EndOfRunAction() ((see also
|
||||
\link B4b::RunAction::EndOfRunAction() B4b \endlink variant).
|
||||
When running in multi-threading mode, the histograms and the ntuple accumulated
|
||||
on threads are merged in a single output file. While merging of histograms is
|
||||
performed by default, merging of ntuples is explicitly activated in the B4::RunAction
|
||||
constructor.
|
||||
|
||||
The ROOT histograms and ntuple can be plotted with ROOT using the plotHisto.C
|
||||
and plotNtuple.C macros.
|
||||
|
||||
\section B4_s8 HOW TO RUN
|
||||
|
||||
This example handles the program arguments in a new way.
|
||||
It can be run with the following optional arguments:
|
||||
\verbatim
|
||||
% exampleB4a [-m macro ] [-u UIsession] [-t nThreads] [-vDefault]
|
||||
\endverbatim
|
||||
|
||||
The -vDefault option will activate using the default Geant4 stepping verbose
|
||||
class (G4SteppingVerbose) instead of the enhanced stepping verbose with best
|
||||
units (G4SteppingVerboseWithUnits) used in the example by default.
|
||||
|
||||
The -t option is available only in multi-threading mode
|
||||
and it allows the user to override the Geant4 default number of
|
||||
threads. The number of threads can be also set via G4FORCENUMBEROFTHREADS
|
||||
environment variable which has the top priority.
|
||||
|
||||
- Execute exampleB4a in the 'interactive mode' with visualization
|
||||
\verbatim
|
||||
% exampleB4a
|
||||
and type in the commands from run1.mac line by line:
|
||||
Idle> /tracking/verbose 1
|
||||
Idle> /run/beamOn 1
|
||||
Idle> ...
|
||||
Idle> exit
|
||||
\endverbatim
|
||||
or
|
||||
\verbatim
|
||||
Idle> /control/execute run1.mac
|
||||
....
|
||||
Idle> exit
|
||||
\endverbatim
|
||||
|
||||
- Execute exampleB4a in the 'batch' mode from macro files
|
||||
(without visualization)
|
||||
\verbatim
|
||||
% exampleB4a -m run2.mac
|
||||
% exampleB4a -m exampleB4.in > exampleB4.out
|
||||
\endverbatim
|
||||
|
||||
- Execute exampleB4a in the 'interactive mode' with a selected UI session,
|
||||
e.g. tcsh
|
||||
\verbatim
|
||||
% exampleB4a -u tcsh
|
||||
\endverbatim
|
||||
|
||||
<hr>
|
||||
|
||||
The following paragraphs are common to all basic examples
|
||||
|
||||
\section B4_A VISUALISATION
|
||||
|
||||
The visualization manager is set via the G4VisExecutive class
|
||||
in the main () function in exampleB4a.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
|
||||
\verbatim
|
||||
/vis/open DAWNFILE
|
||||
\endverbatim
|
||||
then to get the same view
|
||||
\verbatim
|
||||
/vis/viewer/copyView viewer-0
|
||||
\endverbatim
|
||||
or to get the same view *plus* scene-modifications
|
||||
\verbatim
|
||||
/vis/viewer/set/all viewer-0
|
||||
\endverbatim
|
||||
then to see the result
|
||||
\verbatim
|
||||
/vis/viewer/flush
|
||||
\endverbatim
|
||||
|
||||
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,\n
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4OpenGLTutorial/G4OpenGLTutorial.html">
|
||||
OpenGL Tutorial </a>
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4DAWNTutorial/G4DAWNTutorial.html">
|
||||
DAWN Tutorial </a>
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4HepRAppTutorial/G4HepRAppTutorial.html">
|
||||
HepRApp Tutorial </a>
|
||||
|
||||
The tracks are automatically drawn at the end of each event, accumulated
|
||||
for all events and erased at the beginning of the next run.
|
||||
|
||||
\section B4_B USER INTERFACES
|
||||
|
||||
The user command interface is set via the G4UIExecutive class
|
||||
in the main () function in exampleB4a.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).
|
||||
|
||||
*/
|
||||
|
||||
|
||||
@@ -0,0 +1,269 @@
|
||||
-------------------------------------------------------------------
|
||||
|
||||
=========================================================
|
||||
Geant4 - an Object-Oriented Toolkit for Simulation in HEP
|
||||
=========================================================
|
||||
|
||||
Example B4
|
||||
-----------
|
||||
|
||||
This example simulates a simple Sampling Calorimeter setup.
|
||||
To demonstrate several possible ways of data scoring, the example
|
||||
is provided in four variants: B4a, B4b, B4c, B4d.
|
||||
(See also examples/extended/electromagnetic/TestEm3)
|
||||
|
||||
1- GEOMETRY DEFINITION
|
||||
|
||||
The geometry is constructed in B4[c,d]::DetectorConstruction class.
|
||||
The calorimeter is a box made of a given number of layers. A layer
|
||||
consists of an absorber plate and of a detection gap. The layer is
|
||||
replicated.
|
||||
|
||||
Four parameters define the geometry of the calorimeter :
|
||||
- the thickness of an absorber plate,
|
||||
- the thickness of a gap,
|
||||
- the number of layers, and
|
||||
- the transverse size of the calorimeter (the entrance face is a square).
|
||||
|
||||
In addition, a global, uniform, and transverse magnetic field can be
|
||||
applied using G4GlobalMagFieldMessenger, instantiated in
|
||||
B4[c,d]::DetectorConstruction::ConstructSDandField
|
||||
with a non zero field value, or via interactive commands.
|
||||
For example:
|
||||
|
||||
/globalField/setValue 0.2 0 0 tesla
|
||||
|
||||
|
||||
|<----layer 0---------->|<----layer 1---------->|<----layer 2---------->|
|
||||
| | | |
|
||||
==========================================================================
|
||||
|| | || | || | ||
|
||||
|| | || | || | ||
|
||||
beam || absorber | gap || absorber | gap || absorber | gap ||
|
||||
======> || | || | || | ||
|
||||
|| | || | || | ||
|
||||
==========================================================================
|
||||
|
||||
A more general version of this geometry can be found in:
|
||||
examples/extended/electromagnetic/TestEm3
|
||||
where all the geometry parameters, the absorber and gap materials
|
||||
can be modified interactively via the commands defined in the DetectorMessenger
|
||||
class.
|
||||
|
||||
2- PHYSICS LIST
|
||||
|
||||
The particle's type and the physic processes which will be available
|
||||
in this example are set in the FTFP_BERT physics list. This physics list
|
||||
requires data files for electromagnetic and hadronic processes.
|
||||
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
|
||||
The following datasets: G4LEDATA, G4LEVELGAMMADATA, G4SAIDXSDATA and
|
||||
G4ENSDFSTATEDATA are mandatory for this example.
|
||||
|
||||
In addition the build-in interactive command:
|
||||
/process/(in)activate processName
|
||||
allows to activate/inactivate the processes one by one.
|
||||
|
||||
3- ACTION INITALIZATION
|
||||
|
||||
A newly introduced class, B4[a,b,c,d]::ActionInitialization,
|
||||
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:
|
||||
B4[a,b,c,d]::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
|
||||
B4[a,b,c,d]::ActionInitialization::BuildForMaster()
|
||||
which is invoked only in multi-threading mode.
|
||||
|
||||
4- PRIMARY GENERATOR
|
||||
|
||||
The primary beam consists of a single particle which hits the
|
||||
calorimeter perpendicular to the input face. The type of the particle
|
||||
and its energy are set in the B4::PrimaryGeneratorAction class, and can
|
||||
be changed via the G4 built-in commands of the G4ParticleGun class (see
|
||||
the macros provided with this example).
|
||||
|
||||
5- RUNS and EVENTS
|
||||
|
||||
A run is a set of events.
|
||||
The user can choose the frequency of printing via the Geant4 interactive
|
||||
command, for example:
|
||||
|
||||
/run/printProgress 100
|
||||
|
||||
6- DETECTOR RESPONSE
|
||||
|
||||
The energy deposit and track lengths of the charged particles are recorded on
|
||||
an event by event basis in the Absober and Gap layers.
|
||||
|
||||
In order to demonstrate several possible ways of data scoring,
|
||||
the example is provided in four variants:
|
||||
|
||||
Variant a: User Actions
|
||||
|
||||
These 4 quantities are data members of the B4a::EventAction class.
|
||||
They are collected step by step in
|
||||
B4a::SteppingAction::UserSteppingAction(), and passed to the event action
|
||||
via two methods: B4a::EventAction::AddAbs() and B4a::EventAction::AddGap().
|
||||
|
||||
In B4a::EventAction::EndOfEventAction(), these quantities are printed and
|
||||
filled in H1D histograms and ntuple to accumulate statistic and compute
|
||||
dispersion.
|
||||
|
||||
Variant b: User data object
|
||||
|
||||
In order to avoid dependencies between action classes, a user object
|
||||
B4b::RunData, derived from G4Run, is defined with data members needed
|
||||
for the accounted information.
|
||||
In order to reduce the number of data members a 2-dimensions array
|
||||
is introduced for each quantity.
|
||||
Then the quantities are collected step by step in user action classes:
|
||||
B4b::SteppingAction::UserSteppingAction() and
|
||||
B4b::EventAction::EndOfEventAction() in a similar way as in variant a.
|
||||
|
||||
Variant c: Hits and Sensitive detectors
|
||||
|
||||
In this option, the physics quantities are accounted using the hits
|
||||
and sensitive detectors framework defined in the Geant4 kernel.
|
||||
The physics quantities are stored in B4c::CalorHit via two B4c::CalorimeterSD
|
||||
objects, one associated with the Absorber volume and another one with Gap
|
||||
in B4c::DetectorConstruction::ConstructSDandField().
|
||||
|
||||
In contrary to the B2 example (Tracker) where a new hit is created
|
||||
with each track passing the sensitive volume (in the calorimeter), only one
|
||||
hit is created for each calorimeter layer and one more hit to account for
|
||||
the total quantities in all layers. In addition to the variants a and b,
|
||||
the quantities per each layer are also available in addition to the total
|
||||
quantities.
|
||||
|
||||
Variant d: Scorer
|
||||
|
||||
In this option, the Geant4 scorers which are defined on the top of hits
|
||||
and sensitive detectors Geant4 framework are used.
|
||||
In practice this means that the user does not need to define hits and sensitive
|
||||
detector classes but rather uses the classes already defined
|
||||
in Geant4. In this example, the G4MultiFunctionalDetector with
|
||||
G4PSEnergyDeposit and G4PSTrackLength primitive scores are used (see
|
||||
B4d::DetectorConstruction::ConstructSDandField()).
|
||||
|
||||
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.
|
||||
|
||||
Also with this approach, the quantities per each layer are available
|
||||
in addition to the total quantities.
|
||||
|
||||
7- HISTOGRAMS
|
||||
|
||||
The analysis tools are used to accumulate statistics and compute the dispersion
|
||||
of the energy deposit and track lengths of the charged particles.
|
||||
H1D histograms are created in B4[b]::RunAction::RunAction() for the
|
||||
following quantities:
|
||||
- Energy deposit in absorber
|
||||
- Energy deposit in gap
|
||||
- Track length in absorber
|
||||
- Track length in gap
|
||||
The same values are also saved in an ntuple.
|
||||
|
||||
The histograms and the ntuple are saved in the output file in a format
|
||||
according to a specified file extension, the default in this example
|
||||
is ROOT.
|
||||
|
||||
The accumulated statistic and computed dispersion is printed at the end of
|
||||
run, in B4::RunAction::EndOfRunAction().
|
||||
When running in multi-threading mode, the histograms and the ntuple accumulated
|
||||
on threads are merged in a single output file. While merging of histograms is
|
||||
performed by default, merging of ntuples is explicitly activated in the B4::RunAction
|
||||
constructor.
|
||||
|
||||
The ROOT histograms and ntuple can be plotted with ROOT using the plotHisto.C
|
||||
and plotNtuple.C macros.
|
||||
|
||||
8- HOW TO RUN
|
||||
|
||||
This example handles the program arguments in a new way.
|
||||
It can be run with the following optional arguments:
|
||||
% exampleB4a [-m macro ] [-u UIsession] [-t nThreads] [-vDefault]
|
||||
|
||||
The -vDefault option will activate using the default Geant4 stepping verbose
|
||||
class (G4SteppingVerbose) instead of the enhanced stepping verbose with best
|
||||
units (G4SteppingVerboseWithUnits) used in the example by default.
|
||||
|
||||
The -t option is available only in multi-threading mode
|
||||
and it allows the user to override the Geant4 default number of
|
||||
threads. The number of threads can be also set via G4FORCENUMBEROFTHREADS
|
||||
environment variable which has the top priority.
|
||||
|
||||
- Execute exampleB4a in the 'interactive mode' with visualization
|
||||
% exampleB4a
|
||||
and type in the commands from run1.mac line by line:
|
||||
Idle> /tracking/verbose 1
|
||||
Idle> /run/beamOn 1
|
||||
Idle> ...
|
||||
Idle> exit
|
||||
or
|
||||
Idle> /control/execute run1.mac
|
||||
....
|
||||
Idle> exit
|
||||
|
||||
- Execute exampleB4a in the 'batch' mode from macro files
|
||||
(without visualization)
|
||||
% exampleB4a -m run2.mac
|
||||
% exampleB4a -m exampleB4.in > exampleB4.out
|
||||
|
||||
- Execute exampleB4a in the 'interactive mode' with a selected UI session,
|
||||
e.g. tcsh
|
||||
% exampleB4a -u tcsh
|
||||
|
||||
The following paragraphs are common to all basic examples
|
||||
|
||||
A- VISUALIZATION
|
||||
|
||||
The visualization manager is set via the G4VisExecutive class
|
||||
in the main() function in exampleB4a.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 exampleB4a.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).
|
||||
@@ -0,0 +1,341 @@
|
||||
|
||||
///\file "B5/.README.txt"
|
||||
///\brief Example B5 README page
|
||||
|
||||
/*! \page ExampleB5 Example %B5
|
||||
|
||||
Example B5 implements a double-arm spectrometer with wire chambers,
|
||||
hodoscopes and calorimeters. Event simulation and collection are
|
||||
enabled, as well as event display and analysis.
|
||||
|
||||
|
||||
\section B5_s1 GEOMETRY
|
||||
|
||||
The spectrometer consists of two detector arms
|
||||
(see B5::DetectorConstruction). One arm provides
|
||||
position and timing information of the incident particle while the
|
||||
other collects position, timing and energy information of the particle
|
||||
after it has been deflected by a magnetic field centered at the
|
||||
spectrometer pivot point.
|
||||
|
||||
- First arm: box filled with air, also containing:
|
||||
- 1 hodoscope (15 vertical strips of plastic scintillator)
|
||||
- 1 drift chamber (5 horizontal argon gas layers with a
|
||||
"virtual wire" at the center of each layer)
|
||||
|
||||
- Second arm: box filled with air, also containing:
|
||||
- 1 hodoscope (25 vertical strips of plastic scintillator)
|
||||
- 1 drift chamber (5 horizontal argon gas layers with a
|
||||
"virtual wire" at the center of each layer)
|
||||
- 1 electromagnetic calorimeter:
|
||||
a box sub-divided along x,y and z
|
||||
axes into cells of CsI
|
||||
- 1 hadronic calorimeter:
|
||||
a box sub-divided along x,y, and z axes
|
||||
into cells of lead, with a layer of
|
||||
plastic scintillator placed at the center
|
||||
of each cell
|
||||
|
||||
- Magnetic field region: air-filled cylinder which contains
|
||||
the field (see B5::MagneticField)
|
||||
|
||||
The maximum step limit in the magnetic field region is also set
|
||||
via the G4UserLimits class in a similar way as in Example B2
|
||||
(see \ref B2_s6 in B2 example documentation).
|
||||
|
||||
The rotation angle of the second arm and the magnetic field value
|
||||
can be set via the interactive commands defined using the G4GenericMessenger
|
||||
class.
|
||||
|
||||
\section B5_s2 PHYSICS
|
||||
|
||||
This example uses the reference hadronic physics list, FTFP_BERT,
|
||||
and also adds the G4StepLimiter process.
|
||||
|
||||
\section B5_s3 ACTION INITALIZATION
|
||||
|
||||
B5::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:
|
||||
B5::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
|
||||
B5::ActionInitialization::BuildForMaster()
|
||||
which is invoked only in multi-threading mode.
|
||||
|
||||
\section B5_s4 PRIMARY GENERATOR
|
||||
|
||||
The primary generator action class employs the G4ParticleGun.
|
||||
The primary kinematics consists of a single particle which is
|
||||
is sent in the direction of the first spectrometer arm.
|
||||
|
||||
The type of the particle and its several properties can be changed
|
||||
via the G4 built-in commands of the G4ParticleGun class or
|
||||
this example command defined using the G4GenericMessenger class.
|
||||
|
||||
|
||||
\section B5_s5 EVENT
|
||||
|
||||
An event consists of the generation of a single particle which is
|
||||
transported through the first spectrometer arm. Here, a scintillator
|
||||
hodoscope records the reference time of the particle before it passes
|
||||
through a drift chamber where the particle position is measured.
|
||||
Momentum analysis is performed as the particle passes through a magnetic
|
||||
field at the spectrometer pivot and then into the second spectrometer
|
||||
arm. In the second arm, the particle passes through another hodoscope
|
||||
and drift chamber before interacting in the electromagnetic calorimeter.
|
||||
Here it is likely that particles will induce electromagnetic showers.
|
||||
The shower energy is recorded in a three-dimensional array of CsI
|
||||
crystals. Secondary particles from the shower, as well as primary
|
||||
particles which do not interact in the CsI crystals, pass into the
|
||||
hadronic calorimeter. Here, the remaining energy is collected in a
|
||||
three-dimensional array of scintillator-lead sandwiches.
|
||||
|
||||
Several aspects of the event may be changed interactively by the user:
|
||||
- angle of the second spectrometer arm
|
||||
- strength of magnetic field
|
||||
- initial particle type
|
||||
- initial momentum and angle
|
||||
- momentum and angle spreads
|
||||
- type of initial particle may be randomized
|
||||
|
||||
The initial particle type can be changed using the G4ParticleGun command:
|
||||
\verbatim
|
||||
/gun/particle particleName
|
||||
\endverbatim
|
||||
|
||||
The UI commands specific to this example are available in /B5 command
|
||||
directory:
|
||||
\verbatim
|
||||
/B5/detector/armAngle angle unit
|
||||
/B5/field/value field unit
|
||||
/B5/generator/momentum value unit
|
||||
/B5/generator/sigmaMomentum value unit
|
||||
/B5/generator/sigmaAngle value unit
|
||||
/B5/generator/randomizePrimary [true|false]
|
||||
\endverbatim
|
||||
|
||||
They are implemented in
|
||||
- B5::DetectorConstruction::DefineCommands(),
|
||||
- B5::MagneticField::DefineCommands() and
|
||||
- B5::PrimaryGeneratorAction::DefineCommands() methods
|
||||
using G4GenericMessenger class.
|
||||
|
||||
In first execution of B5::EventAction::BeginOfEventAction()
|
||||
the hits collections identifiers are saved in data members of the class
|
||||
and used in B5::EventAction::EndOfEventAction() for accessing
|
||||
the hists collections and filling the accounted information in defined
|
||||
histograms and ntuples and printing its summary in a log file.
|
||||
The frequency of printing can be tuned with the built-in command
|
||||
\verbatim
|
||||
/run/printProgress frequency
|
||||
\endverbatim
|
||||
|
||||
\section B5_s6 DETECTOR RESPONSE
|
||||
|
||||
All the information required to simulate and analyze an event is
|
||||
recorded in hits. This information is recorded in the following
|
||||
sensitive detectors:
|
||||
|
||||
- hodoscope:
|
||||
- particle time
|
||||
- strip ID, position and rotation
|
||||
- see B5::HodoscopeSD, B5::HodoscopeHit
|
||||
|
||||
- drift chamber:
|
||||
- particle time
|
||||
- particle position
|
||||
- layer ID
|
||||
- see B5::DriftChamberSD, B5::DriftChamberHit classes
|
||||
|
||||
- electromagnetic calorimeter:
|
||||
- energy deposited in cell
|
||||
- cell ID, position and rotation
|
||||
- see B5::EmCalorimeterSD, B5::EmCalorimeterHit classes
|
||||
|
||||
- hadronic calorimeter:
|
||||
- energy deposited in cell
|
||||
- cell column ID and row ID, position and rotation
|
||||
- see B5::HadCalorimeterSD, B5::HadCalorimeterHit classes
|
||||
|
||||
The hit classes include methods GetAttDefs and CreateAttValues to define
|
||||
and then fill extra "HepRep-style" Attributes that the visualization system
|
||||
can use to present extra information about the hits.
|
||||
For example, if you pick a B5::HadCalorimeterHit in OpenGL or a HepRep viewer,
|
||||
you will be shown the hit's "Hit Type", "Column ID", "Row ID",
|
||||
"Energy Deposited" and "Position".
|
||||
These attributes are essentially arbitrary extra pieces of information
|
||||
(integers, doubles or strings) that are carried through the visualization.
|
||||
Each attribute is defined once in G4AttDef object and then is filled for
|
||||
each hit in a G4AttValue object.
|
||||
These attributes can also be used by commands to filter which hits are drawn:
|
||||
/vis/filtering/hits/drawByAttribute
|
||||
Detector Geometry and trajectories also carry HepRep-style attributes,
|
||||
but these are filled automatically in the base classes.
|
||||
HepRep is further described at the
|
||||
<a href="http://www.slac.stanford.edu/~perl/heprep/"> HepRep Home Page </a>
|
||||
|
||||
\section B5_s7 ANALYSIS
|
||||
|
||||
The analysis tools are used to accumulate statistics.
|
||||
Histograms and an ntuple are created in B5::RunAction::RunAction()
|
||||
constructor for the following quantities:
|
||||
|
||||
- 1D histograms:
|
||||
- Number of hits in Chamber 1
|
||||
- Number of hits in Chamber 2
|
||||
|
||||
- 2D histograms:
|
||||
- Drift Chamber 1 X vs Y positions
|
||||
- Drift Chamber 2 X vs Y positions
|
||||
|
||||
- Ntuple:
|
||||
- Number of hits in Chamber 1
|
||||
- Number of hits in Chamber 2
|
||||
- Total energy deposit in EM calorimeter
|
||||
- Total energy deposit in Hadronic calorimeter
|
||||
- Time of flight in Hodoscope 1
|
||||
- Time of flight in Hodoscope 2
|
||||
- Vector of energy deposits in EM calorimeter cells
|
||||
- Vector of energy deposits in Hadronic calorimeter cells
|
||||
|
||||
The histograms and ntuple are saved in two output files in a default
|
||||
(Root) file format.
|
||||
|
||||
Another file format (for example xml) can be selected either by
|
||||
changing the generic analysis manager default file type:
|
||||
\verbatim
|
||||
analysisManager->SetDefaultFileType("xml");
|
||||
\endverbatim
|
||||
or by providing the file names with the extension:
|
||||
\verbatim
|
||||
analysisManager->SetFileName("B5.xml");
|
||||
analysisManager->SetNtupleFileName(0, "B5ntuple.xml");
|
||||
\endverbatim
|
||||
|
||||
When running in multi-threading mode, the histograms and ntuple accumulated
|
||||
on threads are automatically merged in a single output file.
|
||||
|
||||
\section B5_s8 PLOTTING:
|
||||
|
||||
This example comes with a commented plotter.mac that shows how to use the
|
||||
plotting coming with some of the visualization drivers (for example the
|
||||
ToolsSG ones) to see the histograms. In it you will see how to activate
|
||||
the vis driver (create a "scene handler"), create a viewer, create a scene
|
||||
containing a plotter model object, create plotting "regions" (here 2x2
|
||||
regions) and attach the histograms to each region. When done, each
|
||||
run beamOn should display at end the content of the histograms.
|
||||
|
||||
In the second part of plotter.mac, is shown various ways to customize the
|
||||
regions, for example changing the bins color, the axis labels fonts, etc...
|
||||
This could be done by using default embedded styles, defining styles with commands,
|
||||
or setting up directly parameters of the various parts of a plot by using a
|
||||
dedicated command.
|
||||
|
||||
By default the fonts used are the Hershey vectorial ones that do not need
|
||||
an extra package, but you can use some freetype fonts if building with the
|
||||
cmake flag -DGEANT4_USE_FREETYPE=ON. Two embedded ttf fonts comes with the
|
||||
ToolsSG plotting: roboto_bold (some open source kind of the Microsoft arialbd)
|
||||
and lato_regular (close to an helvetica). You can use your own .ttf files by
|
||||
using the TOOLS_FONT_PATH environment variable to specify the directory where
|
||||
they could be found.
|
||||
|
||||
<hr>
|
||||
|
||||
The following paragraphs are common to all basic examples
|
||||
|
||||
\section B5_A VISUALISATION
|
||||
|
||||
The visualization manager is set via the G4VisExecutive class
|
||||
in the main () function in exampleB5.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
|
||||
\verbatim
|
||||
/vis/open DAWNFILE
|
||||
\endverbatim
|
||||
then to get the same view
|
||||
\verbatim
|
||||
/vis/viewer/copyView viewer-0
|
||||
\endverbatim
|
||||
or to get the same view *plus* scene-modifications
|
||||
\verbatim
|
||||
/vis/viewer/set/all viewer-0
|
||||
\endverbatim
|
||||
then to see the result
|
||||
\verbatim
|
||||
/vis/viewer/flush
|
||||
\endverbatim
|
||||
|
||||
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.
|
||||
|
||||
vis.mac has additional commands that demonstrate additional functionality
|
||||
of the vis system, such as displaying text, axes, scales, date, logo and
|
||||
shows how to change viewpoint and style.
|
||||
To see even more commands use help or ls or browse the available UI commands
|
||||
in the Application Developers Guide.
|
||||
|
||||
For more information on visualization, including information on how to
|
||||
install and run DAWN, OpenGL and HepRApp, see the visualization tutorials,
|
||||
for example,\n
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4OpenGLTutorial/G4OpenGLTutorial.html">
|
||||
OpenGL Tutorial </a>
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4DAWNTutorial/G4DAWNTutorial.html">
|
||||
DAWN Tutorial </a>
|
||||
- <a href="http://geant4.slac.stanford.edu/Presentations/vis/G4HepRAppTutorial/G4HepRAppTutorial.html">
|
||||
HepRApp Tutorial </a>
|
||||
|
||||
The tracks are automatically drawn at the end of each event, accumulated
|
||||
for all events and erased at the beginning of the next run.
|
||||
|
||||
\section B5_B USER INTERFACES
|
||||
|
||||
The user command interface is set via the G4UIExecutive class
|
||||
in the main () function in exampleB5.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).
|
||||
|
||||
\section B5_C HOW TO RUN
|
||||
|
||||
- Execute exampleB5 in the 'interactive mode' with visualization
|
||||
\verbatim
|
||||
% exampleB5
|
||||
and type in the commands from run1.mac line by line:
|
||||
Idle> /control/verbose 2
|
||||
Idle> /tracking/verbose 1
|
||||
Idle> /run/beamOn 10
|
||||
Idle> ...
|
||||
Idle> exit
|
||||
\endverbatim
|
||||
or
|
||||
\verbatim
|
||||
Idle> /control/execute run1.mac
|
||||
....
|
||||
Idle> exit
|
||||
\endverbatim
|
||||
|
||||
- Execute exampleB5 in the 'batch' mode from macro files
|
||||
(without visualization)
|
||||
\verbatim
|
||||
% exampleB5 run2.mac
|
||||
% exampleB5 exampleB5.in > exampleB5.out
|
||||
\endverbatim
|
||||
*/
|
||||
|
||||
@@ -0,0 +1,314 @@
|
||||
|
||||
=========================================================
|
||||
Geant4 - an Object-Oriented Toolkit for Simulation in HEP
|
||||
=========================================================
|
||||
|
||||
Extended Example B5
|
||||
--------------------
|
||||
|
||||
Example B5 implements a double-arm spectrometer with wire chambers,
|
||||
hodoscopes and calorimeters. Event simulation and collection are
|
||||
enabled, as well as event display and analysis.
|
||||
|
||||
|
||||
1- GEOMETRY
|
||||
|
||||
The spectrometer consists of two detector arms
|
||||
(see B5::DetectorConstruction). One arm provides
|
||||
position and timing information of the incident particle while the
|
||||
other collects position, timing and energy information of the particle
|
||||
after it has been deflected by a magnetic field centered at the
|
||||
spectrometer pivot point.
|
||||
|
||||
- First arm: box filled with air, also containing:
|
||||
|
||||
1 hodoscope (15 vertical strips of plastic scintillator)
|
||||
1 drift chamber (5 horizontal argon gas layers with a
|
||||
"virtual wire" at the center of each layer)
|
||||
|
||||
- Second arm: box filled with air, also containing:
|
||||
|
||||
1 hodoscope (25 vertical strips of plastic scintillator)
|
||||
1 drift chamber (5 horizontal argon gas layers with a
|
||||
"virtual wire" at the center of each layer)
|
||||
1 electromagnetic calorimeter:
|
||||
a box sub-divided along x,y and z
|
||||
axes into cells of CsI
|
||||
1 hadronic calorimeter:
|
||||
a box sub-divided along x,y, and z axes
|
||||
into cells of lead, with a layer of
|
||||
plastic scintillator placed at the center
|
||||
of each cell
|
||||
|
||||
- Magnetic field region: air-filled cylinder which contains
|
||||
the field (see B5::MagneticField)
|
||||
|
||||
The maximum step limit in the magnetic field region is also set
|
||||
via the G4UserLimits class in a similar way as in Example B2.
|
||||
|
||||
The rotation angle of the second arm and the magnetic field value
|
||||
can be set via the interactive command defined using the G4GenericMessenger
|
||||
class.
|
||||
|
||||
2- PHYSICS
|
||||
|
||||
This example uses the reference hadronic physics list, FTFP_BERT,
|
||||
and also adds the G4StepLimiter process.
|
||||
|
||||
|
||||
3- ACTION INITALIZATION
|
||||
|
||||
B5::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:
|
||||
B5::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
|
||||
B5::ActionInitialization::BuildForMaster()
|
||||
which is invoked only in multi-threading mode.
|
||||
|
||||
4- PRIMARY GENERATOR
|
||||
|
||||
The primary generator action class employs the G4ParticleGun.
|
||||
The primary kinematics consists of a single particle which is
|
||||
is sent in the direction of the first spectrometer arm.
|
||||
|
||||
The type of the particle and its several properties can be changed
|
||||
via the G4 built-in commands of the G4ParticleGun class or
|
||||
this example command defined using the G4GenericMessenger class.
|
||||
|
||||
|
||||
5- EVENT
|
||||
|
||||
An event consists of the generation of a single particle which is
|
||||
transported through the first spectrometer arm. Here, a scintillator
|
||||
hodoscope records the reference time of the particle before it passes
|
||||
through a drift chamber where the particle position is measured.
|
||||
Momentum analysis is performed as the particle passes through a magnetic
|
||||
field at the spectrometer pivot and then into the second spectrometer
|
||||
arm. In the second arm, the particle passes through another hodoscope
|
||||
and drift chamber before interacting in the electromagnetic calorimeter.
|
||||
Here it is likely that particles will induce electromagnetic showers.
|
||||
The shower energy is recorded in a three-dimensional array of CsI
|
||||
crystals. Secondary particles from the shower, as well as primary
|
||||
particles which do not interact in the CsI crystals, pass into the
|
||||
hadronic calorimeter. Here, the remaining energy is collected in a
|
||||
three-dimensional array of scintillator-lead sandwiches.
|
||||
|
||||
Several aspects of the event may be changed interactively by the user:
|
||||
- angle of the second spectrometer arm
|
||||
- strength of magnetic field
|
||||
- initial particle type
|
||||
- initial momentum and angle
|
||||
- momentum and angle spreads
|
||||
- type of initial particle may be randomized
|
||||
|
||||
The initial particle type can be changed using the G4ParticleGun command:
|
||||
/gun/particle particleName
|
||||
|
||||
The UI commands specific to this example are available in /B5 command
|
||||
directory:
|
||||
/B5/detector/armAngle angle unit
|
||||
/B5/field/value field unit
|
||||
/B5/generator/momentum value unit
|
||||
/B5/generator/sigmaMomentum value unit
|
||||
/B5/generator/sigmaAngle value unit
|
||||
/B5/generator/randomizePrimary [true|false]
|
||||
|
||||
They are implemented in
|
||||
B5::DetectorConstruction::DefineCommands(),
|
||||
B5::MagneticField::DefineCommands() and
|
||||
B5::PrimaryGeneratorAction::DefineCommands() methods
|
||||
using G4GenericMessenger class.
|
||||
|
||||
In first execution of BeginOfEventAction()
|
||||
the hits collections identifiers are saved in data members of the class
|
||||
and used in EndOfEventAction() for accessing
|
||||
the hists collections and filling the accounted information in defined
|
||||
histograms and ntuples and printing its summary in a log file.
|
||||
The frequency of printing can be tuned with the built-in command
|
||||
/run/printProgress frequency
|
||||
|
||||
6- DETECTOR RESPONSE:
|
||||
|
||||
All the information required to simulate and analyze an event is
|
||||
recorded in hits. This information is recorded in the following
|
||||
sensitive detectors:
|
||||
|
||||
- hodoscope:
|
||||
particle time
|
||||
strip ID, position and rotation
|
||||
(see B5::HodoscopeSD, B5::HodoscopeHit classes)
|
||||
|
||||
- drift chamber:
|
||||
particle time
|
||||
particle position
|
||||
layer ID
|
||||
(see B5::DriftChamberSD, B5::DriftChamberHit classes)
|
||||
|
||||
- electromagnetic calorimeter:
|
||||
energy deposited in cell
|
||||
cell ID, position and rotation
|
||||
(see B5::EMCalorimeterSD, B5::EMCalorimeterHit classes)
|
||||
|
||||
- hadronic calorimeter:
|
||||
energy deposited in cell
|
||||
cell column ID and row ID, position and rotation
|
||||
(see B5::HadCalorimeterSD, B5::HadCalorimeterHit classes)
|
||||
|
||||
The hit classes include methods GetAttDefs and CreateAttValues to define
|
||||
and then fill extra "HepRep-style" Attributes that the visualization system
|
||||
can use to present extra information about the hits.
|
||||
For example, if you pick a B5::HadCalorimeterHit in OpenGL or a HepRep viewer,
|
||||
you will be shown the hit's "Hit Type", "Column ID", "Row ID",
|
||||
"Energy Deposited" and "Position".
|
||||
These attributes are essentially arbitrary extra pieces of information
|
||||
(integers, doubles or strings) that are carried through the visualization.
|
||||
Each attribute is defined once in G4AttDef object and then is filled for
|
||||
each hit in a G4AttValue object.
|
||||
These attributes can also be used by commands to filter which hits are drawn:
|
||||
/vis/filtering/hits/drawByAttribute
|
||||
Detector Geometry and trajectories also carry HepRep-style attributes,
|
||||
but these are filled automatically in the base classes.
|
||||
HepRep is further described at: http://www.slac.stanford.edu/~perl/heprep/
|
||||
|
||||
7- ANALYSIS:
|
||||
|
||||
The analysis tools are used to accumulate statistics.
|
||||
Histograms and an ntuple are created in B5::RunAction::RunAction()
|
||||
constructor for the following quantities:
|
||||
|
||||
1D histograms:
|
||||
- Number of hits in Chamber 1
|
||||
- Number of hits in Chamber 2
|
||||
|
||||
2D histograms:
|
||||
- Drift Chamber 1 X vs Y positions
|
||||
- Drift Chamber 2 X vs Y positions
|
||||
|
||||
Ntuple:
|
||||
- Number of hits in Chamber 1
|
||||
- Number of hits in Chamber 2
|
||||
- Total energy deposit in EM calorimeter
|
||||
- Total energy deposit in Hadronic calorimeter
|
||||
- Time of flight in Hodoscope 1
|
||||
- Time of flight in Hodoscope 2
|
||||
- Vector of energy deposits in EM calorimeter cells
|
||||
- Vector of energy deposits in Hadronic calorimeter cells
|
||||
|
||||
The histograms and ntuple are saved in two output files in a default
|
||||
(Root) file format.
|
||||
|
||||
Another file format (for example xml) can be selected either by
|
||||
changing the generic analysis manager default file type:
|
||||
analysisManager->SetDefaultFileType("xml");
|
||||
or by providing the file names with the extension:
|
||||
analysisManager->SetFileName("B5.xml");
|
||||
analysisManager->SetNtupleFileName(0, "B4ntuple.xml");
|
||||
|
||||
When running in multi-threading mode, the histograms and ntuple accumulated
|
||||
on threads are automatically merged in a single output file.
|
||||
|
||||
8- PLOTTING:
|
||||
|
||||
This example comes with a commented plotter.mac that shows how to use the
|
||||
plotting coming with some of the visualization drivers (for example the
|
||||
ToolsSG ones) to see the histograms. In it you will see how to activate
|
||||
the vis driver (create a "scene handler"), create a viewer, create a scene
|
||||
containing a plotter model object, create plotting "regions" (here 2x2
|
||||
regions) and attach the histograms to each region. When done, each
|
||||
run beamOn should display at end the content of the histograms.
|
||||
|
||||
In the second part of plotter.mac, is shown various ways to customize the
|
||||
regions, for example changing the bins color, the axis labels fonts, etc...
|
||||
This could be done by using default embedded styles, defining styles with commands,
|
||||
or setting up directly parameters of the various parts of a plot by using a
|
||||
dedicated command.
|
||||
|
||||
By default the fonts used are the Hershey vectorial ones that do not need
|
||||
an extra package, but you can use some freetype fonts if building with the
|
||||
cmake flag -DGEANT4_USE_FREETYPE=ON. Two embedded ttf fonts comes with the
|
||||
ToolsSG plotting: roboto_bold (some open source kind of the Microsoft arialbd)
|
||||
and lato_regular (close to an helvetica). You can use your own .ttf files by
|
||||
using the TOOLS_FONT_PATH environment variable to specify the directory where
|
||||
they could be found.
|
||||
|
||||
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 exampleB5.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.
|
||||
|
||||
vis.mac has additional commands that demonstrate additional functionality
|
||||
of the vis system, such as displaying text, axes, scales, date, logo and
|
||||
shows how to change viewpoint and style.
|
||||
To see even more commands use help or ls or browse the available UI commands
|
||||
in the Application Developers Guide.
|
||||
|
||||
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 exampleB5.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 exampleB5 in the 'interactive mode' with visualization:
|
||||
% ./exampleB5
|
||||
and type in the commands from run1.mac line by line:
|
||||
Idle> /control/verbose 2
|
||||
Idle> /tracking/verbose 1
|
||||
Idle> /run/beamOn 10
|
||||
Idle> ...
|
||||
Idle> exit
|
||||
or
|
||||
Idle> /control/execute run1.mac
|
||||
....
|
||||
Idle> exit
|
||||
|
||||
- Execute exampleB5 in the 'batch' mode from macro files
|
||||
(without visualization)
|
||||
% ./exampleB5 run2.mac
|
||||
% ./exampleB5 exampleB5.in > exampleB5.out
|
||||
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
-------------------------------------------------------------------
|
||||
|
||||
=========================================================
|
||||
Geant4 - an Object-Oriented Toolkit for Simulation in HEP
|
||||
=========================================================
|
||||
|
||||
Basic Examples
|
||||
----------------
|
||||
|
||||
The set of basic examples is oriented to "novice" users and covering many
|
||||
basic general use-cases typical of an "application"-oriented kind of
|
||||
development.
|
||||
|
||||
ExampleB1
|
||||
- Simple geometry with a few solids
|
||||
- Geometry with simple placements (G4PVPlacement)
|
||||
- Scoring total dose in a selected volume user action classes
|
||||
- Using G4Accumulable for automatic merging of scored values in multi-threading mode
|
||||
- Geant4 physics list (QBBC)
|
||||
|
||||
ExampleB2
|
||||
- Simplified tracker geometry with global constant magnetic field
|
||||
- Geometry with simple placements (G4PVPlacement) and parameterisation
|
||||
(G4PVParameterisation)
|
||||
- Scoring within tracker via G4 sensitive detector and hits
|
||||
- Geant4 physics list (FTFP_BERT) with step limiter
|
||||
- Started from novice/N02 example
|
||||
|
||||
ExampleB3
|
||||
- Schematic Positron Emitted Tomography system
|
||||
- Geometry with simple placements with rotation (G4PVPlacement)
|
||||
- Radioactive source
|
||||
- Scoring within Crystals via G4 scorers
|
||||
- Using G4Accumulable for automatic merging of scored values in multi-threading mode (a)
|
||||
and G4StatAnalysis for accumulating statistics (b)
|
||||
- Modular physics list built via builders provided in Geant4
|
||||
|
||||
ExampleB4
|
||||
- Simplified calorimeter with layers of two materials
|
||||
- Geometry with replica (G4PVReplica)
|
||||
- Scoring within layers in four ways: via user actions (a), via user own
|
||||
object (b), via G4 sensitive detector and hits (c) and via scorers (d)
|
||||
- Geant4 physics list (FTFP_BERT)
|
||||
- Histograms (1D) and ntuple saved in the output file
|
||||
- Started from novice/N03 example
|
||||
|
||||
ExampleB5
|
||||
- A double-arm spectrometer with wire chambers, hodoscopes and calorimeters
|
||||
with a local constant magnetic field
|
||||
- Geometry with placements with rotation, replicas and parameterisation
|
||||
- Scoring within wire chambers, hodoscopes and calorimeters via
|
||||
G4 sensitive detector and hits
|
||||
- Geant4 physics list (FTFP_BERT) with step limiter
|
||||
- UI commans defined using G4GenericMessenger
|
||||
- Histograms (1D, 2D) and ntuple saved in two output files
|
||||
- Plotting of histograms with visualization drivers
|
||||
- Started from extended/analysis/A01
|
||||
Reference in New Issue
Block a user