Mixed Mesh Layouts: Same or Different Files?

[Flamefire]

When running PIC-Simulations one may also have records that are not fields. E.g. running a Photon-Scatter-Simulation with Photons (particles), Field (electron density) and Detector (2D record)

The current version of the standard (to my understanding) demands additional required attributes once the ED-PIC extension is enabled, such as currentSmoothing, which do not make sense for a detector (but may for the Field) So currently there are 2 options: Create 2 files, one with the extension and one without, which might be impractical for e.g. checkpoints or include all these pointless attributes on the Detector

I see 2 possible solutions: 1) Separate field and Detector by means of paths (meshes/fields, meshes/foobar) or 2) add an attribute to the Field, that marks it as a Field as defined in the extension. These 2 approaches may also be combined, if the attribute recursively applies to all sub-records. Then one can e.g. add the attribute only to meshes/fields and store all ED-PIC data there, and other data anywhere else.

[ax3l]

Yes that is correct and as you mentioned there are a few solutions to that.

Creating few files for different aspects of a (complex) simulation is fine, and we do that for various aspects of plugins in PIConGPU all the time for checkpoints. E.g., a particle detector should checkpoint its own internal state in its own file if necessary. The ED-PIC extension is for the internal state of the core routines of a PIC simulation, not for extensions or plugins deriving quantities in different bases from it.

In that case, a scattering detector is clearly not a particle-in-cell simulation, has a totally different layout and should therefore implement the base standard only in its own file(s) (and maybe it's own extension with additional attributes, will bring more information about realistic/useful detector settings with me after the week).

Furthermore, attributes such as #105 and the mentioned currentSmoothing should really be migrated to the species they belong to, but this is still ED-PIC specific.

[ax3l]

The current solution is that in the same basePath of an openPMD file, the same set of the openPMDversion and selected extensions need to be fulfilled.

I leave this open for the future in case we want to relax to put extensions only on sub-parts, but for now we recommend to write several files in case one wants to combine data that is only the openPMD base standard and data that is also using an extension.