<div dir="ltr">Hi,<div><br></div><div>We have a number of things that have been identified to be duplicate functionality, or have serious implementation deficiencies that we should warn users about before we remove them finally. So, I propose that in the 2018 release we have a note (e.g. to the .log file) advising users of this functionality that it may go away, and where appropriate, what alternative exists. We already do a similar thing for the group scheme.</div><div><br></div><div>People can volunteer to work on things in order to keep them, but &quot;it&#39;s important to me, but I won&#39;t commit resources to work on it&quot; carries zero weight. That&#39;s particularly true in cases where they&#39;ve said that 6-36 months ago on the various Redmine issues that we&#39;ve debated them on. ;-)</div><div><br></div><div>In particular:</div><div>* mdrun -multi (does not work reliably with files created by modules that weren&#39;t designed to work with multi-simulations; works much more reliably with -multidir because that uses the existing abstraction for a group of related files, ie. a folder)</div><div>* BG/Q support (some aspects have been broken for a few versions, and most places are phasing out their machines)</div><div>* CUDA compute capability 2.0 devices (more than 5 years old, and deprecated also in recent CUDA versions)</div><div>* Generalized Born (will remove, has been mostly broken since version 4.6)</div><div>* QM/MM (except for areas Gerrit and Tomas are working on - what is your intended scope here, please?)</div><div>* all-vs-all kernels (we might have a form of this available for the Verlet scheme, but we will not prioritise that highly for 2019 release; it&#39;s only really useful for GB or vacuum simulations)</div><div>* mdrun options -nsteps -confout -resetstep -resethway (the implementations are bad, and/or duplicate gmx convert-tpr, and/or don&#39;t work reliably in combination with tuning features; they are not things normal users should ever use, and should be replaced by something implemented to do benchmarking after tuning stabilizes; notably, we keep -maxh because that&#39;s something useful for users)</div><div>* the ability of trjconv to concatenate files (trjcat is the tool for that)</div><div><br></div><div>Any other things people want to add or remove from that list? We might raise some version requirements (possibly cmake or CUDA) but those aren&#39;t things I think we should notify users about in advance. We should work on breaking trjconv, trjcat, eneconv and editconf into a forest of sub-tools, but I think that there&#39;s not any value in telling users anything about that in advance.</div><div><br></div><div>We should also be aware that -deffnm is brittle in the same way that -multi is, because our filename-handling machinery doesn&#39;t centralize changing the prefix/suffix needed to support -deffnm or -multi. So I think we should plan to announce -deffnm as deprecated in the 2019 release (and remove after that). If we think that&#39;s useful enough to want to keep, we need people to put up their hands for the work to make all the mdrun modules work with it.</div><div><br></div><div>Thanks,</div><div><br></div><div>Mark</div></div>