[gmx-users] Overriding Wildcard dihedraltypes

[Mark Abraham]

On Thu, Jan 9, 2014 at 5:51 PM, hubert santuz <hubert.santuz at gmail.com>wrote:

> Hi,
>
> First, thanks for your detailed response.
>
>  Thanks for the question, and particularly the detail. It seems that you
>> are
>> trying use a [dihedraltypes] section in my_molecule.itp, which is
>> generally
>> a bad idea, because all such directives must appear before the first
>> [molecule] directive, which defeats the point of molecule.itp files being
>> somewhat movable. Because of that intention for molecule.itp files,
>> there'd
>> be no reason to have separate [dihedraltypes] sections that should be
>> logically treated together, so the code assumes such sections are
>> separable, and so you get unintended behaviour (perhaps particularly with
>> wildcard atom types, and/or type 9 dihedrals) unless you change
>> ffbonded.itp like you have now done.
>>
> By trying to simplify my problem, I have misleading you.
> In fact, I have 2 itp files for my molecule (its is the cholesterol) :
>   - One containing all the *types sections [atomtypes, bondtypes,
> dihedraltypes] (params_chol.itp)
>  - The second one is a 'regular' itp file containing [molecules, atoms,
> bond ] sections. (cholesterol.itp)
> So, in my topol. top, I have in reality this :
>
> #include "charmm36.ff/forcefield.itp"
> #include "params_chol.itp"
> #include "cholesterol.itp"
>
> My [dihedraltypes] directive is then before the [molecule] directive.
> I have to do this because I have 2 new atoms for this molecule so I need
> to declare them somewhere. Therefore, I also need to declare the bondtypes,
> angletypes and dihedraltypes associated with these 2 new atoms.
> All is working well except this dihedral override.
> That's why I suspected a bug but maybe it is that part I'm not doing in
> the good way...


Yes, the above is more workable, but it has the same problem that
cholesterol.itp depends on correctly formed [dihedraltypes]. I think it is
likely that the implementation assumes you would not try to declare a set
of additive [dihedraltypes] in such a modular way, since the
copy-and-modify-ffbonded.itp procedure is available. Not ideal, but odds
are excellent it won't be fixed, either ;-)

Recommended procedures are
>> * to copy the charmm36.ff directory into your working directory and modify
>> ffbonded.itp to work like you want it to, or
>> * to give explicit parameters in the [dihedrals] section of your
>> molecule.itp (*not* [dihedraltypes]), so that the parameter lookup from
>> [dihedraltypes] is not invoked at all. Note that the behaviour for
>> multiple
>> matching [dihedrals] is to add the functions; the behaviour for multiple
>> matching [dihedraltypes] is to override earlier functions (except for type
>> 9).
>>
> I'll try your second procedure and I'll let you know.
>

I'd guess that's not worth your time, given that you more-or-less have the
first solution already done.


> Thanks for the explanation between [dihedrals] and [dihedraltypes], I
> didn't know about it.
>

Diligent Googling will find me learning that one from Berk about 5 years
ago, too ;-)

Mark