VMD-L Mailing List

From: Stefan Doerr (stefdoerr_at_gmail.com)
Date: Fri Feb 13 2015 - 09:25:12 CST

Yes, I am sure that moving the protein center back to 0,0,0 would avoid
that problem as long as the protein is not some big complex

On Fri, Feb 13, 2015 at 4:17 PM, Morgan, Brittany <
Brittany.Morgan_at_umassmed.edu> wrote:

> Dear Stefan,
>
>
>
> Thank you for informing the VMD community of this issue. For those of us
> working with small proteins, would a temporary fix be to remove the
> translational motion (using an r.m.s alignment, for example) before calling
> STRIDE?
>
>
>
> Thank you,
>
> Brittany
> ------------------------------
> *From:* owner-vmd-l_at_ks.uiuc.edu [owner-vmd-l_at_ks.uiuc.edu] on behalf of
> Stefan Doerr [stefdoerr_at_gmail.com]
> *Sent:* Monday, February 09, 2015 11:53 AM
> *To:* vmd-l_at_ks.uiuc.edu
> *Subject:* vmd-l: VMD secondary structure Stride bug
>
> 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
>