-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A simple question #7
Comments
A little bit more information: Thanks! |
Hi George. Thanks for reporting this. Why is "999" in your ALT field for the second file? I need to look at the code, but I think any line with invalid ALT entries will be skipped. Are there any errors reported in the ".log" file? |
As another note, SVmerge will in general consider deletions without the sequence only when you have an "END" tag in the INFO field (which I see you do for both variants), and will only consider insertions if the inserted sequence is specified either in the ALT field or as a "SEQ=" INFO field entry. |
Sorry the manta call was copied wrong, it should be like this: They all have END tag in the INFO field. The log file is this: 2020/07/29 10:13:42 Calculating distances between neighboring variants in VCF files listed in test.fof Thanks! |
Hi there,
For testing, I made two vcf files, one file has record like this
chr1 108190704 DEL00000334 T <DEL> . PASS IMPRECISE;SVTYPE=DEL;SVLEN=-3926;SVMETHOD=EMBL.DELLYv0.8.1;CHR2=chr1;END=108194630 ...
and another file has only one record like this:
chr1 108190708 MantaDEL:180899:0:1:0:0:0 A <DEL> 999 PASS END=108194629;SVTYPE=DEL;SVLEN=-3921;
Supposedly, they should be merged, since breakpoints are very close to each other (left side 4bp, right side 1bp). But the output file still has two records. Is this expected?
I ran the command as this:
SVmerge --fof ${filename} --ref $HG38
Thanks!
George
The text was updated successfully, but these errors were encountered: