Axel Huebl

@proy30 let me know when you are ready for me to review the updates discussed above :) :pray:

@proy30 let me know when you are ready for me to review the updates discussed above :) 🙏

Solvable via spack packaging when depending on `util-linux`: http://frodo.looijaard.name/project/getopt

One thing we want to update is the logic for the upper bound here in write: https://github.com/BLAST-WarpX/warpx/blob/25.11/Source/Diagnostics/FullDiagnostics.cpp#L761-L774 Instead of taking the first box from `ba = diag_ba.maxSize()` we should use...

We have a reproducer now (file is still a bit with sim details, on Slack). ``` export OMP_NUM_THREADS=4 $ ./warpx.3d minimal.input # still right: (size in z is 1um) $...

- If I set `warpx.end_moving_window_step = 0` (i.e. never) the checkpoints after restart stay correct. - If I set `warpx.start_moving_window_step = 0` and keep `warpx.end_moving_window_step = 30` the checkpoints after...

Makes sense. Here is my hypothesis: `Diagnostics::m_geom_output` is a persistent state but not checkpoint-restarted. Functions like `FullDiagnostics::MovingWindowAndGalileanDomainShift` rely on it being updated from prior value. Will print to confirm.

diff to printf debug To print `Diagnostics::m_geom_output`: ```diff diff --git a/Source/Diagnostics/Diagnostics.H b/Source/Diagnostics/Diagnostics.H index 7d42913496..295d7751a5 100644 --- a/Source/Diagnostics/Diagnostics.H +++ b/Source/Diagnostics/Diagnostics.H @@ -293,7 +293,9 @@ protected: * the respective levels. This geometry...

Imho, there is a design flaw to double _book-keep the moving window_ at all in diagnostics, to track relative selections of fields/particles while the simulation evolves/moves. Instead of storing an...

Fix ideas, we could do one of the following: A) checkpoint-restarting `m_geom_output` B) rewriting that `m_geom_output` just stores a relative offset, which does not change over time and can be...