Task #2863

improve PBC handling

Added by Szilárd Páll almost 2 years ago. Updated over 1 year ago.

Target version:


During force compute PBC calculation is (set_pbc_dd()) is needed by the listed forces only (and the group scheme). To avoid unclear dependencies, we could move the call into the listed forces (and duplicate it for the group scheme) eliminating.

However, the constraints and vsites code also does the same computation separately and therefore we should consider whether it's worth constructing the PBC struct once (based on querying the modules that may need it), and passing it around.

Associated revisions

Revision 39f66f14 (diff)
Added by Artem Zhmurov over 1 year ago

Basic routines to handle periodic boundary.

This is a generalization of the SIMD/GPU-like PBC
routines so that they can be used in a CPU code as well.

(Related to Refs #2863)


Patch set 6:

-- TODOs and reference to Redmine #2863 added.
-- Comments improved.


Patch sets 7 and 8: Rebasing.


Patch set 9:

-- Minor changes to comments.
-- Standsrd float3 vector subtraction used.


Patch set 10 and 11: Rebase, uncrustify.


Change-Id: I9efded685fcc41d05bbc5d7deed3ce70f43f5e98


#1 Updated by Mark Abraham almost 2 years ago

I would further/instead suggest that we do all our PBC handling in the style we use for SIMD/GPU, rather than making different data structures.

#2 Updated by Berk Hess almost 2 years ago

For the cases where that can be done, I agree. There are some cases where we might need distances larger than half the shortest box diagonal (or whatever the limit of the simple PBC computation is), but that should be limited to the pull code and analysis tools and maybe one or two special things I forgot.

#3 Updated by Artem Zhmurov almost 2 years ago

There is a PbcAiuc struct in pbcutils/gpu_pbc.cuh, which is essentially the same data-structure to one used in SIMD. Also, there is a subroutine, that constructs this structure from pbc box matrix object. These can be used in the CPU code as well.

#4 Updated by Gerrit Code Review Bot almost 2 years ago

Gerrit received a related patchset '1' for Issue #2863.
Uploader: Artem Zhmurov ()
Change-Id: gromacs~master~I9efded685fcc41d05bbc5d7deed3ce70f43f5e98
Gerrit URL:

#5 Updated by Mark Abraham over 1 year ago

We could think of having a PbcManager that at setup time asks the set of relevant modules what they need (host or device, simple or whatever the alternative is, if on the host then SIMD or not).

Then in current mdrun when the box is updated, the PbcManager can get notified of the new box, and can know to update the relevant data structures. That will mean it needs to have a copy of a GPU context+stream that it would need to use in the relevant cases.

In a future GPU-only MD loop, the box will already be updated on the GPU, so the manager will need to schedule a device-to-host transfer as well as call any necessary updatePbcAiucOnGpu() kernel, when there is CPU-side work that needs the box. As an optimization, I assume it probably makes sense to fuse the box update kernel with the PBC update kernel.

Also available in: Atom PDF