Multiple dihedrals v5.0.2
I've noticed that pdb2gmx in version 5.0.2 does not add multiple dihedral potentials (for a set of the same four atoms) as defined in the rtp file to the topology file. I've only tried it using the GROMOS force field. It is a serious problem since multiple dihedrals are present in the carbohydrate, lipid and protein parameter sets. Versions 4.07 thru 5.0.1 produce a correct topology file.
I read in the release notes for version 5.0.2: "Fixed message about usage of dihedral type 9 (multiple proper dihedrals).", which makes me wonder if the problem is related to such a change.
Fix bug removing multiple dihedrals in main rtp entries
The Gromacs-5.0 series has had a serious bug where pdb2gmx
would only consider the first entry when several explicit
bonds were listed for the same atoms in an RTP entry. Older
topologies have worked fine.
#1 Updated by Justin Lemkul about 4 years ago
The commit you reference was not a functional change; it just modified an output message.
Type-9 dihedrals have very specific requirements. They must appear on consecutive lines, otherwise they overwrite each other instead of summing. Which version of the GROMOS force field are you using? I do not see how this affects proteins; the default dihedraltype in aminoacids.rtp is 1 (e.g. normal periodic). CHARMM and AMBER use type 9 by default.
#5 Updated by Victor Rusu almost 4 years ago
I would like to attach the files concerning this bug.
To make things simple. I attached two folders containing a protein 4LZT.
And I modified the ALA residue on the gromos 53a6 force field.
The modification was the following:
I added another proper dihedral to ALA residue.
BEFORE WAS JUST:
N CA C +N gd_40
N CA C +N gd_40
N CA C +N gd_41
GROMACS 4.5.7 is able to recognize both dihedral but GROMACS 5.0.5 cannot.
Please check the difference between the files gromacs-4.5.7/topol.top and gromacs-5.0.5/topol.top using:
vimdiff gromacs-4.5.7/topol.top gromacs-5.0.5/topol.top
#6 Updated by Erik Lindahl almost 4 years ago
While the default behavior might have changed, this is not a bug, IMHO. You are employing a force field (GROMOS 53a6) that specifically uses dihedrals of type 1, i.e. torsions where only one potential should be used for each torsion. This is also actually the case for all other residues defined in it, as far as I can tell.
Now, because GROMOS uses a bit of a screwed up format with the defines for each line instead of proper matches based on atom type names this might not have been caught in earlier versions, and you effectively got two torsions instead, but to some extent that appears to have relied on undocumented (or even incorrect) behavior?
The problem with changing pdb2gmx to allow this is that anybody who then happens to make a typo and have duplicated atom names in their torsion list would then get incorrect torsions instead of an error, despite having selected a force field where torsions should be unique.
#7 Updated by Roberto Lins almost 4 years ago
Thanks for taking a look into that. However, pretty much all classes of biomolecules in the GROMOS ff eventually uses more than one dihedral potential over a set of same four atoms. It dates back at least since 2003 with the lipid force field by Chandrasekhar et al. It's also present in the nucleic acid fff (Soares et al., 2004), sugars (Lins and Hunenberger, 2005) and more recently for proteins when using the 54A7 parameter set.
pdb2gmx has produced fine topologies for the GROMOS ff until version 4.6.7, but this change in version 5.x makes the code to generate topologies that do not correspond to a correct GROMOS topology. I don't know how AMBER deals with that nowadays, but until late 90s, early 2000s I remember that the AMBER ff also used to have more than one torsional potential over a set of same four atoms.
#15 Updated by Mark Abraham over 3 years ago
Roberto suggested that 5.0.1 was OK and 5.0.2 was not. I had a look at the history between 5.0.1 and 5.0.2 and there's almost nothing that could have such an effect, so I think that observation is wrong. Erik's 8ebd438f fixing #1395 before 5.0 seems the most likely time we introduced this problem, though I have not tested this.