[gmx-users] Implicit solvent

Justin A. Lemkul jalemkul at vt.edu
Mon Jul 5 17:27:17 CEST 2010



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.

-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.
> 
> 

-- 
========================================

Justin A. Lemkul
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin

========================================



More information about the gromacs.org_gmx-users mailing list