[gmx-developers] pdb2gmx default water model

[Justin A. Lemkul]

Maybe there should be a hybrid approach from everything that's been said.  Since 
even the use of SPC/e may be complicated depending on the user's purpose, I 
don't think there is any true way to make pdb2gmx incredibly smart.  I would 
vote for providing a default water model for each force field (which is already 
in place for Encad, anyway), but also always print a big, bold note (much like 
what grompp does) at the very end of the pdb2gmx output saying that a choice has 
been made and that this may or may not be suitable for the user's purpose.  I 
don't see a way to satisfy everyone.  If I choose Gromos96 53A6 for a protein, I 
may want SPC/e, but if that protein is in a membrane, I want SPC.  There's no 
way for pdb2gmx to outsmart the user, nor should it try :)

GROMACS can only do so much to help the learning curve, but I do agree with 
Michael's assessment that one needs to do some homework before plowing ahead 
with eyes shut and fingers crossed :)

-Justin

Thomas Piggot wrote:
> Maybe I am wrong but I thought that different water models are more (or 
> less) appropriate for certain systems, as well as being forcefield 
> dependant?
> 
> For example SPC has been shown to perform better than SPC/e when 
> simulating membranes (Tieleman and Berendsen 1996 J Chem Phys) but SPC/e 
> is better than SPC when simulating proteins (Hess and van der Vegt 2006 
> J Phys Chem B). Doesn't this make things more complex than having a 
> single appropriate default model for a forcefield?
> 
> And also what about the issues where it is not so clear as to which 
> model is the appropriate default. For example CHARMM TIP3P Vs. standard 
> TIP3P model for use with the CHARMM forcefield. Would it be standard 
> TIP3P because of the increase in speed as discussed in the recent 
> ffcharmm paper or would the more commonly used CHARMM TIP3P be a better 
> choice?
> 
> Because of these points I think having SCP/e as default with a clear 
> message saying that the user should be warned that this may not be the 
> best water model for their system would be the best way to handle this.
> 
> Cheers
> 
> Tom
> 
> Anton Feenstra wrote:
>> On 16/06/10 17:24, Shirts, Michael (mrs5pt) wrote:
>>>> I thought about that, but I think that choice is asking too much in
>>>> terms of knowlegde
>>>> from the general user.
>>> See, I'm all in favor of making them think a little.  If you don't 
>>> know what
>>> water model you should use, you don't deserve to be running a 
>>> simulation.
>>>
>>> Make them look up what they should be running, as long as the error 
>>> message
>>> pretty clearly says that - something like:
>> [...]
>>
>> I don't agree here. Yes, the user should be responsible for her 
>> choices, but also a good tool should come with a *full* set of 
>> appropriate default options. Then, it is clearly the responsibility of 
>> the user to assert their validity for a particular application.
>>
>> Is/are there (a) paper(s) that say that either SPC or SPC/e is the 
>> better water model? If most non-expert users would prefer SPC /or/ 
>> most reviewers would require that (for historical reasons of no other 
>> /or/ some well-cited papers highlight SPC as the best option, then I'd 
>> argue to leave that the default.
>>
>> Expert user will (want to) know better ;-)
>>
>> B.t.w., how transferable are water models between ff's? I've always 
>> been thought that they are actually non-transferable (or at least that 
>> is what I remember), making e.g. Amber/SPCe a bad option, as would 
>> gromos/tip4p.
>>
>>
> 

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

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

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