Re: [AMBER] NAB: pbc calculations available after all?

From: case <case.biomaps.rutgers.edu>
Date: Mon, 26 Jul 2010 10:03:46 -0400

On Mon, Jul 26, 2010, Josh Berryman wrote:

> Hello everyone... I am trying to build a NAB application, and am prepared to
> extend it a little bit to add PBCs if needs be; but I notice that with the
> settings:
>
> #define MM_OPTIONS ("gb=0, cut=12.0, tautp=24, temp0=300.0, ntpr=1,
> ntpr_md=1, ntwx=10")
>
> That periodic imaging does actually seem to work already, albeit for the
> solvent only (which is fine if the solute stays centred). *nbond_box* and *
> nblist_box* are the functions called,
> and to a cursory check everything seems fine.
>
> The documentation says that:
>
> "periodic simulations are not (yet) supported" ... does that mean that they
> are there, but undocumented, or that there is some serious pitfall waiting
> for me if I run this kind of calculation?

There are serious pitfalls. Note that the long-range part of
electrostatics usually provided by PME is not included in the code you
saw, which started as a primitive attempt to support periodic simulations
using ips. If you were *very* careful, you might get an IPS calculation
working: check the amber11/AmberTools/test/nab/Run.ips script for a simple
test case. But there are all kinds of rough edges: I'm not sure the
forces are correct, not sure that it works correctly in parallel, quite
sure that the nonbond list is horribly inefficient, won't work with extra
points, has no support for constant pressure simulations, etc., etc.

[Incidentally, I don't see any restriction in the code to solvent only--in
fact, it should not know the difference between "solute" and "solvent". If
there is such a limitation, it's a bug.]

We are working toward releasing the mdgx program described here:

%T Multi-Level Ewald: A Hybrid Multigrid/Fast Fourier Transform Approach to
the Electrostatic Particle-Mesh Problem
%A D.S. Cerutti
%A D.A. Case
%P 443-458
%J J. Chem. Theory Comput.
%V 6
%D 2010

Right now, this is not very well integrated into NAB/sff (it's written as a
stand-alone code). It's much better tested, but getting it documented has
been slow, as is incorporating key features like extra points. It's easy to
see why it took many years to get sander and pmemd to the place where they are
now...going from "proof of principle" to a code that can be used for serious
simulations is big jump.

....dac


_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Jul 26 2010 - 07:30:03 PDT
Custom Search