Previous Thread
Next Thread
Print Thread
Joined: May 2010
Posts: 69
G
gpat Offline OP
Forum Member
OP Offline
Forum Member
G
Joined: May 2010
Posts: 69
Hi

I am trying to understand one or two things about lookup tables.

1. What is exactly the role of the NBOND statement before calling the lookup
code? Is it for generating the non-bonded atom pair list from which the
separate solute-solute, solvent-solute and solvent-solvent lista are extracted?

2. Does the choice of ELEC and VDW method/options play any role?

Thanks
George

Joined: Sep 2003
Posts: 4,850
Likes: 6
Forum Member
Online Content
Forum Member
Joined: Sep 2003
Posts: 4,850
Likes: 6
1. No. It is to fill internal parameter arrays.
2. Not for speed.


Lennart Nilsson
Karolinska Institutet
Stockholm, Sweden
Joined: May 2010
Posts: 69
G
gpat Offline OP
Forum Member
OP Offline
Forum Member
G
Joined: May 2010
Posts: 69
Thanks for this and apologies for my ignorance; what is exactly the relation between the ELEC/VDW options and the lookup tables method? Are they to
determine the functions that are indexed?

So, if I use the nbonds options I have been using so far (nbonds atom ewald pme...) plus the LOOKup call, what is exactly the difference than when I don't
have the LOOKup call?

Joined: Sep 2003
Posts: 4,850
Likes: 6
Forum Member
Online Content
Forum Member
Joined: Sep 2003
Posts: 4,850
Likes: 6
Lookup tables simply implement the functional form specified by the ELEC/VDW options using (you guessed it!) lookup tables instead of using direct calculation at each step. Ie, it is a numerically different way of computing the same thing.
Where did you get the impression that anything else would be going on? And why would a something different be useful (and not documented)?

Your question is a good starting point for some experimentation (see the 2009 JCC paper about the lookup tables) - what do you find? The difference should be speed.


Lennart Nilsson
Karolinska Institutet
Stockholm, Sweden
Joined: May 2010
Posts: 69
G
gpat Offline OP
Forum Member
OP Offline
Forum Member
G
Joined: May 2010
Posts: 69
I didn't think that something else might be going. I am only trying to clarify matters.

I run two simulations of protein/water/ions (33611 atoms) with the following nbond options

nbonds atom ewald pmewald kappa 0.42 -
fftx 90 ffty 72 fftz 72 order 6 - ! values greater or equal to box lengths
cutnb 13.0 ctofnb 12.0 ctonnb 8.0 vdw vshift -
eps 1.0 inbfrq -1 wmin 1.5 qcor 0.0 -
imgfrq -1 cutim 13.0 ntrfrq 50 -
BYCBim

The simulation with the direct calculation of energies yielded the following timings:
$$$$$$ Average profile $$$$$

Shake Setup 0.02 Other: 0.00
First List 0.10 Other: 0.00
Shake time 38.87 Other: 0.00
Comm coords 37.47 Other: 0.00
dynamc 50.02 Other: 0.00
Dynamics total 107.41 Other: 0.00
Image Update 71.85 Other: 0.00
xdistm setup 7.79 Other: 0.00
xdistm Build list 136.06 Other: 0.00
List time 260.48 Other: 26.92
Direct Ewald time 426.74 Other: 0.00
Fill charge grid 86.57 Other: 0.00
Scalar sum 11.09 Other: 0.00
Grad sum 66.57 Other: 0.00
FFTcomm 88.35 Other: 0.00
FFT 98.88 Other: 62.50
Recip Ewald time 263.95 Other: 7.48
Ewald time 714.95 Other: 0.00
Nonbond force 715.05 Other: 0.00
Bond energy 5.23 Other: 0.00
Angle energy 2.93 Other: 0.00
Dihedral energy 1.15 Other: 0.00
Restraints energy 0.04 Other: 0.00
INTRNL energy 65.11 Other: 56.46
Comm force 44.13 Other: 0.00
Energy time 894.01 Other: 64.17
Total time 1275.70 Other: 0.00

NORMAL TERMINATION BY NORMAL STOP
MOST SEVERE WARNING WAS AT LEVEL 1

$$$$$ JOB ACCOUNTING INFORMATION $$$$$
ELAPSED TIME: 21.23 MINUTES
CPU TIME: 21.18 MINUTES


The simulation with the lookup tables (LOOKup sele segid wat end INT TABI 20 ENERgy) resulted in the following timings

$$$$$$ Average profile $$$$$

Shake Setup 0.05 Other: 0.00
First List 0.47 Other: 0.00
Shake time 38.85 Other: 0.00
Comm coords 38.83 Other: 0.00
dynamc 52.41 Other: 0.00
Dynamics total 111.54 Other: 0.00
Image Update 85.46 Other: 0.00
xdistm setup 7.51 Other: 0.00
xdistm Build list 158.97 Other: 0.00
List time 381.21 Other: 84.91
Direct Ewald time 2.57 Other: 0.00
Fill charge grid 87.10 Other: 0.00
Scalar sum 11.11 Other: 0.00
Grad sum 66.57 Other: 0.00
FFTcomm 176.67 Other: 0.00
FFT 187.25 Other: 146.37
Recip Ewald time 353.04 Other: 96.04
Ewald time 355.65 Other: 93.85
Nonbond force 686.86 Other: 425.03
Bond energy 5.22 Other: 0.00
Angle energy 2.93 Other: 0.00
Dihedral energy 1.21 Other: 0.00
Restraints energy 0.05 Other: 0.00
INTRNL energy 77.73 Other: 68.93
Comm force 46.02 Other: 0.00
Energy time 903.60 Other: 77.11
Total time 1410.32 Other: 0.00

NORMAL TERMINATION BY NORMAL STOP
MOST SEVERE WARNING WAS AT LEVEL 1

$$$$$ JOB ACCOUNTING INFORMATION $$$$$
ELAPSED TIME: 23.50 MINUTES
CPU TIME: 23.37 MINUTES

Overall the simulation with the lookup tables seems to be slower. Am I missing something here?

Thanks

Joined: Sep 2003
Posts: 4,850
Likes: 6
Forum Member
Online Content
Forum Member
Joined: Sep 2003
Posts: 4,850
Likes: 6
The lookup tables only affect the (real-space) nonbonded interations (Coulomb and vdW), "Nonbond force" in the printed timings, and the greatest speed-up is for the water-water interactions. When other parts of the code take most of the time, eg in parallel runs at processor counts when scaling is not so good anymore, there is no gain to be seen. It is also very important in (parallel) benchmarking that no other (non-essential) processes are running at the same time on any of the cores. It is strange that eg the internal energy (which has nothing to do with the nonbonded lookup/no lookup status) also takes significantly longer in your second run.

What you can do to speed things up are:
1/ Do not use the ENERGY option to the LOOKup command
2/ Increase CUTNB and CUTIM to at least 4A > CTOFNB.
3/ Turn off lookup tables for solute-solute and/or solvent-solute interations; options NOUU and NOVU to the LOOKup command.
4/ Benchmark on single core.
5/ Do not use PME.
6/ If you don't care about energy consevation you can also turn off the interpolation in the lookup code, NOINterpolation


Lennart Nilsson
Karolinska Institutet
Stockholm, Sweden
Joined: May 2010
Posts: 69
G
gpat Offline OP
Forum Member
OP Offline
Forum Member
G
Joined: May 2010
Posts: 69
Many thanks for these suggestions. With 2) and 3), I get about 19% speed up. The speedup for a singe core is indeed greater.

Just a couple of more questions related to the documentation.

Is true that with NOEnergy option on, the energy is evaluated ONLY when the non-bonded list is updated?

If I use linear interpolation, can I get away with TABI 10 or 15 rather than 20?

Joined: Sep 2003
Posts: 4,850
Likes: 6
Forum Member
Online Content
Forum Member
Joined: Sep 2003
Posts: 4,850
Likes: 6
Yes, NOENergy only evaluates nonbonded (lookup) energies at list updates.
10 is probably OK with linear interpolation (which I recommend to use).


Lennart Nilsson
Karolinska Institutet
Stockholm, Sweden

Moderated by  BRBrooks, lennart, rmv 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.5
(Release build 20201027)
Responsive Width:

PHP: 7.3.31-1~deb10u1 Page Time: 0.009s Queries: 30 (0.005s) Memory: 0.7696 MB (Peak: 0.8443 MB) Data Comp: Off Server Time: 2022-09-27 00:48:31 UTC
Valid HTML 5 and Valid CSS