Improving alignment across insertions

[wdecoster]

I'm aligning some nanopore PromethION WGS data in which we know that a large insertion should be present (~10kb). But the alignment of these reads results in soft clipping of the fragment spanning the insertion. Which parameters could I tune to improve this?

I've been trying a few combinations of -r, --no-long-join and -z, but I also don't really know which values make sense.

[lh3]

Generally, you need >30kb reads to see a 10kb insertion reliably contained in an alignment. Being too permissive with insertions leads to false alignments elsewhere.

[wdecoster]

I see, but for this scenario, I'm actually okay with being too permissive. I'm only aligning the reads belonging to this locus and only interested in this particular insertion.

[lh3]

In theory it is possible to tune internal parameters to force the long gap to be aligned. However, some of these parameters are not exposed to the command line. An alternative is to do a local assembly and then map.

[wdecoster]

Thanks for the suggestion, I'll see if that helps.

[jblamyatifremer]

To wdecoster,

If you read depth is enough (60X) a program as sniffles (https://github.com/fritzsedlazeck/Sniffles) could detect such features from a bam files. For that it is better to use NGMLR aligner... The bam produced by minimap2 does not fit to sniffles.
Cheers

[wdecoster]

Hi jblamyatifremer,

Thanks, and I'm aware of NGMLR and Sniffles. But the coverage is indeed not enough for this case...

Wouter

[lh3]

@wdecoster do you have any luck with assemble-first-map-later?

[wdecoster]

Would you recommend using minimap2 -x ava-ont followed by miniasm and nanopolish?

[wdecoster]

As a quick follow up, this doesn't seem to work. I'll email you some details I cannot disclose here.

[lh3]

If you can send me some example reads by email, I can have a look.

[wdecoster]

I'm sorry for the delay, I've just send you some reads.

[lh3]

With github master, you can align the second read with the 10kb insertion using:

minimap2 -c --lj-min_ratio=0.3

The default is 0.5. However, your "r1" read has no hit. What's that?

[wdecoster]

Well, same target as the other read. Blat gets it right - more details in email.

[lh3]

@wdecoster sent me two reads. ee4cd08 enables the second read to be mapped with a long insertion. The first read has higher error rate and short flanking regions. Minimap2 is not expected to align it without heavily tuning parameters for small regions.

I will mark this issue to be resolved. Thanks for the example. Very helpful.

[wangyugui]

@lh3 Can we add an abs length value(min split length?, such as 2K bp?) in addition to this relative value --lj-min_ratio=0.3?

[lh3]

This has been taken care of by other internal parameters. Long-join parameters need more tuning on real data. Won't happen very soon.

[wdecoster]

@lh3 bit late feedback, but we figured out that the argument has to be --lj-min-ratio rather than --lj-min_ratio.

Cheers,
Wouter

[ggrimes]

I have a similar issue, did this ever get solved, if so how?
Thanks

[lh3]

Yes, resolved with new versions. Long insertions are hard to be aligned, so you can always find cases where very long insertions are missed, but anyway, options suggested in this thread have been removed and are no longer relevant.

[Suger0917]

I used version 2.28-r1209 and had a similar issue. I tried to extract the long insertions from bam files and re-align the reads. The insertions can be well aligned. Do you have any suggestions on running minimap2 to solve this problem?