On 7/20/07, David A. Case <case.scripps.edu> wrote:
> 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?)
>
I've been discussing this with Ross and Dave M.
I'm making changes needed to have NEB work with explicit water,
which it won't currently 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.
>
yes, it is just that there is a huge amount of unnecessary communication
for NEB, not sure if that' true for PIMD also. for example, in NEB all beads
share coordinates with all other beads. I've changed my version so that only
neighbors communicate. I've also gotten rid of the extra velocity communication
and I think we can get rid of the extra force communication with a little work.
> 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
> sander.LES.
>
I think we can keep the LES-style NEB/PIMD completely separate from
the multisander
one. you're right that LES is overly complicated, so many ifdefs and so on.
we could think of converting the LES code into more of a partial multisander,
and then have specific options depending on whether it is LES/NEB/PIMD/etc
but that would take a little work, I don't think I could do much for amber10.
> 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.
>
absolutely, we were thinking last week of extra communicators. Since this
will be very useful in the future and is such a pain to do, we should
talk about
the next change being to a more general scheme that can easily be extended.
carlos
Received on Wed Jul 25 2007 - 06:07:33 PDT
