"too many CIGAR operations" when converting to sorted BAM - workaround?

[holtjma]

Hello,

I was running a test of minimap2 on the ONT NA12878 data and ran into an issue piping the output into "samtools sort -o output.bam":

[E::sam_parse1] too many CIGAR operations

I'm fairly certain it's related to this issue in samtools, so I don't think there is a fix for it at this time. My question is whether you know of a work-around other than using the uncompressed SAM format instead of BAM?

Thanks!

p.s. love how fast minimap2 runs compared to some of the other tools I'm testing!

[lh3]

SAM/CRAM do not have the same limitation. 64k cigar is a BAM only issue. You can convert SAM to BAM as follows:

git clone https://github.com/lh3/htsbox
cd htsbox; make
./htsbox samview -bS in.sam > out.bam

Sorting and viewing out.bam with old tools will preserve reads with long cigars. However, old pileup and igv will not see them.

[lh3]

Or use cram.

[holtjma]

I think I got both of these options working now and they appear to be producing summary level results identical to the original SAM, thanks for the help on finding workarounds!

[ghost]

If you want a short walk through on how to proceed with SAM files having too long CIGAR strings for BAM files you can follow this:
https://thvd.net/index.php/2017/12/03/how-to-map-long-oxford-nanopore-reads-to-reference-genome-and-view-in-igv/
It is showing how to use CRAM (and then having a look on the aligment in IGV).