[gmx-developers] Gromacs-FEP proposal

Mon Mar 15 12:47:09 CET 2021

Hello,

thanks as well from me for your contribution!

Concerning what Erik said, I would suggest that you open an issue on our 
GitLab (gitlab.com/gromacs/gromacs) so we can have the proper discussion 
there.

We are also having major ongoing effort for improving the free energy code.
So it would be great if you could join the next developer call on the 
24th so that we can discuss things there with the rest of the developer 
community.

Please don't hesitate to contact me for further discussions in any case.

Cheers

Paul

On 15/03/2021 12:34, Erik Lindahl wrote:
> Hi Yuzhi (&Junhan)!
>
> 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.
>
> 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.
>
> Some of the things we will like discuss would be:
>
> 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.
>
> 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.
>
> 3. Documentation and Unit tests are critical to ensure new code keeps 
> working ;-)
>
> Cheers,
>
> Erik
>
> -- 
> Erik Lindahl <erik.lindahl at scilifelab.se>
> Professor of Biophysics
> Science for Life Laboratory
> Stockholm University & KTH
> Office (SciLifeLab): +46 8 524 81567
> Cell (Sweden): +46 73 4618050
> Cell (US): 1 267 307 8746
>
>
>> On Mar 15, 2021, at 12:13, Yuzhi Zhang <352 at pku.edu.cn> wrote:
>>
>> 
>> Dear Gromacs developers,
>>     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.
>>     High-performance implementations:
>>     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. 
>>
>>     2.  Offload non-bonded free energy 
>> kernel to GPU. Our status: finished.
>>     3.  Offload bonded free energy kernel to GPU. Our status: finished.
>>     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. 
>>
>>     5.  Support GPU replica exchange. Our status: finished.
>>
>>     New features:
>>     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. 
>>
>>     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 
>> https://gitlab.com/gromacs/gromacs/-/merge_requests/882 
>> <https://gitlab.com/gromacs/gromacs/-/merge_requests/882> ) 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. 
>>
>>     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? 
>>
>>
>>     Best wishes!
>>     Happy Simulating!
>>     Yuzhi & Junhan
>>
>> -- 
>> 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.
>

-- 
Paul Bauer, PhD
GROMACS Development Manager
KTH Stockholm, SciLifeLab
0046737308594

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20210315/79979b88/attachment-0001.html>