Project

General

Profile

Bug #52

periodicity not handled correctly for dihedrals computed with g_angle

Added by David Mobley over 13 years ago. Updated over 13 years ago.

Status:
Closed
Priority:
Normal
Category:
analysis tools
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

I keep noticing that when I compute dihedral angles using g_angle, periodicity
is not handled correctly anytime the dihedral flips completely around in the
course of a simulation. In particular, 360^o is never subtracted out, so over
the course of a ns or two, dihedrals go from being in the range of 0 to about
1500^o or so. I always have to take care of the periodicity when I read output
of g_angle, which is inconvenient.

Suggested fix: Subtract out m*360 when the angles are outside the range 0 to 360
or something similar.

gmx_angle.c (11.8 KB) gmx_angle.c New version of gmx_angle.c David van der Spoel, 03/02/2006 08:24 PM
gmx_angle.c (11.8 KB) gmx_angle.c New version of gmx_angle.c David van der Spoel, 03/17/2006 08:01 PM

History

#1 Updated by David van der Spoel over 13 years ago

This is by design, so that you can compute how many revolution a dihedral has
turned in one direction. You can fix it afterwards in xmgrace. One could make it
optional of course.

#2 Updated by David van der Spoel over 13 years ago

Created an attachment (id=22)
New version of gmx_angle.c

Please test this version with new flag -periodic

#3 Updated by David van der Spoel over 13 years ago

Any luck with the new version?

#4 Updated by David Mobley over 13 years ago

David:

No luck. Syntax error?

gmx_angle.c: In function 'gmx_angle':
gmx_angle.c:110: error: syntax error before 'int'
gmx_angle.c:119: error: 'bPBC' undeclared (first use in this function)
gmx_angle.c:119: error: (Each undeclared identifier is reported only once
gmx_angle.c:119: error: for each function it appears in.)
make: *** [gmx_angle.lo] Error 1

Did you try compiling? It doesn't work for me.

David

#5 Updated by David van der Spoel over 13 years ago

Created an attachment (id=27)
New version of gmx_angle.c

This version at least compiles!

#6 Updated by David Mobley over 13 years ago

David,

That compiles, but as far as I can tell it doesn't do anything. In particular,
just using "-periodic" on a trajectory where the dihedral rotates more than
360^o still gives me dihedrals running on 0 to 1500 degrees.

I looked at the code and didn't see anything obvious, but I'm not used to
parsing input arguments in C.

#7 Updated by David van der Spoel over 13 years ago

Did you use the -all flag? Please load up some input files and an example.

#8 Updated by David Mobley over 13 years ago

David,

I did some more testing on this. The -all flag does seem to change the behavior
(it adds an extra column in the xvg files output to -ov) but the entries in this
column still doesn't seem to be correct.

Also, things are even more weird than I thought. When I run it on a full 1 ns
trajectory, it doesn't work at all. But if I use trjconv to generate a partial
trajectory from 20-40 ps (using -b and -e) it works fine on that trajectory
(in that it takes out the periodicity correctly). But if I use trjconv to
generate a partial trajectory with either command alone (either -b or -e) it
doesn't work on the resulting trajectory (in that periodicity is NOT removed).

I am uploading a tarball so that you can hopefully reproduce this. I have to
apologize for the size of it, but since any trajectory where I've removed the
beginning using -b won't seem to reproduce the problem, I have to include some
irrelevant regions of the trajectory.

In my tarball are:
traj0_40.trr: Frames 0 to 40 of my trajectory (running g_angle with -periodic
on this leaves in the stuff that the -periodic flag SHOULD remove).
-traj.trr: Frames 20 to 40 of the same trajectory. -periodic works fine on this.
traj.tpr: the relevant tpr file.
- anglegps.ndx: the index file for the relevant dihedral.

It seems EXTREMELY strange to me that how exactly I apply trjconv makes a
difference in whether or not the periodicity is removed correctly. Please let me
know what the problem is, as it seems very concerning to me.

Thanks,
David

#9 Updated by David van der Spoel over 13 years ago

Hi David,

were you unsuccesfull in uploading that tarball? If it's too big maybe you could
put a http adress for me to fetch it from.

#10 Updated by David Mobley over 13 years ago

David,

Whoops. No wonder it took you so long to respond: You were waiting for me! I am not sure whether I
simply forgot to upload it, or whether the upload claimed to work but didn't upload the file (I thought for
sure I had uploaded it). Regardless, I will make another attempt at uploading now and if it doesn't work,
let me know and I will put it on the web somewhere.

David

#11 Updated by David Mobley over 13 years ago

Hmm. Seems to be too big.

I uploaded to my group's web page, but at the moment the server seems to be down. It is at
www.dillgroup.ucsf.edu/~dmobley/forbugzilla.tar.gz. You should be able to get it hopefully later this
afternoon (as soon as the server is back up).

Thanks,
David

#12 Updated by David van der Spoel over 13 years ago

This is now resolved in CVS with changes to four files. The new PBC flag is the
default, since without it averaging does not make sense (with -pbc averagin
makes only limited sense). You don't need the -all flag anymore.

Also available in: Atom PDF