Project - Transport

Noisy simulated detector geometry.

About

Project - Transport is a C++11 radiotherapy Monte Carlo framework I wrote in 2012. It was written for a graduate course (MSc) in Medical Physics (Phys 539 at the University of British Columbia). There are about 5k SLOC.

Project - Transport is generally useful, but still very much 'prototype' quality. I have used it to create a virtual Computed Tomography (CT) scanner, and used the scanner to create virtual CT images of some virtual geometry. Plese note that EGSnrc, GEANT4, GPUMCD or many of the other high-quality, highly-technical frameworks should be used for "real" work. I have no immediate plans to continue development, and am not currently using it for research.

Basic Premise

At the most basic level, this framework takes a cache of particles which originate from a source, cycles through the cache sequentially, determines how far each particle should move based on an arbitrary set of parameters (typically energy and geometry), and performs one or more interactions. Each interaction might result in energy being deposited or additional particles being created. Such energy is recorded in the format desired (voxels, vector-based formats) and such particles are added to the cache. Simulation continues until the cache empties.

Some interesting capabilities have emerged from the code. For example:

  1. The “particles” need not be particles. They could also be generic radiation sources (brachytherapy seeds, MRI nucleii, etc.) or sinks (black holes, detectors, etc.).
  2. The “sources” need not be beams. They can be made to vary spatially and over a set of temporal keyframes, such as a rotating LINAC gantry head.
  3. All interactions and particles are treated using C++ polymorphism, so very little additional work is required to simulate exotic particles.
  4. All interactions are treated in a fully-relativistic manor, so the spacetime the simulation is embedded in could be changed to something more exotic.

Rationale

Why did I make this project? First, it was for an assignment. However, I also wanted a small, flexible C++11 transport framework to play with. When I sat down to design the framework, I thought it should...

  1. ...impose no constraints on the user, so long as what they want to do is physically consistent,
  2. ...be configured directly with code - not configuration files,
  3. ...be entirely modular with all components of a simulation being loaded into the simulation kernel on-the-fly,
  4. ...remain as focused as possible, offloading post-simulation analysis to helper programs where appropriate,
  5. ...be able to have modules written in the language of choice for the user,
  6. ...be fast enough to justify the choice of the simulation kernel being written in C++, but no faster.

I believe these goals were met with the exception of the first (due to time constraints.) Note that although speed was not a stated design goal, overall efficiency has been found to be suitable for the types of problems examined by your dear author. (Benchmarks are given.)

Report

I produced a lengthy technical report that may answer some questions you have. (It was not peer reviewed; it was part of the assignment and was graded.) It is available here:


Download

The entire project, including most data used to simulate photon beams of various nominal energies, is available here. References to other data sources are provided. All code is release under the GPLv3 license. Please send questions or comments to . Or, even better, send a pull request on GitHub ☺.