Picongpu: reflections from boundary after slide

[PrometheusPi]

There is an error when the slide_point = 0.0 and restarts are used because the restart calculates the slide steps wrongly.

@psychocoderHPC and me are investigating it currently. More details will follow.

UPDATE:
The error is do a sudden activation of the absorbing (and thus reflecting) boundary conditions after a slide. The variable slide_point does not define a slide_point but the move point and thus does not cause this effect. To avoid further confusion:

• the name conflict should be fixed #1915
• the issue with boundary conditions after slides #1916 should be solved

Thus this issue will be closed.

[ax3l]

back link: might be a regression to #1783

[PrometheusPi]

The detailed study of the hdf5 data (with @psychocoderHPC) showed that we do not slide on the first time step - but this is intended.
The first iteration does not slide but it moves.
So the only misconception (for me) was that slide_point is actually a moving_point in PIConGPU and libPMacc speak.

• move - translate the co-moving window
• slide - empty last GPU(s) in y and place them to the front (y) of the simulation

[PrometheusPi]

I will still check if the h5 output is correct and if this really solves the restart issue I encountered.

[ax3l]

Thanks for the clarification, that all seems normal and the naming is indeed confusing (wrong).

Can you please elaborate what the specific restart issue is that you encountered? The report does not say that yet, maybe you have discussed it offline. Does it crash or does it screw the offset or is something wrong with a specific plugin's output or did you just misinterpret it in post-processing (checkpoint or output data)?

[PrometheusPi]

In the hdf5 checkpoint and data files the fields looked like wrongly copied:

However this is an effect that comes with every slide (relocation of GPUs) because our absorber is defined on y_entire=[0:32] on the entire simulation volume not in the moving volume. Thus we have non-zero fields in the moving box y_moving = [0:32] which regularly are reduced and thus "reflected" by an (unphysical) absorber if we slide/relocate GPUs. Thus, this is not an effect of slide_point==0 but of slides in general. However, since I have seen this so far only with setups using slide_point = 0 and because we "missed sliding after the first iteration" I suspected the origin of these field jumps to be the slide_point = 0.

[ax3l]

Thanks for the clarification! Yes, that's why we hide non-physical parts of the sim in the regular output from the user, in checkpoint data you need to crop on your own :)

NB: crop on your own would also be a great handicraft workshop title... :scissors:

[PrometheusPi]

closed and redistributed issues to #1915 and #1916