TRiP98 data objects


Projectiles

Throughout TRiP98 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.

Targets

It is foreseen that throughout TRiP98 target materials are specified by name or chemical composition. A builtin table is searched first. If the material is not found there, it will be interpreted as a chemical composition. However, at present only H2O will be accepted as material.

Coordinate Windows

At various places in TRiP98 coordinate windows are used, e.g. to describe the outer limits of raster positions or to describe the volumes of interest in the patient CT. Windows may have two or three dimensions. Three-dimensional windows, however, are just a set of two-dimensional windows stacked along the third dimension. Windows may be simply rectangular or, for the two-dimensional case, defined as a closed polygon. When coordinates are checked against window limits it depends on the context whether the limits are included or not. For polygon windows an even-odd algorithm is used to determine inside/outside. For three-dimensional windows the third dimension coordinate is related to the lower stacked window, and, in case of a polygon window, the inside/outside decision is based on the lower polygon.

File to Memory Mapping

Whereever possible the UNIX memory-mapping services are used in order to save valuable main memory and I/O-time. This is a very efficient mechanism in case of read-only files like CT-cubes and spectral distributions of fragments. Essentially these external files are made visible to the CPU just like an extension of the real memory. The calculated dose cubes are handled this way too.

Data cubes

These are usually three-dimensional data like CT- and Dose-cubes. They are stored in binary format, usually as short integers (2 byte), in little or big endian format. When stored on files (extension e.g. .CTX or .DOS) they must be accompanied by a like-named header file (extension .HED). These header files contain information on format, dimension, stepsize and byte order. The header files are plain text files for readability. The data cube files themselves are handled, whereever possible, by means of the memory mapping services.

4D-transformations

(later)

Range shifter

The spring 2001 release of TRiP98 includes support of a range shifter device inserted between beam outlet and irradiation volume. A range shifter consists of a several independently movable layers of material of different water-equivalent thickness thus enabling passive energy variation of the ion beam. Both, the old as well as the new CAVE A range shifter are supported by means of the respective scanner control files. New irradiations, however, can only be planned for the new CAVE A range shifter. The properties of the shifter are specified by a command, the actual settings are included in the scanner control files.

Scanner capabilities

Several properties and limitations of the raster scanner in particular and the GSI irradiation setup in general are combined as "scanner capabilities". The most important are Some are computed internally, others are handled by a command. Although some "reasonable" default is hard coded, care should be taken that the correct values are set at startup.

Table of accelerator (SIS) energies

This is a very important data object because it contains the energy steps and the associated focus and intensity steps accessible from CAVE M. Dose and intensity optimization is based on the information in this table. SIS tables always have a version number which is passed to the scanner steering (.rst) files. They are checked online for validity ! Be sure that the most recent table is selected and loaded at session start !
With a dedicated clinic facility in mind which will handle all kinds of light ions a special command is provided to generate SIS tables for projectiles other than 12C.
For CAVE A irradiations without MEFI operation a SIS table does not make sense. You specify a dummy SIS table instead. Consequently no checks against available energies and foci can be performed and no respective table indices can be passed to the raster scanner files. The raster scanner files generated this way cannot be used in CAVE M, of course.
SIS tables are kept on external text files, they are handled by a command, the file format is described in the appendix

Ripple Filter

This device is used to broaden the very sharp Bragg peaks of ions in order to facilitate the generation of a homogeneous dose distribution. It is represented simply by pairs of numbers: a peak shift (in mm) and its relative weight. This can be viewed as the filter transmission function. From 1310b onwards negative offsets are allowed in order to estimate the deformation of dose distributions in lung tissue.
Dealing with the ripple filter is needed only when new data bases are to be generated for depth dose distribution and fragment spectra. In this case the original distributions are folded with the transmission function. Ripple filter transmission functions are handled by a command, the file format is described in the appendix

Random numbers

A single data object holds information pertinent to random number generation: Random numbers are needed in particular for RBE calculation. Random numbers are handled by a command.

Energy loss tables

These tables contain dE/dx and optionally range values for various projectiles at various energies. Multiple tables for different materials are now supported. dE/dx tables are needed for biology based dose optimization and the generation of depth dose distributions with the integrated beam model subsystem. Detector signal predictions also require dE/dx tables to be loaded at compute time.
dE/dx tables are handled by a command, the file format is described in the appendix

Total reaction cross sections

These tables contain total cross sections for nuclear reactions of various projectiles at various energies. Multiple tables for different target nuclei are supported. Reaction cross section tables are needed for proper beam modelling
Cross section tables are handled by a command, the file format is described in the appendix

Fragment spectra

Fragment spectra (in energy and particle species) are generated together with the depth dose distributions. They are needed at various places, in particular for biological calculations, but also for determination of detector responses. Spectra are represented by a set of nested substructures. Spectra are organized as tables, one for each primary beam energy. A set of such tables represents a database. For each beam energy (in MeV/u) a set of substructures describe the spectral distributions at a particular depth (in mm, not necessarily equidistant). At each depth exists - for each particle species - an energy distribution.
Spectra are handled by a command. Due to their large size the data are kept in native binary format.

Depth Dose Distributions

Depth dose distributions are one of the most important inputs for dose optimization and/or calculation. They are organized as tables, one for each primary beam energy. A set of such tables represents a database. If an energy is needed, which is not directly available, it is interpolated linearly between the available ones. Extrapolation is not permitted, that is, energies requested by any calculational procedure within TRiP98, which are outside the database limits will abort the calculation.
Depth dose distributions are handled by a command, the file format is described in the appendix

RBE data tables

RBE tables are needed for the calculation of the biologically equivalent dose. They contain cell specific RBE data as a function of particle species and energy. In addition, X-ray alpha and beta values and the radius of the cell nucleus are kept. Note: these tables represent only the initial slope of the ion dose-effect curve (single particle, monoenergetic) ! For the RBE calculation in the usually mixed radiation field TRiP98 follows the full formalism of the LEM model.
RBE tables are referenced by the cell type which they are belonging to. Provision is made to distinguish between mean, minimum and maximum RBE. However, only the mean RBE is used at present. Multiple RBE tables are kept in a list which makes up an RBE data base. It is possible to "alias" RBE tables so that different tissue types may share the same table. RBE tables are handled by a command, the file format is described in the appendix

OER data tables

(under construction) (soon to come)

Hounsfield look-up table

This table describes the relation between Hounsfield (CT) numbers and the water-equivalent ion pathlength. It consists of pairs of numbers. It is needed for all dose computations. HLUT tables are handled by a command, the file format is described in the appendix

Volumes of Interests

Volumes of interest (VOIs) describe the contours of the target and the critical structures within the irradiated area, usually the patient CT. A single volume of interest is a three-dimensional window with a name and a tissue type attached. Tissue types are obviously mandatory for biology based planning. At least one VOI (the target volume) must be present for dose optimization.
All VOIs for a given patient are combined in a single file with the extension .VDX, accompanied by a header (.HED) file which contains readable information on patient name, cube dimensions, et al. Normally this header file is shared with the CT cubes (.CTX).
VOIs also keep Dose-Volume histograms and related information, as well as specifications for dose optimization.
VOIs are handled by a command, the file format is described in the appendix

CT cubes

CT data cubes describe the irradiated volume in terms of the Hounsfield numbers. It is needed for all dose computations. To be useful, an additional Hounsfield table is necessary in order to derive particle ranges within the irradiated volume. When stored as files, they have the extension .CTX and are accompanied by a header (.HED) file which contains readable information on patient name, size, et al. The data themselves are stored as binary (usually short) numbers in little or big endian order. By default they are mapped read-only into the CPUs address space. Byte swapping is performed on-the-fly when needed.
It is possible to generate "simple" CT-cubes (with constant water-equivalent path length or constant Hounsfield unit) of arbitrary dimension and stepsize without an external file.
In addition, a user plug-in is provided which allows complex CT number distributions to be generated by means of an externally linked user-supplied C function.
CT cubes are handled by a command, the file format is described in the appendix

Raster scanner data

Raster scanner data are organized in a rather complex way, reflecting the complex nature of the application. In fact, they comprise a nested set of substructures.
A raster (RST) contains the information needed to perform an actual irradiation with the GSI raster scanner, that is A raster slice (RSTSLICE) contains information pertinent to a slice of constant energy, the most important are: A raster point (RSTPNT)contains information pertinent to a particular scanner position: RST data are normally handled as part of the fields by an appropriate command, the file format is described in the appendix In addition, single RSTs can be read and written by a dedicated command, e.g. to test or apply various scan path optimizations.

Fields

Fields comprise raster data (RST) plus additional information like Multiple fields are supported, they are referenced by their identifier. Fields are handled by a command

Dose cubes

Dose data cubes hold the three-dimensional dose distribution, either physical or biological. Similar data, such as the RBE and the survival distribution are kept in dose cubes too. True dose data are normalized to the prescribed dose. When stored as files, they have the extension .DOS and are accompanied by a header (.HED) file which contains readable information on patient name, cube dimensions, et al. The data themselves are stored as binary (usually short) numbers, in the format (endianness) native to the creator. Data stored as short integers are scaled up by a factor 1000 in order to preserve precision.
Dose cubes not only appear as the result of a dose calculation, but also as an input to dose optimization to specify inhomogeneous dose prescriptions (e.g. ramps).
Dose cubes are handled by a command, the file format is described in the appendix

Plans

A plan comprises all data objects needed to describe a particular patient irradiation: For a plan to be valid (for dose optimization and calculation), the prescribed dose and possibly the target tissue type and the residual tissue type must be specified. The latter is the tissue which does not belong to a particular VOI. Plans are handled by a command.

Optimization

When the parameters of a plan (fields, dose level) have been decided, optimization of dose can be started. Several algorithms try to determine the particle intensities of the various scanner positions in the different energy slices in such a way that the resulting dose distribution matches the prescribed one in an optimum way.
  1. An iterative matching algorithm simply fixes the Bragg peaks so that they "match" the prescribed dose.
  2. if requested, this procedure is repeated with the biological dose instead of the physical alone.
  3. a conjugate gradient algorithm is used to account also for the valleys.
Optimizations are handled by a command.

Beam modelling(under construction)

TRiP98 has a subsystem to calculate its beam model. As a result, depth dose distributions and fragment spectra can be calculated and stored on file. Beam modelling is handled by a command.
This "subsystem" is currently being overhauled.

Efficiency tables

All condensed phase detectors (and maybe even gas filled chambers) respond nonlinearly to heavy ions and show saturation for high doses. This behaviour depends strongly on charge and energy of the ions as well as on the type of detector.
For our purposes it can be described in terms of either "efficiencies" or, alternatively "cross sections".
The expected signal of such detectors for verification purpose is calculated as
Signal = Factor * ( 1 - exp(-S) )
with
S = Sum( Eff(Z,E) * dE(Z,E)/dx * dN(Z,E) * 1.602189E-8 )
where Eff are "classical efficiencies" and
S = Sum( Eff(Z,E) * dN(Z,E) * 100 )
where Eff are cross sections, respectively.
The sum runs over all Z's and E's of the local particle spectrum described by dN(Z,E). The strange numerical factors account for conversion of mm=>cm or Joule => Gy.
For more details of see e.g.
Three-dimensional dose verification with x-ray films in conformal carbon ion therapy
B. Spielberger, M. Krämer and G. Kraft
Phys. Med. Biol., 48/4, 2003, 497-505 www.iop.org/EJ
Efficiency tables are handled by a command, the file format is described in the appendix

Detectors

Once the ion response of detectors is known they can actually be used for dose verification by predicting their signal output and comparing it with measurements. For this purpose detectors can be placed within a "virtual CT", e.g. a PMMA phantom. The distortion of the radiation field by the detectors are taken into account by means of their water-equivalent path length. Each detector is treated as a "micro-CT" embedded in the bigger phantom CT and either the complete micro-CT (e.g. for films) or only an average signal (e.g. for TLDs) can be calculated and stored on file.
Detectors are handled by a command, the file format is described in the appendix

Last updated:
$Id: trip98dataobjects.html,v 1.15 2015/11/03 15:54:03 kraemer Exp $
M.Kraemer@gsi.de