Error code 255 - assembling SRA data

[henicorhina]

Hello,

I am trying to assemble paired-end illumina data that I downloaded from SRA. SPAdes works just fine when assembling my own original read data, but when using the SRA reads it fails when using BWA, saying that the read names do not match. The names match except for the final number in the SRA read names (a 1 or a 2, depending on the read).

Example read names from one set of paired reads:
@SRX2913786.1.1 1 length=100
@SRX2913786.1.2 1 length=100

and the SPAdes error message:

paired reads have different names: "SRX2913788.3.1", "SRX2913788.3.2"
  0:03:36.654   112M / 112M  INFO   DatasetProcessor         (dataset_processor.cpp     : 152)   bwa failed, skipping sublib
  0:03:36.654   112M / 112M  ERROR  DatasetProcessor         (dataset_processor.cpp     : 215)   Failed to align paired reads /work/ojohnson/mike_data/2_clean_reads/Campephilus_melanoleucos_AMNH12719/split-adapter-quality-trimmed/Campephilus_melanoleucos_AMNH12719-READ1.fastq.gz and /work/ojohnson/mike_data/2_clean_reads/Campephilus_melanoleucos_AMNH12719/split-adapter-quality-trimmed/Campephilus_melanoleucos_AMNH12719-READ2.fastq.gz


== Error ==  system call for: "['/home/ojohnson/.conda/envs/phyluce/share/spades-3.12.0-1/bin/spades-corrector-core', '/worka/work/ojohnson/mike_data/3_spades_assembly/Campephilus_melanoleucos_AMNH12719_spades/mismatch_corrector/contigs/configs/corrector.info', '/worka/work/ojohnson/mike_data/3_spades_assembly/Campephilus_melanoleucos_AMNH12719_spades/misc/assembled_contigs.fasta']" finished abnormally, err code: 255

Any ideas on how to get SPAdes to use these reads?

Here's the spades log file.

spades.log

Thanks!

Oscar

[lilitch]

Hi,

l have the exact issue here.

`[mem_sam_pe] paired reads have different names: "SRR2677532.1.1", "SRR2677532.1.2"
0:00:22.524 4M / 8M INFO DatasetProcessor (dataset_processor.cpp : 152) bwa failed, skipping sublib
0:00:22.524 4M / 8M ERROR DatasetProcessor (dataset_processor.cpp : 215) Failed to align paired reads /home/lyndant/Documents/ProjetSession/Donnees/Trimmed_SRR2677532_1.fastq.fastq and /home/lyndant/Documents/ProjetSession/Donnees/Trimmed_SRR2677532_2.fastq.fastq

== Error == system call for: "['/home/lyndant/Documents/ProjetSession/SPAdes-3.13.0-Linux/bin/spades-corrector-core', '/home/lyndant/Documents/ProjetSession/SPAdes-3.13.0-Linux/bin/spades_results/mismatch_corrector/contigs/configs/corrector.info', '/home/lyndant/Documents/ProjetSession/SPAdes-3.13.0-Linux/bin/spades_results/misc/assembled_contigs.fasta']" finished abnormally, err code: 255`

l tried the --continue option as suggested here, but it didn't change anything.

params.txt
spades.log

Any suggestion on what we can do?

Thanks,
Linda

[asl]

Hello

Unfortunately, SRA tools produce invalid names for paired-end reads. Indeed, BWA requires the name of reads from the pair match. And as far as you can see – they don't. Note that per FASTQ specification everything after space in the read name is actually a comment; this is why name is just SRX2913786.1.1 1 and not SRX2913786.1.1 1 length=100.

[henicorhina]

I solved this by renaming the fastq read names with sed, where data have been cleaned by illumiprocessor. Spades ran normally after this.

for dir in /path/to/clean/2_clean_reads/*; do
	echo $dir;
	cd $dir/split-adapter-quality-trimmed/
	NAME=$(basename *-READ1.fastq.gz '.gz')
	echo $NAME;
	gzip -d *-READ1.fastq.gz
	sed -i.copy "s/.1 / 1 /g" $NAME
	gzip $NAME
	NAME=$(basename *-READ2.fastq.gz '.gz')
	gzip -d *-READ2.fastq.gz
	sed -i.copy 's/.2 / 2 /g' $NAME
	gzip $NAME
	NAME=$(basename *-READ-singleton.fastq.gz '.gz')
	echo $NAME;
	gzip -d *-READ-singleton.fastq.gz
	sed -i.copy "s/.1 / 1 /g" $NAME
	sed -i.copy2 "s/.2 / 2 /g" $NAME
	gzip $NAME
	rm *.copy*
done

[lilitch]

Thank you asl, thank you henicorhina,

I didn't manage to reuse the above code (I'm really new at this). I found rename sequences on Galaxy, and used it to rename the reads with only their number, for both files. It finally worked.

[kmkocot]

I was also having this problem but this thread solved it. Thanks! It would be helpful if spades checked for this issue at the beginning of the pipeline.