A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/marbl/canu/issues/1872 below:

Bogart findPotentialOrphan assertion failing · Issue #1872 · marbl/canu · GitHub

Hi,
I'm using canu snapshot v2.2-development +82 changes (af771ef) on a linux system, and have issues with the bogart step of unitigging. This is using about 45x ONT reads on a 2.7gb mammal genome.

An assertion is failing in findPotentialOrphans, which is similar to the (idle) unresolved issue in #1831. Unfortunately I can't share the sequencing data at this time, as asked for in that issue. Using the ovl algorithm was proving to be extremely slow, so I tried using mhap even for trimming and tigging, which is not recommended in the docs, but was suggest by some colleagues in the USDA. I wasn't sure if that approximate algorithm could be the cause of the failed assertion, or if there is potentially some issue upstream.

I've included final lines in the unitigger.err file below.

==> MERGE ORPHANS.

computeErrorProfiles()-- Computing error profiles for 4946 tigs, with 32 threads.
computeErrorProfiles()-- Finished.

findPotentialOrphans()-- working on 4946 tigs.
findPotentialOrphans()-- found 4218 potential orphans.
mergeOrphans()-- flagged     146        bubble tigs with 8494 reads
mergeOrphans()-- placed       13 unique orphan tigs with 228 reads
mergeOrphans()-- shattered     2 repeat orphan tigs with 80 reads
mergeOrphans()-- ignored      34               tigs with 902 reads; failed to place
mergeOrphans()--

==> MARK SIMPLE BUBBLES.
    using 0.010000 user-specified threshold


findPotentialOrphans()-- working on 4946 tigs.
read 845459 at 802795 743355 olap to read 1331274 hangs 61633 17804 -> coords 743355 741162
bogart: bogart/AS_BAT_MergeOrphans.C:229: void findPotentialOrphans(TigVector&, BubTargetList&, bool): Assertion `mincoord < maxcoord' failed.

Failed with 'Aborted'; backtrace (libbacktrace):
(null)::0 in (null)()

Thanks,
Alex

PS I think there is a typo in the .trimReads.log files in the 3-overlapbasedtrimming stage, it uses NOV for the message column where the header suggests NOC for no change. It appears here.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4