[gmx-developers] do_dssp bugfix

Carsten Kutzner ckutzne at gwdg.de
Wed Apr 29 12:04:30 CEST 2009


Hi,

I have not commited yet since there were also other inconsistencies in  
do_dssp:

If one inputs a file with more than one chain

- the area.xpm file would miss one y value per chain, since the empty  
lines for
   the chain separators were not taken into account
- the averea.xvg output was incorrect for all chains other than the  
first one,
   again due to the chain separators. For the same reason the  
totarea.xvg
   contents were completely wrong
- the scount.xvg file output was wrong for the "Coils" column, since  
the chain
   separators were counted as coils (they were assigned the same  
symbol "~")

I have corrected all these things and also a few minor ones:

- there was an extra axis entry in the ss.xpm file leading to an extra  
"0" at
   the end of the x-axis
- Now there is a special symbol "=" for chain separators such that  
they can
   be distinguished from Coil structures.

The only question that I have before commiting is whether the ss.map  
file
is also used by other programs than do_dssp. In that file I added an  
extra
Chain_Separator entry, which I suppose is ignored by possible other  
tools.

Carsten



On Apr 27, 2009, at 7:51 PM, David van der Spoel wrote:

> Carsten Kutzner wrote:
>> Hi,
>> we have recently detected a memory problem in do_dssp.
>> When do_dssp is given an input pdb containing more than 10 chains,
>> memory corruption is likely to appear. This happens because the
>> strip_dssp function assumes that the number of lines in the file  
>> written
>> by the dssp program is equal to the number of residues. However,
>> the dssp output file also contains chain separators in separate  
>> lines,
>> resulting in an extra line per chain.
>> For some reason, the affected arrays are currently snewed with (nres 
>> +10)
>> elements, allowing for 10 separate chains at most. I would suggest to
>> snew them with 2*nres-1 elements, allowing each residue to be a
>> separate chain at most.
>> The allocations that have to be extended are for the variables bb,
>> average_area, av_area, norm_av_area, and accri[i].
>> Should I immediately fix that in the head and 40 branch?
> Yes, please do.
>
>> Carsten
>> -- 
>> Dr. Carsten Kutzner
>> Max Planck Institute for Biophysical Chemistry
>> Theoretical and Computational Biophysics
>> Am Fassberg 11, 37077 Goettingen, Germany
>> Tel. +49-551-2012313, Fax: +49-551-2012302
>> http://www.mpibpc.mpg.de/home/grubmueller/ihp/ckutzne
>> _______________________________________________
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://www.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the www  
>> interface or send it to gmx-developers-request at gromacs.org.
>
>
> -- 
> David.
> ________________________________________________________________________
> David van der Spoel, PhD, Professor of Biology
> Dept. of Cell and Molecular Biology, Uppsala University.
> Husargatan 3, Box 596,  	75124 Uppsala, Sweden
> phone:	46 18 471 4205		fax: 46 18 511 755
> spoel at xray.bmc.uu.se	spoel at gromacs.org   http://folding.bmc.uu.se
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
> +++
> _______________________________________________
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://www.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the www  
> interface or send it to gmx-developers-request at gromacs.org.


--
Dr. Carsten Kutzner
Max Planck Institute for Biophysical Chemistry
Theoretical and Computational Biophysics
Am Fassberg 11, 37077 Goettingen, Germany
Tel. +49-551-2012313, Fax: +49-551-2012302
http://www.mpibpc.mpg.de/home/grubmueller/ihp/ckutzne







More information about the gromacs.org_gmx-developers mailing list