New Extension: BeamPhysics by DavidSagan · Pull Request #183 · openPMD/openPMD-standard

DavidSagan · 2018-02-20T05:30:29Z

This is the new proposed Beam Physics extension for describing particle beams in accelerators, storage rings, etc.

RemiLehe · 2018-02-23T04:15:15Z

@DavidSagan Thanks for your answers!
For the points on which we both agreed: could you update your pull request? To do so, you can simply create more commits on the same branch, and push them to this repository ; the pull request will update automatically.

DavidSagan · 2018-02-23T18:37:43Z

@RemiLehe

For the points on which we both agreed: could you update your pull request? To do so, you can simply create more commits on the same branch, and push them to this repository ; the pull request will update automatically.

Will Do.

DavidSagan · 2018-02-26T04:22:45Z

@RemiLehe @ChristopherMayes @ax3l @marcguetg

OK I pushed a new version based upon the discussion. Much thanks for the comments.

marcguetg

I really like the way it is now. One small comment though:

I would make the presence of either charge/totalCharge 'Required' as this would allow processing of most data even if 'SpeciesType' is not implemented.

DavidSagan · 2018-02-26T16:52:59Z

@marcguetg

even if 'SpeciesType' is not implemented

I'm not understanding this. The plan is to have the species type extension become official in the 2.0.0 standard along with the Beam Physics standard.

marcguetg · 2018-02-26T16:58:42Z

@DavidSagan

I understand, I'm just saying this duplication of information would allow a user to implement a 'light version' which is still according to specs. I agree it would be small use case, as most would use the official bindings, but still something that might be worth considering.

DavidSagan · 2018-04-09T02:07:15Z

New revision with minor typo fixes. One thing that needs to be done is reorganization of the Definitions section in conjunction with implementing Definitions section in the base standard #187.

DavidSagan · 2018-04-09T02:09:52Z

Sorry hit the close button by mistake.

ax3l

Added a few more inline notes on consistent style and markdown.

Just for consistency with existing extensions (e.g. ED-PIC please keep spellings similar. Examples:

lowercase type:, description:, example: ... in keywords
scope: for required/optional

DavidSagan · 2018-04-24T14:42:20Z

Note: There is a conflict with position and positionOffset in the base standard (#182) which must be rectified.

ax3l · 2018-04-24T14:45:19Z

@DavidSagan but you only use position and not positionOffset in this extension. Anyway, we can discuss this in an hour in detail :)

ax3l · 2019-09-13T20:41:07Z

+
+- `fileType`
+  - Type: Optional *(string)*
+  - Description: The type of data being stored in the file. If present, must be set to `openPMD`. This attribute is used in systems where different data files can contain different types of data and allows for quick identification of the what type of data is in a given file.


maybe I missed it, but isn't this already possible to be quickly identified with the base standard identifier, attribute openPMD in /?

But a non-openPMD file will not have the openPMD attribute.

I am confused how this is useful for files that use openPMD and the openPMD extension :)

It is useful for readers that can read a variety of data types including openPMD.

ax3l

This already looks very good to me. 🚀 ✨

@DavidSagan please just address the introduction section comments to unify the style with the other extension.
Then, please squash your commits into one:

git fetch --all
git rebase -i origin/upcoming-2.0.0
# change all but the first commit to "squash" instead of "pick"
git push -f

@ChristopherMayes and @RemiLehe can you give this your blessing already? :) Comments, wishes?

ax3l · 2019-11-05T18:39:44Z

+
+The `BeamPhysics` extension to the openPMD standard is meant for describing particles and fields commonly encountered in accelerator physics simulations.
+
+How to Use this Extension


We potentially do not need this paragraph on technical usage ("how specify the attribute") since the base standard explains this already.

Instead, we can write an introduction here and the requirement to co-use the extension with SpeciesType.

@ax3l I'm not exactly sure what you are thinking about here. Could you write a proposed change?

No problem, can you squash all commits first please?

ax3l · 2019-12-17T22:48:53Z

+
+where `Z` is the complex field, `f` is the Oscillation frequency, `t` is the time, and `t0` is a reference time.
+
+Software that writes complex data must use native complex storage for formats that support complex numbers. For formats that do not have native complex support (for example, HDF5), complex numbers are to be stored using subgroups labeled `r` and `i` for real and imaginary respectively. 


I would change this to:

Suggested change

Software that writes complex data must use native complex storage for formats that support complex numbers. For formats that do not have native complex support (for example, HDF5), complex numbers are to be stored using subgroups labeled `r` and `i` for real and imaginary respectively.

Software that writes complex data must use native complex storage for formats that support complex numbers.

For formats that do not have native complex support (for example, HDF5), complex numbers are to be stored using value pairs for real and imaginary component and shall follow the `h5py` convention for annotations.

Example code:

import h5py as h5 import numpy as np x = np.array([1.+2j, 3.+4j, 5.+6j], np.cdouble) x # array([1.+2.j, 3.+4.j, 5.+6.j]) x.dtype # dtype('complex128') f = h5.File('complex.h5', 'w') f['/mydata'] = x f.close()

Creates:

$ h5ls -d -r complex.h5 / Group /mydata Dataset {3} Data: (0) {1, 2}, {3, 4}, {5, 6} $ h5dump complex.h5 HDF5 "complex.h5" { GROUP "/" { DATASET "mydata" { DATATYPE H5T_COMPOUND { H5T_IEEE_F64LE "r"; H5T_IEEE_F64LE "i"; } DATASPACE SIMPLE { ( 3 ) / ( 3 ) } DATA { (0): { 1, 2 }, (1): { 3, 4 }, (2): { 5, 6 } } } } }

I think this totally works well and corresponds to what I suggest here: #29 (comment)

ax3l · 2019-12-21T03:30:30Z

Before we merge this:
Can you please provide an example file or file series that used this convention already? I would like to run it through the validator, viewer, and reference API implementations to see if the extension is fully compatible with the base standard.

…for the electric field.

ax3l · 2020-04-20T20:05:24Z

offline/zoom discussed: we don't need to squash and rebase, I will just squash & merge all PRs from now on :)

… base standard).

ax3l

The extension looks like it is in great shape. Thank you for the work on this and the contribution!

@ChristopherMayes @RemiLehe, if you confirm, I would target a merge today. Otherwise if you have further comments early next week. What do you think?

ax3l · 2020-10-16T20:26:56Z

@marcguetg just as a notification to you: we plan to merge the beam-physics extension

Looks like all points have been addressed from this review. Please don't hesitate to note if something new slipped in, in which case we can open a follow-up PR.

Ported EXT_BeamPhysics.md from other branch.

1924a90

ax3l added the EXT: BeamPhysics proposed accelerator phsyics extension label Feb 20, 2018

ax3l requested review from RemiLehe, ax3l and jlvay February 20, 2018 09:25

ax3l added this to the openPMD 2.X milestone Feb 20, 2018

ax3l added major change non-backwards compatible change minor change backwards-compatible change and removed major change non-backwards compatible change labels Feb 20, 2018

ax3l changed the title ~~New BeamPhysics Extension~~ New Extension: BeamPhysics Feb 20, 2018

ax3l requested a review from marcguetg February 20, 2018 16:58

RemiLehe reviewed Feb 22, 2018

View reviewed changes

DavidSagan added 2 commits February 25, 2018 23:10

Changes made per discussion on openPMD.

5ab0932

Minor update.

7d03aa7

marcguetg reviewed Feb 26, 2018

View reviewed changes

ax3l reviewed Apr 3, 2018

View reviewed changes

Minor typo fixes.

746f716

DavidSagan closed this Apr 9, 2018

DavidSagan reopened this Apr 9, 2018

ax3l reviewed Apr 24, 2018

View reviewed changes

Comment thread EXT_BeamPhysics.md Resolved

Comment thread EXT_BeamPhysics.md Resolved

Comment thread EXT_BeamPhysics.md Resolved

Comment thread EXT_BeamPhysics.md Resolved

Comment thread EXT_BeamPhysics.md Resolved

ax3l reviewed Apr 24, 2018

View reviewed changes

Comment thread EXT_BeamPhysics.md Resolved

Cosmetic change.

04db263

ax3l reviewed Sep 13, 2019

View reviewed changes

DavidSagan added 2 commits September 13, 2019 17:10

Small stylistic changes.

8bb8e39

Cosmetic change.

bcc45fb

ax3l reviewed Nov 5, 2019

View reviewed changes

Cosmetic change.

feeb1b2

DavidSagan requested a review from RemiLehe November 6, 2019 21:48

DavidSagan mentioned this pull request Dec 12, 2019

openPMD standard for describing particle beams. SixTrack/SixTrack#1024

Open

Added note on complex storage.

9807a2b

ax3l reviewed Dec 17, 2019

View reviewed changes

Changed standard on how complex numbers are stored.

2dcbf0b

DavidSagan added 5 commits February 5, 2020 10:13

Minor description updates.

cdc26a6

Minor cleanup.

1db9277

Change from using Bx, By, Bz to MagneticField/x, y, z. And similarly …

89c158d

…for the electric field.

Minor mod.

55a3b82

Added particleID field.

eac41ef

ax3l reviewed Apr 15, 2020

View reviewed changes

Comment thread EXT_BeamPhysics.md Resolved

Modify "id" description.

d649e31

This was referenced May 5, 2020

Rename Particle Species openPMD/openPMD-api#729

Open

Relax ID type openPMD/openPMD-api#730

Open

Removed paragraph on how to store complex numbers (this is now in the…

ec66f04

… base standard).

ax3l approved these changes Oct 16, 2020

View reviewed changes

ax3l self-assigned this Oct 16, 2020

ChristopherMayes approved these changes Oct 16, 2020

View reviewed changes

ax3l merged commit 70d06c8 into openPMD:upcoming-2.0.0 Oct 23, 2020

ax3l mentioned this pull request Dec 3, 2025

Ext beam physics #268

Closed


		The `BeamPhysics` extension to the openPMD standard is meant for describing particles and fields commonly encountered in accelerator physics simulations.

		How to Use this Extension


		where `Z` is the complex field, `f` is the Oscillation frequency, `t` is the time, and `t0` is a reference time.

		Software that writes complex data must use native complex storage for formats that support complex numbers. For formats that do not have native complex support (for example, HDF5), complex numbers are to be stored using subgroups labeled `r` and `i` for real and imaginary respectively.

	Software that writes complex data must use native complex storage for formats that support complex numbers. For formats that do not have native complex support (for example, HDF5), complex numbers are to be stored using subgroups labeled `r` and `i` for real and imaginary respectively.
	Software that writes complex data must use native complex storage for formats that support complex numbers.
	For formats that do not have native complex support (for example, HDF5), complex numbers are to be stored using value pairs for real and imaginary component and shall follow the `h5py` convention for annotations.

Conversation

DavidSagan commented Feb 20, 2018 • edited by ax3l Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RemiLehe commented Feb 23, 2018

Uh oh!

DavidSagan commented Feb 23, 2018

Uh oh!

DavidSagan commented Feb 26, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marcguetg left a comment

Choose a reason for hiding this comment

Uh oh!

DavidSagan commented Feb 26, 2018

Uh oh!

marcguetg commented Feb 26, 2018

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

DavidSagan commented Apr 9, 2018

Uh oh!

DavidSagan commented Apr 9, 2018

Uh oh!

ax3l left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

DavidSagan commented Apr 24, 2018

Uh oh!

ax3l commented Apr 24, 2018

Uh oh!

Uh oh!

ax3l Sep 13, 2019

Choose a reason for hiding this comment

Uh oh!

DavidSagan Sep 13, 2019

Choose a reason for hiding this comment

Uh oh!

ax3l Sep 13, 2019

Choose a reason for hiding this comment

Uh oh!

DavidSagan Oct 11, 2019

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ax3l left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ax3l Nov 5, 2019

Choose a reason for hiding this comment

DavidSagan commented Feb 20, 2018 •

edited by ax3l

Loading

DavidSagan commented Feb 26, 2018 •

edited

Loading

ax3l left a comment •

edited

Loading

ax3l Dec 17, 2019 •

edited

Loading