From: Stefan Doerr (stefdoerr_at_gmail.com)
Date: Mon Feb 09 2015 - 10:53:10 CST

Hi all. I sent this message to vmd_at_ks.uiuc.edu but since I didn't receive a
response I am posting it here.
There is a bug in the secondary structure calculation in VMD. Stride is not
designed for use on MD coordinates (or really large proteins) which can
reach high positive or negative coordinate values.
The reason is that by default it reads PDB files which have a limited
number of columns for the coordinates.

Even better, in a nice example of bad coding, in p_atom.c it replaces the
first value of the coordinate fields with empty char, making coordinates
under -99.999 A, like -100.000 look positive, just so that it can split the
coordinate string on whitespace.

    strcpy(Tmp,Buffer);
    Buffer[38] = ' ';
    SplitString(Tmp+30,Field,1);
    r->Coord[NA][0] = atof(Field[0]);

    strcpy(Tmp,Buffer);
    Buffer[46] = ' ';
    SplitString(Tmp+38,Field,1);
    r->Coord[NA][1] = atof(Field[0]);

    strcpy(Tmp,Buffer);
    Buffer[54] = ' ';
    SplitString(Tmp+46,Field,1);
    r->Coord[NA][2] = atof(Field[0]);

This leads to wrong secondary structure in all molecules which move more
than 100A from the origin. I saw that VMD is writing the coordinates out
for each frame into a PDB and feeding it to STRIDE. So the problem
definitely exists in VMD and I've seen it happen in various cases.

I have made my own version of Stride which can be compiled into a C project
like VMD, which accepts atom coordinates directly in a C matrix instead of
reading them from a PDB to avoid truncations and also fixes multiple memory
leaks in the code. I could provide you the code, however it would require a
bit of work to make it work in VMD since I only implemented it for a single
chain and I haven't looked up how to access all the atom information it
needs from the VMD source code.

Best greetings,
Stefan