[gmx-developers] last days for 5.1

[Mark Abraham]

Hi all,

As you may have seen, 5.1 is now live. Thanks all very much for the hard
work - we hope the new version meets your simulation needs better than ever!

Naturally there's a bunch of things we have been planning for the next
GROMACS release, so watch this space!

Mark

On Thu, Aug 13, 2015 at 2:24 PM Mark Abraham <mark.j.abraham at gmail.com>
wrote:

> Hi,
>
> Update - everything is looking pretty good. I plan to release 5.1
> tomorrow. Thanks, all, for all the help!
>
> I haven't done as much work on the docs as I would like, but c'est la vie.
>
> We've got a new FTP server set up and DNS transfer is underway. I'll put
> the files on old and new servers so there should be no problems while DNS
> changes propagate.
>
> Mark
>
> On Sat, Aug 8, 2015 at 1:47 AM Mark Abraham <mark.j.abraham at gmail.com>
> wrote:
>
>> Hi,
>>
>> On Thu, Aug 6, 2015 at 1:21 PM Kutzner, Carsten <ckutzne at gwdg.de> wrote:
>>
>>> Hi,
>>>
>>> I wanted to quickly report back on tune_pme for 5.1, what are the issues
>>> so we could discuss on how best to proceed.
>>>
>>
>> Many thanks!
>>
>>
>>> In principle, tune_pme works, however as a user one may have to set extra
>>> options so that actually tuning can be done.
>>>
>>> The issues are:
>>>
>>> a) A valid mdrun executable needs to be specified first, see:
>>> https://gerrit.gromacs.org/#/c/4771/
>>
>>
>> OK. I think we need to make this a first-class property of tune_pme, and
>> have proposed such at https://gerrit.gromacs.org/4963
>>
>> b) On GPU nodes, mdrun typically segfaults, due to timers not being reset
>>> at a neighborsearching step, see:
>>> and http://redmine.gromacs.org/issues/1781
>>
>>
>> Fixed at https://gerrit.gromacs.org/4964
>>
>> c) One needs to specify -ntomp somevalue, otherwise it is 1 by default
>>> and mdrun refuses to run.
>>>
>>
>> Can you provide an example here? I'm not sure what's the problem, to
>> assign blame or to fix! :-)
>>
>>
>>> Issue b) is probably the most important one to address, which could be
>>> either
>>> done in mdrun or in tune_pme.
>>> Tune_pme would have to determine from the .tpr what the actual
>>> neighborsearching
>>> frequency will be and adjust the counter resetting appropriately.
>>>
>>
>> Not very workable - nstlist varies according to what hardware is
>> available, and one can't really know that without running mdrun. (e.g. you
>> could run gmx tune_pme from a non-CUDA install and it has no idea that
>> mdrun can use a GPU).
>>
>> Mark
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20150814/47411688/attachment.html>