David -
Mu is actually trying to run pmemd here, based on the error message (which
references a pmemd subroutine). I think your suggestion is still correct
about one of several possible problems with memory limits (I addressed the
rest in a previous reflector email). Regarding the test suite, the "pmemd
test suite" consists of doing 50 steps, dumping every 10 steps, in sander 6
or sander 7, and then doing a comparable run in pmemd. Running the full
test suite on pmemd does not work particularly well due to the formatting
differences (I run the relevant parts with hacked up scripts, but it is a
pain). In general, pmemd should do pretty much the same thing as sander 6
or 7 for the initial steps (50 for sure, usually several hundred), or
complain. Past that point, as everyone knows, rounding errors creep in and
trajectories diverge. The exceptions to this rule that I am aware of
include 1) Crosslinked molecules in amber 7 compatibility mode may produce
slightly different results due to the fact that pmemd treats atomic and
molecular virials in the amber 6 fashion in this special case (amber 7
changed; neither approach is particularly more correct, and the difference
is trivial); 2) If MD is run on unequilibrated systems, parallel pmemd may
produce slightly different results due to axis reorientation in some
systems. What is happening here is that the fft slabs for the pme
reciprocal space calcs are being set up on different axes. This causes a
selection of slightly different grid points, and if there are really big
field inhomogeneities, one will see significantly larger than normal ewald
error estimates (for both pmemd and the sanders) and slight differences in
the reciprocal space results. I have observed this when throwing huge
(200K+ atom) systems with large vacuum bubbles straight into MD runs (CP,
300K, hey, why not test what happens when you totally screw things up).
Regards - Bob
----- Original Message -----
From: "David A. Case" <case.scripps.edu>
To: <amber.scripps.edu>
Sent: Wednesday, October 15, 2003 10:25 AM
Subject: Re: AMBER: tru64 alpha
> On Wed, Oct 15, 2003, Mu Yuguang (Dr) wrote:
> > I try Machine.axp
> >
> >
> > FATAL dynamic memory allocation error in subroutine alloc_ew_dat_mem
> >
>
> This means you don't have enough memory available to run the program.
Check
> the limits on your shell: sometimes that is set to much lower values than
> is needed. (Check the reflector archives for suggestions as well.)
>
> You don't say whether the test suite ran correctly or not...that
information
> might also be helpful.
>
> .gooc luck...dac
>
> --
>
> ==================================================================
> David A. Case | e-mail: case.scripps.edu
> Dept. of Molecular Biology, TPC15 | fax: +1-858-784-8896
> The Scripps Research Institute | phone: +1-858-784-9768
> 10550 N. Torrey Pines Rd. | home page:
> La Jolla CA 92037 USA | http://www.scripps.edu/case
> ==================================================================
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber.scripps.edu
> To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
>
>
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Thu Oct 16 2003 - 15:53:01 PDT
