Axel Huebl

additionally, we could call `absorbing` boundaries `open` boundaries as in the `fieldBoundary` namings

For particles it might not. Since the boundaries are all surfaces, `open` is used for `open surface` which is well defined what to expect (and implementation dependent on how it...

@richardbriggs @CFGrote I know Richard is currently between jobs but just a quick question: Are you already using an [`openPMDextension`](https://github.com/openPMD/openPMD-standard/blob/1.0.0/STANDARD.md#hierarchy-of-the-data-file) ID for your hydro files? Above I proposed/reserved `2`. Just...

Thank you for the quick answer! No problem, wish you good luck in the next weeks!

> Would it make sense ( I guess it would) to find a more self-descriptive enumeration scheme for openpdm flavours? yes, absolutely: we are drafting to change that in https://github.com/openPMD/openPMD-standard/issues/151

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....

> To specify custom species, the species Type extension allows: "user are free to append a free text after a colon". Is really any text allowed? (What even is text?)...

Thank you for the PR! Before we start the review, can you please rebase against the `upcoming-2.0.0` branch and squash your commits into one? so basically you do: ``` $...

@CFGrote @JunCEEE do you like to update the PR for merging? :)

VC meeting today: - after initial LAMMPS experiments, further XMD and GROMACS workflows are being explored - classic MD [atomic positions] & hybrid MD (DFT, ab initio) [additional particle attributes]...