[gmx-developers] force field reorganization done

[hess at sbc.su.se]

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

Another option would be to give a fatal error by default when two
rtp entries with the same name are found and to have on option in pdb2gmx
that allows overriding.

Berk