Picongpu: Weird assymetrical electron density in the LWFA example ( with dev branch ).

Created on 26 Mar 2020  路  9Comments  路  Source: ComputationalRadiationPhysics/picongpu

I noticed that the LWFA example (default setting, 4.cfg configuration file) produces weird outputs compared to what it was doing before (current master branch 0.4.3).

Run on hemera聽( tried on both k20 and gpu partitions ).
For people with access, here you can find the full simulation outputs (2020_03_26_dev and 2020_03_26_0-4-3):
/bigdata/hplsim/scratch/ordyna35/runs/LWFA

Bellow, for comparison, two exemplary pngs generated with the png plugin (XY plane).
Dev (900th simulation step, ):
e_png_yx_0 5_000900

0.4.3 (900th simulation step):
e_png_yx_0 5_000900

This is not only a problem with the png plugin, electron density dumped by the hdf5 or adios looks the same.

@PrometheusPi, @sbastrakov, @psychocoderHPC

bug core

Most helpful comment

I confirm that #3161 caused the bug and #3218 fixes it.
The error was introduced to the code side, not the setup.

All 9 comments

To me it looks like some of the electrons would stop moving :sweat_smile:

Thanks for reporting @pordyna !

I am looking into this, as this might be a bug to fix before the release.

Intermediate result: this is definitely a bug that needs to be fixed urgently. Introduced to dev some time between 5 February and 3 March. I will narrow it down and fix, think today.

@pordyna Thank you for reporting this issue. It is awesome you found this bug.
I just checked my LWFA simulations I ran tonight and the same error occurs (k20/hemera - 2D only, 16GPUs):
grafik

Seems to affect a fixed number of cells at the absorbers.

@PrometheusPi I think I figured out the bug. Since Feb. 20 the exponential absorber strength was very wrong. Making a PR to fix in a moment.

@sbastrakov Excellent! I am looking forward to your pull request.
(I did not see any recent changes in picongpu/share/picongpu/examples/LaserWakefield/include/picongpu/param/grid.param)

I confirm that #3161 caused the bug and #3218 fixes it.
The error was introduced to the code side, not the setup.

The fixing PR is merged, closing.

Was this page helpful?
0 / 5 - 0 ratings