From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Thu Sep 06 2012 - 08:27:08 CDT
On Thu, Sep 6, 2012 at 3:15 PM, Marc Gordon <marcgrdn55_at_gmail.com> wrote:
> Hi all
>
> I've recently started running my NAMD sims on a cluster on campus as opposed
> to on my local machine so that I can do a whole lot more a whole lot
> quicker.
>
> I uploaded the exact same config file and the various force field and
> structure files onto the cluster and began some test runs just to be sure
> that the results being produced were comparable to the stuff I was getting
> on my local machine.
>
> Long story short the results I get from these runs are inconsistent.
>
> As an example I can start 2 identical runs and 1 falls over with some or
> other instability error halfway through (usually "atoms moving too fast" or
> "low global exclusion count" errors but it varies) while the other runs to
> completion. Is this normal NAMD behaviour? Any idea what could be causing
two possibilities: failing hardware causing bitflips or too
aggressive simulation parameters.
inconsistent behavior can be expected when running due to
load balancing and particularly when running on nodes that
are not use exclusively or have differences in hardware.
> this? I have had the poor admin for the cluster installing multiple versions
> of NAMD to test this (2.8, 2.9 nightly build, 2.9 stable precompiled, 2.9
> stable compiled on the cluster) and they all seem to follow a similar
> pattern (although the nightly build develops instabilities with every run so
> far).
>
> To give you some background I am simulating a dissaccharide, no water or
> anything just the dissacch. The only thing that could be said to be beyond
> the "totally vanilla carb sim" label is that I am using the colvars module
> for some metadynamics sampling on the dihedral bond between the residues.
how many atoms does you system have? sounds like there would be very few.
i assume you are not running parallel then, right?
> Any insights would be appreciated as right now I am tearing my hair out with
> this problem.
as usual, the usual reminder:
it is difficult to discuss such problems on such a generic level.
running an MD is a bit of a balancing act and debugging it is
like being a medical doctor: the description of the patient is
not necessary pointing to the real problem. the more details
and tangible information is made available the better the diagnosis.
otherwise there is not much more to say as in:
"doctor, doctor. it hurts when i am doing this."
"well, don't do it then."
cheers,
axel.
-- Dr. Axel Kohlmeyer akohlmey_at_gmail.com http://goo.gl/1wk0 International Centre for Theoretical Physics, Trieste. Italy.
This archive was generated by hypermail 2.1.6 : Mon Dec 31 2012 - 23:22:02 CST