Dumped data axis order

[skuschel]

I have some h5 output dumps, written by PIConGPU and tried to postprocess them. I am slightly confused, because
h5['/data/16000/fields/FieldE/x'] tells me that the shape is in my case (40000, 2000), BUT
h5['/data/16000/fields/FieldE/x'].attrs['_size'] returns (2000L, 40000L, 1L)
so x and y are swaped?
My Question acutually aims to: Where can I find the correct Grid for the data in general and particularly if I have a moving window?

[skuschel]

I went through the data again checking total extents of the domain along different axes and it seems to me that PIConGPU writes all kind of Field data (E's, B's, Densities,...) with a weired axis order: y, x, z. Is that on purpose?

[ax3l]

@skuschel yes you are reading an internal attribute of libSplash which is indeed stored in the wrong order: ComputationalRadiationPhysics/libSplash#162

the order in _size and _offset is indeed inverted and uses x,y,z and should be as the other attribute z,y,x. I don't see a y, x, z order, can you pls double-check that?

The next release of libSplash, version 1.3.0, will change this internal value. Please use the public .shape() attribute of h5py instead.

The offset for moving windows can be taken from the second internal attribute, _offset, which refers to the global window's offset + global domain's offset in dump files. In easier words: it's the offset you see due to the moving window for the full field.

(in checkpoint files, which I do not encourage you to use for analysis, the whole domain and not only the window is written out making this offset only the global domain offset. These are our naming conventions in PIConGPU when talking about subsets, sizes and offsets. libSplash does not yet use exactly the same namings.)

[ax3l]

Regarding the upcoming change of this value: I will introduce the upgrade of PIConGPU to use OpenPMD at the same time as we will use the 1.3.0 release of libSplash. Due to that, we can refactor it once afterward and use the OpenPMD defines instead of the (then in-order-corrected) libSplash internals.

[skuschel]

I interpreted the shape of the data to be in the order x,y,z (as matplotlib assigns them to the axis in python) and thus came to y,x,z in the attrs['_shape']. Having the axis order reversed in the data turns out to be the same in 2D.
cc @stetie

[ax3l]

ah all right, so it's not a second bug/inconsistency :)

[ax3l]

just ftr: this specific attribute in libSplash is still swapped in order but the problem will be mitigated by both using openPMD and indepentend of that it is tracked in ComputationalRadiationPhysics/libSplash#162