Had a successful assembly with SparseAssembler k101, but figured I’d just tweak the kmer setting and throw it in the queue and see how it compares; minimal effort/time needed.
Initiatied an assembly run using SparseAssembler on our Mox HPC node on all of our geoduck genomic sequencing data:
Kmer size set to 95.
Slurm script: 20180423_sparse_assembler_kmer95_geoduck_slurm.sh
After the run finished, I copied the files to our server (Owl) and then ran Quast on my computer to gather some assembly stats, using the following command:
<code>
/home/sam/software/quast-4.5/quast.py \
-t 24 \
--labels 20180423_sparse_k95 \
/mnt/owl/Athaliana/20180423_sparseassembler_kmer95_geoduck/Contigs.txt \
</code>Results:
SparseAssembler output folder: 20180423_sparseassembler_kmer95_geoduck/
SparseAsembler assembley (FastA; 15GB): 20180423_sparseassembler_kmer95_geoduck/Contigs.txt
Quast output folder: quast_results/results_2018_05_10_15_04_07
Quast report (HTML): quast_results/results_2018_05_10_15_04_07/report.html
I’ve embedded the Quast HTML report below, but it may be easier to view by using the link above.
Well, it’s remarkable how different this is than the previous SparseAssembler with k101 setting!
This assembly doesn’t have a single contig >50,000bp, while the previous one has four contigs over that threshold!
Definitely shows what a large impact the kmer setting in assembly software can have on the final assembly!