<p>[Not quite an answer but too long for a comment]</p>
<p>I am guessing that your assembly <code>Big_burk_assembly.fasta</code> is a rather large assembly. Assembly indexing can be very memory intensive for complex assemblies. If it is eating enough memory to kill the bowtie2 indexing process (as noted in comment by @terdon), I'd consider filtering it, for example if there are lots of very short contigs that are unlikely to be meaningful, consider removing those.</p>
<p>Just looking at the way you've named the assembly file, it looks like it might be a somewhat ad hoc assembly, so maybe there is a meaningful way to filter it. We might be able to suggest more disciplined ways to do this if you tell us more about it.</p>
<p>Alternately, just get more memory as suggested in comments by @terdon. This will be hard if you are running on a personal computer, but on a cluster you can usually specify this in a job parameter file. <a href="https://ecs.rutgers.edu/slurm_commands.html" rel="nofollow noreferrer">Here</a> (section &quot;submit scripts&quot;) is how to set it on SLURM, for example.</p>

CC BY-SA 4.0
2022-12-17T17:58:05.877Z
2022-12-18T04:54:23.897Z
2022-12-18T04:54:23.897Z
Maximilian Press
<p>The code I ran was here, so nothing fancy.</p>
<pre><code>breseq -l 110 -o RifR_align -r Big_burk_assembly.fasta RifRNano_nanopore.fastq.gz
</code></pre>
<p>This was the output.</p>
<pre><code>NOW PROCESSING Read alignment to reference genome
[system] bowtie2-build -q &quot;RifR_align/data/reference.fasta&quot; &quot;RifR_align/02_reference_alignment/reference&quot;
    [system] bowtie2 -t --no-unal -p 1 -L 31 --ma 1 --mp 3 --np 0 --rdg 2,3 --rfg 2,3 --ignore-   quals --local -i S,1,0.25 --score-min L,1,0.9 -k 2000 --reorder -x &quot;RifR_align/02_reference_alignment/reference&quot; -U &quot;RifR_align/01_sequence_conversion/RifRNano_nanopore.converted.fastq&quot; -S &quot;RifR_align/02_reference_alignment/RifRNano_nanopore.stage1.sam&quot; --un &quot;RifR_align/02_reference_alignment/RifRNano_nanopore.stage1.unmatched.fastq&quot;
    Time loading reference: 00:00:00
    Time loading forward index: 00:00:00
    Time loading mirror index: 00:00:00
    Killed
    Use of uninitialized value <span class="math-container">$l in scalar chomp at /home/lts/miniconda3/envs/assemblers/bin/bowtie2 line 588, &lt;BT&gt; line 4626.
Use of uninitialized value $</span>l in substitution (s///) at /home/lts/miniconda3/envs/assemblers/bin/bowtie2 line 589, &lt;BT&gt; line 4626.
Use of uninitialized value $l in print at /home/lts/miniconda3/envs/assemblers/bin/bowtie2 line 593, &lt;BT&gt; line 4626.
(ERR): bowtie2-align exited with value 137
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!&gt; FATAL ERROR &lt;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Error running command:
[system] bowtie2 -t --no-unal -p 1 -L 31 --ma 1 --mp 3 --np 0 --rdg 2,3 --rfg 2,3 --ignore-quals --local -i S,1,0.25 --score-min L,1,0.9 -k 2000 --reorder -x &quot;RifR_align/02_reference_alignment/reference&quot; -U &quot;RifR_align/01_sequence_conversion/RifRNano_nanopore.converted.fastq&quot; -S &quot;RifR_align/02_reference_alignment/RifRNano_nanopore.stage1.sam&quot; --un &quot;RifR_align/02_reference_alignment/RifRNano_nanopore.stage1.unmatched.fastq&quot;
Result code: 35072
FILE: libbreseq/common.h   LINE: 1411
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!&gt; STACK TRACE &lt;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Backtrace with 6 stack frames.
breseq(+0x44cf4) [0x56102c3c3cf4]
breseq(+0x4a4f1) [0x56102c3c94f1]
breseq(+0x6d142) [0x56102c3ec142]
breseq(+0x36cc4) [0x56102c3b5cc4]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f71ba61e0b3]
breseq(+0x40559) [0x56102c3bf559]
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

</code></pre>
<p>The programs seemed to have no trouble aligning the reference genome, however the Bowtie2 package is throwing error code 137 and terminating the program.</p>

CC BY-SA 4.0
2022-12-05T09:48:55.247Z
That first `Killed` message you get suggests the process was killed by the system because it was taking too much RAM. It could be that all the other errors are just because the first was killed. Does it run through if you use a smaller dataset?
terdon
CC BY-SA 4.0
2023-09-14T12:04:13.213Z
@LiamTSullivan please do consider the comment and the answer of MaximillanPress via upvote/accept.
M__
<reference-genome><bowtie2>
Breseq error (code 137). Any ideas?
# Breseq error (code 137). Any ideas?

(Asked by: username_0 on 2022-12-05)

The code I ran was here, so nothing fancy.
breseq -l 110 -o RifR_align -r Big_burk_assembly.fasta RifRNano_nanopore.fastq.gz

This was the output.
NOW PROCESSING Read alignment to reference genome
[system] bowtie2-build -q "RifR_align/data/reference.fasta" "RifR_align/02_reference_alignment/reference"
    [system] bowtie2 -t --no-unal -p 1 -L 31 --ma 1 --mp 3 --np 0 --rdg 2,3 --rfg 2,3 --ignore-   quals --local -i S,1,0.25 --score-min L,1,0.9 -k 2000 --reorder -x "RifR_align/02_reference_alignment/reference" -U "RifR_align/01_sequence_conversion/RifRNano_nanopore.converted.fastq" -S "RifR_align/02_reference_alignment/RifRNano_nanopore.stage1.sam" --un "RifR_align/02_reference_alignment/RifRNano_nanopore.stage1.unmatched.fastq"
    Time loading reference: 00:00:00
    Time loading forward index: 00:00:00
    Time loading mirror index: 00:00:00
    Killed
    Use of uninitialized value $l in scalar chomp at /home/lts/miniconda3/envs/assemblers/bin/bowtie2 line 588,  line 4626.
Use of uninitialized value $l in substitution (s///) at /home/lts/miniconda3/envs/assemblers/bin/bowtie2 line 589,  line 4626.
Use of uninitialized value $l in print at /home/lts/miniconda3/envs/assemblers/bin/bowtie2 line 593,  line 4626.
(ERR): bowtie2-align exited with value 137
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!> FATAL ERROR  STACK TRACE 
The programs seemed to have no trouble aligning the reference genome, however the Bowtie2 package is throwing error code 137 and terminating the program.

**Tags:** reference-genome, bowtie2
> **Comments:**
> **username_1**: That first `Killed` message you get suggests the process was killed by the system because it was taking too much RAM. It could be that all the other errors are just because the first was killed. Does it run through if you use a smaller dataset?  
> **username_2**: @LiamTSullivan please do consider the comment and the answer of MaximillanPress via upvote/accept.  

---

## 1 answers

### Answer by username_3 on 2022-12-17. Score: 1

[Not quite an answer but too long for a comment]

I am guessing that your assembly `Big_burk_assembly.fasta` is a rather large assembly. Assembly indexing can be very memory intensive for complex assemblies. If it is eating enough memory to kill the bowtie2 indexing process (as noted in comment by @terdon), I'd consider filtering it, for example if there are lots of very short contigs that are unlikely to be meaningful, consider removing those.

Just looking at the way you've named the assembly file, it looks like it might be a somewhat ad hoc assembly, so maybe there is a meaningful way to filter it. We might be able to suggest more disciplined ways to do this if you tell us more about it.

Alternately, just get more memory as suggested in comments by @terdon. This will be hard if you are running on a personal computer, but on a cluster you can usually specify this in a job parameter file. [Here](https://ecs.rutgers.edu/slurm_commands.html) (section "submit scripts") is how to set it on SLURM, for example.


---

