Implementation of position attribute of Fields about smilei HOT 5 CLOSED

Thank you for both reports. The attributes are indeed incorrect and will be fixed.

from smilei.

I read the standard again, and I find it very confusing. It does not specify that this is about staggering. There is a confusing way to refer to cells or elements. I would not have guessed this was about grid staggering. Can you confirm that the staggered direction must have a value of 0.5 in this attribute?

from smilei.

I have made changes locally to fix both the position issue and the timeOffset issue. Does this look ok to you?

$ h5ls -rvd Fields0.h5/data/0000001800/Bx_m | grep -4 timeOffset
    Attribute: position {2}
        Type:      native double
        Data:
               0, 0.5
    Attribute: timeOffset scalar
        Type:      native double
        Data:
               0.0785398163397448
    Attribute: unitDimension {7}
$ h5ls -rvd Fields0.h5/data/0000001800/Ex | grep -4 timeOffset
    Attribute: position {2}
        Type:      native double
        Data:
               0.5, 0
    Attribute: timeOffset scalar
        Type:      native double
        Data:
               0
    Attribute: unitDimension {7}

from smilei.

Thanks for the quick fix, looks good to me! Regarding your queston: Yes, the position attribute is related either to the stagger or to the (half) iteration when the fields are dumped. Some codes perform half iterations to make sure that the fields are dumped without offset, some codes dont and this is what is saved here. Its designed in its own variable to make sure this possibly tiny offset is always resolved numerically, even if the absolute coordinates are large values. The definition is here:

The following attributes must be stored with each scalar record and each component of a vector record:

position
    type: 1-dimensional array of N (floatX) where N is the number of dimensions in the simulation.
    range of each value: [ 0.0 : 1.0 )
    description: relative position of the component on the current element of the mesh/grid/node/cell/voxel; 0.0 means at the beginning of the mesh element and 1.0 is the beginning of the next mesh element; the same dimensionality N as in gridSpacing and gridGlobalOffset

from https://github.com/openPMD/openPMD-standard/blob/latest/STANDARD.md#mesh-based-records

In Contrast the gridGlobalOffset, which also has to be stored on every mesh record, can set arbitrary offsets for the entire grid, for example a moving window can be saved by only changing this number. Does that make sense?

from smilei.

Fixed: 12dd7db

from smilei.