Project

General

Profile

Bug #1704

Multiple dihedrals v5.0.2

Added by Roberto Lins about 2 years ago. Updated 10 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
preprocessing (pdb2gmx,grompp)
Target version:
Affected version - extra info:
5.0.2 and later
Affected version:
Difficulty:
uncategorized
Close

Description

Dear Developers,

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.

dihedral-bug-gromacs-5.0.5.tar.gz (2.61 MB) Victor Rusu, 06/02/2015 01:45 PM


Related issues

Duplicated by GROMACS - Bug #1755: gromacs topology file generated with amber99sb-ildn force field Closed 06/24/2015
Duplicated by GROMACS - Bug #1778: gromacs 5 pdb2gmx doesn't pick up multiple torsions additive torsions in AMBER99sb-ILDN Closed 07/14/2015

Associated revisions

Revision 910e8ed9 (diff)
Added by Erik Lindahl almost 2 years ago

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.

Fixes #1704, #1755.

Change-Id: I0b34aeb905dab8ea66196cabc0745583ef6d7209

History

#1 Updated by Justin Lemkul about 2 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.

#2 Updated by Justin Lemkul about 2 years ago

  • Priority changed from High to Normal

Adjusting priority because this is not a silent error. The code in toppush.c informs the user that dihedral terms are being overwritten if something is wrong in the inputs.

#3 Updated by Mark Abraham about 2 years ago

Agree with Justin. If Roberto still finds there is an issue, then please attach a tarball of the complete set of inputs to grompp, so we can reproduce the problem.

#4 Updated by Mark Abraham about 2 years ago

Ping. Can we have some inputs, please Roberto?

#5 Updated by Victor Rusu almost 2 years ago

Dear Developers,

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

NOW IS:
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

Thanks,
Victor Rusu

#6 Updated by Erik Lindahl almost 2 years ago

Hi Victor,

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 2 years ago

Hi Erik,

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.

Best,

-r

#8 Updated by Gerrit Code Review Bot almost 2 years ago

Gerrit received a related patchset '1' for Issue #1704.
Uploader: Erik Lindahl ()
Change-Id: I0b34aeb905dab8ea66196cabc0745583ef6d7209
Gerrit URL: https://gerrit.gromacs.org/4772

#9 Updated by Erik Lindahl almost 2 years ago

  • Status changed from New to Fix uploaded

#10 Updated by Erik Lindahl almost 2 years ago

  • Duplicated by Bug #1755: gromacs topology file generated with amber99sb-ildn force field added

#11 Updated by Gerrit Code Review Bot almost 2 years ago

Gerrit received a related patchset '1' for Issue #1704.
Uploader: Erik Lindahl ()
Change-Id: I0c34aeb905dab8ea66196cabc0745583ef6d7210
Gerrit URL: https://gerrit.gromacs.org/4797

#12 Updated by Erik Lindahl almost 2 years ago

  • Status changed from Fix uploaded to Resolved

#13 Updated by Erik Lindahl almost 2 years ago

  • Status changed from Resolved to Closed

#14 Updated by Teemu Murtola almost 2 years ago

  • Duplicated by Bug #1778: gromacs 5 pdb2gmx doesn't pick up multiple torsions additive torsions in AMBER99sb-ILDN added

#15 Updated by Mark Abraham over 1 year 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.

#16 Updated by Mark Abraham 10 months ago

  • Target version changed from 5.x to 5.0.7

Also available in: Atom PDF