[gmx-developers] force field reorganization done

hess at sbc.su.se hess at sbc.su.se
Wed Jan 27 17:33:20 CET 2010


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

This behavior is intentional.
pdb2gmx warns you that it ignores the force field dir entry and uses
an rtp entry from your local copy.

But we could indeed consider only allowing this for identically named files.
If we would find to identically named entries in differently named rtp
files we would have to generate a fatal error.

Berk




More information about the gromacs.org_gmx-developers mailing list