[gmx-users] Implemetation of the CHARMM27 ff into gromacs : managment of dihedral terms

[Mark Abraham]

Nicolas SAPAY wrote:
> Hello Mark,
> 
> Thanks for your scripts. They are well commented and very easy to
> understand. Unfornunately, they don't work with my CHARMM parm files. It
> is probably a problem of format at the .par begining. I don't know well
> Perl but I think I can fix this.

Thanks for the compliment! It is also good to know that somebody else 
has looked and hasn't noticed any error I might have made in the scripts 
:-) If you want to send me the parm files off-list I can probably 
develop a work-around quite easily, but I may not get to it until next week.

> In the conversion made by Yuguang MU, available in the Gromacs site,
> improper angles seem to be treated by a periodic function, as said
> previously. for exemple, the dihedral angle between O, CT1 NH2 and CC
> types is defined as followed in the CHARMM .par
> i    j    k    l    Kpsi      ignored   psi0
> O    CT1  NH2  CC   45.0000   0         0.0000
> 
> after conversion by Yuguang, it becomes in the xxxbon.itp
> [ dihedraltypes ]
> #define  improper_O_CP1_NH2_CC_  180.00000  94.14000  2
> 
> and in the xxx.rtp
> [ impropers ]
> C NT -CA O improper_O_CP1_NH2_CC_
> 
> while in your scripts, impropers are defined in the [ dihedraltypes ] with
> function 2. So, I'm not sure to well understand the trick behind that...
> May be it depends on the way that CHARMM and Gromacs have implemented
> harmonic functions?

You will notice in section 5.5.1 of the GROMACS manual that the .rtp 
file implicitly defines the function number of the impropers - 2 in this 
case. Also there, it is described that you can give override parameters 
here, or (as in GROMOS96 force field) a symbolic string that is #defined 
in the .itp files. This usage is adopted by Yuguang in his .rtp and .itp 
files, but it is not encouraged. Thus my .itp files do not define those 
symbolic strings, instead relying on the implicit function number, the 
listed atom names (which imply the four atom types) and the ability of 
grompp to look up the correct function with this information. pdb2gmx 
uses the [impropers] section of the .rtp file blindly to fill a 
secondary [dihedrals] section of the .top file for the impropers. If you 
use Yuguang's .rtp then those symbolic strings will be there in the .top 
file, but silently ignored by grompp when the preprocessor can't find 
anything useful to do with them, and the lookup proceeds as normal. You 
can verify this with gmxdump -s file.tpr | less and looking for the 
IDIHS section which describes the functional forms and gives a unique 
index for each one actually used, and then the "Improper Dih.:" section 
that lists the atom numbers such an interaction together with that index 
to look up the functional form. Also you could strip the symbolic 
strings from the .rtp file and have an aesthetically pleasing solution :-)

> Additionally, I have checked how you deal with the 1-4 LJ parameters of
> CHARMM.  You define them as comment on the same line than regular LJ
> parameters, in the atomtypes section of the xxxnb.itp file, and then
> correct them with the second script. It is probably a stupid question (I'm
> new in Gromacs :-) ), but is it  a good idea to defined 1-4 parameters in
> the [ pairtypes ] section? Let's say that the atom type CT1 is defined
> with 1-4 LJ parameters. Then, it can be possible to define all  pair with
> CT1 with its 1-4 LJ parameters int the pairtypes section and use them to
> produce the .top... It is probably not a bright solution, but if it can
> work...

There is the alternate way to skin the proverbial cat that you describe. 
Given that I'm doing post-processing for other reasons, I judged it 
easier not to generate the N*N pairtypes for the .itp file from the N 
atom types from the .prm file, but rather to fix it after the fact in 
the .top file. Arguably a false economy, but I believe it works :-)

Mark