[gmx-developers] Re: water optimization?

[Erik Lindahl]

Hi,

I think Berk stepped in and answered some of this, but anyway:
>
> I'm working with David Mobley and John Chodera at UCSF to port my free
> energy changes that I put in 3.1.4 into 3.3.  Here are some of the
> things we've been thinking about -- it would be great to hear your
> thoughts (and I'm cc'ing this to the developer's list to get
> additional thoughts). Are there any suggestions or thoughts on these
> subjects as we work on getting them in?
>
> Here are our thoughts:
>
> 1) A toggle for decoupling versus mutating interactions of  
> perterbed atoms.

This should be pretty straightforward - Berk, are there any special  
reasons why all all interactions (infinite cutoff) need to be  
included in the decoupled state if they aren't there in the coupled one?

I understand the problem with PME, but then I guess we could either  
just create a separate list with all interactions if the decoupled  
molecule is tiny, or use an extra PME call to calculate the  
interactions of the separate states.

> 2) Being able to print out the energy differences to arbitrary numbers
> of different lambda values from the equilibrium sampled value, for use
> in FEP, or BAR/WHAM

This one is quite easy - just call the free energy loop multiple  
times during a run.

>
> 3) Eventually, a new g_bar (or perhaps modification of g_wham) to
> handle these calculations with the standard gromacs tools.

Not sure if we'll have time to write that, but I'd be happy to  
include it if someone does :-)

>
> 4) Evaluating the free energy only every N steps (it becomes expensive
> when multiple PME calls are required)

As Berk mentioned, the only duplicated step is the force back- 
interpolation - so make sure we're not comparing it with a non-PME  
run. How slow is the run compared to the same system running without  
free energy?

In the long term, the best option both for PME dG/dl and decoupling  
might be to use standard Ewald for small separate parts of the  
system, since that comes with way less overhead (even though it  
doesn't scale very well).

Cheers,

Erik

-----------------------------------------------------------
Erik Lindahl  <lindahl at sbc.su.se>     Backup address:  
<erik.lindahl at gmail.com>
Assistant Professor, Computational Structural Biology
Stockholm Bioinformatics Center, Stockholm University, SE 106 91  
Stockholm
Phone: +46 8 5537 8564     Fax: +46 8 5537 8214