<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi Yuzhi (&Junhan)!<div><br></div><div>First, thanks for getting involved! We love to have more people involved, and will do our best to welcome you to the extended team. free energy is definitely an area we want to improve further, and contributions like the ones below sound great.</div><div><br></div><div>Why don't you joint our next open developer call every second Wednesday? Or, if the timezone makes things inconvenient we could schedule a separate meeting.</div><div><br></div><div>Some of the things we will like discuss would be:</div><div><br></div><div>1. We are gradually moving to support both CUDA, SYCL and Hip so we run well on all accelerators - but this also means we need to avoid hacking things just for CUDA, and rather have a clean hierarchical implementation where different platforms might initially support different accelerated features. Much of this stuff has already started to happen in gmx 2021.</div><div><br></div><div>2. For new features and functional forms we tend to be restrictive, partly because it means a collective undertaking for the entire team the next 5-10 years to ensure that feature works with all other features. We have not quite settled things on free energy yet, and we might consider modifying the interactions, but we don't want 4-5 different implementations from different teams - instead we should try to settle on which one will serve us all best.</div><div><br></div><div>3. Documentation and Unit tests are critical to ensure new code keeps working ;-)</div><div><br></div><div>Cheers,</div><div><br></div><div>Erik</div><div><br><div dir="ltr">--<div>Erik Lindahl <erik.lindahl@scilifelab.se></div><div>Professor of Biophysics</div><div>Science for Life Laboratory</div><div>Stockholm University & KTH</div><div>Office (SciLifeLab): +46 8 524 81567</div><div>Cell (Sweden): +46 73 4618050 </div><div>Cell (US): 1 267 307 8746</div><div><br></div></div><div dir="ltr"><br><blockquote type="cite">On Mar 15, 2021, at 12:13, Yuzhi Zhang <352@pku.edu.cn> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div class=" __aliyun_node_has_color" style="margin:0px;padding:0px;border:0px;outline:0px;line-height:1.7;font-family:Tahoma, Arial, STHeiti, SimSun;font-size:14px;">
        <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                Dear Gromacs developers,
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         Based on Gromacs-2020.2, we've done a series of development related to FEP in following aspects . We would like to contribute our codes to Gromacs and we're looking forward to hearing your opinions first.
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         High-performance implementations:
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         1. Offload FEP-PME to GPU. Our status: finished. We've also noticed that this function has been implemented in commit f7be07e3cc901eb03700d93248fc09b573370282 by M. Lundborg et. al. and has been merged in Gromacs-2021. So we won't commit this.
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         2. Offload non-bonded free energy kernel to GPU. Our status: finished.
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         3. Offload bonded free energy kernel to GPU. Our status: finished.
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         4. Support GPU updates for FEP. Our status: finished md-integrator. We've noticed that this has also been implemented in Gromacs-2021, but we'are still interested in supporting GPU updates of sd-integrator. Similar discussion can be found in issue #3258 on gitlab.
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         5. Support GPU replica exchange. Our status: finished.
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                        <br>
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         New features:
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         1. Support "Soft Bond Potential" in FEP, which is proposed in DOI: 10.1021/acs.jctc.6b00991 and allows a more smooth change of bond topology when there is bond formation or breaking in a FEP transformation, such as 5-member ring to 6-member ring. Our status: finished.
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         2. Split softcore parameters for VDW and Coulomb interactions. We noticed that currently Gromacs supports only one parameter "sc-alpha" to modify soft-core interactions. After our tests, this will cause a phase-transition-like phenomenon at middle lambdas in some cases. Our status: finished. We also noticed recently there have been some new forms of softcores like gapsys softcore (DOI: dx.doi.org/10.1021/ct300220p and discussed in <a href="https://gitlab.com/gromacs/gromacs/-/merge_requests/882" target="_blank">https://gitlab.com/gromacs/gromacs/-/merge_requests/882</a> ) and Amber SSC2 softcore (DOI: 10.1021/acs.jctc.0c00237.) And we would like to ask if you consider it's necessary to support such new softcore potentials.
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         These terms are all that we want to contribute to Gromacs. But we have to admit that there is still a lot of work to test and standardize our codes to meet all requirements of Gromacs. Is there any suggestion?
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                        <br>
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         Best wishes!
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         Happy Simulating!<br>
                </div>
                <div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;">
                         Yuzhi & Junhan
                </div>
        </div>
</div>
<div style="margin:0px;padding:0px;border:0px;outline:0px;clear:both;font-size:0px;height:1px;overflow:hidden;">
</div>
<div style="margin:0px;padding:0px;border:0px;outline:0px;line-height:20px;clear:both;">
        <br style="font-family:Helvetica, Tahoma, Arial;font-size:14px;white-space:normal;">
</div><span>-- </span><br><span>Gromacs Developers mailing list</span><br><span></span><br><span>* Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before posting!</span><br><span></span><br><span>* Can't post? Read http://www.gromacs.org/Support/Mailing_Lists</span><br><span></span><br><span>* For (un)subscribe requests visit</span><br><span>https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or send a mail to gmx-developers-request@gromacs.org.</span></div></blockquote></div></body></html>