[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
Hi,
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.
Cheers,
Erik
More information about the gromacs.org_gmx-developers
mailing list