<div dir="ltr">Hi,<div><br></div><div>Another one came up in recent discussion. A series of bug reports (<a href="https://gitlab.com/gromacs/gromacs/-/issues/942">https://gitlab.com/gromacs/gromacs/-/issues/942</a>, <a href="https://gitlab.com/gromacs/gromacs/-/issues/2154">https://gitlab.com/gromacs/gromacs/-/issues/2154</a>, <a href="https://gitlab.com/gromacs/gromacs/-/issues/2205">https://gitlab.com/gromacs/gromacs/-/issues/2205</a>, <a href="https://gitlab.com/gromacs/gromacs/-/issues/3653">https://gitlab.com/gromacs/gromacs/-/issues/3653</a>, <a href="https://gitlab.com/gromacs/gromacs/-/issues/3442">https://gitlab.com/gromacs/gromacs/-/issues/3442</a>) 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.</div><div><br></div><div>As we suggested 3 years ago at <a href="https://gitlab.com/gromacs/gromacs/-/issues/942#note_310274862">https://gitlab.com/gromacs/gromacs/-/issues/942#note_310274862</a> 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. :-)</div><div><br></div><div>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.</div><div><br></div><div>Discussion could continue at <a href="https://gitlab.com/gromacs/gromacs/-/issues/3818">https://gitlab.com/gromacs/gromacs/-/issues/3818</a>, 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 :-)</div><div><br></div><div>Mark</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 10 Dec 2020 at 12:17, 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:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>Another potentially controversion point is deprecating the mdrun-only build.</div><div><br></div><div>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...</div><div><br></div><div>Mark</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 10 Dec 2020 at 09:54, Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>I've proposed several things to deprecate at <a href="https://gitlab.com/gromacs/gromacs/-/issues/3818" target="_blank">https://gitlab.com/gromacs/gromacs/-/issues/3818</a> and want to encourage people to consider those choices before I make an MR for the GROMACS 2021 release notes.</div><div><br></div><div>Often things we announce as deprecated remain that way for months or years before we actually remove it. That's fine.</div><div><br></div><div>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.</div><div><br></div><div>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 :-).</div><div><br></div><div>Please feel free to discuss OpenCL here, and anything else at that gitlab issue!</div><div><br></div><div>Mark</div></div>
</blockquote></div>
</blockquote></div>