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, -- Sebastian Weber Group of Cell Communication and Control Freiburg Institute for Advanced Studies - FRIAS School of Life Sciences - LIFENET Albert-Ludwigs-Universität Freiburg Albertstr. 19 79104 Freiburg T.: +49-761-203-97237 Fax:+49-761-203-97334
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>
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
-- Sebastian Weber Group of Cell Communication and Control Freiburg Institute for Advanced Studies - FRIAS School of Life Sciences - LIFENET Albert-Ludwigs-Universität Freiburg Albertstr. 19 79104 Freiburg T.: +49-761-203-97237 Fax:+49-761-203-97334
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 -- Tiago de Paula Peixoto <tiago@skewed.de>
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
-- Sebastian Weber Group of Cell Communication and Control Freiburg Institute for Advanced Studies - FRIAS School of Life Sciences - LIFENET Albert-Ludwigs-Universität Freiburg Albertstr. 19 79104 Freiburg T.: +49-761-203-97237 Fax:+49-761-203-97334
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 -- Tiago de Paula Peixoto <tiago@skewed.de>
participants (2)
-
Sebastian Weber -
Tiago de Paula Peixoto