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

[Mark Abraham]

Hi,

Another one came up in recent discussion. A series of bug reports (
https://gitlab.com/gromacs/gromacs/-/issues/942,
https://gitlab.com/gromacs/gromacs/-/issues/2154,
https://gitlab.com/gromacs/gromacs/-/issues/2205,
https://gitlab.com/gromacs/gromacs/-/issues/3653,
https://gitlab.com/gromacs/gromacs/-/issues/3442) have taught us the lesson
that the practice of letting modules write their own .xvg files, while
permitting global replacement of filename prefixes with -deffnm doesn't
work when the resulting filenames collide. We've tried local fixes for the
pull code, but those don't work when we do the check that the files on disk
match those used for the simulation that matched the checkpoint, because
the local fix for pulling hasn't acted early enough.

As we suggested 3 years ago at
https://gitlab.com/gromacs/gromacs/-/issues/942#note_310274862 it is better
all round to remove -deffnm after due deprecation. That will impact users
in the short term, but will also benefit them by letting us focus on
implementing code that we can test and keep working. Clearly the existing
complexity has been too much for us and we have not demonstrated ourselves
able and willing to fix it. :-)

The updated documentation should encourage users to either write out the
options and filenames that they want to change, or to use the standard
practice of using folders to group sets of related files.

Discussion could continue at
https://gitlab.com/gromacs/gromacs/-/issues/3818, but unless there's a
volunteer to make things work well in the general case, there's quite a few
developers who are keen to simplify this aspect :-)

Mark

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

> 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/20210113/28409255/attachment.html>