Repository navigation
P3M: shifted Green's function for the truncated solver, adjustable overlap cutoff, overlap-layout fixes - #611
Merged
aaadelmann merged 10 commits intoOct 14, 2026
Conversation
…ide P3M's truncated Greens solver for approximate Dirichlet BCs
…ce clear error when number of cell counts exceeds the maximum
…or PP interaction. This optimization can use larger cells optimizing memory in sparse regions A LOT. Edge cases can have slightly worse performance, but at least no random seg-fault
…nd periodic Ewald kernels whenever alpha changes, so updating alpha between solves moves the P3M split.
…he boundary ones and losing all attribute data when the views grow, with a regression scenario.
…or a cutoff-aware updateLayout that rebuilds halos and cells, and report cutoffs exceeding half a rank region with a descriptive exception.
…out and solver each have their own. Properly set a cellsOutdated_m flag on layout change
aaadelmann
approved these changes
Oct 14, 2026
aaadelmann
self-requested a review
October 14, 2026 12:11
aaadelmann
approved these changes
Oct 14, 2026
Collaborator
Author
|
Tests look good. But still, I cannot merge myself until the CI notification is fixed. |
aaadelmann
deleted the
610-implement-shifted-greens-function-overwrite-for-p3m
branch
October 14, 2026 13:13
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
closes #610
This RP was intended to implement a shifted Green's implementation such that we can run simulation with source planes and P3M in OPALX. The main idea is that the "image" solve is performed with a normal shifted Green's kernel. PP interaction in the images are ignored, since they are (this is an approximation) more than
RCUTaway from the source plane.Apart from that, I also found a few optimizations and smaller fixes that help with using P3M on bigger problems.
Changes
FFTOpenPoissonSolver::shiftedGreensFunctionnow acceptsTRUNCATED. It still uses the Green's function without theerffactor, but the distinction is necessary to optimize Green's rebuilds. Then P3M can useFFTTruncatedGreenPeriodicPoissonSolver::shiftedGreensFunction(shift), which delegates to the open solver.RCUT) between runs. That allows for "adaptive cutoff radii", which is necessary if we want to defineRCUTwithParticleSpatialOverlapLayoutgets a few helper methods to changemax(16 N, 2^24)whereNis the number of local plus ghost particles after exchange (this is necessary to not run into "exceeds INT_MAX" errors. If it runs into this cap, the cells are simply widened to reduce the number of cells necessary (which can increase PP count, but at least the program doesn't crash). This does not influence the set of interacting particle pairs.particleRanksis now constructed with an explicit extent of 0. Kokkos 5.2.0 treated the missing extent as a huge one, which caused illegal memory accesses on GPU.outsideCountsis now indexed byi(the position inoutsideIds) instead of by the particle ID.createPeriodicGhostParticlesnow re-reads the position view after the copy, because the copy may have reallocated it.ParticleAttrib::internalCopy, used for periodic ghosts, had three problems: it copied the first particles instead of the boundary particles (view(i)instead ofview(indices(i))), it grew the views destructively (dropping all attribute data), and it took the view before the views grew. All fixed now.Testing
I ran OPALX against this branch on up to 8 GH200 nodes just fine. This branch also works fine with OPALX master (even though some adjustments are needed to use these new features). Also added some more unit tests that should check more edge cases.
There is still a bug with periodic ghost particles in the PP interaction, which has already existed in master before. I will make a separate issue and fix it at a different time. It's not critical, since we want to use open P3M anyways.