[gmx-users] 2018: large performance variations

Szilárd Páll pall.szilard at gmail.com
Fri Mar 2 19:28:49 CET 2018


Hi Michael,

Can you post full logs, please? This is likely related to a known issue
where CPU cores (and in some cases GPUs too) may take longer to clock up
and get a stable performance than the time the auto-tuner takes to do a few
cycles of measurements.

Unfortunately we do not have a good solution for this, but what you can do
make runs more consistent is:
- try "warming up" the CPU/GPU before production runs (e.g. stress -c or
just a dummy 30 sec mdrun run)
- repeat the benchmark a few times, see which cutoff / grid setting is
best, set that in the mdp options and run with -notunepme

Of course the latter may be too tedious if you have a variety of
systems/inputs to run.

Regarding tune_pme: that issue is related to resetting timings too early
(for -resetstep see mdrun -h -hidden); not sure if we have a fix, but
either way tune_pme is more suited for parallel runs' separate PME rank
count tuning.

Cheers,

--
Szilárd

On Thu, Mar 1, 2018 at 7:11 PM, Michael Brunsteiner <mbx0009 at yahoo.com>
wrote:

> Hi,I ran a few MD runs with identical input files (the SAME tpr file. mdp
> included below) on the same computer
> with gmx 2018 and observed rather large performance variations (~50%) as
> in:
> grep Performance */mcz1.log7/mcz1.log:Performance:       98.510
> 0.244
> 7d/mcz1.log:Performance:      140.733        0.171
> 7e/mcz1.log:Performance:      115.586        0.208
> 7f/mcz1.log:Performance:      139.197        0.172
>
> turns out the load balancing effort that is done at the beginning gives
> quite different results:
> grep "optimal pme grid" */mcz1.log
> 7/mcz1.log:              optimal pme grid 32 32 28, coulomb cutoff 1.394
> 7d/mcz1.log:              optimal pme grid 36 36 32, coulomb cutoff 1.239
> 7e/mcz1.log:              optimal pme grid 25 24 24, coulomb cutoff 1.784
> 7f/mcz1.log:              optimal pme grid 40 36 32, coulomb cutoff 1.200
>
> next i tried tune_pme as in:gmx tune_pme -mdrun 'gmx mdrun' -nt 6 -ntmpi 1
> -ntomp 6 -pin on -pinoffset 0 -s mcz1.tpr  -pmefft cpu -pinstride 1 -r 10
> which didn't work ... in some log file it says:Fatal error:
> PME tuning was still active when attempting to reset mdrun counters at step
> 1500. Try resetting counters later in the run, e.g. with gmx mdrun
> -resetstep.
>
> i found no documentation regarding "-resetstep"  ...
>
> i could of course optimize the PME grid manually but since i plan to run a
> large numberof jobs with different systems and sizes this would be a lot of
> work and if possible i'd like to avoid that.
> is there any way to ask gmx to perform more tests at the beginning of
> therun when optimizing the PME grid?or is using "-notunepme -dlb yes" an
> option, and does the latter require aconcurrent optimization of the domain
> decomposition, if so how is this done?
> thanks for any help!
> michael
>
>
> mdp:
> integrator        = md
> dt                = 0.001
> nsteps            = 500000
> comm-grps         = System
> ;
> nstxout           = 0
> nstvout           = 0
> nstfout           = 0
> nstlog            = 1000
> nstenergy         = 1000
> ;
> nstlist                  = 40
> ns_type                  = grid
> pbc                      = xyz
> rlist                    = 1.2
> cutoff-scheme            = Verlet
> ;
> coulombtype              = PME
> rcoulomb                 = 1.2
> vdw_type                 = cut-off
> rvdw                     = 1.2
> ;
> constraints              = none
> ;
> tcoupl             = v-rescale
> tau-t              = 0.1
> ref-t              = 300
> tc-grps            = System
> ;
> pcoupl             = berendsen
> pcoupltype         = anisotropic
> tau-p              = 2.0
> compressibility    = 4.5e-5 4.5e-5 4.5e-5 0 0 0
> ref-p              = 1 1 1 0 0 0
> ;
> annealing          = single
> annealing-npoints  = 2
> annealing-time     = 0 500
> annealing-temp     = 500 480
>
>
> --
> Gromacs Users mailing list
>
> * Please search the archive at http://www.gromacs.org/
> Support/Mailing_Lists/GMX-Users_List before posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-request at gromacs.org.


More information about the gromacs.org_gmx-users mailing list