EGSnrc development project ideas

[ftessier]

EGSnrc scientific research projects

Add Delbrück scattering

• see PRL: All-Order Coulomb Corrections to Delbrück Scattering above the Pair-Production Threshold

Add particle polarization effects #973

• Determine impact of polarization on $\large \sigma_i$ above 1 keV, and for each particle type
• Consider EGS5 and Geant4 implementation of polarized interactions
• Add polarization sampling in the core EGSnrc routines, or as an egs++ augab extension.

Mesh transport algorithm, mesh interchange formats, etc.

• Review open mesh formats (and converters for commercial formats)
• Consider either surface or volumetric mesh (or both?)
• Develop howfar() and hownear() methods for mesh geometry
• Test mesh transport against existing geometries, e.g., meshed phantom vs DOSXYZnrc
• Test performance, increase efficiency
• Mesh geometry library and the mevegs user code  #556
• Add egs_mesh msh file parser #637

Extend electron-impact ionization (EII) to higher shells

• Review EII physics, models, and cross section data
• Review Kawrakow's model of EII
• Review EII implementation and logic in EGSnrc
• Review EII implementation in Penelope and Geant4
• Extend model to higher shells
• Verify using HVL measurements

Cherenkov radiation modelling

• Review Cherenkov physics
• Review implementation in other packages, for example Geant4
• Consider the optical part of the problem
• Propose an algorithm to implement Cherenkov radiation
• Test the algorithm against an established one, such as Geant4
• References: Zlateva et al. [1, 2, 3]

Gamma-gamma angular correlations for radionuclide emissions

• Review radionuclide and angular correlation physics
• Add angular correlations to egs++ radionuclide source
• Consider adding internal pair production angular correlations
• Design experimental tests
• Test experimental design using Monte Carlo
• Perform and analyze experimental test

Convert EGSnrc to a modern language

• Consider languages: Rust, C++, Java, Javascript, Julia, Swift, Go, Python etc.
• Consult: http://pypl.github.io/PYPL.html or https://www.tiobe.com/tiobe-index/, for example.
• Redesign data structures and overall framework and logic
• Port core functions to new framework
• Test by linking new core function with existing code; brute force and fuzzy testing by MC
• Convert EGSnrc input files to YAML or JSON and write a JSON schema for it

Investigate GPU port, considering GPU-like CPU future (AVX-512)

• Tong Xu from Carleton University has ported EGSnrc to GPU; divide calculations by interactions type
• Look into numpy/JAX (XLA) implementations (idea from @SimonBiggs)
• Python JAX/Numpy implementation of EGSnrc #658

Deep learning for Monte Carlo of radiation transport

• Electron multiple scattering step algorithm
• Variance reduction parameter selection
• Rich virtual source modelling; replace phase space sources?
• Generative tool for training data with perfect ground truth

Support GNDS cross section data format

• Enable EGSnrc cross sections to be read (on-the-fly?) from GNDS format, or a processed version
• Consider use of FUDGE (https://github.com/LLNL/fudge), GIDI (https://github.com/LLNL/gidiplus), MCGIDI and HAPI
• Ensure compatibility with atomic relaxation energy levels, radionuclide decay

EGSnrc technical projects

EGSnrc applications

• Implement region-by-region ECUT and PCUT across all EGSnrc applications
• Add parallel processing to the g application.
• Fully implement dosxyznrc in egs++
• Replace create with python implementation
• Replace statdose with plot-dose-1d.py

Fully implement beamnrc in egs++

• Review geometries that can already be built from elementary ones (discard obsolete ones)
• Validate new geometries with Fano test
• Same review for sources (discard obsolete ones)
• Define a uniform input syntax and names
• Write a schema for all inputs
• Add public x-ray tube models to geometry library
• Cast linac examples into new geometries
• Get CAD input for MLCs (remove obsolete ones)
• model MLCs as curated .gmsh files or in .stl format
• Implement motion with dynamic geometries (including MLC leaf motion)
• Commission new geometries and sources against BEAMnrc, systematically
• Avoid creating a new application, if possible!

Improve scoring tools in egs++

• Add a latch filtering object

Dynamic geometry motion in egs++

This project involves adding the motion of physical objects into the C++ side of EGSnrc (called egs++). This is essential for modelling increasingly complex scenarios, such as the internal multi-leaf collimators of linear accelerators which may move while a radiation beam is turned on. Currently, egs++ simulations don't include any time component, so it will be necessary to add a new parameter to the particle structure that tracks a time index. This time index would need to be synchronized with the existing functionality to dynamically move/rotate a source of particles. The new code would allow the user to specify in their input file a line or curve of motion for a piece of geometry, as well as rotation. Both of these parameters would be provided by giving a list of static positions/rotations, and then the code would interpolate between the points to model continuous motion. Each new particle from the source would effectively see a static geometry, since radiation movement is orders of magnitude faster than any mechanical motion. After implementing this, we would also look into how to visualize the particle tracks in 4D by adding a new dimension into the existing 3D viewing tool, egs_view.

• Add a new dynamic geometry, that allows for motion of any given geometry following a time index 0-1
• Synchronize the motion with EGS_DynamicSource
• The motion can be between any two MU endpoints, but the simulation will have to check that all times 0-1 are defined and valid
• Consider how best to handle motion of many geometries at once (e.g. MLCs)
• Possibly add a validity check routine to ensure that the geometries end up valid at all motion points
• Add visualization of the motion in egs_view, with a slider+input to scroll/type through every/any time point and stop to look closely
• Synchronize the visualization of geometry motion with tracks - this means tracks will need to include MU index

Comprehensive review of EGSnrc data files

• Density correction files against ICRU90. See supplementary data: http://bit.ly/ICRU90supplemental
• Data files in $HEN_HOUSE/data
• All pegs4 files provided in $HEN_HOUSE/pegs4
• Pegsless materials.dat file
• Examples provided with the default installation
• Spectra in $HEN_HOUSE/spectra; LARA format x-ray spectra
• Harmonize atomic relaxation data with radionuclide modelling
• Add all dosimeter materials used in radiation processing, from ICRU Report 80
• Use JAC (github.com/OpenJAC/JAC.jl) to compute molecular form factors

Include ESTAR code inside EGSnrc for on-the-fly density correction calculations

• Confirm copyright and permissions from NIST
• Translate ESTAR Fortran code into C++.
• Verify that the graphite valence electrons are handled correctly (Ernesto's version)
• Validate translated code against reference, for all elements and compounds
• Integrate code into EGSnrc initialization
• Add egs++ media inputs to specify ESTAR parameters
• Test stopping powers against SBETHE code (Salvat and Andreo, https://data.mendeley.com/datasets/7zw25f428t/1

Ionization chamber repository

• Consolidate, harmonize ~30 chamber models
• Implement pegsless materials in a chamber material data file
• Calculate volumes for all regions in all models
• Fano test all chamber models
• Clear the release with manufacturers
• Add chamber models to the EGSnrc github repository

Convert EGSnrc documentation to Markdown or other light-markup format

• Consider available formats: Mardown, reStructuredText, etc.
• Consider distribution platform: Readthedocs, Docusaurus, ghost, github.io, github wiki
• Consider LaTeX integration as a must; see Typora software and Texify (.tex.md files)
• Convert EGSnrc manuals to selected format
• Host, self-host, or distribute converted documentation
• Update citation recommendation for manual; obtain separate doi for the manuals?

Animation of EGSnrc simulations

• Determine the purpose and value of EGSnrc visual animations
• Consider integration into egs_view
• Review open formats and open source tools available currently
• Proof of principle from sequences of images, using avconv or ffmpeg for example
• Add camera animation tools and capture and export tools in egs_view
• Implement animation of dose maps in 1D, 2D and 3D, in similar fashion
• Add the ability to animate live, interaction-by-interaction, for debugging and education

General egs_view improvements

• Add a "free look" mode, where the camera can fly around the geometry and look from any position/angle
• Optimize visualization efficiency for large number of regions or tracks
• egs++ input file editor gui integration in egs_view

EGSnrc QA tests and QA automation

• Enable github Actions for comprehensive QA after each merge into develop
• Standardized egs++ input validation and linting
• Implement bats or TAP testing for EGSnrc configuration, other scripts and code

Add the ability to model multi-phase materials

• Define materials as a combination of 2 or more materials, with volume ratios
• Macroscopic transport occurs in combined material
• Microscopic interaction occurs in material selected based on volume ratios
• Example: mixture of graphite powder (90%) and resin (10%) in G347B from Tokai Carbon Corp.

Improve EGSnrc random number generators (rng)

• Default to high resolution random number generators #594
• Implement the xoshiro256+
• Implement PCG64 rng
• Implement ranlux++ generator for reference (now part of C++11)
• Implement Mersenne twister rng?
• Consider other modern rngs

EGSnrc packaging and configuration

• Create a .deb package for EGSnrc
• Create a .rpm package for EGSnrc
• Create a linux snap for EGSnrc
• Move all EGSnrc configuration to ~/.config/egsnrc/ (or $XDG_CONFIG_HOME?)

EGSnrc third-party submodules

• Create a EGSnrc/third-party directory to link to external software
• Add 3ddose_tools as a third-party submodule #906
• Add egs_brachy as a submodule
• Add the Victoria dose viewer as a submodule
• Refactor and integrate Epp application within EGSnrc

[mchamberland]

Whomever decides to tackle the dynamic geometry motion in egs++ should at least take a cursory glance at the switched autoenvelope geometry.

There are similar ideas implemented in the switched autoenvelope, which basically allows to model geometry motion in a limited way, e.g., an HDR source stepping through an applicator.

[crcrewso]

I think it's time to break out the input file modernization task. I would propose these independent steps in this order to avoid breaking changes

• Create a standard format/schema (.newinp) and a converter to convert from it to egsinp
• Create the reverse converter
• Update the compiled binaries so that if they were presented with a .newinp file they would transparently convert and then call the existing tools on the newly created egsinp file
• Update all parsers so .newinp becomes the files directly processed and .egsinp becomes the format needing to be converted.

[ftessier]

I would add a first step to write a JSON schema for the input file. Then we can read, write and validate input files written in YAML automatically, using standard yaml libraries! See #659. I would not worry to much about a converter. We can keep the existing .egsinp parser in EGS_Input and detect yaml format to branch to the new parser at run time.

[Kelvin-Ngowi]

Hi Fred I hope this email finds you well. I want to investigate the impact of source placement on dose distribution when undergoing cervical cancer brachytherapy. Besides the research needs me to use Monte Carlo simulation to model the applicator and radiation source and even the organs. Can egsnrc be the right software for this? Best regards Kelvin ngowi.

…

On Thu, Nov 7, 2024, 07:46 Frederic Tessier ***@***.***> wrote: I would add a first step to write a JSON schema for the input file. Then we can read, write and validate input files written in YAML automatically, using standard yaml libraries! See #659 <#659>. I would not worry to much about a converter. We can keep the existing .egsinp parser in EGS_Input and detect yaml format to branch to the new parser at run time. — Reply to this email directly, view it on GitHub <#790 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4RRXV7AGBBPEIAK7IZXG4DZ7LWD7AVCNFSM6AAAAABRJDK4QOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMJXGMZTKNI> . You are receiving this because you commented.Message ID: ***@***.***>

[rtownson]

Hello, please post this as a new discussion topic! Yes, EGSnrc and egs_brachy are suitable tools for this.

[nexustowers]

How about adding region labels to egs_kerma?

[rtownson]

Added in #1235 :)

[ftessier]

Added:

• Implement region-by-region ECUT and PCUT across all EGSnrc applications

[JemmeCh]

Hello!

I have a class in dosimetry and we are using EGSnrc as an educational tool. We are using simulation results to develop our understanding of radiative phenomenons in an "applied" setting. This got me very interested in the EGSnrc project and found this repository.

Right now, I'm finishing my classes to later start my research which isnt related to Monte Carlo simulations. I was wondering if I could work on modernizing EGSnrc for educational purposes (mostly the technical projects described above) during my free time (very part-time). Is this ok or do I need special permission from your team? I also wanted to know if other people already stared working on some of them.

Thank you
Jean-Emmanuel

PS: Sorry for the bad English, it isn't my first language

[rtownson]

We always welcome user contributions, you don't need special permission but we do have control on what actually ends up included in EGSnrc. It is indeed a good idea to check-in with us so that you're not duplicating effort. If you're looking to improve the user-friendliness of EGSnrc, maybe working on egs_view improvements or documentation/tutorials is a good idea. We just pushed a huge batch of improvements to egs_view on the develop branch, that will be in the v2026 release in the next month or so, so you'd want to start from there.

[JemmeCh]

Alrighty then! I was indeed thinking of improving egs_view in the future, so I will check the new update in the develop branch before starting my brainstorming for new ideas. Before that, I need to read the documentation more thoroughly so I could work on that too. Thank you for the reply!