[AMBER-Developers] generalized distance constraints

From: David A. Case <case.biomaps.rutgers.edu>
Date: Tue, 10 Mar 2009 08:58:09 -0400

> Date: Mon, 9 Mar 2009 11:51:19 -0500
> From: "M. L. Dodson" <activesitedynamics.comcast.net>
> Subject: Re: [AMBER] generalized distance restraint

> On Mon, Mar 09, 2009 at 12:39:43PM -0400, Carlos Simmerling wrote:
> > well I can't say much about the jar option, but in your case you
> > didn't write an end to the first restraint so sander probably thinks
> > there is only 1. maybe someone else can say whether jar with >1
> > restraint will work.
> >
> I think with the regular SMD setup using NMR-type restraints, only the
> first restraint is "steered" when jar is turned on. Any other
> restraints are treated as regular NMR-style restraints, so must
> satisfy the syntax rules for those. There may be a way to do multiple
> steered restraints, but if so I don't know how.
> I think you can do what you want using SMD within the ABMD-formalism.
> I have gone over to that type of SMD setup exclusively. You can mix
> regular NMR-style restraints with an AMBD-style SMD setup (or any of
> the other ABMD-derived designs, probably).

Just a note: as I briefly mentioned at Sanibel, I hope developers will
think about merging divergent code streams for things like umbrella
sampling and steered molecular dynamics.

I wrote the original umbrella code, which was a real kludge, but did
allow one to re-use the NMR restraint stuff. But I think that what
Volodymyr has done is more general and powerful, and doesn't have
problems like the ones listed above. So, my proposal is to see if we
can use his code as a base for most or all of this sort of thing.

There may be some good reasons *not* to do this, so people should feel
free to express their ideas. But I'd like to avoid duplication of user
interfaces to the greatest extent we can.


AMBER-Developers mailing list
Received on Wed Mar 11 2009 - 01:23:55 PDT
Custom Search