Project

General

Profile

Bug #1425

impossible to disable automated nstlist tuning with verlet scheme

Added by Szilárd Páll over 6 years ago. Updated over 6 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
mdrun
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

In v4.6 the GMX_NSTLIST environment variable can be used to set/override nslist at runtime. This functionality provided the additional benefit of allowing to bypass the automated nstlist tuning. This can be necessary in cases where the tuning can lead to performance drop, e.g. with GPU accelerated runs when using a not sufficiently fast GPU, in this case a larger nstlist will often cause greater slowdown in the non-bonded kernel (translating to "GPU wait time and idling on CPU threads) than the benefit of less frequent pair search (and DD).

In 5.0 the GMX_NSTLIST environment variable has been removed which makes it impossible to prevent mdrun from switching tot a larger nstlist additionally to making it harder to switch nstlist without regenerating the tpr.

I suggest that we add back the GMX_NSTLIST environment variable and as the pair search frequency has a clear role in performance tuning, we should consider adding an mdrun command-line option "-nstlist".

History

#1 Updated by Mark Abraham over 6 years ago

git log -GGMX_NSTLIST

finds a792ba2f2ba which I think does almost exactly what you suggest

#2 Updated by Szilárd Páll over 6 years ago

Mark Abraham wrote:

git log -GGMX_NSTLIST

finds a792ba2f2ba which I think does almost exactly what you suggest

Indeed, I missed that change and I was looking for GMX_NSTLIST in the code. Just came across the command line option myself...

#3 Updated by Szilárd Páll over 6 years ago

PS: for my own purposes keeping the environment variable would be great, otherwise I'll need to go through all my scripts that use it. Do you think there would be any use to it? I'm not sure...

#4 Updated by Mark Abraham over 6 years ago

Szilárd Páll wrote:

PS: for my own purposes keeping the environment variable would be great, otherwise I'll need to go through all my scripts that use it. Do you think there would be any use to it? I'm not sure...

It's useful, but two-edged. Easy for someone to have it set and not remember/know it is set, particularly if there's a script within a script ever (Copernicus?).

I like the semantic divide between "public" command-line options, and things that are more hidden (environment variables even when they are documented, hidden command-line options, etc.)

#5 Updated by Szilárd Páll over 6 years ago

  • Status changed from New to Rejected

It did not sound like you supported the idea of reintroducing the env. var. so I'll just reject this.

Also available in: Atom PDF