[gmx-developers] last days for 5.1

[Mark Abraham]

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/20150807/3eef615c/attachment.html>