occasional missing arc from diagram drawing

[ceheitsch]

Was looking at different tRNA structures today and noticed two instances where the there is an arc missing from the diagram. This is apparent from the counts at the top of the window (see attached), which also agree with the statistics window. BA000023_b_mfe.ct.txt BA000023_b_nop.ct.txt CP000412_o_mfe.ct.txt CP000412_o_nop.ct.txt

[maxieds]

@ceheitsch This does not seem to be an issue with missing bases based on my testing. Rather, it's an issue with how we are tallying the counts displayed below the drop down boxes at the top of the window. I'm working on amending the logic now.

[maxieds]

@ceheitsch Here is what I now have:

Does this seem to make more sense now? If not can you give me accurate expected counts for common pairs between 1 and 2, 1, and 2? This is what I get as output in the form of index/index/pairIndex for each type:

1 & 2: 0/0/72
1 & 2: 1/1/71
1 & 2: 2/2/70
1 & 2: 3/3/69
1 & 2: 4/4/68
1 & 2: 5/5/67
1 & 2: 6/6/66
2: 7/7/65
1 & 2: 9/9/25
1 & 2: 10/10/24
1 & 2: 11/11/23
1 & 2: 12/12/22
1: 26/26/44
1: 27/27/43
1: 28/28/42
2: 28/28/64
1: 29/29/41
2: 29/29/63
1: 30/30/40
2: 30/30/62
1: 31/31/39
2: 31/31/61
2: 33/33/59
2: 34/34/58
2: 35/35/57
2: 37/37/55
2: 38/38/54
2: 39/39/53
2: 40/40/52
2: 41/41/51
2: 42/42/50
1: 49/49/65
1: 50/50/64
1: 51/51/63
1: 52/52/62
1: 53/53/61

And it seems to make sense now to me: 22 pairs for structure1, 25 pairs for structure 2, of which they share 11 pairs, and have (respectively) 22-11=11 and 25-11=14 to themselves...

[maxieds]

Now the trick should be debugging the three structure case.

[ceheitsch]

Here is another example. The attached ct file has base pairs (9,45) AND (8,46), but the program (still v2.2.2-testing on my desktop machine) is only drawing one of them. Please see if the current version has both drawn. Thanks! o.nivara_region_07c.dot.txt

P.S. The selection window to ct file viewer is EXCELLENT.

[maxieds]

@ceheitsch Ok. I believe I pinned down the issue. This is the new resulting diagram:

[maxieds]

Mac OSX 10.14.x support verified!

[ceheitsch]

Reopening this issue because I discovered a missing base pair in the arc diagram. The original file this time is a dot format (rather than ct). In the ct file viewer, there is a base pair (8,49). I confirmed (but you should of course double-check!) that it's there in the dot file. However, it isn't appearing in the arc diagram.

hyperthermus.butylicus.dsm.5456_CP000493_ad.max.dot.txt

[maxieds]

@ceheitsch I just pushed code to fix the last error with the missing arc (8, 49). Please be aware that there was a more insidious bug that has existed for a while that (I guess) happened in the transition between FLTK drawing to Cairo graphics! Namely, the FLTK routines apparently used angles in degrees where Cairo drawing methods want arcs specified in radians. This fix has been made, but could affect older data generated with the application.

Please note by inspection (there are 79 total bases in the example above) that the bounding tick mark labels drawn around the circle are incorrect. I will work on fixing that part of the issue next.

[ceheitsch]

Reinstalled RNAStructViz (now v2.3.6-testing), but don't see the (8,49) base pair; what I see still looks like the picture that I posted, and not like the picture that you posted. FWIW, this is on a laptop running 10.14.4.

[maxieds]

@ceheitsch I was waiting to release the version with the fix v2.3.7-testing until I fixed the errors with the bounding tick mark labels (to save everyone the hassle of having to reinstall twice). It will get released soon. The v2.3.6-testing release does not yet have the critical degrees to radians fix. I will message you as soon as the new brew formula for the updated release is available.

[ceheitsch]

Yes. Just realized that the version I have isn't 2.3.7. Not sure when I'll next have time to deal with this, but great that we're making progress.

[maxieds]

@ceheitsch The new testing release of v2.3.7-testing can now be installed (has been verified to work) with brew. I believe you can now close out this issue.

[ceheitsch]

The hyperthermus.butylicus.dsm.5456_CP000493_ad.max.dot structure is now displaying correctly. Do you know why this was a problem although the o.nivara issue was fixed? In other words, before closing this issue thread again, it would be good to be certain that the underlying problem has been addressed. Thanks!

[maxieds]

@ceheitsch I do not know precisely, but I can guess on the order of this problem...

The last release fixed a Cairo drawing error where the routines were expecting arc angles in radians, but instead we were erroneously specifying the angles in degrees. As I pointed out in previous posts above, I believe this error crept in somewhere in the transition between FLTK native drawing (as was in place before I started working on the codebase) to the updated Cairo graphics drawing.

Note that even with the angles specified in degrees, the resulting diagrams still resemble the correct diagram behavior (for the most part, with the exception of some missing corner cases you pointed out leading to this fix). In your newest hyperthermus.butylicus.dsm.5456_CP000493_ad.max.dot structure case, there were missing arcs due to this error whereas in the first o.nivara structure case this did not occur.

I am confident that having fixed the radians-versus-degrees near debacle of sorts, the drawing behavior should now be correct. If another issue shows up, do not hesitate to bring it to my attention!

[ceheitsch]

Seems reasonable to justify closing issue.