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.
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.
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.