---
author: Sam White
toc-title: Contents
toc-depth: 5
toc-location: left
date: 2018-04-22 18:06:55+00:00
layout: post
slug: assembly-sparseassembler-k-131-on-geoduck-sequence-data
title: Assembly – SparseAssembler (k 131) on Geoduck Sequence Data
categories:
  - 2018
  - Geoduck Genome Sequencing
tags:
  - geoduck
  - mox
  - Panopea generosa
  - SparseAssembler
---

After some runs with kmergenie, [I've decided to try re-running SparseAssembler using a kmer setting of 131](https://robertslab.github.io/sams-notebook/posts/2018/2018-04-21-kmer-estimation-kmergenie-k-301-on-geoduck-sequence-data/).

The job was run on our Mox HPC node.





  * Slurm script: [20180422_sparse_assembler_kmer131_geoduck_slurm.sh](https://owl.fish.washington.edu/Athaliana/20180422_sparseassembler_kmer131_geoduck/20180422_sparse_assembler_kmer131_geoduck_slurm.sh)





##### Results:



Output folder:





  * [20180422_sparseassembler_kmer131_geoduck/](https://owl.fish.washington.edu/Athaliana/20180422_sparseassembler_kmer131_geoduck/)



Slurm output file:



  * [20180422_sparseassembler_kmer131_geoduck/slurm-163406.out](https://owl.fish.washington.edu/Athaliana/20180422_sparseassembler_kmer131_geoduck/slurm-163406.out)



This failed with the following error message:

`Error! K-mer size too large!`

Looking into this, it's because the maximum kmer size for kmergenie is 127! Doh!

It'd be nice if the program looked at that setting first before processign all the data files...

A bit disappointing, but I'll give this a go with a lower kmer setting and see how it goes.