Wrong about RALEE bug

After having email discussion with Sam Griffiths-Jones, the author of RALEE, I discovered that there was a difference interpretation, not a bug, and I decided that Sam's interpretation was better.

I had interpreted a contiguous run of base pairs to be a helix, but after looking at a few structures in VARNA, I realized that some of the "helices" could be considered one helix with a few bulges. Sam gave some good examples:

You have continuous on one side, but not the other:

.((((((...))).))).

Alignments where a helix is continuous in most sequences, but bulged occasionally:

AGCGCUUCG.CU
AGCGCUUCG.UU
AGCGCCGCG.CU
AGCGCUUCG.CU
AGGGCUUCC.CU
AGCGCUUCGGCU
((((...)).))

In the above case, what is a helix could be subject to arbitrary change, just by adding one sequence with a bulge.

Bug in RALEE code

I came across across a bug in the RALEE code that processes the secondary structure line in Stockholm files. The Stockholm file (of vault proteins) just happened to break the code that processes how many helices there are and associates a helix number with each base pair position. Here are the cases that I had to fix:

1. <<..<<..<<..<<<..>>>>>..>>>>

2. <<<<..<<<<<..>>>..>>..>>..>>

If there isn't another separate helix within the sequence, the helices that aren't separated by unpaired nucleotides can't be detected in the original code. I was able to fix the bug by adding more cases. Hopefully I haven't created another bug.

What happens when you open a Stockholm File?

Alot of things, and a journey through how Jalview works. I wrote out part of this before in my notebook, but I hadn't connected it to the Stockholm file parser before. I haven't described the different types of objects yet, but here is the data flow:


jalview.gui.Desktop calls file loading functions, Stockholm parse is called, and then a new window with the alignment is displayed.

In jalview.gui package
-Desktop.instance.inputLocalFileMenuItem_actionPerformed(viewport) is called
--->calls FileLoader.LoadFile() in jalview.io package
-------this starts a new thread, which calls FileLoader.run() (use start() method to do this)
-----------Checks file format
-----------Alignment object = FormatAdapter().readFromFile(source,format) in jalview.io package
-------------->calls AppletFormatAdapter.readFromFile
------------------>Calls StockholmFile()

In StockholmFile in jalview.io
-StockholmFile extends AlignFile which extends FileParse
--->Fileparse() resolves type, checks if valid file type, position in file
--->AlignFile() calls parse(), which is in StockholmFile()
------->StockholmFile.parse() called
-----------checks if file has Stockholm file features, e.g. starts with #STOCKHOLM \d.\d
-----------use regular expressions to figure out line type
--------------if not an annotation line, process sequence line and store in hashtable
--------------else, figure out annotation type
------------------>if GC annotation, call parseAnnotationRow() to parse secondary structure

StockholmFile.parseAnnotationRow(annotations member of AlignFile, ID, sequence)
-make Annotation array else
-for each position in sequence
---->make Annotation obj ann
-------->component secondary structure determined by getDssp3State (jalview.schemes.ResidueProperties)

(Basically this is creating an annotation for each position)

-create AlignmentAnnotation object annots
--->calls validateRangeAndDisplay()
------>calls labelsSecondaryStructure()

-returns annots


Finally, back in the Desktop instance, the viewport is changed and you see the alignment visualization.
--if viewport exists, update using firePropertyChange()
--else new AlignFrame object is created
-----new AlignViewport object is created and initialized

Regular expressions in Jalview

I was looking at this about a week ago, and I decided that it might be worthy of a blog post. Part of the parsing of Stockholm files in Jalview utilizes the power of regular expressions, and Jalview uses the com.stevesoft.pat package. It simplifies some of the syntax; a tutorial is online here.

With this package you can create Regex objects and compile and match regular expressions. The Stockholm file parser detects the end of the file, annotation and sequence lines, and parses lines using regular expressions.

Bug tracker, svn

Jalview has a bug tracker which can be found here.

I found a bug with reading Stockholm files and I logged it there. There were a few Stockholm files from Rfam that I wasn't able to open. "\\" is used to denote the end of a Stockholm file, which coincidentally is found in urls! I fixed the bug by requiring that the line with "//" start with "//" or a space then "//".

After fixing this bug I decided to start a branch in my svn repository (just to try it out), but I found out that I did not do this correctly. The svn red book has a nice entry about branch philosophy. What you should do is copy the existing trunk into the new branch. This allows diffs to be created properly between different versions. For now I am not going to have branches since Jim is going to set up an official repository for Jalview later.