Option --relaxed not working properly for bamtofastq-1.4.1

[JurMich]

Hello,

I have .bam file of paired reads that was pre-filtered to specific locus using samtools (ie.):

samtools view -bS possorted_genome_bam.bam -f 2 -F 4 "14:21621800-22552200" "7:142299100-142813500" > possorted_genome_filt.bam

which was indexed afterwards. Now I want to convert it back to fastqs using bamtofastq-1.4.1. Obviously not every read will have its mate, so I wanted to use --relaxed option on resulting .bam. However when I do, I get this error:

bamtofastq v1.4.1
Didn't find both records for a paired end read. Skipping. Read name of unpaired record: A00703:356:H3KFNDSX7:1:1513:27163:20635 3:N:0:0
bamtofastq failed unexpectedly. Please contact support@10xgenomics.com with the following information: 'swap_remove index (is 0) should be < len (is 0)' library/alloc/src/vec/mod.rs:1300:
   0: bamtofastq::set_panic_handler::{{closure}}
             at /root/src/main.rs:975:25
   1: std::panicking::rust_panic_with_hook
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:610:17
   2: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:502:13
   3: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:139:18
   4: rust_begin_unwind
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:498:5
   5: core::panicking::panic_fmt
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/panicking.rs:107:14
   6: alloc::vec::Vec<T,A>::swap_remove::assert_failed
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/alloc/src/vec/mod.rs:1300:13
   7: alloc::vec::Vec<T,A>::swap_remove
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/alloc/src/vec/mod.rs:1305:13
      bamtofastq::proc_double_ended
             at /root/src/main.rs:1241:18
      bamtofastq::inner
             at /root/src/main.rs:1115:13
   8: bamtofastq::go
             at /root/src/main.rs:1026:13
      bamtofastq::main
             at /root/src/main.rs:958:15
   9: core::ops::function::FnOnce::call_once
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/ops/function.rs:227:5
      std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:123:18
  10: main
  11: __libc_start_main
             at /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
  12: <unknown>

Strangely while without --relaxed option bamtofastq does output at least some reads in .fastq files with --relaxed option they are all empty. I am not very familiar with Rust so i am not sure whether this is some kind of bug or I am missing some dependencies. Could you please help me to find out what is happening and how to solve the issue? Sadly, subsetting locus with bamtofastq directly is not an option because bamtofastq doesn't seem to support multiple loci in one command.

[blake-bowen]

Did you figure out a solution for this? I'm having a similar issue

[JurMich]

Sorry for late reply, I didn't figure the source of issue beyond it being definitely caused by presence of unpaired reads and/or --relaxed option. I circumvented it by filtering unpaired reads (after filtering by samtools to specific loci as in original post) out manually before passing them to bamtofastq without --relaxed option. For me it was feasible as relatively few reads mapped to given loci so it didn't require lot of time/memory. Another option, if you filter to single locus, is to use --locus option in bamtofastq directly (format chrom:start-end is like in samtools). This won't work however if you need to filter reads that map to a list of multiple loci, as in my case.