|
|
Joined: May 2010
Posts: 69
Forum Member
|
OP
Forum Member
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,883 Likes: 12
Forum Member
|
Forum Member
Joined: Sep 2003
Posts: 4,883 Likes: 12 |
1. No. It is to fill internal parameter arrays. 2. Not for speed.
Lennart Nilsson Karolinska Institutet Stockholm, Sweden
|
|
|
|
Joined: May 2010
Posts: 69
Forum Member
|
OP
Forum Member
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,883 Likes: 12
Forum Member
|
Forum Member
Joined: Sep 2003
Posts: 4,883 Likes: 12 |
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
Forum Member
|
OP
Forum Member
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,883 Likes: 12
Forum Member
|
Forum Member
Joined: Sep 2003
Posts: 4,883 Likes: 12 |
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
Forum Member
|
OP
Forum Member
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,883 Likes: 12
Forum Member
|
Forum Member
Joined: Sep 2003
Posts: 4,883 Likes: 12 |
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
|
|
|
|
|
|