Further gPMC developments

Aside from the improvements presented in chapter4, other unpublished improvements have been implemented in order to provide further capabilities, giving support for the projects presented in chapters5–7and others like [Gia+17;Ver+17].

The following is a non-exhaustive list of the extensions and improvements implemented. Minor features, bugs fixes and code refactoring are omitted.

1. Physics development mode: Extra control over parameters and additional hyper- parameters for physics benchmark and development as compilation option. Added cylindrical scorers to take advantage of the symmetric profiles often used for physics benchmark.

2. Particle source: The initial version of gPMC imported the primary protons from a single phase space file generated by a different code. This was not an ideal solution, not only because it was produced by a different code increasing the number of steps required to perform a simulation, but also because the other code did not take advantage of GPU parallelization. Also, this implied a disconnect between gPMC and the files defining treatments in the clinic. To solve this, a particle source was implemented that reads the treatment files and samples primaries employing a beam model selected by the user from several available options (see next item). The particle source was implemented in the GPU, causing a minor overhead to the whole simulation.

3.1 Monte Carlo simulations and gPMC 37

3. PBS beam models: Beam models to use in IMPT treatment simulations were imple- mented following [GLP15]. The beam model from MGH was also implemented, along others characterizing a range of beamlet widths (σ ) to support studies with several beamlet sizes(σ ). Ideal sources with zero initial σ and/or energy spread were also included. A parameter is passed to the CUDA kernel running the particle source to select the beam model to sample primaries from. All beam models present Gaussian σ and energy spread.

4. Simulation levels: The original version of gPMC disregarded the treatment hierarchy in fields, beamlets and individual protons. Four execution levels with parameters exposed to the user were implemented to select what level within the hierarchy should be simulated and how it should be reported:

• Simulate all fields and output the results.

• Simulate all fields, but output the results per field. • Simulate all fields, but output the results per beamlet. • Simulate a single field.

• Simulate a single field, but output the results per beamlet. • Simulate a single beamlet.

5. Treatment devices: Added lucite (hardcoded) range shifters and binary apertures with automatic beamlet filtering. Automatic beamlet filtering in the aperture refers to only testing those beamlets that are likely to be cropped by the aperture, speeding up the process.

6. Additional scored quantities: gPMC was extended not only to score dose to medium or water per voxel, but also other quantities that can be activated by the user:

• Energy deposited.

• Proton dose-averaged LET: A maximum allowed LET value was included at 100 keV µm−1to prevent LET spikes. LET spikes are an artifact created by the transportation of particles in a voxelized geometry in MC simulations. Near the border of a voxel, very short steps depositing a relatively high energy can cause these spikes. The maximum unrestricted LET in water is in the order of ~83 keV µm−1 [Ber+17a].

• Proton end of tracks: Accumulate the number of protons stopping per voxel. This is a more stable quantity than LET and could be employed as a surrogate to take into account high RBE areas.

• Proton spectrum: The proton spectrum can be scored with a variable number of bins per voxel for the application of prompt gamma spectroscopy to range verifi- cation. The spectrum can then be utilized to evaluate prompt gamma production cross sections [Hue+18].

7. Scoring masks: The code accepts a set of arbitrarily shaped binary masks in a cartesian grid to define a sensitive region in the scoring grid. The mask may represent the planning target, main OARs and/or a desired sensitive region. If more than one mask are passed, they are combined. This implementation allows scoring in a single structure, paving the way to score per structure and to take the structures into account during the simulation for variance reduction techniques or uncertainty levels assessment for intelligent simulation stopping. The results are given within the scoring grid, leaving 0 outside the mask and the tallied quantities inside of it.

8. Scoping mask mode: Transforms a 3D scoring grid into a linear index defined by a scoping mask. The scoping mask attribute can be attached to the scoring masks. Because there is no scoring outside the scoring mask, this option removes the voxels outside the mask by linearizing the grid, drastically reducing the necessary memory space allocated in the GPU memory. The implementation of this attribute is driven by the necessity to employ more aggressive binnings on the original scoring grid, like for example creating a scoring grid per beamlet.

9. Dose/LET matrices for optimization: Create and fill an array of n beamlets × m voxels for optimization. A scoring grid is allocated per beamlet, multiplying the memory required in the GPU. In order to maintain the memory requirements within the capabilities of the GPU, this feature can be used while scoring in arbitrarily shaped scoped regions and simulating field by field. It is therefore a mixture between a scorer and an execution mode due to its influence in other parameters.

10. Native scoring grid: Transport particles in the CT grid, but score in scoring grid, as opposed to navigate and score in the CT grid and interpolate to scoring grid after the calculation. When doing this, the interaction point were quantities are recorded becomes important due to the high impact of the CT voxel borders.

11. Random interaction point within step: Randomly use scoring position along step, as opposed to scoring at the end of the step. Scoring at the end of step causes artifacts when scoring in grids other than the CT because a step is forced at each voxel change. Therefore many interactions are recorded at the voxel interfaces. Another option would be to split the quantity to be scored between the voxels contained in the step