marbl / canu

A single molecule sequence assembler for genomes large and small.
http://canu.readthedocs.io/
646 stars 178 forks source link

Canu failing in Unitigger: Failed with 'Aborted'; backtrace (libbacktrace): AS_UTL/AS_UTL_stackTrace.C::102 in _Z17AS_UTL_catchCrashiP9siginfo_tPv() #544

Closed jonhultqvist closed 7 years ago

jonhultqvist commented 7 years ago

Hi, Thank you for developing this fine tool. Unfortunaley, we have been experiencing some problems with one of our assemblies. The dataset is about 5.0 Gbp of Oxford Nanopore 1D reads (from R9.5 pore, 1D^2 library but used as 1D reads only), basecalled using Albacore 1.0.2, trimmed 75 bp at either end and filtered to only have reads longer than 3 kb. The assembly appears to progress nicely until the unitigging stage where it fails. I have tried to re-launch it from where is failed without success. I also tried some changes to the settings, like increasing the memory allowed for the 'bat' stage without any effect. The Canu version is: Canu snapshot v1.5 +98 changes (r8298 ffb36aae9419bd600247237e8cfdb378b8fbedf2).

I have seen some similar issues in issue threads but not exactly at the unitigging stage. Could it be problematic reads that is causing this? In any case, I would very much appreciate your help in trying to figure of what could be going wrong here.

This is the shell script for launching Canu (UNIX system).

#!/bin/bash
#$ -S /bin/bash
. /etc/profile
#$ -cwd
#$ -pe threaded 16

export PATH=/opt/perun/jre1.8.0_121/bin:$PATH

/scratch2/software/canu/canu-jun-2017/Linux-amd64/bin/canu \
-p Bnat_Canu3k_1.5_rerun -d Bnat_Canu3k_1.5_rerun \
genomeSize=95.0m \
maxMemory=100g \
maxThreads=16 \
batMemory=100g batThreads=16 \
-nanopore-raw /scratch2/annaa/LGT_BNAT/MinION/TRIMMED_READS/Bnat_MinION.cutadapt75_5_3_3k.fastq \
useGrid=false

The error message in assembly log-file occurs in the unitigging stage.

 Starting 'bat' concurrent execution on Thu Jul  6 04:42:39 2017 with 13695.449 GB free disk space (1 processes; 1 concurrently)

    cd unitigging/4-unitigger
    ./unitigger.sh 1 > ./unitigger.000001.out 2>&1

-- Finished on Thu Jul  6 04:43:28 2017 (49 seconds) with 13693.631 GB free disk space
----------------------------------------
-- 
-- Unitigger failed.
--

ABORT:
ABORT: Canu snapshot v1.5 +98 changes (r8298 ffb36aae9419bd600247237e8cfdb378b8fbedf2)
ABORT: Don't panic, but a mostly harmless error occurred and Canu stopped.
ABORT: Try restarting.  If that doesn't work, ask for help.
ABORT:
ABORT:   canu iteration count too high, stopping pipeline (most likely a problem in the grid-based computes).
ABORT:

From unitigging.err

==> BUILDING GREEDY TIGS.

breakSingletonTigs()-- Removed 115 singleton tigs; reads are now unplaced.
optimizePositions()-- Optimizing read positions for 282 tigs, with 16 threads.

==> PLACE CONTAINED READS.

computeErrorProfiles()-- Computing error profiles for 282 tigs, with 16 threads.

placeContains()-- placing 227731 contained and 620 unplaced reads, with 16 threads.
bogart: bogart/AS_BAT_PlaceReadUsingOverlaps.C:350: void placeRead_computePlacement(overlapPlacement&, uint32, uint32, overlapPlacement*, Unitig*): Asse$

Failed with 'Aborted'; backtrace (libbacktrace):
AS_UTL/AS_UTL_stackTrace.C::102 in _Z17AS_UTL_catchCrashiP9siginfo_tPv()
(null)::0 in (null)()
(null)::0 in (null)()
(null)::0 in (null)()
(null)::0 in (null)()
(null)::0 in (null)()
bogart/AS_BAT_PlaceReadUsingOverlaps.C::350 in _Z26placeRead_computePlacementR16overlapPlacementjjPS_P6Unitig()
bogart/AS_BAT_PlaceReadUsingOverlaps.C::488 in _Z22placeReadUsingOverlapsR9TigVectorP6UnitigjRSt6vectorI16overlapPlacementSaIS4_EEj()
bogart/AS_BAT_PlaceContains.C::126 in (null)()
(null)::0 in (null)()
(null)::0 in (null)()
(null)::0 in (null)()
(null)::0 in (null)()
Aborted (core dumped)
brianwalenz commented 7 years ago

This has been under quite active development over the past week or two. Give the latest a shot - it just ran a human from nanopore. No need to start from scratch, just restart canu or directly run unitigger.sh.

jonhultqvist commented 7 years ago

That was a fix for the issue: The assembly is now through the unitigger stage and into consensus building.

Thanks a bunch!