Commissioning

System configuration file

The configuration file contains the specifications of the computing environment, the preferences of the users and much more. IDEAL cannot run without these specifications. The standard location of the system configuration file is cfg/system.cfg relative to the installation directory of IDEAL.

The syntax of the configuration file is similar to what is found in Microsoft Windows IN files. The configuration is divided in [sections] which contain lists of settings of the form label = value. The labels are case insensitive. The example system.cfg file provided with the IDEAL source contains many explanatory comments that should help the commissioning user to define the correct values.

[directories]

input dicom

Full path of the top directory for finding DICOM input data. This is mainly used by the research GUI, to position the starting location for the input file browser.

tmpdir jobs

Full path of the “work directory” on the shared disk of the cluster. For each IDEAL job, a subfolder will be created in this directory to store all the job specific data, including the intermediate and final results of the cluster subjobs. Upon successful completion of the job, most of the bulky data in the subfolder will be compressed, but not deleted.

first output dicom

Full path of the output directory on the shared disk of the cluster. For each IDEAL job, a subfolder will be created in this directory to store the final output (DICOM dose files and a text summary of the job).

second output dicom

Full path of the directory on an external file system (typically a Windows file share, mounted with SAMBA). The for each job, a copy of the output subfolder is stored here. This setting is optional: leaving this option empty avoids the copy.

logging

Full path of the logging directory. For every IDEAL command, a logging file with all debug level logging output will be stored here.

commissioning

Full path of the so-called “commissioning” directory. This contains site specific calibration and modeling data, such as beam models and HLUT tables, which are described in more detail below.

[mc stats]

There are three possible statistical goals for an IDEAL job: “number of primaries”, “average uncertainty” and “maximum runtime”. The ranges of allowed values and the default values of these goals are specified here, as well as which goals are enabled by default. This information is primarily used by the GUI.

Four values should be specified for each goal, to specify the minimum, default, maximum, and stepsize value, respectively. All values should be positive and the default value should be within the allowed range. It is recommended to choose the stepsize identical to the minimum value. For the goal(s) that should be enabled by default, the word “default” should be put at the end of the configuration line. At least one goal should should be enabled.

For instance:

n minutes per job   =    5        20      10080    5
n ions per beam     =  100   1000000 1000000000  100   default
x pct unc in target =    0.1       1.        99.   0.1

In this example, by default the goal is to simulate 1000000 primaries. The valid values for the number of primaries are in the range from 100 to 1000000000, and in when a GUI user clicks to increment or decrement, then the stepsize is 100. Since Gate uses a signed integer to count primaries, the maximum should be less than the number of cores in the cluster times 231-1=2147483647.

The average uncertainty in the target is defined as the average of the relative uncertainty in the voxels that have a dose larger than the a configurable fraction of the mean dose maximum. We are not using the absolute dose maximum in a voxel, since this tends to fluctuate too much. Instead we find the N highest dose values in the distribution, the mean of those values is the “mean dose maximum”. The number N should be be configured in the system configuration file like this:

n top voxels for mean dose max = 100

The fraction of this “mean dose maximum” that serves as the threshold to mask the voxels that should contribute to the “average uncertainty” is configured like this:

dose threshold as fraction in percent of mean dose max = 50.

In this example configuration, the “mean dose maximum” is computed from the 100 highest dose values and the threshold is set at 50% of that maximum mean dose.

[simulation]

number of cores

This is the number of cores that will be used to simulate a single beam. On a small cluster you will typically set this to the total number of available cores. On a medium/large cluster (>100 cores) you could set it to a smaller number, for instance if you would to leave cores free for other use, if you would like to have several simulation jobs run in parallel or if for some reason there is limited disk space available for the temporary job data (depending on dose grid size, up to a gigabyte per core).

number of threads

As GateRTion v2 supports multithreading, you can specify on how many threads each simulation will be split.

hyper threading

True or False. If True, the simulation will use double the number of threads.

remove dose outside external

Outside the external (in the air, typically) the dose is about the same as inside, but most TPS never show this. If you set this option then IDEAL will mask the final dose output, all voxels outside of the external are forced to have dose equal to zero. This is e.g. useful to avoid artifacts in gamma analysis.

gamma index parameters dta_mm dd_percent thr_gray def

Parameters for gamma index calculation. These values are only used if the run gamma analysis field in the output options section is true. IDEAL will try to compute the gamma index distribution with the TPS dose as the reference image, but only for the voxels that have a dose above a given threshold.

  • dta_mm: distance parameter in mm

  • dd_percent: relative dose difference parameter in percent

  • thr_gray: threshold value in Gray

  • def: default gamma value for target voxels with dose values below threshold

htcondor next job start delay [s]

When HTCondor “stages” the GateRTion jobs (starts the jobs on the calculation nodes), it starts them not all at the same time, but rather with a small delay between each job and the next. This is done on purpose, because all jobs will start by reading lots of input and configuration data. We want to avoid or at least reduce the stampede effect in which all these read requests are clogging up the network. The best value for this delay needs to be found empirically on your network. On a fast network (and with fast network cards on all nodes), that is 10Gbit/s or faster, with about 50 physical cores, 1 second delay seems enough, but on a slower network, e.g. 1Gbit/s, it is advisable to choose a larger delay, for instance 10 seconds.

minimum dose grid resolution [mm]

The user can configure a dose resolution that is different from the TPS dose resolution by changing the number of voxels. Too fine grained resolution will be costly on resources (RAM, disk space) so there is a limit for this, defined by the minimum size that a dose voxel should have in each dimension.

This may not be the optimal way to guard against resource overusage, but it’s simple and intuitive. In later releases we could define other safeguards, maybe a maximum for the total number of voxels in the dose distribution.

use SPR approximation

If True, the DoseActor will not calculate the stopping power ratio (used to score dose to water) at every step, but it will use an approximation. Specifically, the SPR is considered constant with the particle energy and it is calculated only once for each interacting particle type and voxel’s material combinations. The approximation is used only for energies higher than the value configured in SPR transition energy [MeVn]. Enablying this option will speed up the simulation, but the accuracy of the result will be affected. It is up to the user to define appropriate reference and transition energy values.

SPR reference energy [MeVn]

Energy value used for the calculation of the SPR, under the constant SPR approximation.

SPR transition energy [MeVn]

When use SPR approximation = True, the fast calculation will be performed only for particles with energy higher than this value.

Output options

IDEAL allows the user to score physical and biological dose, as well as other quantities like LETd and intermediate outputs of the RBE calculation. The dose distribution can be saved in several stages of the calculation and in various formats. You can configure which quantities and in which format you would like to have:

  • research quantities: let,alpha mix,beta mix. These intermediate output quantities will be saved to DICOM files, if the resource flag is set to true.

  • run gamma analysis : if true, run and write gamma analysis result to MHD format.

  • write mhd unscaled dose: sum of the dose distributions from all simulation jobs, computed in the CT geometry (cropped to a minimal box around the TPS dose distribution and the External ROI). Since the total number of simulated primaries is much smaller than the total number of particles planned, this dose is much lower than the planned dose. This dose can be useful for debugging purposes and if this option is set then this dose will be exported in MHD format.

  • write mhd scaled dose: this is the unscaled dose multiplied with the ‘(tmp) correction factor’ (see below) and with the ratio of the number of planned particles over the number of simulated particles. For example, if the correction factor is 1.01, 1011 particles were planned for each of 30 fractions, and 108 particles were simulated, then the scaling factor is 30300.

  • write mhd physical dose: this is the scaled dose, resampled (using mass weighted resampling) to the same dose grid as the TPS dose distribution. Saved in MHD format.

  • write mhd plan dose: Compute the plan dose (sum of physical and/or RBE beam doses) and save in MHD format.

  • write mhd rbe dose: for protons, the “Relative Biological Effect” dose is estimated by mulitplying the physical dose by the RBE factor for protons setting (typically 1.1). For carbon ions, RBE is calculated according to the RBE model specified by the user in the “physics” section. Saved in MHD format.

  • write mhd let : calculate LETd distributions, for all beams of the beamset, and save to MHD format.

  • write dicom physical dose: this is the scaled dose, resampled (using mass weighted resampling) to the same dose grid as the TPS dose distribution. Saved in DICOM format, for each beam of the beamset.

  • write dicom plan dose: Compute the plan dose (sum of physical and/or RBE beam doses) and save in DICOM format.

  • write dicom rbe dose: Save the RBE dose (for protons and cabon) in DICOM format.

  • write dicom let : save the LETd distribution to DICOM format. This option is overwritten to True, if the research flag is set to true, and the quantity is listed in research quantitites.

  • write dicom alpha mix : write alfa mix to DICOM format. This option is overwritten to True, if the research flag is set to true, and the quantity is listed in research quantitites.

  • write dicom beta mix : write beta mix to DICOM format. This option is overwritten to True, if the research flag is set to true, and the quantity is listed in research quantitites.

  • write dicom survival : write survival to DICOM format. This option is overwritten to True, if the research flag is set to true, and the quantity is listed in research quantitites.

  • write uncertainty : save dose calculation uncertainty image.

  • research flag : if True, all the output listed in research quantities will be calculated and saved to DICOM format.

[physics]

proton physics list

Geant4 physics list for protons. Recommended setting: QGSP_BIC_HP_EMZ

ion physics list

Geant4 physics list for protons. Recommended setting: QGSP_BIC_HP_EMZ

max step size patient

Maximum step size in the patient CT volume

max step size phantom

Maximum step size in solid phantom geometry (used for phantom simulations)

apply limits to

Specifies to which particle types the step limiter will be applied to.

production cut gamma [mm]

Production cut for gammas.

production cut electron [mm]

Production cut for electrons.

production cut positron [mm]

Production cut for positrons.

production cut proton [mm]

Production cut for protons.

rbe factor protons

RBE factor for protons. Conventionally set to 1.1.

rbe model carbons

RBE model to be used for biological dose calculation for carbon ions plans. Available models are mMKM or LEM1 low dose apprximation (LEM1lda). The RBE model specific parameters can be specified in the RBE_parameters.cfg file, in the data folder of IDEAL.

[(tmp) correction factors]

The computed dose distribution for a given treatment plan may need to be corrected by a constant factor to correct for a normalization error that can be due to various causes. Typically this factor is determined using plans and absolute dose measurements on (water) phantoms. In future releases of GateRTion this correction factor will be integrated in the beam model, hence the ‘(tmp)’ in the section name. The correction factor can be defined for each beam line and each radiation type separately, using “TreatmentMachineName RadiationType” as the label and a floating point number (typically close to 1.0) as the value. For combinations of beamlines and radiation types that are not explicitly configured, the “default” value will be used. The radiation type is “proton” for protons and “ion_Z_A_Q” for ions, where Z is the number of protons, A is the atomic number (number of protons plus number of neutrons) and Q is the electric charge of the ion in units of e. The radiation type for carbon ions is ION_6_12_6 and for helium ions it is ION_2_4_2. For example:

default = 1.0
IR2HBL ION_6_12_6 = 1.0
IR2HBL proton = 0.97371
IR2VBL proton = 1.00
IR3HBL proton = 0.97371

[msw scaling]

This section can be used to define an energy dependent scaling of the msw of each spot in the treatment plan. The user defines the scaling by providing the polynomial parameters of p(E) in descending order, where msw’(E) = p(E) * msw(E). The correction factor can be defined for each beam line and each radiation type separately, using “TreatmentMachineName RadiationType”

as the label. For example:

default = 0.0 1.0
IR2VBL ION_6_12_6 = 0.0 1.0
IR3HBL ION_6_12_6 =  1.81847493e-09 -1.69699096e-06  3.62323835e-04  9.82505461e-01

[condor memory]

For typical IDEAL jobs, all core will be used. But for calculations with a large CT, high resolution dose distribution and/or many pencil beams, the RAM usage each Gate process can be so high that it’s better not to run on all cores. An IDEAL job submission to HTCondor includes a “memory request”. This will do two things:

  1. HTCondor will assume that the job is going to use the requested amount of RAM at some point during the run. In order to avoid oversubscribing the RAM and cause swapping, HTCondor will not start running any new jobs if the sum of the requested amounts of RAM would exceed the available RAM.

  2. If a running job uses more than the requested amount of RAM for a too long period of time, then that job will be killed or set on hold by HTCondor (the exact policy details can be configured in the HTCondor configuration files).

You can specify a minimum, default and maximum value of the memory request, in units of megabyte. IDEAL makes an estimate of the required RAM with a simple linear formula: RAM = offset + cA*A + cA*B + .... Here A, B are quantities that are expected to impact the memory usage of the Gate simulation, such as the number of dose voxels, number of CT voxels and the number of spots. The estimate will be different for CT and for phantom simulations (because the phatom does not have “CT voxels”), and for different particles (the cross section tables, which are responsible for an important part of the RAM usage, are significantly larger for carbon ions than for protons). The linearity coefficients (cA, cB, etc.) can be set by the user, based on system observations during a series of test runs with differently sized CTs, phantoms, dose resolutions and plans. The values given in the example below may be a good starting configuration for your local cluster, but may need tweaking depending on the available RAM and other factors.

Example configuration:

# how much memory should condor allocate per job?
# Condor uses the unit "MB", which might mean either 1024*1024 bytes or 1000*1000 bytes.
condor memory request minimum [MB] =  7000
condor memory request default [MB] =  8000
condor memory request maximum [MB] = 50000
condor memory fit proton ct = offset 1200 dosegrid 2.5e-05 ct 1.8e-06
condor memory fit proton phantom = offset 500.0 dosegrid 2.0e-05 nspots 0.0060
condor memory fit carbon ct = offset 1800 dosegrid 5e-05
condor memory fit carbon phantom =  offset 1000.0 dosegrid 8.0e-06
# if e.g. a proton plan gets a dose grid of 200*200*200=8e6 voxels and a ct with 16e6 voxels
# then the memory fit gives 1200 + 8e6*2.5e-5 + 16e6 * 1.8e-6 = 1428.8 MB estimated max RAM usage

[materials]

Everything about materials and material overrides.

materials database

With this setting the basename of the material database should be specified. IDEAL then expects to find a file with this name in the material subdirectory of the Commissioning Data Directory. This file can just be the standard database file GateMaterials.db that is included in the source code package for Gate and defines a large number of materials that are important typical Gate applications but are not included in the standard set of Geant4 materials. The Gate material database is a simple text file, which you can extend with any additional materials that are relevant in your clinic. It is recommended to give such an extended database file a name that makes it clear that this database is different from the standard material database file. E.g.:

materials database = MyClinicalMaterials2020.db
hu density tolerance [g/cm3]

The Schneider 2000 method is used to convert Hounsfield Unit (HU) values to materials, based on a density curve and a material composition table (see section CT protocol Hounsfield Lookup tables). For each new combination of density and composition Geant4 needs to define a new material. The density tolerance value defines the maximum difference between two “equivalent” density values. The full range of HU values is segmented in intervals such that the densities within each interval are equivalent to each other, and only one material defintion is associated with each interval.

Override materials

You may sometimes want to override the material in a region of interest (ROI) in a CT with a particular material from the database, to be used by Gate/Geant4 instead of the materials given by the Schneider tables. A typical use case for this is that in a CT of a water phantom, the volume of the phantom is overridden with G4_WATER, the standard Geant4 definition of water. For all materials that you expect to use for such overrides (Geant4 materials or materials that you provide in the material database file, see above), you should add a line in this section of the system configuration file that associates the name of the material with a density (in units of g/cm3). For instance:

G4_WATER = 1.0
G4_AIR = 0.00120479
G4_GRAPHITE = 2.21
G4_STAINLESS-STEEL = 8.0
G4_ALANINE = 1.42
PMMA = 1.195
Tungsten = 19.3
G4_Ti = 4.54

It would be nice if you only needed to give the list of the names of the allowed materials and that IDEAL would figure out the densities somehow from Geant4’s and Gate’s databases. This may be implemented in a future release, hopefully. For now, you just need to make sure that the density values that you give here are consistent with what the Gate and Geant4 databases are using.

[user roles]

This is the list of users that are expected/allowed to use this installation of IDEAL in a particular role. For users with more than role you need to add one line per role. Each line is of the form ACRONYM, username = role. Here username is a name without whitespaces that contains part of the name of a user plus a word that indicates the role. ACRONYM is a short version of the user name, for instance just the user’s initials. The role can be clinical, commissioning or admin (see Intended Users). Each username and acronym should be unique.

For instance:

OKE, obiwan = clinical
OKE_A, obiwan_admin = admin
OKE_C, obiwan_commissioning = commissioning
LSK, luke = clinical
LSK_C, luke_commissioning = commissioning
LES, leiha = clinical
HSO, han = clinical
DVA, darth = commissioning
YOD_A, yoda_admin = admin
YOD_C, yoda_commissioning = commissioning

RBE configuration

IDEAL currently supports two RBE models: modified MKM (mMKM) and LEM1 low dose approximation (LEM1lda). The models can be used for RBE calculation of generic ions. For protons, IDEAL assumes a constant RBE of value 1.1. Each model is configured with a model specific set of parameters, that are defined in the RBE folder of the commissioning data directory. The folder should contain:

  • RBE configuration file. An template of this file is generated by IDEAL at installation, and is located in the MyClinicCommissioningData\RBE folder. The content of the file is described below.

  • RBE tables in .txt format. The tables shall be provided by the user.

[mMKM]

  • cell_type = HSG

  • alpha_ref = 0.764

  • beta_ref = 0.0615

  • F_clin = 2.41

  • rbe table : file name of the dose-averaged saturation-corrected specific energy z_1D(Z,E) table. The file should be placed in the same folder as the RBE configuration file.

  • survival_ref : If a reference survival fraction is provided, it will be used to calculate the RBEwDose.

[LEM1lda]

  • cell_type = Chordoma

  • alpha_ref = 0.1

  • beta_ref = 0.05

  • D_cut = 30.0

  • rbe table : file name of the intrinsic coefficient α_z(Z,E). The file should be placed in the same folder as the RBE configuration file.

  • survival_ref : If a reference survival fraction is provided, it will be used to calculate the RBEwDose.

API configuration file

To be able to use the IDEAL API interface, the user must customize the api.cfg file, in the cfg folder. The file has two main sections:

[receiver]

send result

true or false. If true, the log_daemon will attempt to send the results back. This assumes that there is a ‘receiving’ API running on the client.

an example of such an API can be found in receiver_test.py in the IDEAL’s main directory.

url to send result

e.g. http://127.0.0.1:3000/api/results

url authentication

e.g. http://127.0.0.1:3000/auth. The API uses login data.

[server]

IP host

IP address of the server

credentials db

.db file containing the authorized users login data and information.

ssl cert

path to the ssl certificate, if needed

ssl key

path to the ssl key, if needed

The API runs by default on the https protocol. Therefore, a self signed certificate and related key should be generated. The API can also run on http, with small modifications to the bin/api.py file. In this case, the ssl certificate and key are not needed. For more info, read the dedicated section on the user manual.

[logging]

logfile

path of the API log file

severity

debug level (e.g. INFO, DEBUG etc…)

Log daemon configuration file

Starting from version 1.1, IDEAL keeps track of all the simulations that have been started, in a global log file. The user has the possibility to have a real time overview of the status of each simulation by launching the log_daemon.py program, from the bin folder. The program runs in the background (hence ‘daemon’) and is responsible for the following tasks:

  1. write and update a ‘cfg_log_file’, which reports, for each simulation:

    • submission date and time

    • working directory path

    • IDEAL status

    • condor id

    • condor status, in terms of how many jobs are running, idle, on hold and completed

  2. zip the working directories of simulations considered ‘hystorical’ and archive them.

  3. in case the user has configured IDEAL to run via the API interface, the daemon is responsible to send back the simulation results, once the simulation is complete.

After installing IDEAL, the user should take care of customizing the log_daemon.cfg file, in the cfg folder.

[Time variables]

historic after

time (in seconds) after which a job is considered hystorical. After this time, the working directory is zipped and moved to “old”.

unsuccessfull after

time after which a job is considered UNSUCCESSFULL after being removed from the condor queue. When a job doesn’t appear anymore in the condor queue, it is one of two cases. Either it was successfully terminated, or it failed, possibly for reasons related to the cluster management.

When a job doesn’t appear in the queue anymore, and after a time equals to the ‘unsuccessfull after’ it is not yet completed, it is marked as unsuccessful.

on hold untill

time that a job can be on hold before being considered UNSUCCESSFULL

running_freq

time (in seconds) between two successive updates of the cfg_log_file

[Paths]

global logfile

path of the global log file. This file will be created by IDEAL, if it doesn’t exist yet.

cfg_log_file

path of the cfg_log_file. This file will be created by IDEAL, if it doesn’t exist yet.

log_daemon_logs

path of the log_daemon.py logs. It is reccommanded to use the same logging directory used by IDEAL.

completed_dir

directory to archive successfully completed jobs

failed_dir

directory to archive failed job

logs_folder

same path as the IDEAL logs

api_cfg

path of the API configuration file

syscfg

path of the system.cfg file

Dictionary of possible condor job status:

submission_err = SUBMISSION ERROR
unsuccessfull = UNSUCCESSFULL
done = DONE
killed_by_log_daem = KILLED BY LOG DAEMON
checking = BEING CHECKED

Beam line modelling

The beam modelling information stored under the beamlines subdirectories of the Commissioning Data Directory. For each treatment machine in the clinic, a subdirectory to the beamlines directory should be created, with the name equal to the same treatment machine name that is also used in DICOM plan files.

One special beamline directory is common, which can contain specifications (of nozzle components or generic passive elements) that can be used in all beamlines. Subfolders can be created under common to organize the resources.

A beam line model is identified by the combination of the nozzle geometry and the source parameters description. This is reflected in the beam line configuration file, which has two sections: geometry_details and source_details. An additional section, from_lut, allows the user to specify if the source parameters are provided as look up tables (LUT) or as energy-dependent polynomial coefficients.

The name of the beam line model file should be of the form <TreatmentMachineName>_<RadiationType>.json. For instance, for a beamline named IR2HBL that can be used both for protons and carbon ions, two beam line model files should be provided, named IR2HBL_PROTON.json and IR2HBL_ION_6_12_6.json, respectively.

The beam line model configuration, as well as the nozzle geometry configuration, are defined in JSON format. This file format supports nested data structures, which allows to easily export/import data in Gate 10. For example, a hierarchy of Gate volumes, each with its properties (material, size, etc…), can be defined in a JSON file, which is used by Gate to set up the volumes in the simulation.

Geometry details

In this section of the beam line model, the user specifies:

  • nozzle_directory : the path of the folder containing the geometry configuration files. This can be for instance the common folder.

  • nozzle_file_name : the file name of the nozzle geometry configuration file .

  • range_shifters : the list of Range Shifters available for the beamline.

  • range_modulators : the list of Range Modulators available for the beamline.

The nozzle geometry file, as well as the files describing the geometry of the passive elements, should be located in the nozzle_directory. All geometry configuration files should be in JSON format, and contain a list of “volumes”. Each volume is parametrized as if it was a volume object in Gate. The nozzle geometry is rotated by IDEAL according to the gantry angle defined in the treatment plan. Specifically, IDEAL applies a rotation around the z axis in Gate coordinates, which correspond to a rotation around the y axis in the IEC fixed reference system. Therefore, it is reccommended to define the nozzle volume along the y axis in Gate coordinates (nozzle at gantry angle 0 degrees). As the positive y axis points toward the ground, the translation of the nozzle should be applied in the negative y direction. The advantage of this apporoach is that the same nozzle geometry can be in principle used for different fixed beamline, as well as for a gantry beamline.

Source details

This section allows the user to specify the parameters that are used by Gate to define a TreatmentPlanPBSource. See Gate documentation. The parameters include:

Geometrical parameters:

  • nozzle to isocenter distance (source to axis distance)

  • distance steraing magnest from the isocenter

Pencil beam energy dependent parameters:

  • optical properties (beam size, angular spread, emittance, convergence)

  • range properties (energy offset between generation and isocenter, energy spread)

  • monitor unit calibration

The source parameters can be either defined via look up tables, where each energy is associated to a parameter value, or via the coefficients of the polynomial interpolating the enrgy-parameter curve. Examples of both configurations can be found in the MyClinicCommissioningData directory.

The procedure for fitting a pencil beam model for Gate is described in [FuchsBeamlineModels2020]. The scripts that were used for that publication are (at the time of writing these docs) not yet open source.

The source_details section also includes a beamline_name entry. This entry will be used by IDEAL to match the treatment machine defined in the DICOM RT plan to the correct beam line model.

CT protocol Hounsfield Lookup tables

The Commissioning Data Directory should have a CT subdirectory. This directory contains the hlut.conf configuration file and three subdirectories, density, composition and cache.

The hlut.conf configuration file describes for each CT protocol which DICOM tags and values should be used to recognize it, as well as how to convert the HU values to materials. This text file should be edited by the commissioning physicist to provide the data for each of the relevant CT protocols in the clinic where IDEAL is installed.

There are two different ways to define the conversion from HU to materials.

  1. For [Schneider2000] type conversion, provide the names of density and composition text files, which are expected to be found in the respective subfolders.

  2. Provide a direct HU-to-material conversion table. A list of HU intervals can be given, and for each interval the name of the material is specified. This can be either a Geant4 material (e.g. G4_WATER) or a material that is defined in the GateMaterials.db file (e.g. PMMA).

IDEAL will not directly use these tables. Rather, for every new combination of density, composition and density tolerance value (usually set in the system configuration file) it will generate a new material database and an interpolated HU-to-material table, in which it associates HU intervals directly with a material from the the new database. The HU intervals are chosen just small enough such that the steps in density between the subsequent materials are less than the density tolerance value. These generated tables are stored in a cache folder CT/cache and will be reused in following IDEAL jobs with the same combination of CT protocol and density tolerance.

Phantoms

In the phantoms subdirectory of the Commissioning directory you can define the phantoms that may be used in IDEAL simulations, instead of the CT image, for instance to simulate patience specific quality assurance (PSQA) measurements.

As for the nozzle geometry, the phantoms are configured via JSON files. A user can define as complex phantom geometries as he/she wishes, by providing a list of volumes in the configuration file. Additionally, the user defines a list of actors. This usually include a DoseActor, attached to one of the phantom volumes, but could in principle be any other type of actors. Example can be found in the MyClinicCommissioningData/phantoms folder.