lars/geant4
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Import Geant4 11.0.0 source tree

Browse Source
This commit is contained in:
Gabriele Cosmo
2021-12-12 17:16:06 +01:00
parent 80e2389dd8
commit 84f33a068c
593 changed files with 68589 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
examples/basic/B2/.README.txt
+230
View File
@@ -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
*/
examples/basic/B2/README
+205
View File
@@ -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