Hi!
I just discovered a quite strange behavior of graph-tool. I want to keep only the largest component of my network and the following code
comp = label_largest_component(G) lc = comp.a == 1 Gv = Graph(GraphView(G, vfilt=lc), prune=True)
simply gives wrong results. It deletes vertices which are in the LC and have comp[v]==1 !!! Instead, the much slower
G.remove_vertex_if(lambda v: comp[v] == 0)
call works just fine. The version of graph-tool is something close to 2.2.12, but I haven't seen any changes on git which seems to relate to this issue. It is quite scary that vertex deletion is somewhat unpredictable or I am doing something wrong here.
Any help would be great here.
Cheers,
On 05/30/2011 04:18 PM, Sebastian Weber wrote:
I just discovered a quite strange behavior of graph-tool. I want to keep only the largest component of my network and the following code
comp = label_largest_component(G) lc = comp.a == 1 Gv = Graph(GraphView(G, vfilt=lc), prune=True)simply gives wrong results. It deletes vertices which are in the LC and have comp[v]==1 !!!
I cannot reproduce this problem. Do you have a concrete (and simple) example of where this happens?
With "prune=True", the filtered vertices are not deleted, but rather only the non-filtered vertices are copied. So in order for this to somehow fail, there must be something wrong with the filtered graph you are trying to copy.
BTW, why do you use 'lc' as the vfilt parameter of GraphView, instead of 'comp' directly?
Cheers, Tiago
Hi Tiago!
Enclosed is a python script which produces the error. I will send the corresponding data file for the example to your personal address in order not to spam half a megabyte to the list. Moreover, when writing the example I encountered weird problems in the find_vertex function. I compile graph-tool without openmp, but apparently there are some issues here with it. When I use find_vertex, as commented out in the example, then the program crashes with this error:
dyld: lazy symbol binding failed: Symbol not found: _omp_get_num_threads Referenced from: /Volumes/Data/sebi/.local/lib/python2.6/site-packages/graph_tool/util/libgraph_tool_util.so Expected in: flat namespace
dyld: Symbol not found: _omp_get_num_threads Referenced from: /Volumes/Data/sebi/.local/lib/python2.6/site-packages/graph_tool/util/libgraph_tool_util.so Expected in: flat namespace
^CTrace/BPT trap
Hence, there seem to be some openmp issues even though I disabled it (or at least did not enable it during compilation). Not using find_vertex, but find_pink does work instead.
Cheers,
Sebastian
Am 31.05.2011 um 00:38 schrieb Tiago de Paula Peixoto:
On 05/30/2011 04:18 PM, Sebastian Weber wrote:
I just discovered a quite strange behavior of graph-tool. I want to keep only the largest component of my network and the following code
comp = label_largest_component(G) lc = comp.a == 1 Gv = Graph(GraphView(G, vfilt=lc), prune=True)
simply gives wrong results. It deletes vertices which are in the LC and have comp[v]==1 !!!
I cannot reproduce this problem. Do you have a concrete (and simple) example of where this happens?
With "prune=True", the filtered vertices are not deleted, but rather only the non-filtered vertices are copied. So in order for this to somehow fail, there must be something wrong with the filtered graph you are trying to copy.
BTW, why do you use 'lc' as the vfilt parameter of GraphView, instead of 'comp' directly?
Cheers, Tiago -- Tiago de Paula Peixoto tiago@skewed.de
graph-tool mailing list graph-tool@skewed.de http://lists.skewed.de/mailman/listinfo/graph-tool
Hi Sebastian,
On 05/31/2011 09:01 AM, Sebastian Weber wrote:
Enclosed is a python script which produces the error. I will send the corresponding data file for the example to your personal address in order not to spam half a megabyte to the list.
So, it seems the problem is not with the copying of the graph itself, but rather with the _properties_. In the case you sent, the _names_ of the vertices get wrongly copied, because the vertex index changed...
The fix is easy enough, and is already in git.
Moreover, when writing the example I encountered weird problems in the find_vertex function. I compile graph-tool without openmp, but apparently there are some issues here with it. When I use find_vertex, as commented out in the example, then the program crashes with this error:
dyld: lazy symbol binding failed: Symbol not found: _omp_get_num_threads Referenced from: /Volumes/Data/sebi/.local/lib/python2.6/site-packages/graph_tool/util/libgraph_tool_util.so Expected in: flat namespace
Strange, I cannot reproduce this here... Can you check if USING_OPENMP is defined in your config.h after you run configure?
Cheers, Tiago
Hi Tiago!
So, it seems the problem is not with the copying of the graph itself, but rather with the _properties_. In the case you sent, the _names_ of the vertices get wrongly copied, because the vertex index changed...
The fix is easy enough, and is already in git.
Great, this is very good news! Thanks. I will check it out in a minute.
Moreover, when writing the example I encountered weird problems in the find_vertex function. I compile graph-tool without openmp, but apparently there are some issues here with it. When I use find_vertex, as commented out in the example, then the program crashes with this error:
dyld: lazy symbol binding failed: Symbol not found: _omp_get_num_threads Referenced from: /Volumes/Data/sebi/.local/lib/python2.6/site-packages/graph_tool/util/libgraph_tool_util.so Expected in: flat namespace
Strange, I cannot reproduce this here... Can you check if USING_OPENMP is defined in your config.h after you run configure?
Yes, it is defined as
#define USING_OPENMP 0
I then added --disable-openmp to the configure script and now it is
/* #undef USING_OPENMP */
So, the default seems to be to include the definition set to 0. I guess you check for definition of USING_OPENMP, but not if it is 0 or 1. Anyway, I will try compilation with the last configure output.
Cheers,
Sebastian
Cheers, Tiago
-- Tiago de Paula Peixoto tiago@skewed.de
graph-tool mailing list graph-tool@skewed.de http://lists.skewed.de/mailman/listinfo/graph-tool
On 06/01/2011 08:45 AM, Sebastian Weber wrote:
Strange, I cannot reproduce this here... Can you check if USING_OPENMP is defined in your config.h after you run configure?
Yes, it is defined as
#define USING_OPENMP 0
Ugh... This is a stupid configure bug. I've fixed it now in the git version.
Cheers, Tiago
-
Sebastian Weber -
Tiago de Paula Peixoto