Project

General

Profile

Task #2863

improve PBC handling

Added by Szilárd Páll 10 months ago. Updated 9 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
mdrun
Target version:
-
Difficulty:
uncategorized
Close

Description

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 9 months 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

History

#1 Updated by Mark Abraham 10 months 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 10 months 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 10 months 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 10 months ago

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

#5 Updated by Mark Abraham 9 months 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