Project

General

Profile

Bug #2346

inconsistent behavior of mdrun -nt 1 with mdrun -nt 3 when both are undersubscribed

Added by Mark Abraham almost 2 years ago. Updated almost 2 years ago.

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

Description

Command line:
  gmx mdrun -s reference_s -deffnm test -nt 1

Reading file reference_s.tpr, VERSION 2016-beta1-dev-20160524-3a9e67d (single precision)
Note: file tpx version 110, software tpx version 112
Changing nstlist from 10 to 100, rlist from 0.9 to 0.999

Using 1 MPI thread
Using 1 OpenMP thread 

NOTE: Thread affinity was not set.

But for -nt 3 (or -nt 2 similarly)

  gmx mdrun -s reference_s -deffnm test -nt 3

Reading file reference_s.tpr, VERSION 2016-beta1-dev-20160524-3a9e67d (single precision)
Note: file tpx version 110, software tpx version 112
Changing nstlist from 10 to 100, rlist from 0.9 to 0.999

Using 1 MPI thread
Using 3 OpenMP threads 

NOTE: The number of threads is not equal to the number of (logical) cores
      and the -pin option is set to auto: will not pin threads to cores.
      This can lead to significant performance degradation.
      Consider using -pin on (and -pinoffset in case you run multiple jobs).

NOTE: Thread affinity was not set.


Related issues

Related to GROMACS - Bug #2342: Avoid yelling about thread pinning twiceClosed

History

#1 Updated by Mark Abraham almost 2 years ago

  • Related to Bug #2342: Avoid yelling about thread pinning twice added

#2 Updated by Berk Hess almost 2 years ago

  • Status changed from New to Fix uploaded

The fix for #2342 fixes this. Performance loss is less with a single unpinned thread, so there we issue the short note instead of the longer one.

#3 Updated by Berk Hess almost 2 years ago

  • Status changed from Fix uploaded to Resolved
  • Assignee changed from Mark Abraham to Berk Hess

I assume this is resolved, unless someone thinks we should also issue the more verbose warning for a single thread.

#4 Updated by Mark Abraham almost 2 years ago

  • Status changed from Resolved to Fix uploaded
  • Assignee changed from Berk Hess to Mark Abraham

OK, I can live with that. But neither the message to the user, nor the code, states why nthreads > 1 is a relevant part of the logic, so perhaps we should do that?

#5 Updated by Erik Lindahl almost 2 years ago

  • Status changed from Fix uploaded to Resolved

I would suggest we add that to the documentation the next time we update the code, but if the double/inconsistent output is no longer there we can close this bug.

#6 Updated by Mark Abraham almost 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF