Issue writing REP metric to VCF about dysgu HOT 3 CLOSED

Hi Patrick,
Thanks for reporting this. I was not able to reproduce the error, but as the error looked relatively trivial I have modified the code so that the exception is bypassed. v1.3.4 should address this issue, but please re-open if this is not the case.
Could I ask, was the file PD26400a_T_vs_PD26400b_N.consensus.somatic.sv.vcf generated by dysgu? I suspect the error originates from merging SV events between the --sites input and the discovered variants.
Also note in v1.3.4, the --hom-ref-sites option has been removed as it is redundant. The --all-sites True option will output a genotype for all input sites including variants with genotype 0/0.

from dysgu.

Hey Kez,
I'll give it another try in the next few days and get back to you if I encounter any further issues.

So that file was not generated by dysgu. It is a consensus call set from Manta, SvABA, and DELLY that was merged using SURVIVOR. This does bring a question to mind, what information does dysgu pull from the VCF when using the --sites parameter? My file PD26400a_T_vs_PD26400b_N.consensus.somatic.sv.vcf is a little messy/unconventional right now so I was curious how to clean it for ensure it worked as intended.

from dysgu.

Currently, the information pulled is quite limited, basically:

chrom, start, chrom2, stop, svt, idx, r.id, svlen, pval

Where svt is SVTYPE and pval is from dysgu (if available).
This is an interesting test case, and I would be interested to know what your conclusions are from trying this combination of callers. In my own tests, I found using calls from other software can work well but as long as the supplied --sites have relatively few false positives. i.e. --sites should be a list of "confident sites".

from dysgu.