[gmx-developers] discussion of deprecation announcements in GROMACS 2021

[Mark Abraham]

Hi,

Another potentially controversion point is deprecating the mdrun-only build.

The mdrun-only build dates from long before we had the gmx wrapper binary.
Having a low-dependency build of GROMACS was desirable if you only want to
run a simulation on a big cluster. However we've now got much better
handling of dependencies in CMake, and our mdrun-only build works the same
as the normal build of gmx does. So it would be simpler for us to maintain
and test if we did not have it. Further,  users won't have to be taught
that there might be two ways to call mdrun, and that that might differ from
one cluster to another...

Mark

On Thu, 10 Dec 2020 at 09:54, Mark Abraham <mark.j.abraham at gmail.com> wrote:

> Hi,
>
> The developers announce functionality as deprecated each year. That gives
> users a chance to learn what changes may happen in future, so they can plan
> how to adapt.
>
> I've proposed several things to deprecate at
> https://gitlab.com/gromacs/gromacs/-/issues/3818 and want to encourage
> people to consider those choices before I make an MR for the GROMACS 2021
> release notes.
>
> Often things we announce as deprecated remain that way for months or years
> before we actually remove it. That's fine.
>
> The potentially controversial item is the proposed deprecation of OpenCL
> support. We have active funded projects to implement support with SYCL for
> Intel GPUs, and some as-yet undecided framework for AMD GPUs. When those
> are in place, the usefulness of OpenCL as a portable approach for GPU
> support in GROMACS has expired. We have not had the resources to develop
> the current CUDA and OpenCL GPU code forks to the same extent, and we are
> not going to be able to do that any better when SYCL and perhaps HIP are
> also around. Continuing to support and test the OpenCL functionality is
> work that we would need to do that costs us the opportunity to further
> improve the ports we expect users to be using in GROMACS 2022.
>
> So, when we have made enough progress on the Intel and AMD fronts, we want
> the freedom to remove the OpenCL port, so that there's less work for us to
> do and more freedom to adapt our GPU portability layer in the directions it
> needs to move. I hope that will happen some time during the 2021 calendar
> year, but it won't be January :-).
>
> Please feel free to discuss OpenCL here, and anything else at that gitlab
> issue!
>
> Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20201210/a5eda9b4/attachment-0001.html>