Closed kapsakcj closed 1 year ago
I'm thinking this is specific to the staphb/seqsero2:1.2.1
docker image which uses spades 3.9.0.
When I ran the same cleaned FASTQ files through a bioconda install of seqsero2 v1.2.1 (uses spades 3.15.5), it ran successfully and predicted the serotype, no spades failure.
I'll open an issue over on docker builds
Perhaps we don't need to use the raw FASTQs as input, I think this will be resolved if we upgrade the docker image
Resolved via upgrading the SPAdes version in the StaPH-B docker image staphb/seqsero2:1.2.1
(PR linked above)
Only seen this with 2 samples so far, but just wanted to document in case we see this again.
For these 2 samples, SeqSero2 only fails when using the "cleaned" FASTQ files as input to SeqSero2 when it is set in the "allele mode"
I ran both samples through SeqSero2 in a variety of configurations, all which correctly predicted Muenster and Kiambu: Cleaned FASTQs - kmer mode ✅ Raw FASTQs - kmer mode ✅ Assembly - kmer mode ✅ Cleaned FASTQs - allele mode ❌
I looked at the SPAdes logs and something went awry during the "micro-assembly" step of the allele mode of SeqSero2 which takes the reads that align to the serotype specific genes as input to the assembly process.
end of log:
Since the micro assembly failed, SeqSero2 was unable to predict a serotype: