[gmx-developers] doing energy evaluations at alternate lambda values (i.e. for bennett acceptance ratio)

Erik Lindahl lindahl at cbr.su.se
Fri Jan 5 11:57:01 CET 2007


On Jan 4, 2007, at 6:30 PM, David Mobley wrote:

> Erik,
>> I do have to loop over the lambda values, but only in the free energy
>> loop, and since that normally only accounts for 1-2% of runtime it's
>> not a problem to do it every single step.
> For some reason I originally thought that this would also involve
> multiple calls to PME, but now I'm thinking that's not the case. Is
> that right? Are you sure there's nothing else that would be a bigger
> percentage of the total runtime? My thinking, again, was to add a
> counter that would allow the extra evaluations just to be performed
> every so often. I realize, as David points out, that the statistics
> output to the .ene files include information on all of the snapshots,
> but we typically don't use those anyway (because we want to do
> autocorrelation analysis on the timeseries of potential energies or
> some such, and because correlation times are typically comparable to
> the frequency at which we write energies to the ene file, so the extra
> data doesn't buy us anything), so it wouldn't cost us anything to give
> up having the energies stored every step.

Once it's working it's of course easy to only do it every N steps :-)

PME can be handled in two different ways. If it's a matter of  
decoupling, Berk has implemented a pretty smart hack where grompp can  
exclude all nonbonded interactions between two arbitrary groups, and  
then add them back as listed interactions (think faked 1,4) so all of  
them are included.

The advantage of this approach is that you get rid of the lattice  
complications where a decoupled molecule is interacting with the  
periodic copies of itself, and since the decoupled interactions are  
listed explicitly we can forget about the PME part too.

Alternatively, we have the group-based PME approach (that was  
complicating my code :-). This is going to be slightly more  
expensive, but probably not more than 5-10% of runtime. Once we have  
the separate group contributions we can calculate the potential for  
as many lambda points as you want without extra cost.



More information about the gromacs.org_gmx-developers mailing list