Maintaining in sync and updating openPMD-standard

[shervin86]

I would like to know who is in charge of maintaining the openPMD-standard fork in sync with the upstream.

We need the issue tracker also for that repository (currently missing).

Furthermore, where is the particle beam extension documented? Has this been proposed and integrated to the upstream?

[shervin86]

I have noticed that @aljosahafner is working on an openPMD extension for photon ray tracing:
https://github.com/PaNOSC-ViNYL/openPMD-standard/blob/latest/EXT_PRAYTRACE.md
and I wonder in what it is supposed to be different from:
https://github.com/DavidSagan/openPMD-standard/blob/EXT_BeamPhysics/EXT_BeamPhysics.md

At a very first glance I can see that there are quantities already defined even if not with the exact same definition. For example why one should define "wavelength" instead of "energy"? I think that one should re-use as much as possible common definitions between similar fields.
Another example is replacing "deadAlive" with "particleStatus" as defined in the EXT_Beam_Physics.

[aljosahafner]

Hey, good question. I think this was not present at the time of making the photon raytracing extension. It would be good to align everything with our modifications during the sprint as well. Some of the things with openPMD are still unclear to me, we can discuss some time soon.

[shervin86]

Yes, it can be a good thing to do during the sprint. Anyway I'm a totally newbie with openPMD, I just noticed and reported.

[aljosahafner]

I mean, during the sprint (which happened some time ago) I was using the openPMD extension that was published as D5.1. However, during the development it turned out that some modifications had to be made. They're visible here: https://github.com/PaNOSC-ViNYL/workshop2020/blob/master/demo/team3/ShadowToSimEx_notebook.ipynb line 6, saveShadowToHDF()

[aljosahafner]

@shervin86 I suggest we schedule a short meeting where we can discuss this and the database, then the situation should become clearer about everything. @ejcjason are you fine with that?

[JunCEEE]

@aljosahafner @shervin86 Yes, it would be good to have a short meeting and sort out the problems we need to solve. Maybe we can have a short meeting after the WP5 vtc on Monday?

I know LCLS people are working on it actively: https://github.com/ChristopherMayes/openPMD-beamphysics It would be nice if the PRAYTRACE and be merged with Beamphysics, thus the efforts can converge.

[shervin86]

@aljosahafner may I suggest you to prepare a set of slides, comparing the different fields you defined in PRAYTRACE and those in the beamphysics extension? The biggest part of the work should be to understand what is in common, what is not, and especially why something in the beamphysics definition is not satisfactory to your use case.

[aljosahafner]

I don't know if I will have time today (depends on the WP5 meeting length), but I will check a bit and post the differences here. After that we can discuss, ok?

[shervin86]

ok. Don't need to rush, let's just setup a meeting when you have looked at the differences. We can do it tomorrow.

[aljosahafner]

I checked a bit now, what would be the point in merging the two? The one made for photon ray tracing is made with the specific application in mind and is already compatible with existing workflows in at least 2 codes in Oasys.
If you take a look here ( https://github.com/DavidSagan/openPMD-standard/blob/EXT_BeamPhysics/EXT_BeamPhysics.md ), there are many redundant fields and many of the fields defined in photon ray tracing are missing.

For example why one should define "wavelength" instead of "energy"?

It is common to use wavelength in synchrotron experiments, that's all...

[shervin86]

Did you have time to make the detailed comparison? Can you please keep me in the loop?

[aljosahafner]

Hey, I had no time yet, I will let you know as soon as I go a bit deeper.

[aljosahafner]

Hey, I checked now. There aren't many differences in terms of physics and I am sure that photon raytracing is (will be) a subset of beamphysics extension. However, as all the openPMD things it is very poorly documented.

The way photon raytracing extension is done right now is according to the codes inside Oasys, so it is fairly straightforward to export data. I have prototyped a widget for Oasys which will do just that. There will probably be a dedicated Panosc widget panel which will include this one.

We would have to speak with the core openPMD team responsible for beam physics extension and then my photon raytracing extension could become a documented case for the application of beamphysics extension to photon raytracing. I hope this is clear enough what I mean. @ejcjason @shervin86 please propose the next steps.

[JunCEEE]

@aljosahafner It's good that there aren't many differences. Could we then use openPMD-beamphysics API with this example to directly write the output of photon raytracing data of OASYS?

[aljosahafner]

That's the goal, no? My question is how to reach it... What is the best way to end up with .write_oasys_raytrace() method in openPMD-beamphysics?