On 19/01/2011 2:48 PM, Cara Kreck wrote:
Hi everyone,
I have been trying to reproduce a simulation that I previously ran
successfully with gromacs 3.3.3 in gromacs 4.0.7 and 4.5.1. It is of a
tip4p water box generated with Packmol (and no I can't use the already
provided tip4p water box). However I can't even make it past the
energy minimisation step. I have noticed that all simulations run into
trouble at step 12 and 3.3.3 manages to recover, whereas 4.0.7 and
4.5.1 get stuck. The results of 4.0.7 and 4.5.1 are identical.
Here's an extract from the 4.0.7/4.5.1 log file:
Step Time Lambda
11 11.00000 0.00000
Energies (kJ/mol)
LJ (SR) Coulomb (SR) Coul. recip. Potential
Pressure (bar)
8.12398e+03 -4.64002e+03 -8.80558e+02 2.60340e+03
-4.27109e+03
Step Time Lambda
12 12.00000 0.00000
Energies (kJ/mol)
LJ (SR) Coulomb (SR) Coul. recip. Potential
Pressure (bar)
5.67868e+03 -7.67528e+03 -1.19351e+03 -3.19011e+03
-5.97596e+04
Step Time Lambda
13 13.00000 0.00000
Step Time Lambda
14 14.00000 0.00000
Step Time Lambda
15 15.00000 0.00000
Step Time Lambda
16 16.00000 0.00000
Step Time Lambda
17 17.00000 0.00000
Step Time Lambda
18 18.00000 0.00000
Step Time Lambda
19 19.00000 0.00000
Step Time Lambda
20 20.00000 0.00000
Step Time Lambda
21 21.00000 0.00000
Step Time Lambda
22 22.00000 0.00000
Step Time Lambda
23 23.00000 0.00000
Step Time Lambda
24 24.00000 0.00000
Step Time Lambda
25 25.00000 0.00000
Step Time Lambda
26 26.00000 0.00000
Step Time Lambda
27 27.00000 0.00000
Step Time Lambda
28 28.00000 0.00000
Step Time Lambda
29 29.00000 0.00000
Stepsize too small, or no change in energy.
Converged to machine precision,
but not to the requested precision Fmax < 100
Double precision normally gives you higher accuracy.
You might need to increase your constraint accuracy, or turn
off constraints alltogether (set constraints = none in mdp file)
Steepest Descents converged to machine precision in 30 steps,
but did not reach the requested Fmax < 100.
Potential Energy = -3.1901118e+03
Maximum force = 6.9292950e+05 on atom 97
Norm of force = 2.1575133e+04
And from the 3.3.3 log file:
Step Time Lambda
11 11.00000 0.00000
Energies (kJ/mol)
LJ (SR) Coulomb (SR) Coul. recip. Potential
Kinetic En.
8.28949e+03 -4.56483e+03 -8.69953e+02 2.85470e+03
0.00000e+00
Total Energy Temperature Pressure (bar)
2.85470e+03 0.00000e+00 0.00000e+00
t = 0.012 ps: Water molecule starting at atom 97 can not be settled.
Check for bad contacts and/or reduce the timestep.Wrote pdb files
with previous and current coordinates
Step Time Lambda
12 12.00000 0.00000
Step Time Lambda
13 13.00000 0.00000
Energies (kJ/mol)
LJ (SR) Coulomb (SR) Coul. recip. Potential
Kinetic En.
6.60039e+03 -6.11407e+03 -1.08723e+03 -6.00910e+02
0.00000e+00
Total Energy Temperature Pressure (bar)
-6.00910e+02 0.00000e+00 0.00000e+00
...
(continued on with a few more similar warnings but eventually settled)
...
Steepest Descents converged to Fmax < 100 in 233 steps
Potential Energy = -2.3777645e+04
Maximum force = 9.8486107e+01 on atom 1393
Norm of force = 5.2092145e+02
And here's the input parameters:
cpp = /usr/bin/cpp
define =
constraints = all-angles
unconstrained_start = no
constraint_algorithm = shake
shake_tol = 0.0001
morse = no
integrator = steep
nsteps = 1000
; Energy minimizing
emtol = 100
emstep = 0.01
nstcomm = 1
nstlist = 10
ns_type = grid
pbc = xyz
rlist = 0.9
coulombtype = pme
rcoulomb = 0.9
vdw-type = cut-off
rvdw = 0.9
nstenergy = 10
Tcoupl = no
Pcoupl = no
gen_vel = no
I then tried running the same parameters using the spc water box in
the tutorial and got these results:
4.0.5/4.7.1
Steepest Descents converged to Fmax < 100 in 63 steps
Potential Energy = -1.0896633e+04
Maximum force = 9.1075676e+01 on atom 202
Norm of force = 1.3547868e+01
3.3.3
Steepest Descents converged to Fmax < 100 in 32 steps
Potential Energy = -1.0760295e+04
Maximum force = 8.2715759e+01 on atom 425
Norm of force = 5.6500586e+02
It also gave the same result for version 4 if I ran 4 with the .tpr
file I had prepared using 3.
I am running these remotely and I didn't know whether single or double
precision versions were installed. The .trr file from 3.3.3 was twice
the size of the others (even with half the steps), but gmxdump told me
that all versions were single precision.
Are the differences simply due changes between the versions? Looking
at the release notes, most changes (particularly between 3.3.3 and
4.0.7) were related to parallelisation and I've run everything on a
single cpu. Or is there something else I'm missing?
Of itself, I don't think this is a problem. The same software with a
different compiler can change its numerical stability, in extreme cases.
It would be surprising for 4.0 to have introduced an algorithmic change
that breaks EM, and for it to be first noticed now. It is normal not to
run EM with constraints, and I suspect some change in the constraint
implementation may be the origin of your observations. Try without
constraints.
Mark
--
gmx-users mailing list gmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
