[gmx-developers] force field reorganization done

[Berk Hess]

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?

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