Skip to content
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

rho_fp from Python charge density deposition edge cells not properly set #2774

Closed
roelof-groenewald opened this issue Jan 24, 2022 · 2 comments · Fixed by #2777
Closed

rho_fp from Python charge density deposition edge cells not properly set #2774

roelof-groenewald opened this issue Jan 24, 2022 · 2 comments · Fixed by #2777
Assignees
Labels
bug Something isn't working component: Python Python layer

Comments

@roelof-groenewald
Copy link
Member

PR #2710 added functionality to deposit the charge density for a given species (at a given level) into the rho_fp multifab. After that PR was merged I discovered that the cells around the simulation domain edge are not properly set with this deposition call, as is shown in the figure below:
electron_density_incorrect

Adding the call warpx.SyncRho(); to the end of the new function WarpXWrapper.cpp::warpx_depositChargeDensity(), fixes this issue for the present case as is shown below:
electron_density_correct

My concern is that the function warpx_depositChargeDensity() specifically deposits the charge density in a given level. For the above simulation this doesn't matter since there is just 1 level in the simulation, but if there were more I suspect the warpx.SyncRho(); call would introduce other problems seeing as the charge density was not deposited in other levels.

An temporary fix would be to add the warpx.SyncRho(); call to warpx_depositChargeDensity() as well as a check that max_level == 0 otherwise print a warning saying the function is not appropriate to use.

@roelof-groenewald
Copy link
Member Author

@dpgrote and @ax3l any thoughts on this issue and the suggested fix?

@ax3l
Copy link
Member

ax3l commented Jan 24, 2022

Or alternatively, we could expose to Python SyncRho and call it after deposition explicitly (from Python)?
That way, we would not change the semantics between C++ and Python calls.

I am wondering right now why we don't do the same sync in the ES solver before calculating fields from the charge...

pc.DepositCharge(rho, local, reset, do_rz_volume_scaling);
// Get the particle beta vector
bool const local_average = false; // Average across all MPI ranks
std::array<Real, 3> beta = pc.meanParticleVelocity(local_average);
for (Real& beta_comp : beta) beta_comp /= PhysConst::c; // Normalize
// Compute the potential phi, by solving the Poisson equation
computePhi( rho, phi, beta, pc.self_fields_required_precision,
pc.self_fields_absolute_tolerance, pc.self_fields_max_iters,
pc.self_fields_verbosity );
// Compute the corresponding electric and magnetic field, from the potential phi
computeE( Efield_fp, phi, beta );
computeB( Bfield_fp, phi, beta );

Update: clarified on Slack - this overload of the deposition handles boundaries. The other one we use in Python currently does not.

The the EM solver loop, we always pair Deposition and Sync calls:
https://github.com/ECP-WarpX/WarpX/blob/9610779cf94427709a6a77530f545d06dfcbbc3a/Source/Evolve/WarpXEvolve.cpp

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working component: Python Python layer
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants