Wrong dimensionality of default attributes

[pordyna]

Without setting the mesh position, gridGlobalOffset, gridSpacing attributes explicitly openPMD-api writes default values. This happens for example when following the First Write example. These default values are integer and not arrays with the dimension of the dataset.

See example:

 string    /data/0/meshes/dens/axisLabels                           attr   = {"x", "y", "z"}
  string    /data/0/meshes/dens/dataOrder                            attr   = "C"
  string    /data/0/meshes/dens/geometry                             attr   = "cartesian"
  double    /data/0/meshes/dens/gridGlobalOffset                     attr   = 0
  double    /data/0/meshes/dens/gridSpacing                          attr   = 1
  double    /data/0/meshes/dens/gridUnitSI                           attr   = 1
  double    /data/0/meshes/dens/position                             attr   = 0

According to the standard:

type: 1-dimensional array containing N (float64 / REAL8) elements, where N is the number of dimensions in the simulation

So I think the single integer is not standard compliant, even if the value is identical for all? This breaks my scipp reader (I know, #1716 is still waiting for me to have time to finish it). Now do I need to support the single integer or is this an actual inconsistency with the standard?

Using openpmd 0.16.1 and adios2 bp5 backend

[franzpoeschel]

Yup, this is a known issue linked with #1439. Fixing this would at least require:

1. Moving the write for required attributes to a later point (i.e. the time when its containing object is closed). They are currently initialized directly at start, but the dimensionality of the datasets is not known by that time yet.
2. Accepting missing values when parsing/opening a Series from disk: If 1. is implemented, then a partially written dataset e.g. after a crash will be missing required attributes.

Right now, the openPMD-api tries to write at least anything for the required attributes. In some way, this can be justified because "required attribute" means that the data producer must provide this information, so it's on the data producer to provide a meaningful value; we just fill in some nonsense value if it is not provided.
So no, your scipp reader does not need to support single integers (except if you want better support for datasets that are not fully standard compliant).