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/eventgenerator/HepMC/.README.txt
+120
View File
@@ -0,0 +1,120 @@
///\file "eventgenerator/HepMC/.README.txt"
///\brief Examples HepMC README page
/*! \page Examples_HepMC Category "eventgenerator/HepMC"
This directory contains examples for using HepMC as an interface with
various Monte Carlo event generators, such as PYTHIA.
It also include an example for demonstrating MC truth handling with HepMC.
\section HepMC_s1 Requirements for external software packages
\subsection HepMC_sub_s11 HepMC
- Tested version : 2.06.09
- http://lcgapp.cern.ch/project/simu/HepMC/
Note: examples were tested only on Linux with gcc.
\subsection HepMC_sub_s12 PYTHIA
- Tested version 6.4.26
- URL: http://www.thep.lu.se/~torbjorn/Pythia.html
\section HepMC_s2 Examples HepMCEx01 and HepMCEx02
\subsection HepMC_sub_s21 class HepMCG4Interface
This class is derived from G4VPrimaryGenerator, and is a base class
for primary generation via HepMC object.
protected members:
- virtual HepMC::GenEvent* GenerateHepMCEvent() \n
Implement this method in his/her own concrete class.
An empty event will be created in default.
- void HepMC2G4(const HepMC::GenEvent* hepmcevt, G4Event* g4event) \n
service method for conversion from HepMC::GenEvent to G4Event
- virtual G4bool CheckVertexInsideWorld(const G4ThreeVector& pos) const \n
We have to take care for the position of primaries because
primary vertices outside the world volume give rise to G4Exception.
If the default implementation is not adequate, an alternative
can be implemented in your own class.
public members:
- virtual void GeneratePrimaryVertex(G4Event* anEvent) \n
The default behavior is that a single HepMC event generated by
GenerateHepMCEvent() will be converted to G4Event through HepMC2G4().
\subsection HepMC_sub_s22 class HepMCG4AsciiReader / HepMCG4AsciiReaderMessenger (derived from HepMCG4Interface)
This derived class is for reading primary information from
an Ascii file generated by HepMC.
\subsection HepMC_sub_s23 class HepMCG4PythiaInterface / HepMCG4AsciiReaderMessenger (derived from HepMCG4Interface)
This derived class is for directly calling PYTHIA functions.
Users can set parameters, initialize, generate, and terminate
by command line operation.
\subsection HepMC_sub_s24 Macros in examples
- hepmc_pygen.in \n
process PYTHIA events(H->4mu) generated at every event.
- hepmc_ascii.in \n
read pregenerated events from HepMC Ascii file (data/example_MyPythia.dat).
\subsection HepMC_sub_s25 Installation
- 1. Download and install HepMC from: \n
http://lcgapp.cern.ch/project/simu/HepMC/ \n
and define the environment variable:
\verbatim
HEPMC_DIR the path to HepMC installation.
\endverbatim
- 2. Download the PYTHIA6 source file from the PYTHIA6 download site:\n
http://www.hepforge.org/downloads/pythia6
- 2A. With CMake: Build pythia6 library
For a convenience a CMake file for building Pythia6 library from
the source is provided in
examples/extended/eventgenerator/CMakeLists.txt.pythia6.
Build the pythia6 library following the instructions in this file
and then define the environment variables:
\verbatim
PYTHIA6 the path where pythia6 library is installed
PYTHIA6_VERSION the pythia version
\endverbatim
- 2B. With GNUmake: Define the environment variables: \n
\verbatim
PYTHIA6 the path to pythia-versionX.f source code
PYTHIA6_VERSION the pythia version
\endverbatim
e.g. If you download pythia-6.4.26.f.gz and unzip it in $HOME,
then you have to set:
export PYTHIA6=$HOME
export PYTHIA6_VERSION="6.4.26"
pythia6 will be then compiled together with example code.
- 3. Compilation:\n
Then the examples are compiled in a standard way, see \ref README_HowToRun.
\subsection HepMC_sub_s26 Examples
See more details in \ref ExampleHepMCEx01 and \ref ExampleHepMCEx02.
\subsection HepMC_sub_s27 Notes
We attached a sample HepMC Ascii data file, "data/example_MyPythia.dat",
which contains 10 PYTHIA events created by "data/example_MyPythia.cxx".
\section HepMC_s3 Example MCTruth
Application \link ExampleMCTruth MCTruth \endlink demonstrating handling of Monte-Carlo truth information through the HepMC package.
*/
examples/extended/eventgenerator/HepMC/HepMCEx01/.README.txt
+56
View File
@@ -0,0 +1,56 @@
///\file "eventgenerator/HepMC/HepMCEx01/.README.txt"
///\brief Example HepMCEx01 README page
/*! \page ExampleHepMCEx01 Example HepMCEx01
HepMCEx01 is based on Example N04, which has a simplified collider detector
geometry. Only part of the primary generator action is replaced with new one.
This example demonstrates the following features.
\section ExampleHepMCEx01_s1 HepMC interface
ExN04PrimaryGeneratorAction has HepMCG4Interface as the generator.
There are two types of generators provided as samples. One generator reads
primary information from a HepMC Ascii file (data/example_MyPythia.dat).
The other one generates primaries directly invoking PYTHIA routines
in every event.
\section ExampleHepMCEx01_s2 Readout geometry
ExN04DetectorConstruction defines a simplified collider detecor
geometry, tracker made of cylindrical tubes, calorimeter made of
cylindrical tubes, and muon trackers made of planes.
Cylindrical calorimeter is made of tubes of lead and scintirator
without cut in phi nor z direction. Energy deposition in scintirator
is accumulated by ExN04CalorimeterSD sensitive detector, which has
a readout geometry to find the phi-z cell.
\section ExampleHepMCEx01_s3 Full set of "ordinary" physics processes
FTFP_BERT physics list defines almost all of leptons and hadrons which
Geant4 has dedicated classes for. Also almost all physics processes
Geant4 has are defined.
\section ExampleHepMCEx01_s4 Event filtering by the stacking mechanism.
Higgs events in "pythia_event.data" have two lepton pairs produced
by the Higgs decay via Z0. At the first stage of each event, only the
primary muons are tracked without tracking secondaries. then the number
of hits on the muon trackers are examined. At the next stage, only
the primary charged particles are tracked only inside the barrel
tracking area and the isolation of the primary muons are examined.
At the third stage, all particles in the RoI (Region of Interest) along
the isolated muons are tracked. All these examinations are applied in
ExN04StackingAction.
\section ExampleHepMCEx01_s5 Installation
See \ref Examples_HepMC how to build this example.
\section ExampleHepMCEx01_s6 Execution
\verbatim
% HepMCEx01 hepmc_pygen.in
\endverbatim
*/
examples/extended/eventgenerator/HepMC/HepMCEx01/README
+57
View File
@@ -0,0 +1,57 @@
-------------------------------------------------------------------
=========================================================
Geant4 - an Object-Oriented Toolkit for Simulation in HEP
=========================================================
HepMCEx01
---------
HepMCEx01 is based on ExampleN04, which has a simplified collider detector
geometry. Only part of the primary generator action is replaced with new one.
This example demonstrates the following features.
1. HepMC interface
ExN04PrimaryGeneratorAction has HepMCG4Interface as the generator.
There are two types of generators provided as samples. One generator reads
primary information from a HepMC Ascii file (data/example_MyPythia.dat).
The other one generates primaries directly invoking PYTHIA routines
in every event.
2. Readout geometry
ExN04DetectorConstruction defines a simplified collider detecor
geometry, tracker made of cylindrical tubes, calorimeter made of
cylindrical tubes, and muon trackers made of planes.
Cylindrical calorimeter is made of tubes of lead and scintirator
without cut in phi nor z direction. Energy deposition in scintirator
is accumulated by ExN04CalorimeterSD sensitive detector, which has
a readout geometry to find the phi-z cell.
3. Full set of "ordinary" physics processes
FTFP_BERT physics list defines almost all of leptons and hadrons which
Geant4 has dedicated classes for. Also almost all physics processes
Geant4 has are defined.
4. Event filtering by the stacking mechanism.
Higgs events in "pythia_event.data" have two lepton pairs produced
by the Higgs decay via Z0. At the first stage of each event, only the
primary muons are tracked without tracking secondaries. then the number
of hits on the muon trackers are examined. At the next stage, only
the primary charged particles are tracked only inside the barrel
tracking area and the isolation of the primary muons are examined.
At the third stage, all particles in the RoI (Region of Interest) along
the isolated muons are tracked. All these examinations are applied in
ExN04StackingAction.
5. Installation
See HepMC/README how to build this example.
6. Execution
% HepMCEx01 hepmc_pygen.in
examples/extended/eventgenerator/HepMC/HepMCEx02/.README.txt
+47
View File
@@ -0,0 +1,47 @@
///\file "eventgenerator/HepMC/HepMCEx02/.README.txt"
///\brief Example HepMCEx02 README page
/*! \page ExampleHepMCEx02 Example HepMCEx02
This example demonstrates how to interface primary particles in Geant4
with various event generators via the HepMC Monte Carlo event interface.
This is another example having the same generator action as HepMCEx01,
but much simpler user control.
\section ExampleHepMCEx02_s1 Primary Generator
H02PrimaryGeneratorAction has HepMCG4Interface as the generator.
There are two types of generators provided as samples. One generator reads
primary information from a HepMC Ascii file (data/example_MyPythia.dat).
The other one generates primaries directly invoking PYTHIA routines
in every event.
\section ExampleHepMCEx02_s2 Geometry
A simplified collider-type geometry, which consists of
- endcap calorimeter (a set of tubes filled with lead),
- barrel calorimeter (tube filled with lead),
- barrel muon detector (8 sets of plates filled with Ar),
- endcap muon detecror, (a set of tubes filled with Ar) and
- uniform magnetic field along the z axis of 3 Tesla at the
central region.
\section ExampleHepMCEx02_s3 Physics List
FTFP_BERT predefined physics list
\section ExampleHepMCEx02_s4 User actions
All particles except muons are killed in the calorimeter section.
\section ExampleHepMCEx02_s5 Installation
See \ref Examples_HepMC how to build this example.
\section ExampleHepMCEx02_s6 Execution
\verbatim
% HepMCEx02 hepmc_pygen.in
\endverbatim
*/
examples/extended/eventgenerator/HepMC/HepMCEx02/README
+48
View File
@@ -0,0 +1,48 @@
-------------------------------------------------------------------
=========================================================
Geant4 - an Object-Oriented Toolkit for Simulation in HEP
=========================================================
HepMCEx02
---------
This example demonstrates how to interface primary particles in Geant4
with various event generators via the HepMC Monte Carlo event interface.
This is another example having the same generator action as HepMCEx01,
but much simpler user control.
1. Primary Generator
H02PrimaryGeneratorAction has HepMCG4Interface as the generator.
There are two types of generators provided as samples. One generator reads
primary information from a HepMC Ascii file (data/example_MyPythia.dat).
The other one generates primaries directly invoking PYTHIA routines
in every event.
2. Geometry
A simplified collider-type geometry, which consists of
- endcap calorimeter (a set of tubes filled with lead),
- barrel calorimeter (tube filled with lead),
- barrel muon detector (8 sets of plates filled with Ar),
- endcap muon detecror, (a set of tubes filled with Ar) and
- uniform magnetic field along the z axis of 3 Tesla at the
central region.
3. Physics List
FTFP_BERT predefined physics list
4. User actions
All particles except muons are killed in the calorimeter section.
5. Installation
See HepMC/README how to build this example.
6. Execution
% HepMCEx02 hepmc_pygen.in
examples/extended/eventgenerator/HepMC/MCTruth/.README.txt
+168
View File
@@ -0,0 +1,168 @@
///\file "eventgenerator/HepMC/MCTruth/.README.txt"
///\brief Example MCTruth README page
/*! \page ExampleMCTruth Example MCTruth
MCTRUTH using HepMC
This example demonstrates a mechanism for Monte Carlo truth handling
using HepMC as the event record. The user does not interact directly
with the HepMC classes but with the MCTruthManager class which takes
care with storing all the necessary information about particles,
vertices and relations between them. A specialized tracking action is
used to test whether given particle is to be stored or not. The
decision criteria for storing particle are configurable via the
MCTruthConfig class.
\section ExampleMCTruth_s1 HOW TO BUILD THE EXAMPLE ?
- if you do not have it yet, install HepMC event record (tested with version 2.06.08)
- set HEPMC_ROOT_DIR variable to point to the directory where HepMC is installed;
if the HepMC is installed in your system directory (/usr/local) you do not need to set anything
- run the CMake configuration and build mctruthex target in your build directory
- execute the application:
\verbatim
% your_binary_directory/mctruthex
\endverbatim
\section ExampleMCTruth_s2 DESCRIPTION OF THE MCTRUTH HANDLING MECHANISM
The main element of the MC truth handling machinery is the
MCTruthManager class. This class is responsible for all the
interaction with the HepMC event and does not depend on Geant4. It is
a singleton, therefore it is guaranteed to be instanciated only once
and the static 'GetInstance' method allows to access it from anywhere
in the code. It contains methods like MCTruthManager::NewEvent() to start a new event,
MCTruthManager::AddParticle() to add particle to the current event, as well as
MCTruthManager::PrintEvent() for the purpose of the debugging. The core of the
algorithm which deals with building up the MC truth event tree within
the HepMC event is implemented in MCTruthManager::AddParticle() method.
The MCTruthManager::AddParticle() method is called with the following arguments:
four-momentum, production position and 'end' position of the particle,
PDG code of the particle, as well as the particle ID (unique identifier,
as we will see later, corresponding to Geant4 TrackID) and the ID of
the mother. Finally, there is a boolean flag specifying whether the
direct mother of the given particle has been stored, or not.
The first step, which always takes place, is to instanciate a new
HepMC::GenParticle with the barcode corresponding to particle ID, as
well as to instanciate a new HepMC::GenVertex which will represent the
'end' vertex of the particle. The barcode of the 'end vertex' is equal
to minus the barcode of the particle.
We can now distinguish several cases:
- 1) the particle is a primary in the Geant4 language, i.e. its
mother ID is 0
\n\n
This is the simplest case, we just instanciate a new 'primary'
(without any incoming particles) GenVertex, we add to it the
particle and we put it all in the event. Additionally we store the
ID of the particle in a special vector, where all the IDs of
primary particles will be stored, allowing quick access to each of
the main 'branches' of the event. We return from the method.
- 2) the particle is not a primary
\n\n
We use the 'event->barcode_to_particle(motherID)' method to get the
pointer to its mother.
\n\n
We check if the 'end vertex' of the mother corresponds to the
'production vertex' of the particle in question.
\n\n
- 2.1) If the two vertices do match, we attach the new particle to
the 'end vertex' of the mother. We return from the method.
\n\n
- 2.2) If the two vertices do not match, i.e. the new particle is not
a product of the 'end vertex' of the mother particle, we can
have two cases:
\n\n
- 2.2.1) The boolean flag says that the direct mother of the
particle has _not_ been stored. This means that the
particle has been 'adopted' by one of its ancestors, or
in other words, the mother ID of the particle does not
correspond to its direct mother (so clearly the
vertices cannot match). This for instance could happen
if we decided not to store gamma coming from pi0 decay
but did decide to store e+/- coming from the gamma
conversion (so the gamma between pi0 and e+/- was
missing). In such a case we instanciate (or use one of
the existing ones, if vertices match) a 'dummy'
particle (with pdg = -999999) which then acts as the
link between the 'adopted' particle and the
(non-direct) mother. In such a way, the navigability up
in the event is still possible, but in the same time,
we can clearly see that the link is not a direct
one. We return from the method.
\n\n
- 2.2.2) The boolean flag says that direct mother of the
particle _has_ been stored. Taking into account that
the vertices do not match, it can mean only one
thing. The new particle has been produced 'on the
flight', i.e. somewhere 'before' the 'end vertex' of
the mother. This can be the case, for instace, for
delta electrons, bremsstrahlung gammas, etc. In such a
situation, we 'split' the mother particle in two
particles and create a new vertex from which the
secondary will be going out. The complication, however,
arises when we have more than one generated 'on the
flight' particle attached to the same mother. In such a
case, for each secondary we need to locate the right
'segment' of the mother particle (i.e. we need to find
between which two vertices we need to add a new
one). To keep track of those segmentations we introduce
a map where each particle ID we map into the number of
existing segments (in the normal case one). Each new
'segment' gets barcode equal to the barcode of the
original particle + N*10000000, where N is the segment
number. In such a way, one can easily follow the
'segmentation' (if any) of each particle. We return
from the method.
This concludes the description of MCTruthManager. The MCTruthConfig
class is a collection of criteria (minimal energy, PDG, creator
process, etc) that we want to apply when deciding whether to store or
not given particle. These values are used by the
'MCTruthTrackingAction' which we describe below. This class can
certainly be extended with other members.
The actual Geant4-dependent part of the MCTruth handling machinery
consists of a few 'G4 user actions' as well as an implementation of
G4VUserTrackInformation. The later one is, for the moment, used only
to store one boolean flag indicating whether the direct mother of the
given track has been stored or not.
The first user action is MCTruthEventAction which is only reponsible
for calling MCTruthManager::NewEvent() at the beginning
of each event. It can also be used for printing out events for the
purpose of debugging.
The actual 'decision making' concerning which particle to store is
done in MCTruthTrackingAction. At the end of each track the method
trackToBeStored(track) is called to check for various characteristics
of the particle. These, for instance can be energy, particle ID,
creator process, etc.
If the particle satisfies the conditions the
MCTruthManager::AddParticle is called and all the
procedure described above is performed. The important element here is
that the Geant4 TrackID is used as the unique particle ID in
MCTruthManager and eventually as the barcode of the
HepMC::GenParticle.
If the particle does not qualify to be stored, there are two actions
performed. First the 'ParentID' of the _daughters_ is set to the
'ParentID' of the currenly processed particle. In other words, the
'ParentID' of the daughters is set to the ID of the last stored
particle. Second, the 'directParent' flag from MCTruthTrackInformation
of the __daughters__ is set to FALSE. In such a way, one is still able
to navigate up in the event (to get the ancestors of the particle),
but in the same time, the particle is flagged as 'not having direct
parent'.
*/
examples/extended/eventgenerator/HepMC/MCTruth/README
+165
View File
@@ -0,0 +1,165 @@
-------------------------------------------------------------------
=========================================================
Geant4 - an Object-Oriented Toolkit for Simulation in HEP
=========================================================
MCTRUTH using HepMC
-------------------
This example demonstrates a mechanism for Monte Carlo truth handling
using HepMC as the event record. The user does not interact directly
with the HepMC classes but with the MCTruthManager class which takes
care with storing all the necessary information about particles,
vertices and relations between them. A specialized tracking action is
used to test whether given particle is to be stored or not. The
decision criteria for storing particle are configurable via the
MCTruthConfig class.
HOW TO BUILD THE EXAMPLE ?
- if you do not have it yet, install HepMC event record (tested with version 2.06.08)
- set HEPMC_ROOT_DIR variable to point to the directory where HepMC is installed;
if the HepMC is installed in your system directory (/usr/local) you do not need to set anything
- run the CMake configuration and build mctruthex target in your build directory
- execute the application:
% your_binary_directory/mctruthex
DESCRIPTION OF THE MCTRUTH HANDLING MECHANISM
The main element of the MC truth handling machinery is the
MCTruthManager class. This class is responsible for all the
interaction with the HepMC event and does not depend on Geant4. It is
a singleton, therefore it is guaranteed to be instanciated only once
and the static 'GetInstance' method allows to access it from anywhere
in the code. It contains methods like 'NewEvent' to start a new event,
'AddParticle' to add particle to the current event, as well as
'PrintEvent' for the purpose of the debugging. The core of the
algorithm which deals with building up the MC truth event tree within
the HepMC event is implemented in AddParticle method.
The AddParticle method is called with the following arguments:
four-momentum, production position and 'end' position of the particle,
PDG code of the particle, as well as the particle ID (unique identifier,
as we will see later, corresponding to Geant4 TrackID) and the ID of
the mother. Finally, there is a boolean flag specifying whether the
direct mother of the given particle has been stored, or not.
The first step, which always takes place, is to instanciate a new
HepMC::GenParticle with the barcode corresponding to particle ID, as
well as to instanciate a new HepMC::GenVertex which will represent the
'end' vertex of the particle. The barcode of the 'end vertex' is equal
to minus the barcode of the particle.
We can now distinguish several cases:
1) the particle is a primary in the Geant4 language, i.e. its
mother ID is 0
This is the simplest case, we just instanciate a new 'primary'
(without any incoming particles) GenVertex, we add to it the
particle and we put it all in the event. Additionally we store the
ID of the particle in a special vector, where all the IDs of
primary particles will be stored, allowing quick access to each of
the main 'branches' of the event. We return from the method.
2) the particle is not a primary
We use the 'event->barcode_to_particle(motherID)' method to get the
pointer to its mother.
We check if the 'end vertex' of the mother corresponds to the
'production vertex' of the particle in question.
2.1) If the two vertices do match, we attach the new particle to
the 'end vertex' of the mother. We return from the method.
2.2) If the two vertices do not match, i.e. the new particle is not
a product of the 'end vertex' of the mother particle, we can
have two cases:
2.2.1) The boolean flag says that the direct mother of the
particle has _not_ been stored. This means that the
particle has been 'adopted' by one of its ancestors, or
in other words, the mother ID of the particle does not
correspond to its direct mother (so clearly the
vertices cannot match). This for instance could happen
if we decided not to store gamma coming from pi0 decay
but did decide to store e+/- coming from the gamma
conversion (so the gamma between pi0 and e+/- was
missing). In such a case we instanciate (or use one of
the existing ones, if vertices match) a 'dummy'
particle (with pdg = -999999) which then acts as the
link between the 'adopted' particle and the
(non-direct) mother. In such a way, the navigability up
in the event is still possible, but in the same time,
we can clearly see that the link is not a direct
one. We return from the method.
2.2.2) The boolean flag says that direct mother of the
particle _has_ been stored. Taking into account that
the vertices do not match, it can mean only one
thing. The new particle has been produced 'on the
flight', i.e. somewhere 'before' the 'end vertex' of
the mother. This can be the case, for instace, for
delta electrons, bremsstrahlung gammas, etc. In such a
situation, we 'split' the mother particle in two
particles and create a new vertex from which the
secondary will be going out. The complication, however,
arises when we have more than one generated 'on the
flight' particle attached to the same mother. In such a
case, for each secondary we need to locate the right
'segment' of the mother particle (i.e. we need to find
between which two vertices we need to add a new
one). To keep track of those segmentations we introduce
a map where each particle ID we map into the number of
existing segments (in the normal case one). Each new
'segment' gets barcode equal to the barcode of the
original particle + N*10000000, where N is the segment
number. In such a way, one can easily follow the
'segmentation' (if any) of each particle. We return
from the method.
This concludes the description of MCTruthManager. The MCTruthConfig
class is a collection of criteria (minimal energy, PDG, creator
process, etc) that we want to apply when deciding whether to store or
not given particle. These values are used by the
'MCTruthTrackingAction' which we describe below. This class can
certainly be extended with other members.
The actual Geant4-dependent part of the MCTruth handling machinery
consists of a few 'G4 user actions' as well as an implementation of
G4VUserTrackInformation. The later one is, for the moment, used only
to store one boolean flag indicating whether the direct mother of the
given track has been stored or not.
The first user action is MCTruthEventAction which is only reponsible
for calling MCTruthManager::GetInstance()->NewEvent() at the beginning
of each event. It can also be used for printing out events for the
purpose of debugging.
The actual 'decision making' concerning which particle to store is
done in MCTruthTrackingAction. At the end of each track the method
trackToBeStored(track) is called to check for various characteristics
of the particle. These, for instance can be energy, particle ID,
creator process, etc.
If the particle satisfies the conditions the
MCTruthManager::GetInstance()->AddParticle is called and all the
procedure described above is performed. The important element here is
that the Geant4 TrackID is used as the unique particle ID in
MCTruthManager and eventually as the barcode of the
HepMC::GenParticle.
If the particle does not qualify to be stored, there are two actions
performed. First the 'ParentID' of the _daughters_ is set to the
'ParentID' of the currenly processed particle. In other words, the
'ParentID' of the daughters is set to the ID of the last stored
particle. Second, the 'directParent' flag from MCTruthTrackInformation
of the __daughters__ is set to FALSE. In such a way, one is still able
to navigate up in the event (to get the ancestors of the particle),
but in the same time, the particle is flagged as 'not having direct
parent'.
examples/extended/eventgenerator/HepMC/README
+118
View File
@@ -0,0 +1,118 @@
Examples for HepMC-Geant4 interface
-----------------------------------
This directory contains examples for using HepMC as an interface with
various Monte Carlo event generators, such as PYTHIA.
It also include an example for demonstrating MC truth handling with HepMC.
Requirements for external software packages
-------------------------------------------
HepMC:
Tested version : 2.06.09
http://lcgapp.cern.ch/project/simu/HepMC/
Note: examples were tested only on Linux with gcc.
PYTHIA
Tested version 6.4.26
URL: http://www.thep.lu.se/~torbjorn/Pythia.html
Examples HepMCEx01 and HepMCEx02
================================
class HepMCG4Interface
This class is derived from G4VPrimaryGenerator, and is a base class
for primary generation via HepMC object.
protected members
+ virtual HepMC::GenEvent* GenerateHepMCEvent()
Implement this method in his/her own concrete class.
An empty event will be created in default.
+ void HepMC2G4(const HepMC::GenEvent* hepmcevt, G4Event* g4event)
service method for conversion from HepMC::GenEvent to G4Event
+ virtual G4bool CheckVertexInsideWorld(const G4ThreeVector& pos) const
We have to take care for the position of primaries because
primary vertices outside the world volume give rise to G4Exception.
If the default implementation is not adequate, an alternative
can be implemented in your own class.
public members
+ virtual void GeneratePrimaryVertex(G4Event* anEvent)
The default behavior is that a single HepMC event generated by
GenerateHepMCEvent() will be converted to G4Event through HepMC2G4().
class HepMCG4AsciiReader / HepMCG4AsciiReaderMessenger
(derived from HepMCG4Interface)
This derived class is for reading primary information from
an Ascii file generated by HepMC.
class HepMCG4PythiaInterface / HepMCG4AsciiReaderMessenger
(derived from HepMCG4Interface)
This derived class is for directly calling PYTHIA functions.
Users can set parameters, initialize, generate, and terminate
by command line operation.
Macros in examples
-----------------
hepmc_pygen.in
process PYTHIA events(H->4mu) generated at every event.
hepmc_ascii.in
read pregenerated events from HepMC Ascii file (data/example_MyPythia.dat).
Installation
--------------
1. Download and install HepMC from:
http://lcgapp.cern.ch/project/simu/HepMC/
(Last tested version : 2.06.09)
and define the environment variable:
HEPMC_DIR the path to HepMC installation.
2. Download the PYTHIA6 source file from the PYTHIA6 download site:
http://www.hepforge.org/downloads/pythia6
A) With CMake: Build pythia6 library
For a convenience a CMake file for building Pythia6 library from
the source is provided in
examples/extended/eventgenerator/CMakeLists.txt.pythia6.
Build the pythia6 library following the insytructions in this file
and then define the environment variables:
PYTHIA6 the path where pythia6 library is installed
PYTHIA6_VERSION the pythia version
B) With GNUmake: Define the environment variables
PYTHIA6 the path to pythia-versionX.f source code
PYTHIA6_VERSION the pythia version
e.g. If you download pythia-6.4.26.f.gz and unzip it in $HOME,
then you have to set:
export PYTHIA6=$HOME
export PYTHIA6_VERSION="6.4.26"
Pythia6 will be then compiled together with example code.
3. Compilation:
Then the examples are compiled in a standard way,
see examples/README_HowToRun.
Examples
----------
See more details in HepMCEx01/README and HepMCEx02/README.
Notes
-----
We attached a sample HepMC Ascii data file, "data/example_MyPythia.dat",
which contains 10 PYTHIA events created by "data/example_MyPythia.cxx".
Example MCTruth
===============
Application demonstrating handling of Monte-Carlo truth information through
the HepMC package.