Open DavidSagan opened 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.
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.
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).
@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.
side note: typo in timeUnitSI
: "conversion factor"
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.
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.