When specifying domain sizes using variables, writing output files smashes the stack about warpx HOT 13 CLOSED

I think this is too big, warpx.const_dt = 0.1 * debye / ve. At least it's too big for current deposition in particle diagnostics.

from warpx.

@WeiqunZhang Thank you for the notice! I thought it would be a problem with variables because I did not put in exactly the same values as the ones that were computed in the equations. Thats my bad. My original code was geometry.prob_hi = "4 * debye" "4 * debye" "4 * debye" and it turns out that "4 * debye" is just at the boundary where this problem is occouring. When I replaced it with an estimated number I was just over the boundary.

I can confirm that using a larger domain like "10 * debye" is sufficent to resolve the issue.

@ax3l Thank you for the suggestion of using the PICMI interface, I will give it a try.

from warpx.

The underlying issue is still there. If you keep all parameters the same except for using more cells, the issue will likely come back because dx has become smaller while dt is still the same. @RemiLehe

from warpx.

This uses the electrostatic solver. In the code, there is an assertion requiring const_dt.

from warpx.

Uiuiui, you might have found a bug in the parser.
Let me verify on Linux.

This is how we debug.

I can reproduce the bug and will backtrace it now with:

cmake -S . -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo
cmake --build build -j 12

cd build/bin
gdb -ex r -ex bt --args ./warpx.3d inputs amrex.throw_exception = 1 amrex.signal_handling = 0

seems to point to Source/Particles/WarpXParticleContainer.cpp:531 which is in doEsirkepovDepositionShapeN aka current deposition (as already seen in your Backtrace above).

Issues here usually mean that particles are out-of-bounds / traveling too far, so this could be an earlier issue with fields or initialization that "pushes" the particles far or into NaN territory.

@WeiqunZhang since this issue only occurs with the parser, it could also be a memory violation from this. I would run compiler sanitizers in the next days to see if we get more info from it.

from warpx.

@electroflow looking at what you do, you might enjoy avoiding the parser and using our Python (PICMI) interface instead. For all kinds of constants and auxiliary calculations, you can perform them in Python there.

from warpx.

We could print out my_constants.debye with 17 digits of precision and then set that in inputs as prob_hi to see if there are issues.

from warpx.

or specifying the domain size using constants

@electroflow what constants are you using?

from warpx.

@electroflow Not that I see it: Yes, as Weiqun suggested the issue could be that your warpx.const_dt does not fulfill the CFL criteria of the default field solvers you are using. Instead of warpx.const_dt, we usually use the warpx.cfl option to simplify fulfilling the dt to dx/dy/dz relation for em solvers - that way you just need to calculate the spatial resolution (amr.n_cell) and the temporal one follows from it.

from warpx.

Ah thanks, I overlooked the warpx.do_electrostatic = labframe.

So it is the diag that requested j and thus deposits it. Maybe we should change the default to not include j for ES sims...

This can be disabled via:

diagnostics.diags_names = particlesr

particlesr.fields_to_plot = Ex Ey Ez Bx By Bz

in your case.

from warpx.

@electroflow can you try algo.current_deposition = direct? That solves it for me.

@RemiLehe and I currently think that for ES solves diags, we should default to direct deposition for diagnostics.
For Esikepov (default) deposition, there is an implied assumption particles do not travel more than once cell:

from warpx.

I am working on a fix that:

• checks the cell lenght and
• changes the default current deposition for ES simulations (purely diagnostics)

from warpx.

There is a fix in #4362 and #4364

Thanks for reporting, @electroflow !!

from warpx.