openPMD / openPMD-standard

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

Make "time", "dt" and "timeUnitSI" optional in basePath #161

Open DavidSagan opened 6 years ago

DavidSagan commented 6 years ago

Since "time", "dt" and "timeUnitSI" do not make sense, say, when particle positions are recorded at constant longitudinal position. These quantities should be made optional.

@ax3l: Please put this in the 2.0 project.

ax3l commented 6 years ago

Thank you for the issue!

Can you elaborate on "particle positions are recorded at constant longitudinal position". Wouldn't these positions be stored over a iteration (snapshot) that can be referred to a time again? You mean e.g. a track of a particle within a single iteration (snapshot) group?

The idea behind the absolute time reference in an iteration (snapshot) is to provide a base reference, for this iteration. Individual records in e.g. a particle can then further add offsets in time (in future versions of the standard), e.g. if one simulated in a boosted frame.

It looks to me that the use case you describe simply does not even want to store a time reference for each position, which makes indeed the base references of time confusing and wrong. Hm, maybe making them optional can indeed express that a time evolution is unknown if you really decide not to add it as a particle record.

A related issue is #141.

DavidSagan commented 6 years ago

Can you elaborate on "particle positions are recorded at constant longitudinal position". Wouldn't these positions be stored over a iteration (snapshot) that can be referred to a time again? You mean e.g. a track of a particle within a single iteration (snapshot) group?

Many accelerator physics codes track using the longitudinal position (often denoted "s") as the independent coordinate instead of time. Thus typically one would record particle positions for the coordinates of the particles as they reach some given s-position (typically the edge of an element).

The idea behind the absolute time reference in an iteration (snapshot) is to provide a base reference, for this iteration.

If, for example, the positions of multiple bunches are recorded each bunch will have its own time reference so there would not be an overall time reference for the snapshot.

Individual records in e.g. a particle can then further add offsets in time (in future versions of the standard), e.g. if one simulated in a boosted frame.

This will be needed by the Accelerator extension so if there is no provision in the base standard then, for now, I will make sure it gets in the Accelerator extension.

ax3l commented 6 years ago

That sounds like a plan. In case we get #141 implemented in 2.0 this might be able to be expressed in the base standard and we might not need this attributes at all (or at a different location).

DavidSagan commented 6 years ago

@ax3l

In case we get #141 implemented in 2.0 this might be able to be expressed in the base standard and we might not need this attributes at all (or at a different location).

Yes I agree that getting rid of these units in basePath would make the standard cleaner.

ax3l commented 6 years ago

side note: typo in timeUnitSI: "conversion factor"

DavidSagan commented 6 years ago

Also should get rid or make optional timeOffset in the "Required for each Record" section as this is related to the basePath "time" and "dt" attributes.