Closed Rob-murphys closed 3 years ago
Your RAM is not enough, try parallel_jobs = 1
.
I am using 80G of RAM here, that should defiantly be sufficient no? Plus this polishing has previously worked with the exact same amount of RAM on the exact same genome in the past. I can try reduce parallel_jobs
though.
As I said in #55, the required RAM depends on each contig length and mapping depth, and parallel_jobs
, multithread_jobs
and reads length.
Okay, but why would the polishing have worked previously with no changes from the current?
And the issue seems to be that NextPolish is just not doing anything more that stalling from memory, it get to this stage 6 almost instantly but then just stays there for however long I set the job to run for. of are the Throw jobID
lines current jobs and not previous ones?
I have tried running with parrallel_jobs = 1
and a low multithread_jobs
, both variations of the NextPolish run are experiencing the same issue unfortunately. Again both jobs got stuch at the exact same point, just after step 6.
First, check your input data and each subtask log. If there is no problem, just delete the working directory and restart from the beginning. If there are still problems, maybe I need you to share the input data with me. so I can debug it. BTW, the probability of NextPolish code with errors is very low, most of the errors are caused by incorrect input or configuration.
I understand and have tried to delete the working directory to restart. I am quite confident there is no issues with the input because as i previously said, this exact same input has worked with these exact same commands before. I will however take a look :) Is there anything in particular I should be looking out for?
the working directory always consists of these same exact files and subdirectories if that helps debug:
00.lgs_polish 02.score_chain input.lgspart.000.fasta.gz input.lgspart.002.fasta.gz input.lgspart.004.fasta.gz input.sgspart.000.fasta.gz input.sgspart.002.fasta.gz input.sgspart.004.fasta.gz
01.lgs_polish 03.kmer_count input.lgspart.001.fasta.gz input.lgspart.003.fasta.gz input.lgspart.005.fasta.gz input.sgspart.001.fasta.gz input.sgspart.003.fasta.gz input.sgspart.005.fasta.gz
You should check each subtask log file, such as for this subtask /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/04.merge.bam.sh.work/merge_bam0/RB110-1.nextPolish.sh
, its log file is /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/04.merge.bam.sh.work/merge_bam0/RB110-1.nextPolish.sh.e
.
ah sorry i did not know to look there!
The output looks odd here:
hostname
+ hostname
cd /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/04.merge.bam.sh.work/merge_bam0
+ cd /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/04.merge.bam.sh.work/merge_bam0
time /faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/samtools merge -f -b /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/sgs.sort.bam.list --threads 5 -|/faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/samtools markdup --threads 5 -r -s - /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/sgs.sort.bam
+ /faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/samtools merge -f -b /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/sgs.sort.bam.list --threads 5 -
+ /faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/samtools markdup --threads 5 -r -s - /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/sgs.sort.bam
READ 0 WRITTEN 0
EXCLUDED 0 EXAMINED 0
PAIRED 0 SINGLE 0
DULPICATE PAIR 0 DUPLICATE SINGLE 0
DUPLICATE TOTAL 0
real 0m0.024s
user 0m0.009s
sys 0m0.011s
time /faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/samtools index -@ 10 /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/sgs.sort.bam
+ /faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/samtools index -@ 10 /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/sgs.sort.bam
real 0m0.105s
user 0m0.003s
sys 0m0.022s
touch /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/04.merge.bam.sh.work/merge_bam0/RB110-1.nextPolish.sh.done
+ touch /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/04.merge.bam.sh.work/merge_bam0/RB110-1.nextPolish.sh.done
From what i think i am looking at no reads are being read?
You should check each subtask log file. Such as /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/03.map.ref.sh.work/map_genome*/RB110-1.nextPolish.sh.e
. All subtasks are shown in the main log, followed by key word Throw jobID
.
Is the log file shown above normal though? I am not sure what I am meant to be seeing in each log file so that makes it kind of hard to debug.
No, but the reason may be caused by its previous step. I think, maybe , you can run NextPolish with test data, and compare its normal log with yours.
I have found the issue I think :)
less /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1-OLD/03.kmer_count/03.map.ref.sh.work/map_genome5/RB110-1.nextPolish.sh.e
hostname
+ hostname
cd /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/03.map.ref.sh.work/map_genome5
+ cd /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/03.map.ref.sh.work/map_genome5
time /faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/bwa mem -p -t 10 /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/input.genome.fasta.sgs /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/input.sgspart.005.fastq.gz|/faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/samtools view --threads 5 -F 0x4 -b - |/faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/samtools fixmate -m --threads 5 - - |/faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/samtools sort - -m 2g --threads 5 -o sgs.part005.sort.bam
+ /faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/bwa mem -p -t 10 /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/input.genome.fasta.sgs /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/input.sgspart.005.fastq.gz
+ /faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/samtools view --threads 5 -F 0x4 -b -
+ /faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/samtools fixmate -m --threads 5 - -
+ /faststorage/project/local-blast/termitoV2/scripts/assembly_annotation/NextPolish/bin/samtools sort - -m 2g --threads 5 -o sgs.part005.sort.bam
[M::bwa_idx_load_from_disk] read 0 ALT contigs
[E::main_mem] fail to open file `/home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/input.sgspart.005.fastq.gz'.
real 0m0.065s
user 0m0.006s
sys 0m0.035s
touch /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/03.map.ref.sh.work/map_genome5/RB110-1.nextPolish.sh.done
+ touch /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/03.kmer_count/03.map.ref.sh.work/map_genome5/RB110-1.nextPolish.sh.done
Unsure why it is happening throuhg as this is not a file I am directing nextpolish too. my sgs-RB110-1.txt
contains:
/home/lamma/faststorage/RB110/clean_short-reads_Q30/RB110-1-cleanQ30.fastq
@moold
I have run on test data and this mapping step in each 00.lgs_polish 01.score_chain 02.kmer_count
output directory steps. What could be causing nextpolish to look /home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1
here instead of the workdir
?
If your short reads file is single end, you need use sgs_options = -unpaired
, otherwise, you should write both pair-end files to sgs-RB110-1.txt
.
I have included this now in the .cfg
file:
[sgs_option]
sgs_fofn = ./nextPolish_sgs/sgs-$sample.txt
sgs_options = -max_depth 100 -bwa -unpaired
The same issue is still occurring:
[E::main_mem] fail to open file '/home/lamma/faststorage/RB110/nextPolish-ouput/RB110-1/input.sgspart.000.fastq.gz'.
I wonder if you are sure that the short reads are single-end? Because the short reads are usually pair-end. BTW, I found -unpaired
option has a bug and I will fix it in the next release.
They are merged paired end so believe you just call that as single end?
Hi, I have released a new version, which has fixed this bug, you can try it.
Describe the bug NextPolish stuck on/after step 6 merging bams when polishing with long and short reads.
Error message
No specific log message just a failure to move past this stage and complete the job, having previously done so with this exact same command and genome. Excerpt from log:
Operating system
GCC
Python
Python 3.7.3
NextPolish
nextPolish v1.3.0
To Reproduce (Optional)
python ~/path/to/NextPolish/nextPolish run_RB110-1.cfg
.cfg
file:Additional context This job has previously worked on this genome with no issues, and as far as I am aware nothing has changed since trying to re run.