From: Bjoern Olausson (namdlist_at_googlemail.com)
Date: Thu Oct 07 2010 - 06:40:17 CDT
On Wednesday 06 October 2010 10:36:04 Bjoern Olausson wrote:
> You wonder why I am asking this. The answer is simple:
> I was running a simulation splitted in 1ns pieces with a python script
> which handled the restarting and did some sanity checks like comparing the
> number of steps written to the restart file to the expected steps. Nothing
> special occurred during the runs (343 so far).
> Yesterday I started some analysis and discovered that four of the
> trajectories were broken:
> Size Run
> 1524552 run051 <- O.K.
> 396388 run052 <- broken
> 396388 run142 <- broken
> 19828 run232 <- broken
> 51844 run322 <- broken
> 1524552 run323 <- O.K.
> 1524552 run324 <- O.K.
I recalculated the broken trajectories but comparing the energies from the
log-files, shows distinct differences. I was using the same NAMD version, same
number of CPUs and same nodes. I even reused the FFTW data.... While writing
this text i realized that I did not reuse the RANDOM SEED. I am currently
recalculating the trajectories with the correct SEED.
I know that the results might diverge since job is running on 288 cores and
this raised a question:
How large must the difference be to be of relevance?
I mean in what case would it be noticeable that a 1ns slice diverges slightly?
Is there some kind of test to check if all the runs are sane?
Maybe a energy peak, jump in motion, ... while proceeding from the last
coordinate set from the recalculated trajectory to the first coordinate set of
the following correct trajectory?
 Trajectory (dcd-file)
- Coordinate set in the correct trajectories
* Coordinate set in the recalculated trajectory
Anything to check for while proceeding from the last * to the first -?
How to determine the threshold for "Too large difference to be consecutive"
-- Bjoern Olausson Martin-Luther-Universitšt Halle-Wittenberg Fachbereich Biochemie/Biotechnologie Kurt-Mothes-Str. 3 06120 Halle/Saale Phone: +49-345-55-24942
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 05:23:15 CST