[gmx-users] is the tip4p MW velocity treated differently in gromacs 3 vs 4

[Chris Neale]

Thanks David, you are correct about initial step constraints. More 
information inline below, but my question has been resolved.

 >Chris Neale wrote:
 >> Hello,
 >>
 >> Does anybody know if there is a reason why the .gro output velocities
 >> would be different for tip4p MW in a zero-step mdrun between gromacs 3
 >> and gromacs 4 (3.3.1 and 3.3.3 are the same, and are different from
 >> 4.0.2 and 4.0.3, which are themselves the same).
 >Is this with the same tpr?

This was utilizing a tpr generated by the same version of gromacs as was 
used from the mdrun (3.3.1 grompp for 3.3.1 mdrun, etc.) although the 
input was identical (with the exception of any undefined .mdp options 
whose default values changes between v3 and v4, although I can't think 
of one that affects only MW).

Based on your question, I did redo the 3.3.1 grompp to generate a single 
.tpr that was used for both 3.3.1 mdrun and 4.0.3 mdrun. The results are 
the same:

$ diff 4.gro 3.gro | head
1156c1156
<    51SOL     MW 1154   6.809   4.077   1.546  0.0120  0.3740 -0.4572
---
 >    51SOL     MW 1154   6.809   4.077   1.546  0.0219 -0.0279  0.0237
1160c1160
<    52SOL     MW 1158   3.557   2.563   1.080  0.2917  0.2007  0.0277
---
 >    52SOL     MW 1158   3.557   2.563   1.080 -0.0421  0.0144  0.0060

 >
 >It could have to do with initial step constraints.

I had considered that, but my .mdp uses unconstrained-start =  yes.

Based on your suggestion I have attempted setting:
1. constraints = none (get the same difference)
2. also define = -DFLEXIBLE (get the same difference)

However, when I define -DFLEXIBLE and make the tpr using gromacs 3 and 
then run using gromacs 4
I do get gromacs 4 - identical velocities.

$ diff 4from3.gro 4.gro | head
$ diff 4from3.gro 3.gro | head
1156c1156
<    51SOL     MW 1154   6.809   4.077   1.546  0.0120  0.3740 -0.4572
---
 >    51SOL     MW 1154   6.809   4.077   1.546  0.0219 -0.0279  0.0237
1160c1160
<    52SOL     MW 1158   3.557   2.563   1.080  0.2917  0.2007  0.0277
---
 >    52SOL     MW 1158   3.557   2.563   1.080 -0.0421  0.0144  0.0060
1164c1164
<    53SOL     MW 1162   2.458   4.404   3.060 -0.0763  0.0165 -0.5712

So thank you, this explains it.

Chris.

 >>
 >> diff gmx4.0.3/feoff.gro gmx3.3.1/feoff.gro | head
 >> 1156c1156
 >> <    51SOL     MW 1154   6.809   4.077   1.546  0.0120  0.3740 -0.4572
 >> ---
 >>  >    51SOL     MW 1154   6.809   4.077   1.546  0.0219 -0.0279  0.0237
 >> 1160c1160
 >> <    52SOL     MW 1158   3.557   2.563   1.080  0.2917  0.2007  0.0277
 >> ---
 >>  >    52SOL     MW 1158   3.557   2.563   1.080 -0.0421  0.0144  0.0060
 >> ...
 >> (continues for all MW)
 >>
 >> This difference does not appear to be related to solvent optimization:
 >>
 >> $ diff gmx4.0.3/feoff.gro gmx4.0.3_GMX_NO_SOLV_OPT/feoff.gro
 >>
 >> I might just chalk this up to different mdp option defaults, but it
 >> seems strange that there is a difference for all MW, but not for any
 >> other atoms in the system.
 >>
 >> $ cat dpc50_md11.mdp
 >> integrator          =  md
 >> comm_mode           =  linear
 >> nstcomm             =  1
 >> comm_grps           =  System
 >> nstlist             =  5
 >> ns_type             =  grid
 >> pbc                 =  xyz
 >> coulombtype         =  PME
 >> rcoulomb            =  0.9
 >> fourierspacing      =  0.12
 >> pme_order           =  4
 >> vdwtype             =  cut-off
 >> rvdw_switch         =  0
 >> rvdw                =  1.4
 >> rlist               =  0.9
 >> constraints         =  all-bonds
 >> constraint_algorithm=  lincs
 >> lincs-iter          =  1
 >> lincs-order         =  6
 >> energygrps          =  System
 >> nsteps              =  0
 >> dt                  =  0.004
 >> gen_vel             =  no
 >> unconstrained-start =  yes
 >>
 >> Note that I explicitly included the tip4p.itp from gromacs 3.3.1 in 
both
 >> runs.
 >>
 >> Perhaps this is related to the gromacs 3 vsite problem?
 >> http://www.gromacs.org/pipermail/gmx-users/2008-November/037659.html
 >>
 >> Thanks,
 >> Chris.