[gmx-developers] Re: water optimization?
Berk Hess
hessb at mpip-mainz.mpg.de
Mon Jan 2 11:13:09 CET 2006
Erik Lindahl wrote:
> 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?
You are suggesting a seperate PME calculation for the decoupled molecule
only?
Then you would include the interaction with all the periodic images,
which can have a significant contribution in vacuum.
In the coupled state one would also like to have all interactions, but this
is not possible in solution, so we use PME instead.
Also PME for the decoupled molecule would be much more expensive than
calculating
plain Coulomb interactions.
I think explicit pairs is a much simpler solution.
>
> 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.
>
A seperate list would be the most elegant solution.
I thought this would be complicated due to periodic boundary conditions.
But if we do it along with the bondeds when the molecules are whole
there are no problems (except with pbc=full).
But we would still need exclusions for all interactions within the molecule
or special loops that calculate the LJ and Coulomb minus the lambda depedent
part that the normal PME and LJ code calculate.
Berk.
More information about the gromacs.org_gmx-developers
mailing list