Bug and Proposal: stride()

Issue #51 resolved
Xinqiu Yao created an issue

I got following warning message from calling stride()

pdb <- read.pdb("1tag")
sse <- stride(pdb)
#Warning message:
#In stride(pdb) : NAs introduced by coercion

But went well with dssp():

sse2 <- dssp(pdb)

Another issue is the inconsistency of returned class by dssp() and stride()

class(sse)
#"list"

class(sse2)
#"dssp"

Propose to return as "sse" class for both function. Accordingly, update print.dssp() to print.sse()

Comments (9)

  1. Barry Grant

    Yes this would be good. Also I would like to see some consistency with the $helix and $sheet returned from read.pdb() when the input file has these REMARK sections. Note that there is no $length in the pdb versions currently. Not a big deal but could catch someone out later - most likely me!

    Note that for vignettes etc. it would be best to take the sse from the pdb as then we done force a user to have dssp or stride installed...

  2. Xinqiu Yao reporter

    How about returning pdb$sse by read.pdb(), where pdb$sse has the same attributes to "sse" object but data extracted from PDB file directly?

  3. Lars Skjærven

    On line 112 in plot.dccm2() we could then change

     sse$helix$length
    

    to

     sse$helix$end - sse$helix$start +1
    

    so that we can provide a pdb object as input to argument sse for that funtion. I'll add that unless you're editing this file already.

  4. Barry Grant

    I am not a big fan of this idea. I like keeping it simple with e.g.

    plot.bio3d(x, sse=pdb)
    

    I don't think we need, or want, to make the pdb version consistent in every way with the dssp and stride results as we don't want to waist time with $phi $acc etc. I guess just a $length is all that I would add to the pdb $helix and $sheet for now.

  5. Xinqiu Yao reporter

    phi and acc are kind of problems for pdb$sse idea (maybe just NULL in this case). But I agree that currently we should focus on essential update and maybe leave the consistent check later.

  6. Barry Grant

    Hi Lars, there is a catch for the missing $length in my last commit and I moved plot.dccm2() to plot.dccm() so hopefully this should work with just a plot(cm, sse=pdb).

    Unfortunately, there is a strange diagonal band of white that appears with your example 1C (see below) that may be related to smoothing???

    pdb.full <- read.pdb("1sx4")
    pdb.open <- trim.pdb(pdb.full, atom.select(pdb.full, chain = "A")) 
    modes <- nma(pdb.open)
    cm <- dccm(modes)
    plot(cm, sse=pdb.open, contour=F)
    
    # Annoying white band on diag
    plot(cm, sse=pdb.open, contour=F, col.regions=bwr.colors(10))
    

    On a related note I was looking at ggplot2 again earlier and I like its various grid based options for adding layers to a plot and being able to edit them after. I think this might be the best way to go in the future for such plots that demand extensive annotation.

  7. Lars Skjærven

    I still get this error at line 125 in the vignette when calling plot.dccm() with sse=pdb.

    > plot(cm, sse=pdb.open, contour=F)
    Error in unit(length - 0.5, "native") : 
      'x' and 'units' must have length > 0
    

    I also see this diagonal white stripe and two vertical white stripes at position ~420 and ~510. hmm...

  8. Barry Grant

    I forgot to push the commit that fixed the missing sse$length from pdb fix - should be there now. The white line on the diag is related to the smoothing done in the contourplot() function. I still have not had a change to look into and fix this. Sorry. Generally I am getting fed up with lattice and am considering switching to ggplot2 for these kind of plots...

  9. Log in to comment