TRAX
is formally designed to support electrons, positrons, photons,
neutrons and ions as primary particles. At present, however,
only electrons and ions are actually treated.
Electrons, positrons, photons and neutrons are specified as
e-
,
e+
,
x
and
n
, respectively.
Throughout TRAX
ionic projectiles may be specified as
<mass><elementsymbol><charge>
Valid specifications are e.g.:
Note that they are case-sensitive, that is
8BE
would be an error, whereas
8Be
would be OK.
When the mass number is omitted, the most abundant nuclide is chosen.
As of TRAX
version > 0804
,
ionic projectiles are no longer builtin but
a large collection of projectiles is provided in the
PROJ
subdirectory
and will be automatically loaded as part of the startup procedure.
In addition,
projectile files moonshine as a database of atomic targets.
Projectile files are handled by a command,
the file format is described in the appendix.
Throughout TRAX
target materials are identified by name.
The actual
chemical composition, physical properties and electronic structure
must be specified as an external table, to be read before calculating
cross sections or running the simulation.
The properties of
a few materials like
H2O
and
N2
are builtin in versions earlier than and including 0804.
For later versions they are no longer built in but
a large collection of target materials is provided in the
TARG
subdirectory
and will be automatically loaded as part of the startup procedure.
Note that the proper handling of composed targets requires the presence of atomic data,
provided by the projectile data base.
Target files are handled by a command,
the file format is described in the appendix.
The (optional) chemical stage of the simulation
works with chemical products, specified just as
target materials.
To distinguish atoms and molecules from radicals,
the latter have a trailing .
(dot).
At present, chemical species only live within the
evaluation function simulating their developmemt after the completion of the
physical stage.
Chemical species and properties of a medium (solvent) are defined within a file,
the file format is described in the appendix.
They
are handled by a command,
A couple of interaction cross sections is supported for
the various particles, identified by a single character abbreviation.
- electrons
-
l
elastic scattering
-
x
excitation
-
i
ionization
- photons (not yet implemented)
-
f
reserved for photoelectric effect
-
c
reserved for compton effect
- ions
-
x
excitation
-
i
ionization
Cross sections can be calculated by various methods.
By default empirical approaches are used which means
they combine theoretical formulae with fits to experimental data.
Cross sections are handled by a command
Interactions can also be specified as filtering options for listmode
data output to reduce post-processing of unwanted information.
For example, if only energy deposition distributions are desired,
elastic events may be excluded from output, thus reducing space
and CPU requirements,
For filtering purposes some "pseudo-interactions" are important:
-
k
cutoff at lower energy limit
-
o
outside, particle doesn't hit any more volume surface
-
e
electric or magnetic field step
-
y
boundary crossing
In particular for absorbed dose calculations the inclusion of "cutoff"
events is mandatory, otherwise the scoring will have an "energy leak".
Filtering is specified with the run command.
Two types of linear congruential random number generators are implemented.
A single data object holds information pertinent to these generators:
- the last seed value(s)
- how many times the generator was called
- the type of generator used:
- a simple 32-bit generator ("PRN") with a period of about 2**30=1073741824.
- the 64-bit L'Ecuyer generator using two seed values with a much longer
period.
The PRN generator maxes out at one billion calls, which means it should only
be used for short simulations involving a few thousand primary events.
Consequently the L'Ecuyer generator is the default from TRAX
version 1808 onwards.
In order to support "trivially parallel" calculations which need different
random sequences it is possible to "fast forward"
the random generation for a specified number of events and to retrieve
the resulting seed value(s).
For special purposes (e.g. program testing), a second independent generator instance is supported.
Random number generators are handled by a command.
Particles are tracked through volumes.
Volumes are identified by a unique name (and internally by a running
number, starting with 1).
They have a shape (cylinder, sphere, box) and consist
of a material.
For each volume scoring tables exist which keep information
like the number of interactions and the accumulated energy deposition.
This information can be retrieved with the
score command.
For each volume electric and/or magnetic fields can be specified,
which affect the charged particle trajectory and energy deposition
in addition to the stochastic interaction events.
Volumes are not accessed directly but are combined
into a simulation geometry.
Before a simulation can be performed the geometry has to be defined.
The geometry comprises one or more non-overlapping (!)
volumes.
Particles which do not hit any volume are discarded from the
simulation.
The geometrical setup is provided by an external file,
it is handled by a command,
the file format is described in the appendix
The simplest source distribution is a point source emitting
monoenergetic particles in a fixed direction.
Such situations can be handled by a simple command.
More complicated scenarios involving energy and/or spatial distributions
of emitters must be specified using an external file.
The source geometry is handled by a command,
the external file format is described in the appendix
The particle object collects all relevant information about a
particle traversing the
volumes of a given simulation.
This information comprises e.g.:
- particle type
- the primary event number
- a unique particle identifier number
- a unique interaction sequence number
- the last interaction type
- the source volume number of the primary particle
- current location, time and direction of flight
- current energy and last suffered energy loss
These quantities cannot be accessed directly,
however, they are stored in binary listmode format
for later or immediate evaluation.
There are two basic modes these data are collected and filed, so called
track mode and volume mode, respectively.
In track mode, each single interaction is recorded (subject
to filtering), thus forming a particle track.
In volume mode the dissipative interactions are accumulated
per volume and per initial projectile event, before they are written.
This corresponds to "classical" detector energy deposition simulation.
Sometimes a simulation might require more sophisticated analysis
than just total energy loss or ionization numbers within a volume.
Typical examples are spatial distributions (radial doses)
with varying grid dimensions
or analysis of particle correlations.
In such cases particle data can be written as events in
listmode on a binary trackfile for later
analysis with one of the evaluation procedures.
Note the difference between track mode and volume mode,
as described in the
particle
paragraph. Most
evaluation
procedures expect data in track mode,
it is stated specifically where volume mode is required.
Trackfiles are handled by a command.
The file and event formats are described in the
appendix
Once all preparations
(
materials,
cross sections,
geometry,
source
)
are completed, the MC simulation may be started.
The MC kernel keeps all particles within a stack of
varying size.
Newly created particles, e.g. after ionization, are
added on top, whereas particles with terminated histories are
removed. Termination occurs when a particle's flight direction no
longer intersects a
volume
or when its energy drops below a cutoff threshold.
This threshold by default equals the lowest limit of
the dissipative interaction cross sections.
It may, however, be set even lower for each
volume
of the simulation
geometry.
This way the diffusion and escape of elastic scattered particles
may be accounted for, as well as the energy take-up of charged particles
in electric fields.
Note, however, that lowering the cutoff level below the dissipative
limit will result in a substantial increase of calculation time.
The kernel also records timing information (CPU, elapsed).
In order to reduce the amount of output data it is possible
to provide filtering requirements.
That is, for each particle type it may be specified which
interaction is written to a trackfile.
For details see the run command.
Last updated: M.Kraemer
$Id: traxdataobjects.html,v 1.9 2019/03/17 22:57:50 kraemer Exp $