<div dir="ltr">Hi,<div><br></div><div>Just to add to Mark's comments, here are a couple of more thoughts:</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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 :-)</div><div><br></div><div>Cheers,</div><div><br></div><div>ERik</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 2, 2021 at 10:13 AM Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><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" target="_blank">lorien.lopez@bsc.es</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color: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-width:1px;border-left-style:solid;border-left-color: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-width:1px;border-left-style:solid;border-left-color: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-width:1px;border-left-style:solid;border-left-color: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>
-- <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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Erik Lindahl <<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a>></div><div>Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div></div></div></div></div></div></div></div></div>