[gmx-developers] Re: gmx-developers Digest, Vol 46, Issue 9

[Michael Shirts]

Hi, all-

> I agree that this might often not be a good approximation.
> But at least the exchange code is there now (although completely
> invisible to the user). So people can experiment with it,
> knowing the limitations.
> Even without the foreign lambda code, one could just call do_force
> with a different lambda at an exchange attempt.
> But it might be better to wait till the foreign lambda code is ready.

I think it might be better to wait.  Anyone who has the sophistication
to really beta test the code is probably willing to wait to have
exchange in there correctly!  I'm planning on waiting, for example :)

> One issue with the foreign lambda code is constraints.
> When constraint lengths depend on lambda, one can not simply
> determine the potential energy for a different lambda
> than at which the actual state is.

Certainly, this is the case.  There should be clear warnings if there
are any lambda-dependent constraints, so that people don't go and try
to predict things using it.  I try to set up simulations where
different constraints will cancel out from the thermodynamic cycle --
for example, when mutating a ligand from A to B, turning off the
bonded/torsion terms to a common nonbonded substructure in both the
ligand and protein environment.

I think that this is another reason one might want to also implement a
general Trotter decomposition method and do the bondeds every 1 fs,
and the nonbondeds every 4 fs, instead of constraints.  Then there
won't be any such issue.

Cheers,
Michael