gistfile1.txt

./vg construct -r /lustre/scratch113/projects/graphs/yeast/data/SGD_2010.fasta \
-v /lustre/scratch113/projects/graphs/yeast/data/SGRP2-cerevisiae-freebayes-snps-Q30-GQ30.vcf.gz \
-m 1000 -a > output/yeastgraph.vg\

./vg mod -pl 16 -e 3 output/yeastgraph.vg \
| ./vg mod -S -l 32 - \
| ./vg kmers -gB -k 16 -F -H 1000000000 -T 1000000001 - \
> output/yeastgraph.graph /

This gets stuck in a weird place. In rebuild_mapping_aux.

To reproduce (assume we've built our graph into yeast1.vg):

gdb vg-81b5a2cb -ex 'r mod -pl 16 -e 3 yeast1.vg >yeast1.modl16e3.vg'

Let it run for a while (10 minutes), now control+c and bt (backtrace) should show us what's happening:

Program received signal SIGINT, Interrupt.
vg::Paths::rebuild_mapping_aux() () at /software/hpag/gcc/4.9.2/include/c++/4.9.2/bits/stl_tree.h:1261
1261            if (!_M_impl._M_key_compare(_S_key(__x), __k))
(gdb) bt
#0  vg::Paths::rebuild_mapping_aux() () at /software/hpag/gcc/4.9.2/include/c++/4.9.2/bits/stl_tree.h:1261
#1  0x000000000047eb0e in vg::VG::prune_complex(int, int, vg::Node*, vg::Node*) () at src/vg.cpp:7909
#2  0x0000000000494756 in vg::VG::prune_complex_with_head_tail(int, int) () at src/vg.cpp:7804
#3  0x000000000044b62f in main_mod(int, char**) () at src/main.cpp:2006
#4  0x0000000000407c35 in main () at src/main.cpp:5892

So one solution may be to remove the paths from the graph before pruning. They are irrelevant for this process.

But this should not be happening, anyway. So thanks @willgdjones for the catch.

There is a hack here that works. Strip the paths.

vg-81b5a2cb mod -D yeast1.vg | vg-81b5a2cb mod -pl 16 -e 3 - >yeast1.modl16e3.vg

This completes pretty quickly. I'm going to try the last parts of the process and see how it goes.

Something is very wrong with the path manipulation. @adamnovak has reported it I think, but I'm not finding the documentation.