[gmx-developers] re: Energy and Foreign Lambdas and Hamiltonian Replica Exchange

[Erik Lindahl]

Hi Matt,

Thanks - I'll look into it when I'm traveling this weekend and get  
back with an updated version!

By the way - to save some time and/or possible debugging if it works  
for me, it would be great if you could send me the input files that  
fail.


Cheers,

Erik


On Feb 19, 2008, at 1:34 AM, Matt Wyczalkowski wrote:

> On Feb 15, 2008 4:56 AM, Erik Lindahl <lindahl at cbr.su.se> wrote:
>> Hi,
>>
>> My own server is unfortunately down since it was hacked last week  
>> and we
>> were anyway about to move from Joomla to Dekiwiki, but I've  
>> uploaded a copy
>> to the ftp site. Have a look in
>>
>> ftp://ftp.gromacs.org/pub/tmp/multilambda/
>>
>> Not sure if it's useful for your stuff, and since I haven't gotten  
>> much
>> feedback for it yet you shouldn't use it for production purposes  
>> without
>> significant testing. You've been warned, have fun ;-)
>
> I've completed a first round of testing.  To get the current version
> (VERSION 3.3.99_development_20071120) to compile, I added the
> following 3 lines to the file include/types/inputrec.h,
>  #define DECOUPLING_VDW                 (1<<0)
>  #define DECOUPLING_COULOMB             (1<<1)
>  #define DECOUPLING_BONDED              (1<<2)
> This was a guess, but seems reasonable given what the constants do and
> I'm not using that functionality anyhow.  After this (and commenting
> out a for-humans-only note in the same file), compilation proceeded
> without a hitch.
>
> Reading through a generated MDP file gives good insight into the
> functionality of the code, and as an initial test I tried to make sure
> that foreign energies (which are specified by the deltaE-lambda
> parameter) match what I'd expect.
>
> The system I ran consisted of a single neutral amino acid residue in a
> 1.1nm box with 45 or so TIP3P waters; all cutoffs are 0.5nm.  The
> parameter lambda controls only the charge of all the atoms in the
> residue, so that at l=0 it is uncharged, and at l=1 the charges are
> the OPLS-AA charges.  For the first round of tests, I simply evaluated
> the energies for the initial configuration of the system. What I found
> was that the native energy (as reported in the log file) differs
> depending on whether deltaE-lambda is defined (as deltaE-lambda=1, in
> this case) or not, and that this behavior is dependent on the
> electrostatic implementation used.  Of course, the native energy of a
> system should not change due to a foreign energy evaluation.
>
> Ewald and PPPM are explicitly not supported, and fail politely when
> free energy calculations are requested.  The Reaction Field energy
> term (RF excl.) differed by an order of magnitude depending on whether
> deltaE-lambda was defined.  PME showed similar errors (but of a
> smaller magnitude).  Finally, simulations with Cutoff electrostatics
> were consistent whether or not deltaE-lambda was defined.
>
> Next I looked at the foreign energies (at various lambda), and checked
> them against the native energy of the system.   The foreign energies
> in the cutoff electrostatics system seem consistent with what I'd
> expect: in a lambda=1 simulation foreign energy at lambda=1 matches
> the native energy.  Also, for a lambda=0.5 simulation, the lambda=1
> foreign energy is consistent with the native energy of the lambda=1
> simulation, as one would expect, and vice versa.
>
> In summary, both the Reaction Field and PME electrostatics seem to
> have broken foreign energy calculations, whereas the Cutoff
> implementation seems OK according to these very preliminary tests.
>
> Regards,
>
> Matt Wyczalkowski
>
> -- 
> Matt Wyczalkowski
> Doctoral Candidate, Biomedical Engineering
> Pappu Lab: http://lima.wustl.edu
> Washington University in St. Louis
> _______________________________________________
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://www.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.