Gmx gangle skewing the values of a dihedral

GROMACS version: 2021
GROMACS modification: No

Dear Users,

I’m having an issue with gmx gangle and wondered if anyone has seen anything similar.

The example I’m showing is for the glycosidic linkage of xylobiose, but the problem occurs for my other, more complex carbohydrate simulations as well. I am using the GLYCAM06 force field. Basically, the Ramachandran plots I was getting were mismatching with the literature (for example Berglund et. al.). I’ve matched their method parameters, and the plots have the same contour spacing of 2 kJ/mol:

Clearly, they mismatch - there’s a weird stretching effect in psi. At first I thought this was a force field issue, but eventually I’ve worked out that the problem is gmx gangle, which I have been using to extract the glycosidic dihedrals (and other variables) from my simulations. When I instead use VMD to do this, I get the following:

which matches the above (and other references).

I’ve tried using gangle both on raw and cleaned (centred, waters removed etc.) trajectory files, to make sure this wasn’t the making the difference, but the results are the same.

By directly comparing scatter plots of each individual dihedral, phi and psi, sourced using either gmx gangle or VMD, I find that phi is identical with eclipsing points while psi is totally off. I have triple checked the atom indices I’m giving to gangle and they are correct, besides there is no other dihedral which could produce the top plot - it’s a skewed version of the correct one.

Here’s the command I’m using:

$ gmx gangle -f *trr -s *tpr -oall 2X_diheds_all.xvg -oh 2X_diheds_hist.xvg -xvg none -sf 2X_diheds_GLYCAM.dat -g1 dihedral

And the selection file reads:

atomnr 22 20 19 9 permute 4 3 2 1;
atomnr 20 19 9 11 permute 4 3 1 2;

Either I’ve found a bug or I’m doing something wrong, in either case if anyone has any insight or similar experience, it would be much appreciated.




you can check if the binwidth is the same.
gmx gangle use a binwidth of 1 (as default), see option -binw

Best regards


I’m afraid it’s certainly not the bin size as the discrepancies I’m seeing are specifically in the time series data (-oall). The binning and plotting is done using my own python scripts.