[gmx-developers] force field reorganization

[Berk Hess]

Mark Abraham wrote:
> Good idea.
>
> ----- Original Message -----
> From: Berk Hess <hess at cbr.su.se>
> Date: Tuesday, January 26, 2010 2:13
> Subject: Re: [gmx-developers] force field reorganization
> To: Discussion list for GROMACS development <gmx-developers at gromacs.org>
>
>   
>> Ah, good that you mention this.
>> I thought about this, but forgot about it.
>> I will add a check such that is always uses the first entry and 
>> warns you
>> when it ignores are second one.
>> Your working dir will always be read first.
>>     
>
> Hopefully this means that the contents of the working directory take *precedence*, rather than being read first, and over-written later by the GMXLIB contents.
>   
Yes.
If a second residue topology is found for a certain residue, pdb2gmx
prints a note
that it ignores the second entry in file yy and will use the first entry
from file xx.
> To add an extra ion type to (say) OPLSAA, would it be necessary to have oplsaa.ff directory in the working directory, with modified files forcefield.atp and ions.itp? Or will be sufficient to have such files with only the extra information required?
>   
Here nothing will change.
The changes only affect pdb2gmx.
The topology will contain, for example, the following includes:
#include "oplsaa.ff/forcefield.itp"
#include "oplsaa.ff/ions.itp"
#include "oplsaa.ff/spc.itp"

So for adding a new ion nothing has changed.
You will have to add it or in the force field directory or in a local
extra itp file
which you will have to manually include in your topology.

Berk
> Should grompp and pdb2gmx have a verbose mode that is able to report which file contributed which piece of data?
>
> Mark
>  
>   
>> Another feature is that you can now have different bonded settings
>> (bond, angle, dihedral types, nrexcl, etc.) for rtp entries in 
>> differentfiles.
>> But within each moleculetype only one setting can be used, pdb2gmx
>> checks this.
>>
>> Berk
>>
>> Tsjerk Wassenaar wrote:
>>     
>>> Hi Berk,
>>>
>>> Sounds like a good idea. So it would also be easy to add 
>>>       
>> ligands, as
>>     
>>> it would only require to put a ligand.rtp to the directory, without
>>> editing the original files? But what will happen if a certain 
>>>       
>> residue> is defined in different files? Will it issue a warning, 
>> or an error,
>>     
>>> something else?
>>>
>>>
>>> Cheers,
>>>
>>> Tsjerk
>>>
>>> On Mon, Jan 25, 2010 at 3:34 PM, Berk Hess <hess at cbr.su.se> 
>>>       
>> wrote:>   
>>     
>>>> Hi,
>>>>
>>>> I have made some changes in pdb2gmx to better organize all 
>>>>         
>> the force
>>     
>>>> field files.
>>>> But before I commit, I would like to have some feedback from 
>>>>         
>> the GROMACS
>>     
>>>> community.
>>>>
>>>> If have now made it such that force fields are all in separate
>>>> directories and there is
>>>> no longer an FF.dat file.
>>>> Force fields are now detected by pdb2gmx by a filename in a 
>>>>         
>> subdirectory>> as follows:
>>     
>>>> <ffname>.ff/forcefield.itp
>>>> For example for OPLS:
>>>> oplsaa.ff/forcefield.itp
>>>> If the directory also contains a file forcefield.doc, the 
>>>>         
>> first line of
>>     
>>>> this file is assumed
>>>> to be a short description of the force field and this is printed
>>>> (previously this was in FF.dat).
>>>>
>>>> pdb2gmx then reads any files ending on .atp, .r2b, .rtp, 
>>>>         
>> .tdb, .hdb,
>>     
>>>> both from the force field directory and the current working 
>>>>         
>> directory.>> The only mandatory files are one .atp file and one 
>> .rtp file.
>>     
>>>> Termini from .tdb files are only applied to rtp entries from 
>>>>         
>> .rtp files
>>     
>>>> with the same base file name.
>>>> The general idea is to have, for instance:
>>>> atomtypes.atp
>>>> aminoacids.rtp
>>>> aminoacids.n.tdb
>>>> aminoacids.c.tdb
>>>> aminoacids.hdb
>>>> dna.rtp
>>>> dna.n.tdb
>>>> dna.c.tdb
>>>> dna.hdb
>>>>
>>>> Especially useful for AMBER, you can have .r2b files to map residue
>>>> names to building block names,
>>>> depending on the protonation state and if in termini or not.
>>>> Also useful for AMBER, you would not longer be required to 
>>>>         
>> make tdb files.
>>     
>>>> pdb2gmx checks if there are no dangling bonds due to missing 
>>>>         
>> termini.>>
>>     
>>>> For backward compatibility of grompp there would still be a 
>>>>         
>> file such as
>>     
>>>> ffoplsaa.itp
>>>> in the lib dir, which would simply #include 
>>>>         
>> ffoplsaa.ff/forcefield.itp,>> similarly there will
>>     
>>>> be spc.itp, tip3p.tip, ions.itp etc.
>>>>
>>>> Are there any objections or comments?
>>>>
>>>> Berk
>>>>
>>>> --
>>>> gmx-developers mailing list
>>>> gmx-developers at gromacs.org
>>>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>> Please don't post (un)subscribe requests to the list. Use the
>>>> www interface or send it to gmx-developers-request at gromacs.org.
>>>>
>>>>     
>>>>         
>>>
>>>   
>>>       
>> -- 
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the 
>> www interface or send it to gmx-developers-request at gromacs.org.
>>