<div dir="ltr"><div>Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 1 Jun 2021 at 16:27, Lorién López Villellas <<a href="mailto:lorien.lopez@bsc.es">lorien.lopez@bsc.es</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello, all.<br><br>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.<br><br>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?<br></div></blockquote><div><br></div><div>Not that I recall. Supporting CG minimization might be a pain.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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?</div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"> 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.<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Mark</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thank you very much in advance,<br>Lorién.<br></div>
-- <br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div></div>