I am currently using SOAPDENOVO2 on a supercomputer with SLURM queuing system to perform a de novo assembly from FASTQ paired-end files with genomic DNA reads.
When I use SOAPdenovo-63mer or SOAPdenovo-127mer, I don't have any problem and I do assemblies with k=63 and k=127 in little more than 16 hours for each assembly, executed in a node with 64 threads and 240Gb of memory, sending to the queue system the following script.sh:
#!/bin/sh
#SBATCH --nodes=1
#SBATCH --ntasks=64
#SBATCH --mem=240000
#SBATCH --time=3-00:00:00
#SBATCH -e error_log.txt
#SBATCH -o output_log.txt
module load soapdenovo2
SOAPdenovo-63mer all -s config_file.txt -o assemblies/k63_ -R -p 64
SOAPdenovo-127mer all -s config_file.txt -o assemblies/k127_ -R -p 64
The troubles start when I try to choose another k value than the predetermined k=63 and k=127 using the -K parameter; for example, if I try to perform an assembly with k=89 through this command:
SOAPdenovo-127mer all -s config_file.txt -K89 -o assemblies/k89_ -R -p 64
the execution fails, and when I check the error_log I get this line:
slurmstepd: error: Detected 1 oom-kill event(s) in StepId=2323585.batch. Some of your processes may have been killed by the cgroup out-of-memory handler.
So, I guess this is a memory issue... but this is not happening with the predefined values of k=63 and k=127... Why does SOAPdenovo2 increase the memory requirements when I use other k values, and how can I overcome this issue?
