Constant Data

[ax3l]

For data that is not changing over time, such as geometry information for detector positions or grids, one could think about a general path to store it (outside of /data/%T/, e.g., /data/constant/).

this can cause problems when only sharing a single time step of a simulation.

[mccoys]

This feature would be very much appreciated. Maybe not in the current way it is formulated.

My situation is that some species have a constant position over time (they don't move). Redefining their position at every timestep is memory-consuming. I would suggest that any record that is not defined at a given timestep should be taken from the previous timestep where it appeared. In my case, I would define "position/x" in the first timestep, but I would not define it again later.

Important note: there is an ambiguity with the current standard where "constant record" does not mean "constant over time", but "uniform over items". Thus, I would suggest to replace the "constant" word by "uniform". In a future release, the expression "constant in time" would thus not be ambiguous.

[ax3l]

My situation is that some species have a constant position over time (they don't move).

In that case it can be achieved without any change in the meta format with e.g. HDF5. Just use internal (for groupBased) or external data links via the H5L API and you can already achieve zero-data references.

[ax3l]

Constant is intrinsically free of preferring a meaning of spatially or temporally, so we define it explicitly to mean constant over all elements of a record component of a certain iteration.

For records components that are constant (for a certain iteration), replacing the record component ...

Unfurtunately, uniform is not free of a double-meaning either, e.g. uniform movement means constant speed over time, a uniform density distribution is spatially, ... So one has to choose and define (as now) in either ways.