[gmx-developers] New constraint algorithm based on SHAKE: Some doubts

Mark Abraham mark.j.abraham at gmail.com
Wed Jun 2 10:13:23 CEST 2021


On Tue, 1 Jun 2021 at 16:27, Lorién López Villellas <lorien.lopez at bsc.es>

> Hello, all.
> We are working on a new constraint algorithm based on SHAKE. We already
> have two versions working in GROMACS; a serial one that works with any kind
> of molecule, and a parallel one that only works with peptide chains. The
> results we have obtained so far are very promising.
> We are trying to extend the algorithm to also work in energy-minimization
> runs. However, we have seen that SHAKE is not supported in this kind of
> runs, is there any reason behind that?

Not that I recall. Supporting CG minimization might be a pain.

One of the following steps is to support MPI. Currently, our parallel
> version only works with OpenMP on a single node. In order to work in
> parallel, we use a precise bond numbering that allows us to distribute the
> constraints between the threads in a very particular manner. This gives us
> a very good performance, but it makes it difficult to support MPI with the
> current domain decomposition implementation, in which two atoms of the same
> molecule can be in different ranks. As far as we know, there is an option
> to prevent constraints of the same molecule from being in different ranks
> (update groups). However, we are guessing it is not a good idea to rely on
> that option, right?

On the contrary, the core team views that as the key direction for the
future, particularly when combined with multiple time stepping. Naturally,
it can only work well when the update groups of mutually constrained atoms
are small enough (e.g. methyl) and cannot work well for long chains of
constrained bonds (so not with all-bonds option) because the domain
decomposition is then based on update groups, not atoms.

> Another alternative would be to send all of the required information (the
> positions mainly) of a molecule in each time-step to a single node to
> execute the algorithm. We are open to any suggestion or idea you can
> provide.

Such approaches with many-to-one communication patterns intrinsically don't
scale past a certain (hardware-dependent) point - just like separate PME
ranks. One might do a little better by replicating the constraint workload
on all ranks, by swapping a single many-to-many communication instead of
the two many-to-one and one-to-many stages, but now you need care to ensure
the computation is bitwise reproducible across ranks.


Thank you very much in advance,
> Lorién.
> --
> Gromacs Developers mailing list
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20210602/589f262e/attachment-0003.html>

More information about the gromacs.org_gmx-developers mailing list