Still finding falsely derived InDels in v2.1.6

[dkuo-ttx]

Describe the bug
Following up from this previous bug report, we are still finding falsely InDel-derived off-targets when using the CRISPRme v2.1.6.

To Reproduce

Command:
The command to run CRISPRme was:

$ bash crisprme_auto_test_conda.sh

with the following modifications to change the mm and bDNA/bRNA limits to 3

crisprme.py complete-search \
    --genome Genomes/hg38/ \
    --vcf list_vcf.txt/ \
    --guide sg1617.txt \
    --pam PAMs/20bp-NGG-SpCas9.txt \
    --annotation Annotations/encode+gencode.hg38.bed \
    --samplesID list_samplesID.txt \
    --gene_annotation Annotations/gencode.protein_coding.bed \
    --bMax 2 \
    --mm 3 \
    --bDNA 3 \
    --bRNA 3 \
    --merge 3 \
    --output sg1617_333_216 \
    --thread 64

This produced the output file CTAACAGTTGCTTTTATCACNNN+NGG_hg38+hg38_1000G_3+3_integrated_results.tsv which we then parsed for potentially missing InDels.

Attached is a subset of 61 InDels from the output file, all of which are designated as problematic as seen in the Indel_Verified column 250227_sg1617_missingindels_v216_n61.csv.

These problematic InDels do not create the reported off-target in the genomic context after applying the CRISPRme reported variants from the column Variant_info_genome_(fewest_mm+b) back to the reference genome.

Thanks for your help and we appreciate your attention to updating the codebase. Do let us know if we can help clarify anything. Cheers!

[lindayqlin]

Thank you for following up! Yes, we are aware of this issue and plan on releasing CRISPRme v2.1.7 late next week hopefully, which fixes this bug and includes some other improvements to the CRISPRme workflow. However, if you'd prefer in the meantime, this indel bug should be absent from CRISPRme v2.1.0.

Thank you for using CRISPRme and for sharing your findings!
Linda