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

[Erik Lindahl]

Hi,

Just to add to Mark's comments, here are a couple of more thoughts:

1. We've gradually been able to remove virtually all specific "chemical
knowledge" from the code. While there might of course be algorithms that
only work for some setups, it's important to detect that directly from
things like connectivity of molecules rather than having code specific e.g.
to amino acids or nucleic acids.

2. The traditional challenge with SHAKE is of course that it's iterative,
which tends to kill performance for parallel runs. Even LINCS has a smaller
iterative step (which might just be 1 iteration in some cases), but this is
why we increasingly focus on update groups combined with
multiple-time-stepping.

3. However... for energy minimization algorithm the problem is that the
particle position changes can be VERY small, which means one would need
lots of iterations. Second, in MD simulations the typical reason for using
energy minimization is just to remove clashes from starting structures, and
since those starting structures are never perfect anyway there simply
typically isn't much point in enforcing bond lengths to 10E-5 or so. As
long as the bond is close to an equilibrium value that's fine enough.


To get a contribution into the main codebase, it's important to think about
impact and long-term maintainability. Without knowing any details of the
algorithm, I think it will be important to document how it performs clearly
better than the alternatives available in the code today for the common
usage cases, and that parallelism/data structures are fully general and
organized the same way as other algorithms :-)

Cheers,

ERik





On Wed, Jun 2, 2021 at 10:13 AM Mark Abraham <mark.j.abraham at gmail.com>
wrote:

> Hi,
>
> On Tue, 1 Jun 2021 at 16:27, Lorién López Villellas <lorien.lopez at bsc.es>
> wrote:
>
>> 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.
>
> Mark
>
> 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.
>
> --
> 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.



-- 
Erik Lindahl <erik.lindahl at dbb.su.se>
Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm
University
Science for Life Laboratory, Box 1031, 17121 Solna, Sweden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20210602/87e9272f/attachment-0003.html>