Open pkerbs opened 2 years ago
Hi @pkerbs
I have not been able to replicate the issue, probably because of different versions of BBDuk being used. I have used here BBMap version 38.44.
In your case there is a forced trimming done by FusionCatcher by using BBduk on the input reads from 101 bp to 100 bp.
If the reads are trimmed beforehand to 100 bp then FusionCatcher will not do any forced trimming using BBduk.
Another way around this is to use the command line command --skip-trim-multiple-5
which will disable the forced trimming.
Hey Daniel,
thanks for your response. All the input reads are 100bp long not 101. So it shouldn't do the forced trimming as you said.
Just for testing, I have trimmed them to 99bp now and run it again. Still same issue. I have also used BBMap 38.44.
I would like to avoid using the --skip-trim-multiple-5
parameter to make the results consistent to other samples.
Do you maybe have another idea what to do? It seems that BBDuk doesn't like 'N' bases having a high quality score and falsely changes the ASCII encoding. Do you maybe know of a script that changes the quality of all N bases in a fastq file?
Best wishes, Paul
Hi @pkerbs
indeed your are right the reads are 100 bp long.
As I wrote before I was not able to reproduce the bug that you reported. Here is how I tried to reproduced it:
mkdir fq
cd fq
wget ftp://ftp.sra.ebi.ac.uk/vol1/fastq/SRR548/000/SRR5484560/SRR5484560_1.fastq.gz
wget ftp://ftp.sra.ebi.ac.uk/vol1/fastq/SRR548/000/SRR5484560/SRR5484560_2.fastq.gz
cd ..
fusioncatcher.py -i fq -o results
Maybe there are issues with the downloading of the FASTQ files and they are somehow broken?
For example, for the read above if I do this:
zgrep -2 ATTCATGCCACCGCTTACTATAAAGTGGACGACCCAGTGTGGAACATTCAAATTGCAAGGATGCTTGAGCTGCCCACTATCTACAGGAAAGTTTATNNNN *.gz
I get this:
@SRR5484560.3 HWI-ST942:51:C3CGDACXX:2:1101:1459:2183/1
ATTCATGCCACCGCTTACTATAAAGTGGACGACCCAGTGTGGAACATTCAAATTGCAAGGATGCTTGAGCTGCCCACTATCTACAGGAAAGTTTATNNNN
+
?@@FFFDEHHDFHIIGGDHGDHHII<AB9CAGGHHHG3?9?B<BBHEBFFIIICHGHIGIEHHFEHD>DBEEEEDD@AACCCDDCDD9AA<ACDD@@ACA
Hi Daniel, grepping for the read yielded this result:
@SRR5484560.3 HWI-ST942:51:C3CGDACXX:2:1101:1459:2183 length=100
ATTCATGCCACCGCTTACTATAAAGTGGACGACCCAGTGTGGAACATTCAAATTGCAAGGATGCTTGAGCTGCCCACTATCTACAGGAAAGTTTATNNNN
+SRR5484560.3 HWI-ST942:51:C3CGDACXX:2:1101:1459:2183 length=100
?@@FFFDEHHDFHIIGGDHGDHHII<AB9CAGGHHHG3?9?B<BBHEBFFIIICHGHIGIEHHFEHD>DBEEEEDD@AACCCDDCDD9AA<ACDD@@ACA
The fastq seems ok, its just formatted a little differently, since I downloaded it years ago through SRAToolkit.
But now I downloaded the same files as you did from the FTP and I still have the same error when I run those files. I don't know what else could be the issue.
EDIT: I just noticed that I didn't include the previous text of the error message:
ERROR: Workflow execution failed at step 101 while executing:
----------------
bbduk.sh \
forcetrimmod=5 \
in=/outputfolder/fusioncatcher/SRR5484560/orig__.fq \
out=/outputfolder/fusioncatcher/SRR5484560/orig__x.fq
----------------
* Size '/outputfolder/fusioncatcher/SRR5484560/orig__.fq' = 4654908938 bytes
* Size '/outputfolder/fusioncatcher/SRR5484560/orig__x.fq' = 0 bytes
Executing second time the same step/command in order to capture error messages (i.e. STDERR)...
-------------------------------------------
orig__x.fq seems to have size 0 on which bbduk is executed. Maybe there is an issue already before bbduk? Thanks for your time
Hello, I am trying to run fusioncatcher 1.33 on the samples: SRR5484560 -> https://trace.ncbi.nlm.nih.gov/Traces/sra/?run=SRR5484560 SRR5484561 -> https://trace.ncbi.nlm.nih.gov/Traces/sra/?run=SRR5484561
However they fail at step 101. It seems BBDuk gets confused with N bases having a high PHRED score and changes ASCII-encoding format. Is this the issue? Would you have a solution for this? Thanks in advance
The Error messages:
for SRR5484560:
and for SRR5484561: