Is this a trim-paf bug?

[nhansen]

Hi Mitchell! We're using a linux install of rustybam (v0.1.33) to neaten up chain files we've produced from hprc assemblies aligned to chm13. As was done for the chrY paper, we use a paf file that was created from an nfLO chain file, and run:

cat chm13v2_to_assembly.paf | rb break-paf --max-size 10000 | rb trim-paf -r | rb invert | rb trim-paf -r | rb invert > chm13v2_to_assembly.final.paf

One assembly (out of over one hundred) is dying on the second trim-paf step. I'm attaching the offending paf lines workingtestcase.paf.txt which trigger the error. Running

cat workingtestcase.paf | rb trim-paf -r

produces the error:

thread 'main' panicked at /home/nhansen/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustybam-0.1.33/src/paf.rs:783:32:
called `Result::unwrap()` on an `Err` value: PafParseCigar { msg: "query bases 2 from cigar does not equal 100134795-100134795=0\nchr14\t101161492\t100134795\t100134795\t-\tpat-0000566\t67653\t24817\t24822\t444\t452\t255\tid:Z:\tcg:Z:1=3D1X\n" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Thanks for any help you can give!
--Nancy

[mrvollger]

Darn. Can you share the target and query contigs as well so I can use a paf validation tool? I imagine there is some corner case that is causing break to produce invalid paf.

It might be a little while till I get to this in part because it's been quite a while till I had to touch this code. One thing you might try in the meantime is changing the break size to see if a different break size will make valid a paf.

Thanks for the report!