Project - Transport
is a minimal radiotherapy Monte Carlo framework written in C++. It is a CPU-only implementation. There are about 5k SLOC.
Project - Transport
is generally useful, but still very much ‘research’ quality. It has been used to create a virtual Computed Tomography (CT) scanner simulating a real, commercially available x-ray tube. The virtual CT scanner was used to create virtual CT images of a virtual geometry. Plese note that EGSnrc
, GEANT4
, GPUMCD
or many of the other high-quality, highly-technical frameworks should be used for “real” work. Also not that this software is not actively developed, nor am I actively using it.
At the most basic level, this framework takes a cache of particles which originate from a user-defined 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 simulates one or more physical interactions. Each interaction might result in energy being deposited or additional particles being created. Energy depositions are recorded in the format desired (voxels, vector-based formats) and new particles are added to the cache. Simulation continues until the cache empties.
Some interesting capabilities have emerged from the code. For example:
The “particles” need not be particles. They could also be generic radiation sources (e.g., brachytherapy seeds, distributions of radioactive materials) or sinks (e.g., black holes, detectors).
The “sources” need not be radiation beams. They can be made to vary spatially and over a set of temporal keyframes, such as a rotating LINAC gantry head.
All interactions and particles are treated using C++ polymorphism, so very little additional work is required to simulate exotic particles.
All interactions are treated in a fully-relativistic manor, so the spacetime that simulations are performed in could be changed to something more exotic.
Why does this toolkit exist? I submitted it for an assignment in graduate school. However, I also wanted a small, flexible transport framework to play with, and I wanted it to be written in at least C++11. When I sat down to design the framework, I thought it should…
…impose no constraints on the user, so long as what they want to do is physically consistent,
…be configured directly with code - not configuration files,
…be entirely modular with all components of a simulation being loaded into the simulation kernel on-the-fly,
…remain as focused as possible, offloading post-simulation analysis to helper programs where appropriate,
…be able to have modules written in the language of choice for the user,
…be reasonably fast enough to justify the choice of the simulation kernel being written in C++.
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 projects in which I’ve used this code.
I produced a lengthy technical report that may answer some questions you have. (It was not peer reviewed; it was part of an assignment and was graded.) It is available here. Note that this report is licensed cc-by-nc-sa-3.0.
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, comments, or pull requests here.