[gmx-users] Implicit solvent

[ms]

On 05/07/10 16:27, Justin A. Lemkul wrote:
>
>
> ithu wrote:
>> Dear gromacs Users,
>>
>> I found this in the web, but I wanted to know if there exists the
>> possibility now of using implicit solvent efficiently.
>>
>
> Implicit solvent will be supported in the upcoming release.

Since it interests me too... How far is the upcoming release from being 
useful for general work? That is, is it just unstable but can I *trust* 
it in terms of results correctness or it is better to leave it to 
developers.

Because in the first case I'd like to try it sooner or later :)

M.

> -Justin
>
>> Thanks,
>> Esteban
>>
>> A repeating question on the mailing list whether GROMACS can perform
>> implicit solvent simulations. The answer is, not really. Over the last
>> few years there have been quite a few papers in (good) journals about
>> why one in general should or should not use it. Please search
>> literature by Ruhong Zhou, Vijay Pande and/or Bruce Berne on the
>> subject (and fill in the references here plus DOI links etc.).
>>
>> * R. Zhou and B. J. Berne. /Can a continuum solvent model reproduce
>> the free energy landscape of a β-hairpin in water?/, Proc. Natl.
>> Acad. Sci. U.S.A. 99 (2002), 12777-12782 DOI
>> <http://dx.doi.org/10.1073/pnas.142430099>
>> * Young Min Rhee, Eric J. Sorin, Guha Jayachandran, Erik Lindahl,
>> and Vijay S. Pande. /Simulations of the role of water in the
>> protein- folding mechanism/, Proc. Natl. Acad. Sci. U.S.A. 101
>> (2004), 6456-6461 DOI <http://dx.doi.org/10.1073/pnas.0307898101>
>> * Hao Fan, Alan E. Mark, Jiang Zhu, and Barry Honig. Comparative
>> study of generalized Born models: protein dynamics, Proc. Natl.
>> Acad. Sci. U.S.A. 102 (2005), 6760-6764 DOI
>> <http://dx.doi.org/10.1073/pnas.0408857102>
>>
>> The current state in Gromacs is that we already have very optimized
>> assembly kernels for the actual generalized born interaction, so that
>> part is done. We also have C language functions to calculate Still
>> radii (not yet in CVS), although these have to be ported to assembly
>> for decent performance.
>>
>> The one big remaining issue is a fast surface calculation algorithm.
>> The problem with the commonly used ones (e.g. Still) is that
>> everything else in Gromacs (including the GB loops) is an order of
>> magnitude faster, so that surface calculation would take over 90% of
>> the time. They also do not parallelize easily.
>>
>> There are some tricks we can use (e.g. only calculating surface every
>> N steps), but we still need a *very* fast surface calculation
>> algorithm. The best starting point in the literature is probably the
>> algorithm of Brooks, where you simply have empiric parameters for
>> sp2/sp3/sp neighbors of different atom types combined with a short
>> neighborlist.
>>
>> We definitely need approximate derivatives of the surface free energy
>> with respect to all atom coordinates, and the last couple of years
>> there has also been some discussion that the volume term could be even
>> more important than the surface, so preferably volume derivatives too.
>> If you're interested in helping I (lindahl at cbr.su.se
>> <mailto:lindahl at cbr.su.se>) have reference code that calculates both
>> surface/volume and the associated derivatives analytically.
>>
>>
>