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/extended/parallel/TopC/ParN02/.README.N02.txt
+124
View File
@@ -0,0 +1,124 @@
///\file "parallel/TopC/ParN02/.README.N02.txt"
///\brief Example N02 (in ParN02) README page
/*! \page ExampleN02InParN02 Example N02 in ParN02
This example simulates a simplified fixe target experiment.
Read \link ExampleParN02 Example ParN02 \endlink for a description
of how to run it in parallel.
\section ExampleN02InParN02_s1 GEOMETRY DEFINITION
The setup consists of a target followed by six chambers of increasing
transverse size. These chambers are located in a region called Tracker
region. Their shape are boxes, constructed as parametrised volumes
(ChamberParametrisation class).
The default geometry is constructed in DetectorConstruction class.
One can change the material of the target and of the chambers
interactively via the commands defined in the DetectorMessenger class.
In addition a transverse uniform magnetic field can be applied (see
N02MagneticField and DetectorMessenger classes).
\section ExampleN02InParN02_s2 PHYSICS LIST
The particle's type and the physic processes which will be available
in this example are set in PhysicsList class.
In this example, all the so called 'electromagnetic processes' are
introduced for gamma, charged leptons, and charged hadrons (see the
method PhysicsList::ConstructEM()).
An important data member of this class is the defaultCutValue which
defines the production threshold of secondary particles
(mainly Ionisation and Bremsstrahlung processes are concerned by this
CutValue).
Notice that the CutValue must be given in unit of length, corresponding
to the stopping range of the particle. It is automatically converted
in energy for each material, and a table is printed in the method
PhysicsList::SetCuts()
In addition the build-in interactive command:
\verbatim
/process/(in)activate processName
\endverbatim
allows to activate/inactivate the processes one by one.
\section ExampleN02InParN02_s3 RUNS and EVENTS
The primary kinematic consists of a single particle which hits the
target perpendicular to the input face. The type of the particle
and its energy are set in the PrimaryGeneratorAction class, and can
be changed via the G4 build-in commands of ParticleGun class.
A RUN is a set of events.
The user has control:
-at Begin and End of each run (class RunAction)
-at Begin and End of each event (class EventAction)
-at Begin and End of each track (class TrackingAction, not used here)
-at End of each step (class SteppingAction)
The class SteppingVerbose prints some informations step per step,
under the control of the command: /tracking/verbose 1
It inherits from G4SteppingVerbose, and has been setup here in order
to illustrate how to extract informations from the G4 kernel during
the tracking of a particle.
\section ExampleN02InParN02_s4 DETECTOR RESPONSE
A HIT is a record, track per track (even step per step), of all the
informations needed to simulate and analyse the detector response.
In this example the Tracker chambers are considered as the detector.
Therefore the chambers are declared 'sensitive detectors' (SD) in
the DetectorConstruction 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,
- the position of the deposit.
A given hit is an instance of the class TrackerHit which is created
during the tracking of a particle, step by step, in the method
TrackerSD::ProcessHits(). This hit is inserted in a HitsCollection.
The HitsCollection is printed at the end of event (via the method
TrackerSD::EndOfEvent()), under the control of the command: /hits/verbose 1
\section ExampleN02InParN02_s5 VISUALIZATION
The Visualization Manager is set in the main () (see exampleN02.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 when running in interactive mode.
The tracks are automatically drawn at the end of event and erased at
the beginning of the next run.
The visualization (with OpenGL driver) assumes two things:
1- the visualisation & interfaces categories have been compiled
with the environment variable G4VIS_BUILD_OPENGLX_DRIVER.
2- ParN02.cc has been compiled with G4VIS_USE_OPENGLX.
(The same with DAWNFILE instead of OPENGLX)
\section ExampleN02InParN02_s6 USER INTERFACES
The default command interface, called G4UIterminal, is done via
standart cin/G4cout.
On Linux and Sun-cc on can use a smarter command interface G4UItcsh.
It is enough to set the environment variable G4UI_USE_TCSH before
compiling ParN02.cc
*/
examples/extended/parallel/TopC/ParN02/.README.txt
+199
View File
@@ -0,0 +1,199 @@
///\file "parallel/TopC/ParN02/.README.txt"
///\brief Example ParN02 README page
/*! \page ExampleParN02 Example ParN02
ParGeant4: Geant4/TOP-C, a parallelization of Geant4
(event-level parallelism)
\author Gene Cooperman,
Northeastern University,
gene@ccs.neu.edu
For the latest information on ParGeant4, see: \n
http://www.ccs.neu.edu/home/gene/pargeant4.html
Note that a version now exists that runs Geant4 over the Grid.
Please write to gene@ccs.neu.edu for further information.
To port other applications to a parallel version, read the
files ../../info/PAR_INSTALL and ../../info/PAR_README.
<hr>
See the beginning of GNUmakefile for reasonable `make' targets to run it.
To run it: \n
-#
- a. Follow the standard Geant4 installation procedure.
- b. Download and install TOP-C. \n
The TOP-C home page is at http://www.ccs.neu.edu/home/gene/topc.html
\verbatim
cd <TOPC_INSTALL_DIR>
gzip -dc topc.tar.gz | tar -xvf -
cd topc
./configure
make
make check
[ Copy bin/topc-config to your path ]
\endverbatim
- c. Verify that the Geant4 example installs:
\verbatim
cd $G4INSTALL/examples/extended/parallel/ParN02
make
$G4WORKDIR/bin/$G4SYSTEM/ParN02 ParN02.in
\endverbatim
\n
-#
\verbatim
make run
\endverbatim
[ By default, the included `procgroup' file creates two slave processes
on localhost. ] \n
[ Note that in addition to output on master,
$G4WORKDIR/bin/$G4SYSTEM/slave*.out contains slave output. ]\n
[ To remove intermediate files and start over: make parclean ]
\n
-#
\n
Try running it with slave processes on remote processes.
First, test that your local environment is set up correctly.
Try:
\verbatim
ssh <REMOTE_HOSTNAME> $G4WORKDIR/bin/$G4SYSTEM/ParN02 `pwd`/ParN02.in
\endverbatim
The above command needs to work without asking for a password.
[ If you use dynamic libraries (*.so), make sure the LD_LIBRARY_PATH
in your shell startup file (e.g. ~.tcshrc) includes both:
$G4INSTALL/lib/$G4SYSTEM and $CLHEP_BASE_DIR/lib
If you use AFS, you may need to type 'klog' to renew your AFS token. ]
In `procgroup' file, replace `localhost' by desired remote hosts;
Add additional remote hosts (additional slaves) if you like.
Then:
\verbatim
make run
\endverbatim
<hr>
If you read ParGNUmakefile, you'll find other things that you can
modify.
- For example, all TOP-C additions are in conditionals:
remove -DG4USE_TOPC from ParGNUmakefile and:
\verbatim
make parclean; make run
\endverbatim
in order to re-compile and rerun without TOP-C.
- Define REMOTE_SHELL differently if you don't use `ssh' for a remote shell.
(If undefined, ParGNUmakefile defines it to be `ssh')
- Define MACROFILE diferently to use a different set of input commands.
- Define MEM_MODEL=--seq
to run with TOP-C, but using a single (sequential) process, suitable
for easy debugging (via gdb, for example).
- Try: pushd $G4WORKDIR/bin/$G4SYSTEM/; ./ParN02 --TOPC-help
to see TOP-C run-time options that can be invoked, such as
pushd $G4WORKDIR/bin/$G4SYSTEM/; ./ParN02 --TOPC-num-slaves=5 ParN02.in
- Alternatively, modify TOPC_OPTIONS in ParGNUmakefile for the same effect.
You can also try other targets: make run-debug
This will run it under gdb, so you can single step to see what happens.
make parclean - Start over with clean set of files.
<hr>
New or modified files:
\verbatim
- ParN02.cc - Adds one line: #include "ParN02.icc"
ParExample.icc inserts: #include "topc.h"
and causes main to calls TOPC_init, TOPC_finalize,
and to use: `new ParRunManager' instead of `new G4RunManager'
- GNUmakefile - Adds one line at beginning: include ParGNUmakefile
ParGNUmakefile defines EXTRALIBS and CPPFLAGS so as to
modify behavior of config/binmake.gmk
in order to use TOP-C libraries and includes
- procgroup - Specifies which slave hosts to use, and where to put output
For example: localhost 1 - > slave1.out
host=`localhost', executable=`same as master',
params of slave=`> slave1.out' (redirect output)
If output not redirected, it goes to stdout on master.
- src/ParRunManager.cc - ParRunManger derived from G4RunManager
replaces Gr4RunManager::DoEventLoop w/ TOP-C parallel loop,
Adds certain local vars of DoEventLoop as ParRunManager members
- include/MarshaledObj.h - run-time utilities for marshalling
- include/MarshaledEx*Hit.h - marshals N02 hits (calorimeter hits)
- include/MarshaledG4*.h - marshaling routines for Geant4 data structures
- ~/slave*.out - Contains outputs of slave1, slave2, etc.
Generated each time parallel ParN02 is executed.
These files are specified in the file procgroup.
\endverbatim
This version passes an event number to the slave and lets the
slave generate the event. The slave passes back marshaled hits to
the master.
I will integrate the track level parallelism into this scenario at
a later date. For the track level, I will generate several
secondary tracks on the master, and then convert the secondary tracks
to new events that can be passed to slaves. I will do this only if
I detect that there are not enough initial events to fully occupy all
the slaves. This scheme has the drawback that we are splitting an event
into many events, which may make the summarization, histogram, and so
on more difficult. However, track level parallelism will be triggered
only when a very small number of events are generated.
I also want to support postponing
a track to the next event ( G4ClassificationOfNewTrack::fPostpone .
To do this, each slave will wait to retire an event until it knows that
the previous event has been retired.
In addition, I plan to have only the master read commands and pass
them to the slaves. Currently, the master and slaves each read
identical commands.
<hr>
If you are curious about some of the layers, the following
stack trace [somewhat out of date now] gives some idea.
- G4RunManager::BeamOn calls ParRunManager::DoEventLoop
(since G4RunManager::DoEventLoop is virtual)
- ParRunManager::DoEventLoop calls TOPC_master_slave
- TOPC_master_slave calls submit_task_input
- submit_task_input eventually calls COMM_send_msg which calls MPI_Send
(COMM_send_msg is the communication layer of TOPC;
ParN02.cc was linked with the TOP-C MPI communication layer.
The same source could have been linked with a POSIX threads layer,
a communication layer, or some other communication layer.
)
- MPI_send calls send
(where send is the socket system call of libc.so)
<pre>
(gdb) where
#0 0x41946c62 in send () from /lib/libc.so.6
#1 0x400839c1 in send () at wrapsyscall.c:186
#2 0x805c547 in MPI_Send (buf=0x82690fc, count=4, datatype=3, dest=2, tag=1, comm=0) at sendrecv.c:236
#3 0x805a0b5 in COMM_send_msg (msg=0x82690fc, msg_size=4, dst=2, tag=TASK_INPUT_TAG) at comm-mpi.c:224
#4 0x805774e in send_task_input (slave=2, input={data = 0x82690fc, data_size = 4}, tag=TASK_INPUT_TAG) at topc.c:560
#5 0x8057aa8 in submit_task_input (input={data = 0x82690fc, data_size = 4}) at topc.c:659
#6 0x805813c in TOPC_master_slave (generate_task_input_=0x4003d2e4 <ParRunManager::GenerateEventInput(void)>,
do_task_=0x4003d350 <ParRunManager::DoEvent(int *)>, check_task_result_=0x4003d420 <ParRunManager::CheckEventResult(int *, void *)>,
update_shared_data_=0) at topc.c:922
#7 0x4003d18c in ParRunManager::DoEventLoop (this=0x80c0bf0, n_event=1, macroFile=0x0, n_select=-1) at src/ParRunManager.cc:51
#8 0x400b14d1 in G4RunManager::BeamOn () from /afs/cern.ch/user/c/cooperma/scratch-pcitapi07/geant4/lib/libG4run.so
#9 0x400b870a in G4RunMessenger::SetNewValue () from /afs/cern.ch/user/c/cooperma/scratch-pcitapi07/geant4/lib/libG4run.so
#10 0x4167157b in G4UIcommand::DoIt () from /afs/cern.ch/user/c/cooperma/scratch-pcitapi07/geant4/lib/libG4intercoms.so
#11 0x416810a3 in G4UImanager::ApplyCommand () from /afs/cern.ch/user/c/cooperma/scratch-pcitapi07/geant4/lib/libG4intercoms.so
#12 0x805db7e in G4UIterminal::ExecuteCommand () at /afs/cern.ch/sw/lhcxx/specific/redhat61/3.2.0/include/CLHEP/Random/Randomize.h:64
#13 0x805d42d in G4UIterminal::SessionStart () at /afs/cern.ch/sw/lhcxx/specific/redhat61/3.2.0/include/CLHEP/Random/Randomize.h:64
#14 0x8056a3d in main (argc=1, argv=0x80bfa00) at ParN02.cc:98
</pre>
*/
examples/extended/parallel/TopC/ParN02/AnnotatedFiles/000README
+47
View File
@@ -0,0 +1,47 @@
The files in this directory are the files that were used to build
../include/Marshaled*.hh . The files ../include/Marshaled*.hh contain
marshaling (serialization) routines that are used by Parallel Geantr4.
Marshalgen is a package that allows one to add a small number of annotations
to the original sequential code, in order to create marshalling or
serialization routines. Those marshalling routines are then used
by ParGeant4 to pass data between slave processes and the master process.
INPUT FILES:
1. G4*.hh : The files *.hh are taken from Geant4. They include annotations
(comments) that describe how to marshal individual fields of the
given classes. These files have additional annotations that describe
how to marshal individual fields of the given classes. For a new
application, you have to change any references to Ex* to your
own example/application include files. These files are then reused
in the new Geant4 parallel application.
2. ../include/Ex*Hit.hh : These files are the original sequential Geant4
application files that describe the application-defined hits.
They remain in the application include directory because they may
depend on other files in the include directory.
For most new parallel Geant4 applications, these files are sufficiently
simple, that one needs only to add Marshalgen begin and end comments
bracketing the class that needs to be marshalled, and a small number
of annotations specifying accessor functions to get and set fields
in the class. It may also be necessary to include marshalling
include files, if it is necessary to marshal other Geant4 data
structures.
Information on how to marshal the fields, etc., is in the Marshalgen
manual, along with the Marshalgen package:
http://www.ccs.neu.edu/home/gene/marshalgen
Marshalgen was then called on the above input files. One calls:
./marshalgen *.hh
./marshalgen ../include/Ex*Hit.hh
OUTPUT FILES:
3. *.msh : These files are intermediate files generated automatically
by marshalgen ( http://www.ccs.neu.edu/home/gene/marshalgen )
These files can be deleted if desired.
4. Marshaled*.h : These files are generated by Marshalgen. They
include of type both MarshaledEx*.h and MarshaledG4*.h .
(In addition, the file MarshaledObj.h is copied directly from
the Marshalgen distribution.) These files are all copied to
the include directory of the Geant4 parallel application.
They provide the marshalling functions that are then used by Geant4.
examples/extended/parallel/TopC/ParN02/README
+155
View File
@@ -0,0 +1,155 @@
ParGeant4: Geant4/TOP-C, a parallelization of Geant4
(event-level parallelism)
Gene Cooperman
Northeastern University
gene@ccs.neu.edu,
For the latest information on ParGeant4, see:
http://www.ccs.neu.edu/home/gene/pargeant4.html
Note that a version now exists that runs Geant4 over the Grid.
Please write to gene@ccs.neu.edu for further information.
To port other applications to a parallel version, read the
files ../../info/PAR_INSTALL and ../../info/PAR_README.
See the beginning of GNUmakefile for reasonable `make' targets to run it.
To run it:
0. a. Follow the standard Geant4 installation procedure.
b. Download and install TOP-C
The TOP-C home page is at http://www.ccs.neu.edu/home/gene/topc.html
cd <TOPC_INSTALL_DIR>
gzip -dc topc.tar.gz | tar -xvf -
cd topc
./configure
make
make check
[ Copy bin/topc-config to your path ]
c. Verify that the Geant4 example installs:
cd $G4INSTALL/examples/extended/parallel/ParN02
make
$G4WORKDIR/bin/$G4SYSTEM/ParN02 ParN02.in
2. make run
[ By default, the included `procgroup' file creates two slave processes
on localhost. ]
[ Note that in addition to output on master,
$G4WORKDIR/bin/$G4SYSTEM/slave*.out contains slave output. ]
[ To remove intermediate files and start over: make parclean ]
3. Try running it with slave processes on remote processes.
First, test that your local environment is set up correctly.
Try:
ssh <REMOTE_HOSTNAME> $G4WORKDIR/bin/$G4SYSTEM/ParN02 `pwd`/ParN02.in
The above command needs to work without asking for a password.
[ If you use dynamic libraries (*.so), make sure the LD_LIBRARY_PATH
in your shell startup file (e.g. ~.tcshrc) includes both:
$G4INSTALL/lib/$G4SYSTEM and $CLHEP_BASE_DIR/lib
If you use AFS, you may need to type 'klog' to renew your AFS token. ]
In `procgroup' file, replace `localhost' by desired remote hosts;
Add additional remote hosts (additional slaves) if you like.
Then: make run
============================================================================
If you read ParGNUmakefile, you'll find other things that you can
modify. For example, all TOP-C additions are in conditionals:
remove -DG4USE_TOPC from ParGNUmakefile and:
make parclean; make run
in order to re-compile and rerun without TOP-C.
Define REMOTE_SHELL differently if you don't use `ssh' for a remote shell.
(If undefined, ParGNUmakefile defines it to be `ssh')
Define MACROFILE diferently to use a different set of input commands.
Define MEM_MODEL=--seq
to run with TOP-C, but using a single (sequential) process, suitable
for easy debugging (via gdb, for example).
Try: pushd $G4WORKDIR/bin/$G4SYSTEM/; ./ParN02 --TOPC-help
to see TOP-C run-time options that can be invoked, such as
pushd $G4WORKDIR/bin/$G4SYSTEM/; ./ParN02 --TOPC-num-slaves=5 ParN02.in
Alternatively, modify TOPC_OPTIONS in ParGNUmakefile for the same effect.
You can also try other targets: make run-debug
This will run it under gdb, so you can single step to see what happens.
make parclean - Start over with clean set of files.
============================================================================
New or modified files:
ParN02.cc - Adds one line: #include "ParN02.icc"
ParExample.icc inserts: #include "topc.h"
and causes main to calls TOPC_init, TOPC_finalize,
and to use: `new ParRunManager' instead of `new G4RunManager'
GNUmakefile - Adds one line at beginning: include ParGNUmakefile
ParGNUmakefile defines EXTRALIBS and CPPFLAGS so as to
modify behavior of config/binmake.gmk
in order to use TOP-C libraries and includes
procgroup - Specifies which slave hosts to use, and where to put output
For example: localhost 1 - > slave1.out
host=`localhost', executable=`same as master',
params of slave=`> slave1.out' (redirect output)
If output not redirected, it goes to stdout on master.
src/ParRunManager.cc - ParRunManger derived from G4RunManager
replaces Gr4RunManager::DoEventLoop w/ TOP-C parallel loop,
Adds certain local vars of DoEventLoop as ParRunManager members
include/MarshaledObj.h - run-time utilities for marshalling
include/MarshaledEx*Hit.h - marshals N02 hits (calorimeter hits)
include/MarshaledG4*.h - marshaling routines for Geant4 data structures
~/slave*.out - Contains outputs of slave1, slave2, etc.
Generated each time parallel ParN02 is executed.
These files are specified in the file procgroup.
====================================================================
This version passes an event number to the slave and lets the
slave generate the event. The slave passes back marshaled hits to
the master.
I will integrate the track level parallelism into this scenario at
a later date. For the track level, I will generate several
secondary tracks on the master, and then convert the secondary tracks
to new events that can be passed to slaves. I will do this only if
I detect that there are not enough initial events to fully occupy all
the slaves. This scheme has the drawback that we are splitting an event
into many events, which may make the summarization, histogram, and so
on more difficult. However, track level parallelism will be triggered
only when a very small number of events are generated.
I also want to support postponing
a track to the next event ( G4ClassificationOfNewTrack::fPostpone .
To do this, each slave will wait to retire an event until it knows that
the previous event has been retired.
In addition, I plan to have only the master read commands and pass
them to the slaves. Currently, the master and slaves each read
identical commands.
====================================================================
If you are curious about some of the layers, the following
stack trace [somewhat out of date now] gives some idea.
G4RunManager::BeamOn calls ParRunManager::DoEventLoop
(since G4RunManager::DoEventLoop is virtual)
ParRunManager::DoEventLoop calls TOPC_master_slave
TOPC_master_slave calls submit_task_input
submit_task_input eventually calls COMM_send_msg which calls MPI_Send
(COMM_send_msg is the communication layer of TOPC;
ParN02.cc was linked with the TOP-C MPI communication layer.
The same source could have been linked with a POSIX threads layer,
a communication layer, or some other communication layer.
)
MPI_send calls send
(where send is the socket system call of libc.so)
(gdb) where
#0 0x41946c62 in send () from /lib/libc.so.6
#1 0x400839c1 in send () at wrapsyscall.c:186
#2 0x805c547 in MPI_Send (buf=0x82690fc, count=4, datatype=3, dest=2, tag=1, comm=0) at sendrecv.c:236
#3 0x805a0b5 in COMM_send_msg (msg=0x82690fc, msg_size=4, dst=2, tag=TASK_INPUT_TAG) at comm-mpi.c:224
#4 0x805774e in send_task_input (slave=2, input={data = 0x82690fc, data_size = 4}, tag=TASK_INPUT_TAG) at topc.c:560
#5 0x8057aa8 in submit_task_input (input={data = 0x82690fc, data_size = 4}) at topc.c:659
#6 0x805813c in TOPC_master_slave (generate_task_input_=0x4003d2e4 <ParRunManager::GenerateEventInput(void)>,
do_task_=0x4003d350 <ParRunManager::DoEvent(int *)>, check_task_result_=0x4003d420 <ParRunManager::CheckEventResult(int *, void *)>,
update_shared_data_=0) at topc.c:922
#7 0x4003d18c in ParRunManager::DoEventLoop (this=0x80c0bf0, n_event=1, macroFile=0x0, n_select=-1) at src/ParRunManager.cc:51
#8 0x400b14d1 in G4RunManager::BeamOn () from /afs/cern.ch/user/c/cooperma/scratch-pcitapi07/geant4/lib/libG4run.so
#9 0x400b870a in G4RunMessenger::SetNewValue () from /afs/cern.ch/user/c/cooperma/scratch-pcitapi07/geant4/lib/libG4run.so
#10 0x4167157b in G4UIcommand::DoIt () from /afs/cern.ch/user/c/cooperma/scratch-pcitapi07/geant4/lib/libG4intercoms.so
#11 0x416810a3 in G4UImanager::ApplyCommand () from /afs/cern.ch/user/c/cooperma/scratch-pcitapi07/geant4/lib/libG4intercoms.so
#12 0x805db7e in G4UIterminal::ExecuteCommand () at /afs/cern.ch/sw/lhcxx/specific/redhat61/3.2.0/include/CLHEP/Random/Randomize.h:64
#13 0x805d42d in G4UIterminal::SessionStart () at /afs/cern.ch/sw/lhcxx/specific/redhat61/3.2.0/include/CLHEP/Random/Randomize.h:64
#14 0x8056a3d in main (argc=1, argv=0x80bfa00) at ParN02.cc:98
examples/extended/parallel/TopC/ParN02/README.N02
+123
View File
@@ -0,0 +1,123 @@
-------------------------------------------------------------------
=========================================================
Geant4 - an Object-Oriented Toolkit for Simulation in HEP
=========================================================
ParN02
------
This example simulates a simplified fixe target experiment.
Read README for a description of how to run it in parallel.
1- GEOMETRY DEFINITION
The setup consists of a target followed by six chambers of increasing
transverse size. These chambers are located in a region called Tracker
region. Their shape are boxes, constructed as parametrised volumes
(ChamberParametrisation class).
The default geometry is constructed in DetectorConstruction class.
One can change the material of the target and of the chambers
interactively via the commands defined in the DetectorMessenger class.
In addition a transverse uniform magnetic field can be applied (see
N02MagneticField and DetectorMessenger classes).
2- PHYSICS LIST
The particle's type and the physic processes which will be available
in this example are set in PhysicsList class.
In this example, all the so called 'electromagnetic processes' are
introduced for gamma, charged leptons, and charged hadrons (see the
method PhysicsList::ConstructEM()).
An important data member of this class is the defaultCutValue which
defines the production threshold of secondary particles
(mainly Ionisation and Bremsstrahlung processes are concerned by this
CutValue).
Notice that the CutValue must be given in unit of length, corresponding
to the stopping range of the particle. It is automatically converted
in energy for each material, and a table is printed in the method
PhysicsList::SetCuts()
In addition the build-in interactive command:
/process/(in)activate processName
allows to activate/inactivate the processes one by one.
3- RUNS and EVENTS
The primary kinematic consists of a single particle which hits the
target perpendicular to the input face. The type of the particle
and its energy are set in the PrimaryGeneratorAction class, and can
be changed via the G4 build-in commands of ParticleGun class.
A RUN is a set of events.
The user has control:
-at Begin and End of each run (class RunAction)
-at Begin and End of each event (class EventAction)
-at Begin and End of each track (class TrackingAction, not used here)
-at End of each step (class SteppingAction)
The class SteppingVerbose prints some informations step per step,
under the control of the command: /tracking/verbose 1
It inherits from G4SteppingVerbose, and has been setup here in order
to illustrate how to extract informations from the G4 kernel during
the tracking of a particle.
4- DETECTOR RESPONSE
A HIT is a record, track per track (even step per step), of all the
informations needed to simulate and analyse the detector response.
In this example the Tracker chambers are considered as the detector.
Therefore the chambers are declared 'sensitive detectors' (SD) in
the DetectorConstruction 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,
- the position of the deposit.
A given hit is an instance of the class TrackerHit which is created
during the tracking of a particle, step by step, in the method
TrackerSD::ProcessHits(). This hit is inserted in a HitsCollection.
The HitsCollection is printed at the end of event (via the method
TrackerSD::EndOfEvent()), under the control of the command: /hits/verbose 1
5- VISUALIZATION
The Visualization Manager is set in the main().
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 when running in interactive mode.
The tracks are automatically drawn at the end of event and erased at
the beginning of the next run.
The visualization (with OpenGL driver) assumes two things:
1- the visualisation & interfaces categories have been compiled
with the environment variable G4VIS_BUILD_OPENGLX_DRIVER.
2- ParN02.cc has been compiled with G4VIS_USE_OPENGLX.
(The same with DAWNFILE instead of OPENGLX)
6- USER INTERFACES
The default command interface, called G4UIterminal, is done via
standart cin/G4cout.
On Linux and Sun-cc on can use a smarter command interface G4UItcsh.
It is enough to set the environment variable G4UI_USE_TCSH before
compiling ParN02.cc