[gmx-developers] force field reorganization

[Berk Hess]

Exactly.
It should be easier now, since you no longer need an FF.dat file
and you can also have a forcefield as a subdirectory of your working
directory
without having to set env.vars.

Also water model management is simpler, since each force field directory
will
have its own water model files.

Berk

Justin A. Lemkul wrote:
>
> I assume it will also still be relatively easy to implement new force
> fields? In the past, it was as easy as copying the necessary files to
> $GMXLIB and updating FF.dat.  Now I assume one can simply add a new
> <something>.ff directory containing all the appropriate files and
> pdb2gmx can process them?
>
> -Justin
>
> Berk Hess wrote:
>> 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.
>>
>> Another feature is that you can now have different bonded settings
>> (bond, angle, dihedral types, nrexcl, etc.) for rtp entries in different
>> files.
>> 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.
>>>>
>>>>     
>>>
>>>
>>>   
>>
>