-
Notifications
You must be signed in to change notification settings - Fork 194
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
vg call fails: Address not mapped to object #1459
Comments
We don't currently support graphs with long dangling pieces; they get parsed into nested unary snarls, but if the tree gets too deep we can't recurse over it and we explode. The right solution is to rewrite all our recursive algorithms as iterative algorithms. The short-term solution is to convince vg call to use a different primary path to structure the snarl traversal, or make the graph more linear-shaped. What shapes are the graphs you are working on? Do they include, for example, edges between different chromosomes? Or multiple alternative telomeres? |
Thanks for your reply. |
Hello,
Yes, clamping each connected component down to a single head and a single
tail should resolve this. Let me know if it doesn't.
We have vague plans to rewrite the algorithm to handle these cases, but
it's unfortunately not critical path for handling any of the graphs the
core development team is working on. This might be a good project for
someone who does want to work on graphs with that structure and wants to
submit a PR. Failing that, I think it's on our "eventually" list.
What *I* really want to do is to rework unary snarls at the conceptual
level; what right now is a very deep nested structure of unary snarls IMHO
ought to be a chain of normal snarls ending in a single unary terminal
snarl. But I think our team has even less free time to hash that out.
…On Tue, Feb 27, 2018 at 1:16 AM, ChriKub ***@***.***> wrote:
Thanks for your reply.
It is probably a long dangling piece/telomere. The graph was constructed
using reveal, thus it is linear and does not contain any edges between
chromosomes, or repeats. I will try to introduce a single node at the end
of each chromosome to anchor the telomeres. That should fix the problem for
now, right?
Do you intend to rewrite the algorithm to be able to cope with this at any
point, as this problem should be fairly common when working with whole
genome alignments.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1459 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AE0_X8c9YsWvVM5-GE6aBWAFJwcERO3eks5tY8gJgaJpZM4SKoEB>
.
|
Hi Adam,
|
Hm.
It could be that the reads are introducing long dangling tails somehow. Can
`vg snarls graph.vg >/dev/null` run through on the graph reference you are
using? If so, the problem is the graph augmentation with the reads. If not,
there's still something complex in the snarl structure of the base graph.
…On Wed, Mar 7, 2018 at 1:38 AM, ChriKub ***@***.***> wrote:
Hi Adam,
I tried clamping down the ends, but it still throws an error. I'm not sure
if it is the same, although stSnarl_makeRecursiveSnarl is still called.
Reading input graph
Calling variants with support caller
Primary path AT6909_Chr1 average/off-path assumed coverage: 20.8359,20.9331
Mininimum binned average coverage: 0,0 (bin 1 / 121089)
Maxinimum binned average coverage: 1522.12,1510.03 (bin 15804 / 121089)
Primary path AT6909_Chr2 average/off-path assumed coverage: 23.2543,23.2987
Mininimum binned average coverage: 0,0 (bin 19 / 80086)
Maxinimum binned average coverage: 1141.86,1172.46 (bin 13936 / 80086)
Primary path AT6909_Chr3 average/off-path assumed coverage: 21.3937,21.4521
Mininimum binned average coverage: 0,0 (bin 1 / 93697)
Maxinimum binned average coverage: 814.596,1477.78 (bin 31430 / 93697)
Primary path AT6909_Chr4 average/off-path assumed coverage: 21.1099,21.1626
Mininimum binned average coverage: 0,0 (bin 2 / 74903)
Maxinimum binned average coverage: 1128.95,1159.84 (bin 27777 / 74903)
Primary path AT6909_Chr5 average/off-path assumed coverage: 20.7084,20.7151
Mininimum binned average coverage: 0,0 (bin 1 / 109331)
Maxinimum binned average coverage: 662.38,695.52 (bin 9905 / 109331)
Stack trace (most recent call last):
#31 <#31> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#30 <#30> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#29 <#29> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#28 <#28> | Source
"impl/stCactusGraphs.c", line 1179, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1195, in stSnarl_makeRecursiveSnarl
[0xdc203d]
#27 <#27> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#26 <#26> | Source
"impl/stCactusGraphs.c", line 1179, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1195, in stSnarl_makeRecursiveSnarl
[0xdc203d]
#25 <#25> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#24 <#24> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#23 <#23> | Source
"impl/stCactusGraphs.c", line 1179, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1195, in stSnarl_makeRecursiveSnarl
[0xdc203d]
#22 <#22> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#21 <#21> | Source
"impl/stCactusGraphs.c", line 1179, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1195, in stSnarl_makeRecursiveSnarl
[0xdc203d]
#20 <#20> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#19 <#19> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#18 <#18> | Source
"impl/stCactusGraphs.c", line 1179, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1195, in stSnarl_makeRecursiveSnarl
[0xdc203d]
#17 <#17> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#16 <#16> | Source
"impl/stCactusGraphs.c", line 1179, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1195, in stSnarl_makeRecursiveSnarl
[0xdc203d]
#15 <#15> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#14 <#14> | Source
"impl/stCactusGraphs.c", line 1179, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1195, in stSnarl_makeRecursiveSnarl
[0xdc203d]
#13 <#13> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#12 <#12> | Source
"impl/stCactusGraphs.c", line 1179, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1195, in stSnarl_makeRecursiveSnarl
[0xdc203d]
#11 <#11> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#10 <#10> | Source
"impl/stCactusGraphs.c", line 1179, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1195, in stSnarl_makeRecursiveSnarl
[0xdc203d]
#9 <#9> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#8 <#8> | Source
"impl/stCactusGraphs.c", line 1179, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1195, in stSnarl_makeRecursiveSnarl
[0xdc203d]
#7 <#7> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#6 <#6> | Source
"impl/stCactusGraphs.c", line 1179, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1195, in stSnarl_makeRecursiveSnarl
[0xdc203d]
#5 <#5> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#4 <#4> | Source
"impl/stCactusGraphs.c", line 1179, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1195, in stSnarl_makeRecursiveSnarl
[0xdc203d]
#3 <#3> | Source
"impl/stCactusGraphs.c", line 1160, in stSnarl_makeRecursiveSnarl
Source "impl/stCactusGraphs.c", line 1151, in stSnarl_makeRecursiveSnarl
[0xdc2094]
#2 <#2> | Source
"impl/stCactusGraphs.c", line 1146, in stSnarl_constructEmptySnarl
Source "impl/stCactusGraphs.c", line 1075, in stSnarl_makeRecursiveSnarl
[0xdc1f09]
#1 <#1> Source "impl/sonLibCommon.c",
line 42, in st_calloc [0xdcaea0]
#0 Source "src/tcmalloc.cc", line 1641, in tc_calloc [0x1165e02]
Segmentation fault (Address not mapped to object [0x7ffefc36eff8])
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1459 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AE0_XzF1bQiyOhr1Rtl4rXd1CMRLxnz_ks5tb6qggaJpZM4SKoEB>
.
|
It doesn't run through. So I will need to have a closer look into the graph. Is there any way of identifying the snarl that kills it with vg snarls?
|
You could hook up a debugger and see what some of the node IDs involved are
by inspecting the arguments to those recursively_emit_snarls calls, I
suppose. Or you could add some extra code to make it dump the snarls it is
working on. There's not really a way to dump the problematic snarls right
now.
…On Wed, Mar 7, 2018 at 3:56 PM, ChriKub ***@***.***> wrote:
It doesn't run through. So I will need to have a closer look into the
graph. Is there any way of identifying the snarl that kills it with vg
snarls?
Stack trace (most recent call last):
#31 <#31> Source "src/snarls.cpp",
line 180, in recursively_emit_snarls [0x94e5fe]
#30 <#30> Source "src/snarls.cpp",
line 180, in recursively_emit_snarls [0x94e5fe]
#29 <#29> Source "src/snarls.cpp",
line 180, in recursively_emit_snarls [0x94e5fe]
#28 <#28> Source "src/snarls.cpp",
line 180, in recursively_emit_snarls [0x94e5fe]
#27 <#27> Source "src/snarls.cpp",
line 180, in recursively_emit_snarls [0x94e5fe]
#26 <#26> Source "src/snarls.cpp",
line 180, in recursively_emit_snarls [0x94e5fe]
#25 <#25> Source "src/snarls.cpp",
line 145, in recursively_emit_snarls [0x94e53d]
#24 <#24> Source "src/snarls.cpp", line
180, in recursively_emit_snarls [0x94e5fe]
#23 <#23> Source "src/snarls.cpp",
line 145, in recursively_emit_snarls [0x94e53d]
#22 <#22> Source "src/snarls.cpp",
line 180, in recursively_emit_snarls [0x94e5fe]
#21 <#21> Source "src/snarls.cpp",
line 145, in recursively_emit_snarls [0x94e53d]
#20 <#20> Source "src/snarls.cpp",
line 180, in recursively_emit_snarls [0x94e5fe]
#19 <#19> Source "src/snarls.cpp",
line 145, in recursively_emit_snarls [0x94e53d]
#18 <#18> Source "src/snarls.cpp",
line 180, in recursively_emit_snarls [0x94e5fe]
#17 <#17> Source "src/snarls.cpp",
line 145, in recursively_emit_snarls [0x94e53d]
#16 <#16> Source "src/snarls.cpp",
line 180, in recursively_emit_snarls [0x94e5fe]
#15 <#15> Source "src/snarls.cpp",
line 145, in recursively_emit_snarls [0x94e53d]
#14 <#14> Source "src/snarls.cpp",
line 180, in recursively_emit_snarls [0x94e5fe]
#13 <#13> Source "src/snarls.cpp",
line 145, in recursively_emit_snarls [0x94e53d]
#12 <#12> Source "src/snarls.cpp",
line 180, in recursively_emit_snarls [0x94e5fe]
#11 <#11> Source "src/snarls.cpp",
line 145, in recursively_emit_snarls [0x94e53d]
#10 <#10> Source "src/snarls.cpp",
line 180, in recursively_emit_snarls [0x94e5fe]
#9 <#9> Source "src/snarls.cpp", line
145, in recursively_emit_snarls [0x94e53d]
#8 <#8> Source "src/snarls.cpp", line
180, in recursively_emit_snarls [0x94e5fe]
#7 <#7> Source "src/snarls.cpp", line
145, in recursively_emit_snarls [0x94e53d]
#6 <#6> Source "src/snarls.cpp", line
180, in recursively_emit_snarls [0x94e5fe]
#5 <#5> Source "src/snarls.cpp", line
180, in recursively_emit_snarls [0x94e5fe]
#4 <#4> Source "src/snarls.cpp", line
145, in recursively_emit_snarls [0x94e53d]
#3 <#3> Source "src/snarls.cpp", line
180, in recursively_emit_snarls [0x94e5fe]
#2 <#2> Source "src/snarls.cpp", line
145, in recursively_emit_snarls [0x94e53d]
#1 <#1> Source "src/snarls.cpp", line
180, in recursively_emit_snarls [0x94e5fe]
#0 Source "src/snarls.cpp", line 73, in recursively_emit_snarls [0x94e331]
Segmentation fault (Address not mapped to object [0x7ffeb3d39f18])
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1459 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AE0_X6MIGBiTYcQjU4_wxCkuvLI8yZe8ks5tcHOmgaJpZM4SKoEB>
.
|
Hi,
I tried to call variants from a short read mapping to a 2 genome variation graph but vg call fails. This happens on two independent graphs with different input sequences and sequencing data sets.
vg call -v -p -t 20 -r Chr1 -r Chr2 -r Chr3 -r Chr4 -r Chr5 -z augment.translation -s augment.support -b graph.vg graph.augmented > variant.vcf 2> variant.out
The text was updated successfully, but these errors were encountered: