Bug report (?): Inconsistencies in BAM alignments rendered at a given bp rendered at different magnification

[ymen]

Hello Dalliance developers,

I've been trying out Dalliance for a couple of days to visualize alignment data and it's been awesome! Thank you!

I wanted to raise a problem that I have encountered in my experience, however. When viewing alignment (from BAM files), I seem to get different number of reads rendered at the same base position at different magnification levels (less reads rendered at high magnification and more at lower magnification). It is a somewhat finicky problem, but I think this example shows this.

Observations/Triggers of Bug

I will use the column of non-ref base (pos at ~41,063,465; the thin red column, boxed in orange) as a reference base position. At a more zoomed out level, there is a large number of reads (>40) that are present at that base.

But when I zoom in to the maximum, there are only about 20 reads that I can visualize (the 2nd screenshot reaches the bottom of scroll, I promise)

If I fiddle with the magnification a little scroll around to force Dalliance to re-render by going out of this viewing range, and scroll back into the same range, I can (sometimes) see the full depth of reads.

Hypotheses

I have 2 hypotheses on why this might be happening:

• Dalliance might be only fetching a subset of reads that are within a range of the current viewing range, which results in some of the reads that actually have a small section in the viewing range but are mostly out of the viewing range to not be fetched? I couldn't pin down where this was done in the code at the moment. :(

(In this case, the reads which extends far to the left seems to be not rendered). The BAM file I'm using have longer reads (~100bp). I'm thinking that only reads that has a start within some constant value of the start of the viewing window may be loaded.

• Dalliance might be fetching the reads but not drawing them in the rendering process, since I think the drawing window might be controlled by the following code in cbrowser.js lines 1168-1170. (I will try to modify the constants and update if that helps!)

   var width = (this.viewEnd - this.viewStart) + 1;

    var minExtraW = (100.0/this.scale)|0;

    var maxExtraW = (1000.0/this.scale)|0;

This was a bit worrying for me because I wanted to be sure that all reads at a specific bp are rendered when I am at max magnification.

I'm sorry I can't share this BAM file that I'm visualizing but if there's any programmatic ways to help pin down the problem I'd be totally up to try it out. I would also be happy to provide a smaller subset of the BAM file which is share-able and can trigger the bug. Would also appreciate any pointers on what else to investigate.

Thank you!

Best, Yifei

[dasmoth]

I've checked the BAM fetching code carefully, and it's should definitely be fetching all the reads it should be.

But there's a slightly different issue at work here: I think your BAM files are hitting a limit of 100 subtiers when "bumping" features to overlap. Historically, this wasn't an issue because BAM files rarely got close to 100x coverage -- but I realize that things have moved on!

There are two ways you can fix this:

• If you've added the track via the API, you can override this setting on a per-track basis by adding the option subtierMax: 1000 (or whatever) to a track config.
• Alternatively, you can just edit DEFAULT_SUBTIER_MAX around line 63 of feature-draw.js.

There are a couple of Dalliance issues here that I'll try to resolve next week:

• [x] There should be an indication of when the subtier limit has been exceeded (this was actually present in Dalliance 0.7, but seems to have been broken when the canvas renderer was introduced).
• [x] There should be a user interface option for reconfiguring this.

[ymen]

There are two ways you can fix this:

If you've added the track via the API, you can override this setting on a per-track basis by adding the option subtierMax: 1000 (or whatever) to a track config.

Alternatively, you can just edit DEFAULT_SUBTIER_MAX around line 63 of feature-draw.js.

Thanks Thomas for your prompt response, up-ing the subtierMax seems to do the trick, I've not considered this problem at all!

I think the changes you're proposing will be awesome, will be looking forward to them. Thanks again!

[dasmoth]

As discussed, there is now a warning when subtierMax is exceeded, and a way of configuring it in the track editor.

These changes have been made on the 0.12.x and master branches, and will be included in the next release.

[ymen]

Thank you for following up with this, works great! :)