[gmx-developers] force field reorganization done

[David van der Spoel]

On 1/27/10 3:34 PM, Berk Hess wrote:
> David van der Spoel wrote:
>> On 1/27/10 2:03 PM, Berk Hess wrote:
>>> Hi,
>>>
>>> I have committed the force field reorganization code and all the force
>>> field files to git master.
>>>
>>> If anyone wants to test, please go ahead and give feedback.
>>> This is a critical part of GROMACS and should be well tested.
>>>
>>> The only thing missing, I think, is updating the Makefile.am in
>>> share.top and adding ones
>>> in the .ff subdirs.
>>
>> I've just updated and added stuff to the Makefile.am, now at least one
>> can install gromacs. A test with the OPLS ff works, however with
>> encads I get:
>> Atom type opls_135 (residue ACE) not found in atomtype database
>>
>> The fact that ACE is not in the database does not concern me, but the
>> ref to opls_135 is weird. In the encads.ff files there is no mention
>> of opls_135 in any file.
> That is very strange indeed.
> I did a grep on opls_135 and it only occur (except for the opls
> parameter files) in:
> oplsaa.ff/aminoacids.rtp and oplsaa.ff/atomtypes.atp
> So I don't see how it could ever end up in a non-oplsaa topology.
>
> Did you generate this top with the new pdb2gmx, or is this an old top
> with the new grompp?

A very subtle "user" error. I had another rtp (new.rtp) file lingering 
in the same directory that was read before the encads.rtp. I'm not sure 
this behavior is what we want, is it? If I had a local modified copy of 
encads.rtp I would want pdb2gmx to replace the default one with that, 
but I would not want pdb2gmx to replace encads.rtp by gmx.rtp, or what 
do you think?

>
> Berk
>>
>>> Also the manual still needs to be updated.
>>>
>>> Now we can add the AMBER and CHARMM force fields with proper building
>>> block
>>> naming support and support for renaming terminal building blocks.
>>>
>>> I am still thinking if it would be useful to be able to keep the
>>> "proper" residue names
>>> and not replace them by the building block names. This might not be very
>>> useful,
>>> because you can no longer easily see the protonation state or special
>>> bonds of residues.
>>
>> In the context of qhop-development we are thinking of having all
>> protons on all residues (e.g. two H on a GLU sidechain) and store an
>> existence function in the occupancy field of the pdb. Maybe this
>> should not be done in general, but some feedback on the idea would be
>> appreciated.
>>
>>
>>>
>>> Berk
>>>
>>
>>
>


-- 
David van der Spoel, Ph.D., Professor of Biology
Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205. Fax: +4618511755.
spoel at xray.bmc.uu.se	spoel at gromacs.org   http://folding.bmc.uu.se