GAMOS: A framework to do GEANT4 simulations in different physics elds

with an user-friendly interface

Pedro Arce
a,n
, Juan Ignacio Lagares
a
, Laura Harkness
b
, Daniel Prez-Astudillo
a
,
Mario Caadas
a
, Pedro Rato
a
, Mara de Prado
a
, Yamiel Abreu
c
, Gianluca de Lorenzo
d
,
Machiel Kolstein
d
, Angelina Daz
c
a
Centro de Investigaciones Energticas, Medioambientales y Tecnologicas (CIEMAT), Avda. Complutense 22, 28040 Madrid, Spain
b
Department of Physics, The University of Liverpool, Liverpool L69 7ZE, UK
c
Department of Physics, CEADEN, Calle 30 #502 e/ 5ta y 7ma Avenida, Playa, Ciudad Habana, Cuba
d
Institut de Fsica d'Altes Energies (IFAE), Campus UAB, 08193 Bellaterra, Barcelona, Spain
a r t i c l e i n f o
Article history:
Received 24 November 2012
Received in revised form
25 April 2013
Accepted 12 September 2013
Available online 21 September 2013
Keywords:
Monte Carlo methods
Geant4
Scripting
Plug-in technology
a b s t r a c t
GAMOS is a software system for GEANT4-based simulation. It comprises a framework, a set of components
providing functionality to simulation applications on top of the GEANT4 toolkit, and a collection of ready-
made applications. It allows to perform GEANT4-based simulations using a scripting language, without
requiring the writing of C code. Moreover, GAMOS design allows the extension of the existing
functionality through user-supplied C classes. The main characteristics of GAMOS and its embedded
functionality are described.
& 2013 Elsevier B.V. All rights reserved.
1. Introduction
GEANT4 [1,2] is a widely used [3] Monte Carlo (MC) system
implemented in the C programming language for simulating
the passage of particles through matter. As a general purpose system,
it provides a set of generic tools to model experimental set-ups and
to transport particles through them. GEANT4 is extremely versatile, but
such exibility comes with the price of requiring some expertise in
C and object oriented programming.
Several software frameworks have been developed to facilitate
the use of GEANT4 in a specic eld by providing pre-compiled
applications whose functionality are accessible through a scripting
language, which avoids the need to write C code. Among
them, we can cite some in the High Energy Physics eld, like
OSCAR [4,5], ATHENA [6], or GIGA [7], some in the Space Physics
eld, like MULASSIS [8] and GRAS [9] or some in the Medical
Physics eld, like GATE [10], or PTSIM and TOPAS [11].
After almost fteen years of experience using and developing
these kind of applications, we have found several common
problems for their users. One problem appears when the user
wants to describe a type of input that is not included in the
application, e.g. a peculiar volume shape, a novel primary gen-
erator position distribution, or some option in the physics pro-
cesses. Another problem commonly found arises when the user
wants to have a deep understanding of a given aspect of the
simulation, while the application only offers a limited amount of
results, which do not include the needed information. A third
problem is that these applications cover a limited number of
physics elds, which may not correspond to the user's needs.
Though originally meant for simulations in the medical physics
eld [12], the GEANT4 based Architecture for Medicine Oriented
Simulation (GAMOS) has been specically developed to serve the
widest possible range of users by minimizing the deciencies
described above. Three strategies have been adopted to try to
reach this goal.
The rst one is to maximize the range of input and output
options available through the scripting language by trying to cover
most of the possibilities offered by GEANT4.
The second strategy is to provide the users with direct access
through the scripting language to a rich set of predened applica-
tions for eld specic simulations. The current version of GAMOS
presents several applications for PET, SPECT, and Compton camera
simulation, as well as for radiotherapy and shielding studies. New
applications are added by the GAMOS community at each new
release, constantly broadening the available portfolio.
Contents lists available at ScienceDirect
journal homepage: www.elsevier.com/locate/nima
Nuclear Instruments and Methods in
Physics Research A
0168-9002/$ - see front matter & 2013 Elsevier B.V. All rights reserved.
http://dx.doi.org/10.1016/j.nima.2013.09.036
n
Corresponding author. CIEMAT, Av Complutense, 40, 28040 Madrid, Spain.
Tel.: 34 913460872; fax: 34 913466275.
E-mail address: pedro.arce@ciemat.es (P. Arce).
Nuclear Instruments and Methods in Physics Research A 735 (2014) 304313
Finally, GAMOS offers the possibility for a user with a minimum
knowledge of C to easily extend and customize the framework
by adding new code without modifying and re-compiling the
GAMOS kernel. This is a key feature that allows the framework to
cover the need of any user who wants to exploit some GEANT4
features that GAMOS developers have not foreseen. To achieve this,
we have based GAMOS on the plug-in technology, whose function-
ality is explained in a dedicated section below.
With currently more than nine hundred registered users
worldwide, GAMOS has a fast growing community that spans well
beyond the original borders of medical physics. The most complete
source of information about GAMOS is available in a dedicated web
site [13] where registered users can nd the newest software
release, the corresponding user manual, and access to the GAMOS
forum for technical support.
This paper provides an overview of the GAMOS software by
detailing rst the basics of the design strategy and implementation.
A brief review of the GEANT4 terminology is followed by the descrip-
tion of the user requirements and the corresponding experimental
use cases that motivated the GAMOS design. The basic technical
choices taken to fulll these user requirements are discussed and
the advantages over the solutions used in other applications or
directly available in the GEANT4 code are explained. Afterwards, the
different eld-specic applications are analyzed in detail. Finally, the
installation procedure and the user support are described.
2. GEANT4 terminology
GEANT4 is a toolkit, this means that it does not provide a
predened conguration, but the user has to describe its setup
and decide which is the best physics for his application. Therefore,
the user has to dene three mandatory objects in the C main
program:

The geometry, by instantiating a C class inheriting from the

GEANT4 class G4VUserDetectorConstruction.

The primary generator, which contains the initial particles of

each event, by instantiating a class inheriting from G4VUser-
PrimaryGeneratorAction GEANT4 class.

The physics list, which creates the particles and the processes
and models dened for each particle, by instantiating a class
inheriting from the GEANT4 class G4VUserPhysicsList.
Four classes dene the structure of any GEANT4 simulation:

A run is a set of events sharing the same conditions, i.e. the

same geometry and physics.

An event is the set of tracks that include the initial particles

created by the primary generator and all the secondary tracks
formed as they are transported through the geometry.

A track is a snapshot of a particle as it is being tracked through

the geometry; it contains only information about the initial
state and the current state.

A step is the information about the change of a track as it is

being propagated, and contains the initial and nal points plus
the differential information (energy loss on the step, time of
ight spent by the step, etc.).
In other words, each time a particle is going to be tracked through
the geometry, a track object is created and this object is moved
through the geometry step by step. A step ends when the particle
changes volume, an interaction occurs or the user limits it after a
certain length.
Throughout this paper, we will use the word job to mean an
execution of a simulation program. A job contains, in principle, one
run, although it is possible to dene several GEANT4 runs in a job,
with different setups each.
To modify the running conditions and to extract information,
GEANT4 offers the user action classes. These are user-dened C
classes invoked by the GEANT4 code at the beginning/end of a run
(G4UserRunAction), at the beginning/end of an event (G4User-
EventAction), at the creation/destruction of a track (G4User-
TrackingAction), at each step (G4UserSteppingAction),
to modify the stack of tracks to be processed (G4User
StackingAction).
3. User requirements
The design of GAMOS described in the next section may be better
understood by rst examining the user requirements that GAMOS is
meant to satisfy. The user requirements were dened by the
analysis of the common problems that users nd when they use
GEANT4 either directly or through an application.
Two main assumptions have been made in the denition of the
user requirements:

Many users interested in simulation have little or no knowl-

edge of C and nd it easier to dene their simulation setup
through a scripting language.

It is unfeasible to cover all the functionality offered by GEANT4

with a scripting language. This means that the scripting
language should be easily extensible by providing a simple
mechanism to integrate new user code.
In the latter condition by simple mechanism we mean the
following:

Only one or a few lines shall be needed to transform a piece of

code (a C class) so that it can be selected with a user
command.

User shall not need to modify the framework, nor understand

how the framework would invoke the new code.

The procedure shall be clearly documented, including step-by-

step examples.
The main user requirements dened in accordance with the
aforementioned assumptions are listed below. They are grouped
into input requirements and output requirements. In general, for
each requirement, both the default functionality accessible
through the scripting language and the extensions involving the
plug-in mechanism are briey discussed. All requirements are
already fullled by the current GAMOS version.
3.1. Input requirements
We analyze here the requirements associated to the denition
of the input of a GEANT4 simulation, i.e. geometry, primary
generator, and physics list.
3.1.1. Geometry
As it will be explained in the section about design below, we
assume that a text le is the easiest way for most users to dene
their geometry. This format shall cover most of the functionality
provided by GEANT4 C code with common scenarios requiring
simple parameterizations. To complement the possibilities offered
by the geometry text le and cover all the possible use cases, it
shall be possible to mix a text le with a user-dened C le.
P. Arce et al. / Nuclear Instruments and Methods in Physics Research A 735 (2014) 304313 305
3.1.2. Primary generator
The primary particles distributions for position, direction,
energy, and time are quite specic for each physics eld. For this
reason, instead of offering a wide variety of predened scenarios
to cover all the possible use cases, the user shall be provided with
a large number of different primary generator distributions. As
GAMOS was originally developed for medical physics applications,
the most commonly used distributions in this eld shall be
supported. To increase the exibility, the denition of the primary
generators and primary generator distributions shall be extensible
with new C code to cover new cases as they are demanded by
GAMOS users.
3.1.3. Physics
GEANT4 offers a considerable variety of physics models and it is
unfeasible to cover all the possible combinations of them with a
scripting language A reasonable set of default physics shall be
provided. This set shall be customisable, allowing the user to select
among the three electromagnetic models: standard, low energy
and Penelope, as well as selectively activate the radioactive decay,
the atomic de-excitation, the Cherenkov process, and the optical
photon processes. The hadronic physics list shall cover the most
appropriate hadronic physics for a hadrontherapy treatment, as
recommended in the GEANT4 ofcial example named advanced/
radiotherapy. Any of the physics lists provided with the GEANT4
source code shall also be selectable with a user command.
Other requirements concerning physics are related to the
provision of user commands to change production cuts and user
limits (see Ref. [14]) for any particle or volume independently.
3.2. Output requirements
GEANT4 offers several mechanisms to extract information out of
a simulation. The rst one is the creation of a sensitive detector,
that simulates the signals (hits) in a device. The second one is the
scoring, which counts a certain type of data (energy deposited,
ux, number of interactions, etc.) within a certain volume during a
run and prints a nal score at the end of run.
In GEANT4, the most exible way to extract information is by
means of the user actions. Through them the user can extract
different data (nal position, energy lost, list of secondary particle
types created in an interaction, etc.) at different moments of the
simulation (each run, each event, each track or each track step).
GAMOS shall provide easy access to a rich set of predened user
actions for the user to extract the needed output information and
store them in the preferred format, be it a histogram, a score, or a
table entry.
As most of the use cases would require the data to be obtained
only under certain conditions (only if particle is a neutron, only if
energy is bigger than 10 keV, only if track is inside a volume, ),
GAMOS shall add the possibility to attach different lters to a user
action or scorer. Another source of exibility that helps in covering
a wider range of use cases is the possibility to add a classier to a
user action or scorer, so that a different histogram, score, or table
entry is produced for each classication index.
More details about the output user requirements fullled by
the current GAMOS version for sensitive detectors, user actions,
data, scoring, histogramming, and verbosity are provided below.
3.2.1. Sensitive detectors
The principal function of GEANT4 sensitive detectors is to mimic
the response of the sensitive parts of real detectors to the passage
of particles. Such response is strictly related to the peculiarities of
the simulated detector and ultimately depends on all the design
parameters selected by the user. With GAMOS, users shall be able to
chose among a number of predened sensitive detector cong-
urations to nd the one that best fulll their needs. The use cases
that are currently covered by GAMOS are those related to PET, SPECT
and Compton camera detectors. To make the simulation realistic, it
is necessary to introduce some detector's physical effects, such as
energy, time and spatial resolution, measuring and dead time.
As for all the other GAMOS components, the set of predened
sensitive detectors can be easily extended with new user code to
be added as a plug-in.
3.2.2. User actions
As mentioned above, the user actions are the preferred way to
extract information out of a GEANT4 simulation. As the require-
ments for data have a large variety, we need to enhance their
exibility by adding a functionality that is not provided by default
in GEANT4, namely the possibility to use any number of user actions
of one or several types in the same job. New user actions shall be
easy to include in the default set by adding new user-dened
C code and then invoking them through the scripting
language.
3.2.3. Data, lters and classiers
We understand by data any piece of information in the form of
a number or a string that can be extracted out of the simulation
(position, direction, kinetic energy, energy lost, particle name,
volume name, track ID number, ). As different use cases may
require the extraction of different data, any kind of data that can
be obtained from GEANT4 shall also be available through the
scripting language. This data is commonly requested under some
given condition, or lter. A lter in GAMOS is a C class that
receives a track or track step information and accepts it or not
depending on some given criteria. For example, a lter can accept
a track if it is of a certain particle type, if its energy lies within an
interval, if it is inside, enters, exits, starts in, ends in, or traverses a
volume, etc. Any possible lter required by the user shall be
available in the scripting language.
It is also common that data is required to be classied under a
certain condition, e.g. a different histogram per particle or per
energy bin. A newconcept with respect to GEANT4 has been created
in GAMOS to satisfy this requirement: the classier. A classier is a
C class that receives a track or track step information and
returns a different index (an unsigned integer) depending on some
given criteria. In other words, it classies the step or track and
returns the index of its classication so to be addressed to the
corresponding output.
3.2.4. Scoring
The main scoring application that was considered at the
beginning of the development of the framework was the simula-
tion of the dose deposition in a voxelized phantom. This use case
covers, in fact, two: the dose calculation in a real voxelized
geometry, and the simulation of a non-voxelized geometry and
the scoring of dose in a voxelized geometry that is not part of the
real geometry, but superimposed on it.
As GAMOS is born with the aim of serving a wide range of physics
elds, the most common scoring quantities shall also be covered,
like ux, current, number of interactions, etc.
Although often the user wants to see the scoring result in the
form of tables or histograms, it is also frequent that some external
software is used to create 3-dimensional images. In this case the
dose shall be dumped to a text or binary le so that it can be read
back by the software.
P. Arce et al. / Nuclear Instruments and Methods in Physics Research A 735 (2014) 304313 306
3.2.5. Histogramming
Many users who start to use GEANT4 have already some
experience, often a good expertise, in one histogram package or
another, like MATLAB [15], ORIGIN [16], GNUPLOT [17], etc. The frame-
work shall therefore give the user the freedom to use any of these
packages, instead of forcing them to use a xed one. This is
achieved in GAMOS by providing two simple text formats, a
comma-separated value (CSV) format, and a simpler text format
that contains only the histogram limits and the list of histogram
entries, one per column. Nevertheless, GAMOS also provides histo-
grams directly written in ROOT [18] format, as this is a C
analysis package with which many GEANT4 users are familiar.
3.2.6. Verbosity
For the detailed understanding of the results of a simulation, it
is frequent that a user needs to run a job with limited statistics
producing very detailed information. This detailed information
would generate too large an output if it were always printed, so
the scripting language has to provide the commands to easily
switch it on or off. GAMOS shall also give the possibility to activate
or not the verbosity only for a specic component of interest, be it
the geometry, the primary generator, or a lter, or only for a few
selected events or tracks.
4. Design
The GAMOS C code is divided into the core and the applica-
tion code. The core is a set of classes that wrap the GEANT4 kernel
with the dual function of making the GEANT4 functionality
accessible to the user through commands and plug-ins and of
providing extra functionality not related to any specic applica-
tion. The application code exploits the tools available in GEANT4 and
those added by the GAMOS core to provide the user with predened
simulation setups optimized for a specic eld.
All GAMOS default tools are directly available through the
scripting language that operates as an interface between the user
and the kernel. The user-provided script is read and interpreted
only once per job to initialize the required conguration. There-
after, all the required GEANT4 classes and parameters are invoked
only once, whether at job initialization or at run initialization.
Those parameters which are needed several times through a job
are stored as private class members, so that their value is read only
once from the user scripts. In this way there is virtually no
difference between a GAMOS dened simulation and a pure GEANT4
one. In other words, in terms of run-time, the penalization
experienced by using GAMOS instead pure GEANT4 is only in the
initialization procedure and therefore negligible.
As already indicated, the set of tools and congurations avail-
able through the scripting language can be easily extended with
plug-ins, without modifying the GAMOS kernel or even knowing
how the kernel works.
A schematic of the GAMOS structure is shown in Fig. 1. Further
details about the scripting language and the plug-in technology
are described in the next section while the most signicant eld-
specic applications are described below.
4.1. The scripting language
With the GAMOS scripting language the user can specify the
desired input and output of a GEANT4 simulation by coding a series
of user commands without implementing any C code. GAMOS
user commands are an extension of the GEANT4 built-in user
interface commands and are based on the same scripting gram-
mar. This means that any existing GEANT4 command can be directly
used in a GAMOS script. Those commands that are specic to GAMOS
are listed in the user documentation.
The conguration of the simulation, involving the experimental
model, primary generator, physics list and other selected func-
tional options, must be specied at run time through user
commands. GAMOS does not provide any default conguration,
giving the user full freedom to mix GAMOS components with his/
her own ones.
4.2. The plug-in technology
GAMOS has been based on the plug-in technology since the
beginning of its development to provide the framework with a
relatively easy mechanism to cover all the possibilities offered by
GEANT4 even if the needed functionality was not foreseen by GAMOS
developers.
Without plug-ins, including some new feature in a framework
would require a deep understanding of the framework structure
and logic, and the framework code would have to be modied and
recompiled. The situation is sometimes made even more compli-
cated by the fact that simulation frameworks usually do not
provide any mechanism to switch from old to new components,
so, if a user needs to alternate between different components, the
framework code has to be modied and recompiled each time.
Plug-ins enable customizing the functionality of an application
without the aforementioned limitations. The user only has to
provide his/her own code, and this code is plugged into the
framework, which takes care of invoking the user component. The
plug-in mechanism in GAMOS may be better understood by illus-
trating it with an example: let us suppose that a user wants to use
the GAMOS geometry text format and one of the GAMOS physics lists,
but he wants to use his/her own primary generator, dened in a
new C class named MyPrimaryGenerator. The user only has to
include in his/her new le the following line:
#DEFINE_GAMOS_GENERATOR(MyPrimaryGenerator);
After compiling the new user class alone, the new primary
generator can be selected in any job by adding in the GAMOS script
the command:
/gamos/generator MyPrimaryGenerator
instead of selecting the GAMOS one:
/gamos/generator GmGenerator
The plug-in mechanism in GAMOS is based on the library SEAL
[19], developed at CERN.
5. Implementation details
This section is dedicated to those design choices that we
consider deserve detailed explanation. When available, alternative
solutions adopted in GEANT4 or in other GEANT4 based applications
are discussed and compared with the GAMOS ones.
5.1. Text le geometry
GAMOS provides the possibility of describing the geometry using
a text le. Details about the text le format can be found in the
GEANT4 documentation as it became part of the GEANT4 ofcial code
in release version 9.2 . It is based on simple tags, whose meaning
can be deduced from their name, as can be seen in the example
below. The order and meaning of parameters in each tag are
the same as in the corresponding GEANT4 C geometry class.
P. Arce et al. / Nuclear Instruments and Methods in Physics Research A 735 (2014) 304313 307
The tags cover all the functionality that can be obtained by directly
using GEANT4, with the exception of complex parameterizations
used to place several copies of a volume, where extra C coding
is needed.
An example of a geometry model built through a text le is
shown in Fig. 2. It consists of twelve tubes with a diagonal cut,
which are stacked in three lines and placed centered in an
aluminum tank lled with water. The explanation of each of the
lines can be found in the GAMOS User's Guide [20].
// Dene parameters to be used later
:P Hmass 1.00794
:P Omass 15.999
:P WaterMass 2n$Hmass$Omass
// Dene my own water, instead of using the predened
one
:ELEM Hydrogen H 1 $Hmass
:ELEM Oxygen O 8 $Omass
:MIXT Water 1ng/cm3 2
Hydrogen 2n$Hmass /$WaterMass
Oxygen $Omass/$WaterMass
:ROTM RM0 0 0 0
// Volume denition
// Use material from Geant4 database
:VOLU world BOX 100 100 200 G4_AIR
// Dene tank
:VOLU TANK_ext BOX 60 40 60 G4_Al
// Place a copy of TANK_ext in world
:PLACE TANK_ext 1 world RM0 0 0 0
:P WALL 0.5ncm
:VOLU TANK_int BOX 60-$WALL 40-$WALL 60-$WALL Water
:PLACE TANK_int 1 TANK_ext RM0 0 0 0
// Dene tubes; the cut is simulated
// subtracting a box
:P RAD 10 // Dene radius
:P HLEN 50 // Dene half-length
:SOLID tube_full TUBE $RAD-1 $RAD $HLEN
:SOLID box BOX $RAD sqrt(2)nRAD sqrt(2)/2n$RAD
:ROTM RM45X 45ndeg 0 0 // rotation matrix
// for a 45 deg rotation around X-axis
:SOLID "my tube" SUBTRACTION tube_full
box RM45X 0 $RAD/2 $HLEN-$RAD/2
:VOLU "my tube" my tube" G4_Al
// Place 43 copies in a 2D grid, centered in the
water tank:
// number of copies X/Y, separation X/Y, offset X/Y,
direction X/Y
:PLACE_PARAM my tube" 1 TANK_int SQUARE RM0
4 3 2n$RAD 2n$RAD -3nRAD -2nRAD
1 0 0 cos(60ndeg) sin(60ndeg) 0
// Visualization attributes
:COLOUR TANK_ext 0.1 0.4 0.5
:COLOUR TANK_int 0 0 1
:COLOUR my tube" 0.1 0.4 0.5
:VIS world OFF
This geometry text le format is the evolution of the original
one developed more than ten years ago, which has been used to
simulate the full HARP detector at the PS, and the CMS detector at
Fig. 1. A schematic view of the GAMOS logic structure.
Fig. 2. VRML [21] view of the example geometry described in the text.
P. Arce et al. / Nuclear Instruments and Methods in Physics Research A 735 (2014) 304313 308
the LHC at CERN. GEANT4 offers an alternative format, the Geant
Detector XML (GDML) [22], which is based on the XML language
[23]. We opted for the text le format as we think it is simpler for
most users for two reasons. First, GDML requires the installation of
another package, Xerces-C [24], with sometimes gives compat-
ibility problems due to the variety of operative system distribu-
tions on which GAMOS is expected to be executed. Second, the big
verbosity of the GDML format makes the writing of a given
geometry much longer. For example, the geometry in the ofcial
GEANT4 GDML example G02 occupies 245 lines and 9468 charac-
ters, while, in text format, it occupies only 53 lines and 1599
characters, almost an order of magnitude less.
The description of human or animal anatomy through a
voxelized geometry deserves a special treatment to ensure the
optimization of the CPU and memory consumption. GAMOS can read
geometries in DICOM [25] format, after transforming the Houns-
eld numbers to materials and densities using the GEANT4 example
examples/extended/medical/DICOM, or, alternatively, reading the
same format used by EGSnrc [26]. The format includes the
possibility to intersect a phantom geometry with any volume,
which can be useful, for example to t a tomographic image of a
human into a PET detector bore by elimination of the air voxels
that surround the body. GAMOS includes an algorithm for fast
navigation in regular geometries which optimizes at the same
time the memory consumption [27]. This algorithm has been
included in the ofcial GEANT4 since the version 9.1 release.
5.2. Primary generator
Many different primary generator distributions are used in
different simulation elds. For this reason we have developed in
GAMOS a exible primary generator. It supports the creation of any
GEANT4 particle type (gamma, electron, positron, proton, neutron,
ions, etc.), and several particles or decaying isotopes can be
created in the same event. For each particle, the user may
independently select a different distribution of energy, position,
direction or time, or use the default one that is provided.
Many distributions are available in GAMOS, including those most
commonly used in medical physics. Among them we can cite the
position distribution on the surface or in the interior of a volume,
the position distribution in a disc with a radial Gaussian prole,
the time distribution of a decaying particle, the energy distribution
of a beta decay (taken from the GEANT4 database or alternatively
from the Lund/Lawrence Berkeley National Laboratory database
[28]), or the energy distribution as read from a text le.
A exible generator called G4GeneralParticleSource (GPS) is
also available in GEANT4. After evaluating it, and using it in the very
rst versions of GAMOS, we decided to build our own one. Three
main reasons motivated this decision. Firstly, GPS does not support
time distributions. The second reason is that several distributions
commonly used in the medical physics eld (the origin of GAMOS)
are not available in GPS. Finally, we wanted a generator based on
the plug-in technology, so that it would be easier to add new
distributions that could satisfy the use cases of a wider community.
5.3. Extracting data
It is difcult to provide user commands to extract any kind of
data available in GEANT4, with any kind of lter and classier. We
have nevertheless tried to satisfy this requirement by providing
over a hundred different classes for as many variables. All these
classes are referred to as GAMOS-data and can be used individually
or in arithmetic expressions (e.g. 2nlog10(InitialKineticEnergy),
sqrt(FinalPositionXnFinalPositionY) ). GAMOS-data are based on the
plug-in technology, so that new GAMOS-data can be easily added if
required by a user. Moreover, over a hundred types of lters and
more than a dozen classiers are available, including the possibi-
lity to lter or classify on any of the GAMOS-data or a combination
of them.
As already mentioned, the GEANT4 user actions are the preferred
mechanism to extract data values. As different users may require
to retrieve different data at different moments of the simulation
(e.g. the position at the start of each track or at the start of each
track step, the energy deposited for a track or for the whole event,
etc.), GAMOS provides a user action for each of the GEANT4 objects,
namely G4Run, G4Event, G4Track and G4Step, plus another user
action for data relating a track with the secondary tracks created in
an interaction (e.g. angle between primary and secondary tracks,
fraction of energy taken by a secondary track, etc.). Because the
use cases may include the writing of some GAMOS-data into text or
binary les, into a histogram, or also into the standard output for
debugging purposes, we have created four different user action
types to cover these four cases. In total, this makes twenty user
actions, which can be activated independently by a user command.
Each user action has a default set of GAMOS-data that it extracts and
outputs, but the list can be overridden through a user command,
and lled with GAMOS-data individually or in combination.
As already mentioned, each one of GAMOS-data corresponds
internally to a C class. These classes take care of dening a
default unit in the case of numeric data and a default number of
characters in the case of string data; both values can also be
changed with user commands. GAMOS-data classes take also care of
checking if the user action where they appear is appropriate (e.g.
one cannot ask for the track number of a run, or use the particle
name to ll a histogram).
For better understanding of the GAMOS mechanism to extract
data during a simulation, we can analyze a simple problem. The
requirement is to ll histograms with the logarithm of the energy
lost by the tracks in a medical linac's jaws, one different histogram
per particle type. The user commands that should be added in the
GAMOS script to obtain this data would be the following:
# Only when track steps happen in JAWS_X or JAWS_Y
/gamos/lter jawsF GmInLogicalVolumeFilter JAWS_
n
# Select what to dump into histograms
/gamos/setParam
GmTrackDataHistosUA_jawsF_GmClassierByParticle:
DataList
log10(AccumulatedEnergyLost)
# Instantiate the user action that will write the
histograms,
# with lter and classier
/gamos/userAction GmTrackDataHistosUA jawsF
GmClassierByParticle
6. Detector applications
GAMOS offers a variety of predened detector applications for
PET, SPECT and Compton camera, whose technical characteristics
are detailed in this section.
The modeling of any of these three systems implies the detailed
simulation of detector signals, and their writing into a le to be
used by an image reconstruction software. GAMOS provides the user
with commands to simulate these signals, including detector
effects like energy resolution, measuring time, dead time, etc.,
and to dump the signals in a simple text of binary le or in a
format compatible with the STIR [29] software.
Another usual requirement is the generation of a table with the
classication of the detected events. GAMOS allows a detailed
simulation of the hits created in a detector and provides a user
P. Arce et al. / Nuclear Instruments and Methods in Physics Research A 735 (2014) 304313 309
action for the classication of PET events and another for the
classication of SPECT events, the latter including an extra classi-
cation that takes into account if the gamma created by the SPECT
isotope has traversed a collimator or has crossed one of the walls
of the detector before reaching the sensitive volumes. A third
classication algorithm serves Compton camera simulations and
classies the events by the number of hits deposited in the
scatterer and the absorber detector. Moreover, several control
histograms may be produced to better understand the behavior
of the setup.
The use cases taken into consideration include the most
advanced PET detectors which use different technologies to
determine the depth of interaction (DOI): dual layer of crystals
with different response, analogue photo diodes (single or double)
which base the signal in the spatial distribution of optical photons,
pixelized semiconductor detectors and liquid argon or xenon
detectors, etc. When the photon originated at the positron
annihilation suffers Compton interactions in the detectors, differ-
ent signals corresponding to the same photon may be produced,
and it is necessary to apply an algorithm to identify which signal
relates to the rst interaction. This need is specially relevant for
detectors with depth of interaction identication and GAMOS
provides several algorithms to solve this problem.
GAMOS can also be used to simulate the counting rate perfor-
mance of PET scanners containing natural radioactivity in the
crystals according to the broadly accepted standards from the
National Electrical Manufacturers Association (NEMA) [30,31]. This
phenomenon is present in several scintillator crystals containing
Lu, such as LSO (lutetium oxyorthosilicate), LYSO (lutetium
yttrium orthosilicate), LuYAP (lutetiumyttrium aluminum per-
ovskite), or MLS (mixed lutetium silicate), which are widely used
in clinical and preclinical systems. The natural radioactivity of
these crystals increases the single count rate of detectors and may
create fake events [32]. The measurement of the fake rate due to
the intrinsic radioactivity is a requirement for the assessment of
the counting performance in the NEMA NU 2-2007 [30] and NEMA
NU 4-2008 [31] protocols.
7. Radiotherapy application
The main use case taken into consideration in this application
is the transportation of the initial beam of particles through the
geometry of a gamma or electron medical linear accelerator and
the calculation of the dose deposited in a voxelized phantom.
Nevertheless, the utilities available in this application can also
satisfy the use cases of dose computation in brachytherapy, X-ray
CT, hadrontherapy or dosimetry, and, in fact, more than a third of
the currently registered GAMOS users in this eld are interested in
one of these applications.
7.1. Accelerator simulation
Any radiotherapy accelerator can be described with the simple
geometry text format. However, for some complex parts, like jaws
or multi-leaf collimator (MLC), GAMOS provides some modules that
facilitate their description using only a few parameters. In the case
of the jaws, the dimensions and apertures are calculated based on
the Z position and the projection of the eld in a given XY plane. In
the case of MLCs, the user has to provide the set of 2-dimensional
points that dene the leaf prole, plus a few parameters about leaf
separations and orientations.
It is common for radiotherapy accelerator simulations to
calculate the dose deposited in several voxelized phantoms from
the same accelerator. To avoid repeating the simulation of the
passage of particles through the accelerator, GAMOS offers a way to
efciently store the information of only those particles (usually a
small fraction of the total) which traverse all or a dened portion
of the accelerator. This information can then be used in the
following jobs without regenerating the particles. To satisfy this
use case, phase space les can be written in several XY planes at
any Z value in the same job (it is assumed that the particle
propagates initially along the Z-axis). The phase space le is
written according to the International Atomic Energy Agency
(IAEA) [33] format, which was created with the aim of becoming
a standard in MC simulations. Another set of user commands is
available to read back the IAEA phase space les and use them as
the source of primary particles.
To simulate the real movement of an accelerator head, the
phase space can be displaced or rotated. Given that the small
percentage of particles that reach the phase space of interest is
usually quite small, the same generated particles can be reused
several times to increase the efciency of the accelerator simula-
tion. To reduce the bias due to particle reusing, there is an option
to mirror the reused particles in either X or Y, in both X and Y, or
with cylindrical symmetry. It is also possible to reuse particles that
reach a certain Z plane without writing a phase space le, which
allows doing the accelerator simulation and dose calculation
efciently in a single job.
7.1.1. CPU optimization of an accelerator simulation
Two variance reduction options are available to optimize the
CPU usage in the simulation of radiotherapy accelerators.
The rst option consists in identifying those particles that reach
a too large transverse position and therefore will probably not
reach the patient, and to randomly reject some of them.
A second option is the optimization through particle splitting.
Currently, two bremsstrahlung splitting techniques are available.
The rst one is a uniform splitting of bremsstrahlung photons, all
with the same weight. The second one checks the momentum of
the split photons and randomly rejects those which do not point
towards the region of interest. A third particle splitting technique,
based on the BEAMnrc DBS technique [34], is expected to give the
best results and it is under development at the time of editing the
present document.
7.2. Dose in phantom simulation
Two different use cases are covered regarding the use of
voxelized phantom geometries: the use of DICOM les describing
patient geometries, and the building of simple geometries made of
one or a few materials. GAMOS can read DICOM geometries in
GEANT4 or EGSnrc format. The scoring of the dose in the phantom
voxels is done through the dose deposit scorer, so that different
lters, classiers, and scorer printers can be associated to it.
Several printing formats for the dose output can be selected, i.e.
a table in the standard output, a text le, a binary le, or the dose
histograms usually requested in radiotherapy. The latter category
includes percentage depth dose (PDD) curves, proles at several
depths, 2-dimensional doses, dose per voxel and dose-volume. The
dose can be given per run or per event properly taking into
account error correlations for each case. When reading phase
space les a proper management of the original number of events
(the number of events in the job that created the phase space) is
implemented.
8. Shielding application
One of the most common set-ups in the eld of shielding
simulation describes a shielding placed between the particle
source and the detector, so that the number of neutron or gamma
P. Arce et al. / Nuclear Instruments and Methods in Physics Research A 735 (2014) 304313 310
particles that are detected is a very small fraction of those
generated. Due to this small fraction of useful particles, a full
simulation could require a prohibitive amount of time. To tackle
this problem we have developed the Point Detector Scorer
technique, based on the MCNPX F5 tally [35]. The basic idea
behind it is that for each neutron or gamma interaction the
probability of the particle reaching the detector without any
further interaction is computed. At the end of the job, the sum
of all these probabilities provides an estimation of the ux of
particles per energy bin in the detector. To increase the exibility,
personal and ambient equivalent dose can also be obtained,
converting the ux to dose with the coefcients of the Interna-
tional Commission on Radiation Units and Measurements (ICRU)
report number 57 [36] or those provided by the user.
Even with the optimization techniques described above, the
convergence of the results is often very slow and therefore the
total number of simulated events required can still result to be a
too big number for many users. To increase the efciency, several
variance reduction techniques are available. They are based on a
GAMOS importance sampling technique which allows to use a big
number of criteria for assigning importance values (by any of the
over hundred of different GAMOS-data or their combinations) and
splits the particles if the importance value is bigger than one or
randomly reject them if it is smaller than one. To check if the
convergence reached is satisfactory, the results of nine conver-
gence tests are shown to the user; these tests are taken from the
GEANT4 code, and are based on the MCNPX ones.
Other utilities that may serve those users interested in shield-
ing calculations are also available. Among them we can cite those
to calculate with a few user commands the width of a material
needed to reduce the number of incident particles by a given
fraction, the table of probabilities of each exit channel in a given
nuclear reaction, the histogram of the hadronic cross-sections
used by GEANT4 at a given temperature, or the activation of a
certain material after it has been hit by a beam of particles and the
subsequent calculation of the activity or the dose at a given point
at any time from the simulation of the decaying isotopes
produced.
9. Validation
The rst validation of GAMOS is the checking of the robustness
and stability of each new GAMOS version with more than sixty
different scripts on at least three different platforms, including one
Mac OS and several different Linux distributors.
GAMOS does not implement any geometry propagation nor
physics process (except for the X-ray reection). Therefore the
accuracy of the GAMOS results is mostly based on the reliability of
the GEANT4 performance. Nevertheless in some cases the proces-
sing of the GEANT4 results by the GAMOS code is quite elaborated and
needs a specic validation. Several users have tested the perfor-
mance of GAMOS with respect to experimental measurements in
different physics elds. This section presents three of those
comparisons, which can be considered as benchmarks in their
respective eld.
9.1. PET detector
The performance of a PET detector, the Raytest ClearPET, has
been systematically compared with real data in Ref. [37]. In this
work simulated results are contrasted with experimental acquisi-
tions including studies of spatial resolution, sensitivity, scatter
fraction and count rates in accordance with the National Electrical
Manufacturers Association (NEMA) NU 4-2008 protocol. Assuming
that GEANT4 provides an excellent description of the physics
processes at such a low energy (511 keV), the good agreement
found between data and simulation in Fig. 3 conrms the validity
of the GAMOS PET model. As an example, Fig. 3 shows a comparison
between the sensitivity as a function of axial distance to the center
of the eld of view measured with this detector and calculated
with a GAMOS simulation (courtesy of Physics in Medicine and
Biology).
9.2. Compton camera detector
GAMOS has also been experimentally validated for Compton
camera applications, by comparing with the data of a Compton
camera congured with double sided high purity germanium strip
detectors [38]. Energy spectra and images for the data sets were
compared, and excellent agreement was observed, as can be seen
in the example data set shown in Fig. 4, reproduced from Ref. [38].
9.3. Gamma accelerator radiotherapy
The usual benchmark in this eld consists in the comparison of
dose proles calculated in a water phantom. In this case, practi-
cally all the calculations are performed by GEANT4, while the work
of GAMOS limits to the denition of the input and output and to the
dumping of the dose calculated in the phantom voxels in the
format requested by the user (table, histograms, binary or text
le).
Fig. 5 shows a good agreement between GAMOS simulation and
real data [39] of the PDD curve in water of a 10 cm10 cm eld of
a 6 MeV VARIAN accelerator.
10. Installation and user support
The installation of a Monte Carlo package is often a difcult
task for non-expert software users. For this reason, a big effort has
been made to provide a simple and robust installation method for
GAMOS. To make it simple, we have suppressed the need to dene
environmental variables or select among several options (which
often users do not understand), but, instead, all that is needed is to
download the installation scripts from the GAMOS web page, and
then type in a Linux or Mac OS shell: sh installGamos.sh MYDIR
where MYDIR is the directory where you want GAMOS to be
installed. This command will download all the needed les, will
check that the user system has the needed basic components
(mainly a C compiler and the X11 libraries if you want
visualization) and will compile GEANT4, optionally ROOT (installed
Axial distance to CFOV (mm)
-60 -40 -20 0 20 40 60
S
e
n
s
i
t
i
v
i
t
y

(
%
)
0
0.5
1
1.5
2
2.5
3
GAMOS
Data
Fig. 3. Clear PET detector sensitivity as a function of the axial distance to the center
of the eld of view, calculated with real data (triangles) and GAMOS simulation
(asterisks).
P. Arce et al. / Nuclear Instruments and Methods in Physics Research A 735 (2014) 304313 311
by default), and nally GAMOS codes. For expert users, an installa-
tion procedure similar to the GEANT4 one can be chosen, which
allows selecting among many options. To make the installation
procedure robust, it has been tested in over ten different Linux and
Mac OS systems. The main source of documentation is the GAMOS
User's Guide [20]. It explains how to install GAMOS and covers all
the available functionality of each GAMOS component (geometry,
physics, scoring, etc.), providing explanation and examples of
every user command. It also explains how to extend the frame-
work by creating new plug-ins.
Once GAMOS is installed, a number of test examples may be run
to check the installation. New users are also strongly encouraged
to complete the tutorials. Seven tutorials are currently available:
histograms and scorers, PET, radiotherapy, shielding, gamma
spectrometry, X-rays and plug-ins. Each one consists of a series
of ten to twenty exercises of increasing difculty that cover the
most important functionality in a specic eld. They are meant to
be solved by the user alone, by reading the slides where they are
proposed, and by following the instructions in the User's Guide.
A reference output is provided to cross-check the results obtained
by the user, and complete solutions are also provided.
The users may subscribe to the GAMOS mailing list to receive
news about new developments and releases. A discussion forum is
open to all the users to post questions, which may be answered by
GAMOS developers as well as by other users. If a bug is found, it can
be reported in the GAMOS bug report system, which is based on the
Bugzilla [40] tool. This system automatically assigns a bug to the
developer who should solve it, keeps track of the bug status and
informs the user when it is solved.
11. Conclusions
GAMOS is a GEANT4-based framework that provides a set of
components providing general simulation functionality plus a set
of utilities to satisfy the most common use cases specic of
different application domains. It is interfaced with a scripting
language based on the GEANT4 commands, which allows to perform
full simulations without the need of coding in C. It also
provides a mechanism, based on the plug-in technology, that
X (mm)
150 200 250 300 350 400 450
Y

(
m
m
)
150
200
250
300
350
400
450
0
200
400
600
800
1000
X (mm)
150 200 250 300 350 400 450
Y

(
m
m
)
150
200
250
300
350
400
450
0
200
400
600
800
1000
1200
X (mm)
200 250 300 350 400 450
C
o
u
n
t
s
0
200
400
600
800
1000
1200
FWHM X = 13 mm
Data
Total Fit
Peak fit
Background fit
X (mm)
150 200 250 300 350 400
C
o
u
n
t
s
0
200
400
600
800
1000
1200
FWHM X = 14 mm
Data
Total Fit
Peak fit
Background fit
Fig. 4. Image slices and intensity proles in the x direction, for 661.7 keV gamma rays emitted from a
137
Cs point-like source situated at (300,300) for (a,c) experimentally
acquired data and (b,d) data generated using GAMOS simulations.
Depth (mm)
0 50 100 150 200 250 300

D
o
s
e

(
G
y
)
0
10
20
30
10
-12
GAMOS
Data
Fig. 5. Comparison of PDD curve in water of a 10 cm10 cm eld of a 6 MeV
VARIAN accelerator from real data (triangles) and GAMOS simulation (line).
P. Arce et al. / Nuclear Instruments and Methods in Physics Research A 735 (2014) 304313 312
allows the conversion of new user C classes into user com-
mands of the scripting language, without the need to modify the
GAMOS code. The great exibility introduced by this mechanism
makes GAMOS suitable for practically any kind of simulation
achievable with the GEANT4 software.
GAMOS is the fruit of more than ten years experience in
providing software utilities to allow the use of GEANT4 with little
or no knowledge of C programming language. The analysis of
many use cases in several elds of physics has shown that, apart
from the need to have a set of predened utilities optimized for
specic application domains, there is the general demand of
having a deep understanding of what happens in the simulation
so to be able to assess the reliability of the results. To satisfy these
requirements, we developed several mechanisms to obtain
detailed information at each step of the simulation with just a
few user commands. These mechanisms are a distinctive feature of
GAMOS with respect to other GEANT4-based frameworks.
The applications already provided by GAMOS include PET, SPECT,
and Compton camera detectors, external beam radiotherapy
applications, and shielding experiments. Though an important
fraction of the almost one thousand registered GAMOS users are
interested in these applications, there is an increasing interest in
employing the framework for simulations in a wide variety of
different disciplines, well beyond the original medical physics
domain.
GAMOS can be run using the GRID technologies, as it has been
ported to the E-science grid facility for Europe and Latin America
[41]. Alternatively, it can be run on a multi-core CPU or a batch
system in a farm of computers; to do this GAMOS provides an utility
to send multiple jobs with different initial random seed each.
Several utilities are available to merge the nal results into one.
A multi-thread version is under progress, which will allow an
optimal efciency in the use of multi-core CPU machines.
The code is maintained by CIEMAT, one of the biggest Spanish
governmental research institutions. It can be freely downloaded,
after a simple registration process, from the GEANT4 web page
(under Applications) or directly from the GAMOS web page: http://
smed.ciemat.es/GAMOS.
References
[1] S. Agostinelli, et al., Nucl. Instrum. Methods Phys. Res. A 506 (2003) 250.
[2] J. Allison, et al., IEEE Trans. Nucl. Sci. NS-53 (2006) 270.
[3] Tracking Trends and Performance in Basic Research. Current Classics, http://
sciencewatch.com/dr/cc/09-deccc/.
[4] S. Abdouline, et al., The CMS simulation software, in: IEEE Proceedings of the
Nuclear Science Symposium Conference Records, 2006, p. 1655.
[5] P. Arce, S. Banerjee, T. Boccali, M. Case, A. de Roeck, V. Lara, M. Liendl,
A. Nikitenko, M. Schroder, A. Straessner, H.P. Wellisch, H. Wenzel, Nucl.
Instrum. Methods Phys. Res. A 502 (2003) 687.
[6] D. Costanzo, A. Dell'Acqua, M. Gallas, A. Rimoldi, J. Boudreau, V. Tsulaia, A. Di
Simone, The Geant4-based simulation software of the ATLAS detector, in: IEEE
Proceedings of the Nuclear Science Symposium Conference Records, 2006,
p. 5.
[7] G. Corti, M. Cattaneo, P. Charpentier, M. Frank, P. Koppenburg, P. Mato,
F. Ranjard, S. Roiser, I. Belyaev, G. Barrand, IEEE Trans. Nucl. Sci. NS-53
(2006) 1323.
[8] F. Lei, et al., IEEE Trans. Nucl. Sci. NS-49 (2002) 2788.
[9] G. Santin, V. Ivanchenko, H. Evans, P. Nieminen, E. Daly, IEEE Trans. Nucl. Sci.
NS-52 (2005) 2294.
[10] G. Santin, et al., IEEE Trans. Nucl. Sci. NS-50 (2003) 1516.
[11] T. Aso, et al., PTSim and TOPAS, Geant4 in the particle therapy clinic, in:
Proceedings of the SNAMC (2010), Progress in Nuclear Science and Technol-
ogy, vol. 2, 2011, pp. 912917.
[12] P. Arce, P. Rato, M. Canadas, J.I. Lagares, GAMOS: a Geant4-based easy and
exible framework for nuclear medicine applications, in: IEEE NSS/MIC
Conference Proceedings, 2008, pp. 31623168.
[13] http://smed.ciemat.es/GAMOS.
[14] http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/ForAppli
cationDeveloper/html/index.html.
[15] MathWorks, http://www.mathworks.com.
[16] OriginLab, http://www.originlab.com.
[17] GNUplot, http://www.gnuplot.info.
[18] A. Naumanna, et al., Comput. Phys. Commun. 180 (2009) 2499.
[19] J. Generowicz, P. Mato, L. Moneta, S. Roiser, M. Marino, L. Tuura, SEAL:
Common Core Libraries and Services for LHC Applications, Presented at CHEP03
http://www.slac.stanford.edu/econf/C0303241/proc/papers/MOJT003.PDF.1.
[20] GAMOS User's Guide, http://smed.ciemat.es/GAMOS/gamos_usersguide.ph.
[21] Virtual Reality Modeling Language, http://www.vrml.org.
[22] R. Chytracek, J. McCormick, W. Pokorski, G. Santin, IEEE Trans. Nucl. Sci. NS-53
(2006) 2892.
[23] eXtended Markup Language, http://www.w3.org/XML.
[24] Xerces-C XML Parser, http://xerces.apache.org/xerces-c.
[25] DICOM: Digital Imaging and Communications in Medicine, http://medical.
nema.org/.
[26] I. Kawrakow, D.W.O. Rogers, The EGSnrc Code System: Monte Carlo Simulation
of Electron and Photon Transport, Technical Report PIRS 701, National
Research Council of Canada, Ottawa, Canada, 2000.
[27] P. Arce, J. Apostolakis, G. Cosmo, A technique for optimised navigation in
regular geometries, in: IEEE NSS/MIC Conference Proceedings, 2008, pp. 857
859.
[28] R.B. Firestone, L. Ekstrom, Table of Radioactive Isotopes LBNL Isotopes Project
LUNDS Universitet, http://nucleardata.nuclear.lu.se/nucleardata/toi/.
[29] K. Thielemans, S. Mustafovix, C. Tsoumpas, STIR: software for tomographic
image reconstruction release 2, in: IEEE Proceedings of the Nuclear Science
Symposium Conference Records, vol. 4, 2006, p. 2174.
[30] NEMA Standards Publication NU 2-2007: Performance Measurements of
Positron Emission Tomographs (PETs), National Electrical Manufacturers
Association, Rosslyn, VA, 2007.
[31] NEMA Standards Publication NU 4-2008: Comparison of Preclinical PET
Imaging Systems, National Electrical Manufacturers Association, Rosslyn, VA,
2007.
[32] S. Yamamoto, H. Horii, M. Hurutani, K. Matsumoto, M. Senda, Ann. Nucl. Med.
19 (2005) 109.
[33] R. Capote, et al., Phase-Space Database for External Beam Radiotherapy,
http://www-nds.iaea.org/phsp/phsp.htmlx.
[34] I. Kawrakow, D.W.O. Rogers, B.R.B. Walter, Med. Phys. 31 (2004) 2883.
[35] D.B. Pelowitz, MCNPX User's Manual Version 2.6.0. Report LA-CP-07-1473,
2008, https://mcnpx.lanl.gov/documents.html.
[36] ICRU Report 57: Conversion Coefcients for use in Radiological Protection
against External Radiation, 1998.
[37] M. Canadas, P. Arce, P. Rato Mendes, Phys. Med. Biol. 56 (2011) 273.
[38] L.J. Harkness, P. Arce, D.S. Judson, A.J. Boston, H.C. Boston, J.R. Cresswell,
J. Dormand, M. Jones, P.J. Nolan, J.A. Sampson, D.P. Scraggs, A. Sweeney,
I. lazarus, J. Simpson, Nucl. Instrum. Methods Phys. Res. A 671 (2012) 29.
[39] M. Paiusco, Personal Communication, May 2005.
[40] Bugzilla, http://www.bugzilla.org.
[41] A.J. Rubio-Montero, P. Arce, J.I. Lagares, Yu.P. Ivanov, D.A. Burbano, G. Daz, R.
Mayo, Performance tests of GAMOS software on EELA-2 infrastructure, in:
Proceedings of the 2nd EELA-2 Conference, 2009, p. 379.
P. Arce et al. / Nuclear Instruments and Methods in Physics Research A 735 (2014) 304313 313