PIConGPU 2D x and y axis ranges are wrong

[PrometheusPi]

When using openPMD_viewer - OpenPMDTimeSeries with the slider() method in 2D, the ranges of x and y axis are interchanged wrong.

Full call:

Zoomed into the plot output:

In PIConGPU, the laser propagates in +y direction, as correctly marked by the axis labels. However, the ranges given are interchanged.
(In this LWFA simulation, I used a moving window)

[PrometheusPi]

@HighIander this might effect your data analysis.

[ax3l]

is it really the range that is interchanged or only the offset of the start of the axis?

[ax3l]

probably similar to #102 fixing #99

but I should also double-check if I annotated them correctly in PIConGPU's output itself

[PrometheusPi]

Actually, I just saw that the ranges (at iteration zero) make no sense at all.
L_y = 0.4430e-7 m/cell * 2368 cells * (7 GPUs/8 GPUs) = 91.8 µm
L_x = 0.1772e-6 m/cell * 704 cells = 124.7 µm

vs.

thus it is not just interchanging the ranges

[ax3l]

it might be possible the scaling per cell is interchanged, too. would be consequent (axisLabels, gridSpacing, gridGlobalOffset and gridUnitSI all have the same order but only the first one is switched correctly during read yet).

weird. btw @HighIander and me won't affect that. ion sims have

• no moving window
• quadratic cells

:-)

[PrometheusPi]

@ax3l but your simulation box size will not always be quadratic thus it will effect you. 🤓

[ax3l]

no, that's shape and has nothing to do with the scaling of individual cells or their offset (in cells)

[ax3l]

I think I have the bug, as decribed in my post above.

FieldMetaInformation is working in Fortran order - we should switch that inside there (imshow extent is e.g. not in revered order in comparison to the matrix one passes in, it's the Fortran data that is described in reverse order. ~~this comment might be a misunderstanding what the origin of an image is~~~ [1] ah no, its about the axis direction ... and imshow is C order since its Python).
Additionally, to not break Warp, we have to revert the read gridSpacing and gridGlobalOffset attributes if 'F' order is used inside field_metainfo before passing those to FieldMetaInformation

[1] update: oh, an there is also the positive vs. negative going axis direction that is different in C and F I guess :)

[RemiLehe]

I am not quite sure it is a Fortran order problem. Warp (like PIConGPU and FBPIC) has dataOrder = C in the openPMD metadata, because the output is done from the Python layer.
Anyway, I am looking into the problem right now.

[ax3l]

Ok, I think the problem is, that we currently only switch axisLabels but we also need to switch gridSpacing & gridGlobalOffset the same way.

[RemiLehe]

Actually, looking at the PIConGPU HDF5 file, I see the following:

So, if axisLabels and gridSpacing should indeed be in the same order (and thus match element-wise), this implies that the grid spacing in y is larger than in x, which contradicts @PrometheusPi above comment.
Also, the offset seems to be in the x direction, whereas one would expect it to be in the y direction.

I am misunderstanding the openPMD standard here, or is there something wrond with the PIConGPU output?

[ax3l]

I just cross-checked the file a minute ago in PIConGPU and I think I did invert the both gridSpacing and gridGlobalOffset. So the viewer is right and I have to fix the writer!
https://github.com/ComputationalRadiationPhysics/picongpu/blob/ad355a4e5616733df4d47f8012e49b41eee6f7fd/src/picongpu/include/plugins/hdf5/writer/Field.hpp#L208-L227

But let me check this tomorrow again when its not 1:02 am :)

[RemiLehe]

Oh, ok, we reached the same conclusion simultaneously.

[ax3l]

Aww, sorry for that!
I even checked and fixed it for axisLabels when we cross-checked this last time but forgot the two others are affected, too.

[PrometheusPi]

great job - so it is no openPMD issue - I will thus close it

[ax3l]

right, I already opened and linked an issue in PIConGPU

but hey, my investigation on the two attributes was right - just on the wrong side of the end ^^

again, mea culpa for the noise @RemiLehe

[RemiLehe]

No, problem! Thanks for using the viewer anyway, and for contributing to its improvement!