-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug w/ Vay Deposition #3189
Comments
Hi @EZoni. I'm not sure if this is related to this issue but it looks similar so I'm putting it here: I tried to run the CI tests again in PR #2336, which reduces the number of guard cells, and the Vay deposition test benchmarks changed. I investigated the issue and the difference comes from the fact that with my PR So I wondered what is the correct value that should be put for WarpX/Examples/Tests/VayDeposition/analysis.py Lines 32 to 37 in 2191ca6
Do you know what value of |
@NeilZaim --- a/Source/Parallelization/WarpXComm.cpp
+++ b/Source/Parallelization/WarpXComm.cpp
@@ -986,10 +986,10 @@ void WarpX::ApplyFilterandSumBoundaryJ (
ng_depos_J.min(ng);
MultiFab jf(j[idim]->boxArray(), j[idim]->DistributionMap(), j[idim]->nComp(), ng);
bilinear_filter.ApplyStencil(jf, *j[idim], lev);
- WarpXSumGuardCells(*(j[idim]), jf, period, ng_depos_J, 0, (j[idim])->nComp());
+ WarpXSumGuardCells(*(j[idim]), jf, period, ng, 0, (j[idim])->nComp());
} else {
ng_depos_J.min(ng);
- WarpXSumGuardCells(*(j[idim]), period, ng_depos_J, 0, (j[idim])->nComp());
+ WarpXSumGuardCells(*(j[idim]), period, ng, 0, (j[idim])->nComp());
}
}
} namely with I do see that the checksum values change, which I think is expected, but I do not see that the checks on charge conservation fail. I ran the tests Also, note that the change from |
Regarding why However, after #3012 this is not the case anymore for Vay deposition: now However, this does not fix the issue reported here, per se, it just moves a bit the longitudinal position of the spurious signal mentioned in the description of the issue. |
Suggestion by @jlvay: the bilinear filter needs to be applied to D, not J, while the sum over guard cells needs to be applied to J (after inversion in Fourier space). This can be tried locally, by adding some flag that triggers either filtering or sum over guard cells in |
Thanks for your replies @EZoni! I have checked again with your modifications and I still see the charge conservation error with the
You don't obtain the same thing with this specific test? Other than that, I agree that generally it is a good idea to use |
The suggestion mentioned above in #3189 (comment) is now implemented in #3208. Note that the plots shown in the description of this issue are not really of interest, because having the bilinear filter turned off is problematic in itself. I will close the issue. We will see if #3208 makes any difference for the changes reported in #2336 (not sure at this point). |
If we run WarpX (
development
branch) with this input file and look at the raw Jz data with guard cells (raw fieldjz_fp
), we getwhich shows some spurious signal at the low and high end of the domain along Z (note that the plot includes guard cells, for Z < 0 and Z > 128).
However, if we comment out the call to
WarpXSumGuardCells
inside WarpX::ApplyFilterandSumBoundaryJ (note that filtering is OFF in this test),WarpX/Source/Parallelization/WarpXComm.cpp
Line 992 in 5959723
and rerun the exact same test, we get
where the spurious signal is not there anymore.
@jlvay and I were thinking that @WeiqunZhang and/or @atmyers could be able to help us debug this, since it might be related to something happening in the guard cells. Will probably follow up on Slack and/or offline.
Note that the test uses
algo.current_deposition = vay
, while the issue does not occur with other current deposition schemes, such asalgo.current_deposition = direct
.The text was updated successfully, but these errors were encountered: