Adding raytracing extension for X-rays and neutrons

[aljosahafner]

This is a photon and neutron raytracing extension for openPMD that has been developed as part of the Panosc project. It is supposed to represent the minimal set of variables to correctly save and represent raytracing simulations.

Description

This extension has been based on the BeamPhysics extension, trying to maintain functionality as close as possible. Furthermore, a working API with C++ and Python bindings based on this extension definition is in the making and will be provided when completed.
We have already created widgets for Oasys simulation package which allows for export of openPMD files. However, the scripts are based on a previous, working version of the extension.

New Components

• EXT_BeamPhysics_PRAYTRACE.md

Logic Changes

Which logic changes are conceptually introduced?

Writer Changes

How does this change affect data writers?
What would a writer need to change?
Does this pull request change the interpretation of existing data writers?

• libopenPMD (upcoming): https://github.com/ComputationalRadiationPhysics/libopenPMD/...

Reader Changes

How does this change affect data readers?

What would a reader need to change? Link implementation examples!

• openPMD-validator: https://github.com/openPMD/openPMD-validator/...
• openPMD-viewer: https://github.com/openPMD/openPMD-viewer/...
• yt: https://github.com/yt-project/yt/...
• VisIt: https://github.com/openPMD/openPMD-visit-plugin
• libopenPMD (upcoming): https://github.com/ComputationalRadiationPhysics/libopenPMD/...
• XDMF (upcoming): https://github.com/openPMD/openPMD-tools/...

Data Converter

How does this affect already existing files with previous versions of the standard?
Is this change possible to be expressed in a way, that an automated tool can update the file?
Link code/pull requests that implement the upgrade logic!

• https://github.com/openPMD/openPMD-converter/...

[DavidSagan]

So my question is if it makes more sense to merge this with the BeamPhysics extension. There is a lot of overlap. The argument for merging is that stuff like readers/writers/viewers only have to be developed for one standard. the argument against is that it makes for a bloated standard. I'm not sure what the best answer is.

[bussmann]

I would leave them as separate implementations not just because of bloating but also because of

1. Different standards for defining beam radii, divergences, etc.
2. Follow-up specific extension for each application area.

[CFGrote]

From my point of view, it's ok to keep this one as a separate standard.

[ax3l]

Thank you for submitting this.

I agree, as long as the extensions are aiming to stay compatible/composable, a separate small extension is to be preferred over merging into larger ones. This makes them easier to implement and pick only what one needs :)

If there is enough overlap in definitions, you could base your extension in the BeamPhysics extension - and require it similar as you already require SpeciesType. As you see fit :)

[ax3l]

This looks very good to me and I have little to add, before this can be merged.

We just got an interested party to add Proton-based particle tracing / Proton Radiography (cc @pheuer). I am wondering if this might be interesting to be addressed in a single extension?

• Proton Radiography Module PlasmaPy/PlasmaPy#895
• https://docs.plasmapy.org/en/stable/ad/diagnostics/proton_radiography.html
• https://scott.cikeys.com/prad/

We could also merge the current one first and improve upon it in a follow-up pull-request, but I would like to your initial thoughts first.

[ax3l]

Thanks a lot!
Can you please cross-link this extension in STANDARD.md? :)
Here is the corresponding location:
https://github.com/openPMD/openPMD-standard/blob/upcoming-2.0.0/STANDARD.md#domain-specific-extensions

[aljosahafner]

I pushed a new commit to add the Raytracing extension to the list of domain specific extensions

[bussmann]

Protons and X-rays in the cases you consider so far are fairly similar.
Yet, photons could carry phase, while protons don't. One could think of exploiting properties of particles in the future (neutrons, electrons) that at first order can be dealt with using raytracing, but might feature additional properties important for the result.
So, a common raytracer is handy if and only if you are aware of these additional opportunities and how to handle them by properties (energy, momentum, phase, charge, spin).

[pheuer]

@ax3l @bussmann

I think the main distinction is that, for our charged particle tracing simulations, we want to store the two inputs (the 3D field mesh and the particles list) and the output (synthetic radiograph) in separate files. That's desirable because particle lists represent sources (corresponding to a particular target and facility, say) while field meshes represent a particular experiment, so there's a natural case to keep one fixed while changing the other.

[bussmann]

@pheuer @ax3l , correct. Thank you for pointing this out.

I thought avout this a bit...

One very important commonality is that if you take a description of a target, it can potentially include both field / mesh data and particle data as input.

Both are assumed to be unchanged by the probing/ scattering by the probe particles (photons, neutrons, protons, electrons, positrons, ...).

Now, raytracing can assume temporal change of the material during the tracing, given this change is available in the material description, but a fixed material description is also possible.

Now, what is left is

• What field / density / ... mesh information is needed to compute the scattering?
• What target particle information is needed for the same purpose?
• What are immutable and mutable information stored for the probe particles (charge, spin, phase, wavelength, energy, momentum)
• What are the physical quantities needed to compute a realistic detector response?

I hope I didn't forget anything (not including all parameters defining a specific scattering setup such as scattering geometry, particle flux density, detector information, etc.).

Love to hear if that could be a way to unify raytracing.

Best, Michael

[pheuer]

I think I may have confused things with the word 'target': what I meant was the source of the protons we are tracing. The initial positions and velocities of the protons characterizes that source (maybe a TNSA source or something). That's why I'd like to keep the source particles in a separate input file, which might in theory be distributed by facilities based on known characteristics of their sources. The detector characteristics would also ideally be specified elsewhere for similar reasons.

We actually don't do collisional scattering calculations yet (the regular E&B scattering just requires the E&B fields). Collisional scattering/stopping is on my future ideas list, likely using a scalar density mesh. Time-varying meshes is also on the list but isn't included yet.

I think the biggest difference is that I'm talking about input files for the simulation (for now) whereas I think you're talking about a format for saving the output?

[bussmann]

Hi,

I think one has to provide separate Inputs for sources, targets and detectors. A full scattering setup includes all of the above. The detector part could be further separated into the scattering signal and the detector description/simulation itself, as the detector simulation must use the scattering Signal.

This leaves us essentially with four main inputs:

• probe / source
• target / material
• geometry
• time / duration

And one output

• scattering signal (spatial, temporal, phase, spin,...)

What do you think?

[pheuer]

I think that's a good high level overview: here's what those data would look like for us:

probe/source
1D arrays of particle initial positions, momenta, charge and mass (although we currently require all particles to be the same species to simplify the particle push).

target/material
3D arrays of E&B vector fields, plus maybe mass density and material if you want to do collisional scattering and stopping.

geometry
Source position (should be ~ the mean of the particle positions), detector position, detector orientation. We specify the detector orientation with two vectors in the detector plane, originating at the center of the detector.

time/duration
We don't currently store this: the simulation just runs until all the particles have passed through the simulation grid. But, it would be easy enough to store a 1D array of the timesteps. It could then be allowable to save the positions of particles at multiple timesteps throughout the simulation.

output
We return the particle positions and velocities, with all particles advanced to the detector plane. The synthetic detector then uses this information to create 2D histograms at different proton energies.

Edit: the particle tracing algorithm at PlasmaPy will eventually be folded into a framework I'm calling 'Path Integrated Diagnostics', which encompasses various diagnostics that use this sort of common geometry: https://plasmapy--1123.org.readthedocs.build/en/1123/ad/diagnostics/path_integrated_diagnostic.html

[bussmann]

Great, thanks for this clarification and the link!

[bussmann]

@pheuer , I assume you are aware of PaNOSC/VINYL:
https://github.com/PaNOSC-ViNYL

[pheuer]

@bussmann I had not, but this looks interesting!

[bussmann]

Great to hear, they are long term openPMD fans ;-)