paudano
commented
1 year ago There are a couple of potential causes for these. PAV calls SVs using two approaches, (a) by looking directly at the alignment (CIGAR string), or (b) by traversing loci where the alignment is split into two records. Indels and smaller SVs are called from the CIGAR string (a), but larger SVs cause the aligner to fragment contigs into two records, for example, one alignment stops at the left end of a deletion, then another alignment starts at the right end.
To make a deletion call this large, the aligner must be fragmenting, and PAV requires that the contig pick up on the right side where it left off on the left side (i.e. each side of the deletion is bordered by the same contig name and contiguous contig coordinates), and that's how PAV makes (b) calls. Minimap2 fragments large SVs, but LRA is often able to capture very large SVs in the CIGAR string (a), although I doubt deletions this large would be in a single alignment, and so I am pretty sure it's calling from fragmented alignments by (b).
I see two possibilities: 1) They are true deletions, although this seems very unlikely. I can't imagine many cells surviving a deletion this large even if heterozygous. Could also be somatic and anneuploid depending on where the sample came from (i.e. a tumor).
2) They are a misassembly. This is the most likely cause and the only deletions I have seen in the megabase range in the HGSVC work were misassemblies where a misjoin across segmental duplications caused a contig to map aberantly and look just like a large deletion.
If it's a misassembly (2), then PAV is dropping all variants inside the deletion assuming that contigs mapping within a deleted locus are aberrant alignments, which does happen.
To investigate this, you can look at the alignment BED (results/SAMPLE/align/aligned_tig_HAP.bed.gz, where SAMPLE and HAP match the sample/hap from the variant call) and see if there are many alignment records under the deletion. If you prefer to work with CRAMs, ask PAV to generate that file but with .cram instead of .bed.gz. It can also generate a UCSC track in BigBed format (tracks/SAMPLE/align/post-cut.bb, track color: pink=hap1, purple=hap2).
If you determine it is a misassembly, using PAV alignments or other tools (i.e. I think Flagger should be able to do this), then you can create a BED file of misassemblies in contig coordinates and give it to PAV as a misassembly filter. On the variant call, you'll see a TIG_REGION annotation for the deletion call (the easiest place to get it is directly from the pre-merged BED, results/SAMPLE/bed/pre_merge/HAP/svindel_del.bed.gz), and you can make a contig BED from that locus, which will be 1 bp long. Note that TIG_REGION is 1-based coordinates, so subtract one from the start position. Also, I would pad it by at least 5 bp on each side, and maybe more to eliminate false variants around the contig misjoin.
With that filter, variants touching that region of the contig will be ignored causing PAV to drop the false-deletion and bring back all the variants underneath it. The configuration option is "tig_filter_pattern", which must contain sample and haplotype wildcard patterns (e.g. /path/to/tig_filter/{sample}_{hap}.bed.gz), then force-rerun PAV from rule call_integrate_sources (add -R call_integrate_sources pav_SAMPLE.vcf.gz to the PAV run command).
I think I need to develop some heuristics in PAV to detect and ignore some large deletions, although these are pretty rare and I haven't seen multi-Mbp deletions with modern aligners. If you are able to share the alignments and variant calls from these, it might help me develop this into PAV.
bioinfogit
I am getting very large deletion >20 Mb for the following version. for ##fileformat=VCFv4.2 ##source=PAV 2.2.3 and I think this is the latest version of singularity image . this is the case for multiple human samples with very good assembly metrics and phasing . these are the largest for two samples . considering both haplotype have good contiguity I am wondering if there is any issue with the SV calling. sample1 chr8 DEL -31.5771M chr7 DEL -47.4833M chr11 DEL -50.008M chr1 DEL -95.0136M sample2 chr9 DEL -20.1368M chr9 DEL -20.8878M chr5 DEL -22.838M chr2 DEL -88.2308M