Re: double-wide sampling with soft-core

From: Floris Buelens (
Date: Thu Jan 22 2009 - 12:02:36 CST

Ah right, that clears up my confusion - what's described in the documentation does make perfect sense. When I referred to linear spacing of intermediate states I was still thinking of the code as it's currently implemented, which doesn't allow a separate comparison lambda to be given for the reverse transformation.
Personally I would benefit from an implementation of lambda lists, I've been working with a replica exchange scheme that exchanges lambda values, which would be cleaner if each simulation could know the lambda values of its neighbours at all times... but for plain FEP I'd say a tcl wrapper is certainly good enough.
One minor point, there's an explicit alchDoubleWideSampling parameter documented, maybe this could be dropped and inferred from the use of both lambdaPlusDelta and MinusDelta?

best regards,


----- Original Message ----
From: Peter Freddolino <>
To: Chris Harrison <>
Cc: Floris Buelens <>; Jerome Henin <>; Se'bastien Le'gare' <>;
Sent: Thursday, 22 January, 2009 17:34:07
Subject: Re: namd-l: double-wide sampling with soft-core

The documentation in cvs suggests that one can simply specify arbitrary
values for alchLambdaPlusDelta and alchLambdaMinusDelta, which seems to
me like the right way to do things. One can wrap this with a (very)
simple script to, for example, run through a list of lambda values, and
always set the minusDelta to the previous value and plusDelta to the
next value. It seems sensible, though, to keep the lowest level
interface (which is what is currently documented -- giving single
values), and consider adding, eg, a "alchLambdaMinusDeltaList" command
as an extra.


Chris Harrison wrote:
> I've implemented doublewide with both a forward and reverse work
> lambda. This is not in the CVS yet, but should be available there in
> several weeks. But in reading Floris' comment I'm thinking it does make
> more sense to implement doublewide's forward and reverse work lambda's
> as lists to accomodate very non-linear perturbation paths ... to allow
> one to match exactly the set of lambda's composing the perturbation
> path. Any holes in this logic?
> C.
> --
> Chris Harrison, Ph.D.
> Theoretical and Computational Biophysics Group
> NIH Resource for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave., Urbana, IL 61801
> <>
> Voice: 217-244-1733
> Fax: 217-244-6078
> On Thu, Jan 22, 2009 at 4:58 AM, Floris Buelens
> < <>> wrote:
> > No, formally this is correct. Numerically though, samples of dE are
> > correlated, so you get pretty much the same statistics by storing it
> > every 10 timesteps or so. You could try it - downsampling dE data from
> > a calculation, and seeing how far you can go without changing the
> > result.
> I agree with Jerome - with linear potential scaling you can
> trivially extrapolate at any timestep the potential energy for any
> value of lambda, but as I think you already realised, you don't
> benefit from the cumulative averaging of the FEP dG that NAMD
> performs for the comparison value lamda2. You can do this yourself
> by post-processing; you could sample less frequently than every
> step, in which case you have to weigh up discarding lots of your
> data against the fact that the intervening values will be highly
> correlated. And as you imply, this approach is anyway no longer
> applicable when using soft core vdW.
> > Again, you are right: actually this is now implemented. The problem
> > is, I think, that the user's guide in CVS has not yet been updated to
> > document this. There is some work being done on that side...
> Actualy there's no provision for a second comparison lambda (a
> 'lambda3') yet, and to my knowledge all the key functionality is
> already documented in CVS.
> I agree that double-wide sampling / Bennett acceptance ratio
> estimatation needs two independent comparison lambdas: the 'forward'
> work to the 'next' point in the transformation and the 'reverse'
> work to the 'previous' point in the transformation. A scheme that
> only calculates work from λ to λ+δλ and λ to λ-δλ appears to me to
> assume linear spacing of intermediates in the transformation, which
> for the work I do is never true...
> best regards,
> Floris


This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:52:17 CST