Re: amber-developers: PIMD, NEB, LES - request for code inspection and tests

From: David A. Case <>
Date: Fri, 20 Jul 2007 17:11:19 -0700

On Fri, Jul 20, 2007, Carlos Simmerling wrote:

> I've been working on some major changes to neb anyway,
> following what has already been done to put neb into multisander.

Can you elaborate some? (That is, what are the changes designed to do?)

> does anyone want to keep neb in the LES style, or can we make it
> multisander only?

I think the rationale behind having a LES-style NEB was to allow "partial"
NEB: that is, keep/require some of the coordinates to be the same in all of
the copies, and allow just a subset of "interesting" coordinates to move.
(This clearly requires the the two end points have identical coordinates for
the non-moving atoms.)

I think Ross has been running NEB a lot: he should chime in here. There is a
question of reducing the search space (by keeping some coordiantes the same
in all copies), and reducing computational costs (which might or might not
flow from our LES implementation.)

One could also ask the same question for pimd:

> does anyone want to keep pimd in the LES style, or can we make it
> multisander only?

Note that the multisander implementation of both neb and pimd is pretty
straightforward: each task works on a single copy, with some communication
between tasks to do what needs to be done. This means the pieces of code that
actually implement pimd or neb are quite localized, and are not likely to
interfere with other pieces of the code when they are turned off. It also
should (almost) automatically work with QM/MM, polarizable force field, etc.

On the other hand, LES is deeply embedded into the code. It makes assumptions
about what the forces should be that work for LES, but might not be very good
for similar (but actually different) models like pimd and neb. [As I
remember, this caveat is partcularly true for how LES and PME interact.] As
far as I know, one could not combine LES with (say) QM/MM or polarization
(etc.) so we have to be very careful about combinations of options. One might
well argue that the LES code should just be for LES, and we are making a
mistake in trying to morph into something else. OR, less drastic: even if we
think we eventually want to have an LES-style NEB/PIMD, we might decide that
this won't be ready for Amber 10, and we would go back to a much simpler

Comments are very welcome here!

As an aside: Kim's point is a good one: we really need to have a scheme for
multiple levels of communicators, so that EVB can co-exist with PIMD/TI/NEB.


David A. Case                     |  e-mail:
Dept. of Molecular Biology, TPC15 |  fax:          +1-858-784-8896
The Scripps Research Institute    |  phone:        +1-858-784-9768
10550 N. Torrey Pines Rd.         |  skype:                 dacase
La Jolla CA 92037  USA            |
Received on Sun Jul 22 2007 - 06:07:53 PDT
Custom Search