Open lfaller opened 6 years ago
That's definitely too long and too much memory, so something's not right! It should work with PacBio reads, so the issue isn't obvious.
What version of Racon are you using? The most recent version of Unicycler (v0.4.6) supports the newer Racon which runs faster. So maybe try updating both Unicycler and Racon.
Another workaround would be to do the long read assembly separately (e.g. in Canu) and give it to Unicycler with the --existing_long_read_assembly
option. That will skip the Racon step entirely and dodge the issue.
Let me know how you go!
Ryan
Hi, I experienced the same phenomenon. Illumina + Pacbio. I use a HPC that have most software pre-installed as modules. Running unicycler 0.4.7 with the then-installed version of racon (dated 20170621) resulted in a stall at the same point as the OP described here.
I had the HPC staff update to racon 1.3.1. Now the process runs to the end. So perhaps it was a question of updating the dependencies to Unicycler.
Hi all,
I usually run
unicycler
on minion + illumina reads but got some raw reads from pacbio the other day and wanted to try it. I usedbam2fastq
to get fastq files from the pacbio bam files, usedfiltlong
to downsample them,bbnorm
to downsample illumina, and then ranunicycler
as usual.It seems that the
racon
step inunicycler
is taking much longer than it ever has. I attached the log output below. It's been running for 47 hrs on 40 cores with 250Gb of RAM.Usually
unicycler
runs pretty fast when I give it downsampled data. This is the first time I am playing around with pacbio reads -- is theracon
issue related to the pacbio reads, or could there be something else? Do I need to preprocess the pacbio reads differently? Should I not be using the raw reads?Any advice is appreciated!
My
bbnorm
parameters:bbnorm.sh in1=R1.fastq in2=R2.fastq out1=R1_norm.fastq out2=R2_norm.fastq target=100 min=5
My
filtlong
parameters:filtlong --min_length 1000 --keep_percent 90 --target_bases 500000000