From: matteo.rotter (matteo.rotter_at_uniud.it)
Date: Mon Aug 24 2009 - 10:51:27 CDT
Dear all,
I use NAMD 2.7 to perform alchemical fep simulations and i have some
questions about the performance of the program.
Usually i perform one single long simulation divided in two parts: (1)
healing of the solvated system composed by ~30k atoms at lambda zero,
then (2) the real fep, incrementing lambda values and doing 60k steps
for every window of dLambda. The timestep value is 2.0.
Doing a "grep Benchmark" of the output of the simulation i see that the
velocity is not the same, and it decreases.
Log:
Info: Benchmark time: 8 CPUs 0.296415 s/step 1.71536 days/ns 60.0635 MB
memory
Info: Benchmark time: 8 CPUs 0.299998 s/step 1.7361 days/ns 60.0762 MB
memory
Info: Benchmark time: 8 CPUs 0.301172 s/step 1.74289 days/ns 60.0842 MB
memory
Info: Benchmark time: 8 CPUs 0.302582 s/step 1.75105 days/ns 60.3094 MB
memory
Info: Benchmark time: 8 CPUs 0.298734 s/step 1.72878 days/ns 60.3107 MB
memory
Info: Benchmark time: 8 CPUs 0.30036 s/step 1.73819 days/ns 60.3828 MB
memory
Info: Benchmark time: 8 CPUs 0.394402 s/step 2.28242 days/ns 48.1992 MB
memory
Info: Benchmark time: 8 CPUs 0.390341 s/step 2.25892 days/ns 48.1989 MB
memory
Info: Benchmark time: 8 CPUs 0.395859 s/step 2.29085 days/ns 48.2004 MB
memory
Info: Benchmark time: 8 CPUs 0.438661 s/step 2.53855 days/ns 61.9679 MB
memory
Info: Benchmark time: 8 CPUs 0.463273 s/step 2.68098 days/ns 61.9408 MB
memory
Info: Benchmark time: 8 CPUs 0.458809 s/step 2.65515 days/ns 61.9406 MB
memory
Info: Benchmark time: 8 CPUs 0.46636 s/step 2.69884 days/ns 64.4346 MB
memory
Info: Benchmark time: 8 CPUs 0.465821 s/step 2.69573 days/ns 64.4345 MB
memory
Info: Benchmark time: 8 CPUs 0.488558 s/step 2.8273 days/ns 64.4349 MB
memory
....
the simulation was done with the ++local option on Quad core xeon.
So my first question is: why this change in velocity?
Trying to solve this issue i searched in the NAMD mailing list and i
found this approach:
http://www.ks.uiuc.edu/Research/namd/mailing_list/namd-l/2476.html ,
doing separate FEP simulations.
So i tried to follow a similar approach doing separate simulations, but
with consequent dLambda values. That is for example that the output of
dLambda 0.1 0.2 is the input of dLambda 0.2 0.3 and on.
The system was first equilibrated with an initial simulation at lambda 0
of 40 ps.
All the values for the .conf files are the same of the one single long
simulation.
For every dLambda window were done 60k steps.
What i found is that with a timestep value 2.0, the Fep simulations exit
prematurely due to constraint failure in rattle algorithm. The benchmark
lines show good values, quite similar to the those at the beginning of
the single long simulation.
Info: Benchmark time: 8 CPUs 0.243659 s/step 1.41006 days/ns 54.2092 MB
memory
Info: Benchmark time: 8 CPUs 0.243631 s/step 1.4099 days/ns 54.2057 MB
memory
Info: Benchmark time: 8 CPUs 0.242427 s/step 1.40293 days/ns 54.435 MB
memory
I tried to solve the problem of crashing using a timestep value of 1.0.
The simulation didn't exit and go without errors to the end.
Looking at the benchmark lines i see that the s/steps value is quite the
same of simulation with timestep 2.0.
Info: Benchmark time: 8 CPUs 0.245462 s/step 2.84099 days/ns 53.2536 MB
memory
Info: Benchmark time: 8 CPUs 0.24511 s/step 2.83692 days/ns 53.6811 MB
memory
Info: Benchmark time: 8 CPUs 0.245676 s/step 2.84347 days/ns 53.3514 MB
memory
So the questions:
why the first single simulation with timestep 2.0 arrives to normal end,
showing an increase in s/steps value?
and why the divided simulations with the same input does crash? And,
last, why using timestep of 1.0 the simulations don't crash?
thanks for your attention.
Regards,
Matteo Rotter.
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:53:12 CST