kcleal
commented
4 months ago Hi @JMencius, That is much slower than expected. If you could share the stderr output of the command that would be useful. As only one core is being used it's probable the pipeline has got stuck processing one large component job. This can sometimes happen at ALT chromosomes, so you could try excluding those chromosomes and running again.
It this issue still persists, then would you mind running this script to see where it is getting stuck:
cat ref.fa.fai | while read line
do
chrom=$(echo $line | cut -d " " -f 1)
length=$(echo $line | cut -d " " -f 2)
echo "${chrom} 1 ${length}" > ${chrom}.search.bed
echo ${chrom}
dysgu run -p 12 --mode nanopore --max-cov 500 -x \
--search ${chrom}.search.bed \
ref.fa temp_${chrom} bam \
> ${chrom}.dysgu.vcf 2>${chrom}.stderr
doneAlso you might want to set the --max-cov parameter to auto or some other suitable number, the default is only 200 for long-reads which will result in some regions being excluded with your 174X coverage.
JMencius
Distinguished DYSGU developers,
I am new to DYSGU software, and I humbly ask for you help for why the prolong run time for DYSGU.
First, I use Minimap2 to align my raw nanopore FASTQ sequnce (X174 coverage) to the reference genome and output the aligned SAM file. I filter the SAM file with -F 4069 with samtools and converted to BAM at the same time. I use this BAM file (filtered.bam) as the DYSGU input.
My command for running DYSGU is :
dysgu call -p 12 --mode nanopore GCA_000001405.15_GRCh38_no_alt_analysis_set.fasta temp filtered.bam
The run took >52 hours (still running) on dual Intel Xeon (with HDD array) and DYSGU only use single core mostly, which I think the run time is too long for you mentioned "Using a single core and depending on hard-drive speed, dysgu usually takes ~1h to analyse a 30X coverage genome". Also the program does not output any error and output nothing after "Building graph with clustering 500000 bp".
Do you have any ideas?