search

openPMD / openPMD-standard

:notebook: Open Standard for Particle-Mesh Data
http://www.openPMD.org
Creative Commons Attribution 4.0 International
78 stars 27 forks source link

Adding raytracing extension for X-rays and neutrons #255

Open aljosahafner opened 2 years ago

aljosahafner commented 2 years ago

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

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?

Reader Changes

How does this change affect data readers?

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

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!

DavidSagan commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

ax3l commented 2 years ago

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 :)

bussmann commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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

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 commented 2 years ago

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 commented 2 years ago

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:

And one output

What do you think?

pheuer commented 2 years ago

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 commented 2 years ago

Great, thanks for this clarification and the link!

bussmann commented 2 years ago

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

pheuer commented 2 years ago

@bussmann I had not, but this looks interesting!

bussmann commented 2 years ago

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