graph-tool November 2021

graph-tool@skewed.de

9 participants
11 discussions

overlap/mixed-membership sbm help
by Eli Draizen 07 Mar '22

07 Mar '22

Hi everyone, I was wondering if it would be possible to provide some more examples of how to run a nested mixed membership SBM with edge weights. The new version seems to have removed the "overlap=True" option for state_args in the minimize_* functions. Is this the correct way to do it now? import graph_tool as gta > import numpy as np > g = .... # build graph > e_score = .... #Set edge weights > state_args = dict( > deg_corr=deg_corr, > base_type=gta.inference.overlap_blockmodel.OverlapBlockState, > B=2*g.num_edges(), #B_max > deg_corr=True, > recs=[e_score], > rec_types=["real-normal"]) > state = gta.inference.minimize_nested_blockmodel_dl( > g, > state_args=state_args, > multilevel_mcmc_args=dict(verbose=True)) > # improve solution with merge-split > state = state.copy(bs=state.get_bs() + [np.zeros(1)] * 4, sampling=True) for i in range(100): > if i%10==0: print(".", end="") > ret = state.multiflip_mcmc_sweep(niter=10, beta=np.inf, verbose=True) I am currently running this for a fully connected bipartite graph with 3454 nodes and 55008 edges. I understand it would take longer than the non-overlapping version, but do you have any suggestions on how to speed it up? The non-overlapping version takes about 15 minutes, while the overlapping version is still running after 1 day. Thanks for your help, Eli -- PhD Candidate, Phil Bourne's lab University of Virginia _______________________________________________ graph-tool mailing list -- graph-tool(a)skewed.de To unsubscribe send an email to graph-tool-leave(a)skewed.de

2 4

How to control the orientation of the graph topology
by Xun Xiao 26 Feb '22

26 Feb '22

Hi Tiago, sometimes, when delete the graph and create a new one, then plot it, the plotted graph is shown upside down (in terms of the node text). So how could we control the orientation of the graph? Or which parameter we should use to always make node text shown in a correct orientation. Thanks a lot. -- View this message in context: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com… Sent from the Main discussion list for the graph-tool project mailing list archive at Nabble.com.

3 5

Upside down labels
by charlie 26 Feb '22

26 Feb '22

Hi, I'm suffering from the same issue mentioned in this post: https://git.skewed.de/count0/graph-tool/issues/174 Namely, I'm trying to draw a graph that includes a lot of self-looping edges, and my labels are being printed upside down. If I remove the self-loops the labels are shown the right way up. Is there a fix for it? Thanks, Charlie -- View this message in context: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com… Sent from the Main discussion list for the graph-tool project mailing list archive at Nabble.com.

3 3

Model specification and extraction of layer-specific partitions in LayeredBlockState when overlap=True
by arttu.malkamaki＠helsinki.fi 25 Jan '22

25 Jan '22

Hello, I'm studying political coalitions over time (three time slices) and across discrete types of relationships (collaboration, ideological similarity, and discursive similarity). Since graph-tool offers (the only) principled approach that does not require arbitrary user-specified parameters (such as 'resolution' or 'coupling'), I would very much like to use it for my analysis. I'm trying to fit a SBM to a graph with edges divided into distinct layers (three time slices X three types of relationships). Each edge has a discrete weight in the range of [0, 3], with weight referring to the 'strength' of the relationship. Not all nodes participate in all layers. I'm interested in how/if the block membership varies across layers that I expect to be somewhat dependent on one another (hence I would like to avoid fitting a separate SBM to each layer). In my ideal scenario, I would be using the NestedBlockState with LayeredBlockState as base and allowing for overlaps across layers: state=NestedBlockState(g, base_type=LayeredBlockState, state_args=dict(deg_corr=True, overlap=True, layers=True, ec=g.ep.layer, recs=[g.ep.weight], rec_types=["discrete-binomial"])) dS, nmoves=0, 0 for i in range(100): ret=state.multiflip_mcmc_sweep(niter=10) dS+=ret[0] nmoves+=ret[1] print("Change in description length:", dS) print("Number of accepted vertex moves:", nmoves) mcmc_equilibrate(state, wait=1000, mcmc_args=dict(niter=10), verbose=True) bs=[] def collect_partitions(s): global bs bs.append(s.get_bs()) mcmc_equilibrate(state, force_niter=10000, mcmc_args=dict(niter=10), verbose=True, callback=collect_partitions) pm=PartitionModeState(bs, nested=True, converge=True) pv=pm.get_marginal(g) bs=pm.get_max_nested() state=state.copy(bs=bs) Two questions: Q1) This is taking very long (days) on a high performance cluster and actually I haven't seen it finishing up for once. Is my model specification correct or simply too complex? If the latter, is there a better strategy to perform my analysis? All I can think of is to revert to a non-nested model and/or reduce the number of layers and/or edges: state=LayeredBlockState(g, deg_corr=True, overlap=True, layers=True, ec=g.ep.layer, recs=[g.ep.weight], rec_types=["discrete-binomial"]) dS, nattempts, nmoves=state.multiflip_mcmc_sweep(niter=1000) print("Change in description length:", dS) print("Number of accepted vertex moves:", nmoves) mcmc_equilibrate(state, wait=1000, nbreaks=2, mcmc_args=dict(niter=10), verbose=True) bs=[] def collect_partitions(s): global bs bs.append(s.b.a.copy()) mcmc_equilibrate(state, force_niter=10000, mcmc_args=dict(niter=10), verbose=True, callback=collect_partitions) pm=PartitionModeState(bs, converge=True) pv=pm.get_marginal(g) Q2) Say that the model runs and yields a neat NestedBlockState (or LayeredBlockState) object with X overlapping blocks, 9 layers, degree-corrected, with 2 edge covariates, for graph <Graph object, undirected, with 220 vertices and 11322 edges, 2 internal vertex properties, 4 internal edge properties>. Now, in previous posts there are mentions about the number of nodes multiplying by the number of layers when 'overlap=True', but in my experiments with only two layers, this does not seem to be the case and I struggle to find a way to extract the layer-specific block and respective memberships of nodes. I've tried iteration over vertices, but what I eventually need is a 2d_array [y=all nodes in g, x=all layers in g, values=most likely block membership] in order to map how/if the block membership of each node varies across those layers in which they participate (ideally somehow denoting non-participation in the layer with NaN or some unique value). Is there some way to get there? l=state.get_levels()[0] #NestedBlockState B=l.get_nonempty_B() bv=l.get_overlap_blocks()[0] z=np.zeros((g.num_vertices(), B)) #to be filled with most likely block membership with potential overlaps across ALL layers, but I need the layer-specific information for i in range(g.num_vertices()): z[int(i), :len(z[v])]=bv[i].a+1 for v in range(g.num_vertices()*max(g.ep.layer)+1): #to see if the number of vertices multiplied by layers, which it didn't print(bv[v]) Many thanks, Arttu

2 15

Layered networks, compared to the a null model
by James Ruffle 30 Nov '21

30 Nov '21

Dear Tiago/community, I have been reading your 2015 article on layered networks, where you illustrate favourable model fits on layered formulation compared to a non-layered null. But, I was wondering if you could please clarify the appropriate null model from which the comparisons in model entropy are then made? Considering the following example, which is the example on the graph-tool website: g = gt.collection.ns["new_guinea_tribes”] #layered model state = gt.minimize_nested_blockmodel_dl(g,state_args=dict(base_type=gt.LayeredBlockState,state_args=dict(ec=g.ep.weight, layers=True))) print(state.entropy()) ##This gives me a model entropy of 166.92854839491955 #Presumably the null model is as follows, where one simply does not pass a layered block state, and fits the model as if a singular edge layer? state_null = gt.minimize_nested_blockmodel_dl(g) print(state_null.entropy()) ##But this gives me a model entropy of 113.74058711521675 I’m a little confused by this as, whilst the example on the website makes perfect sense, then the model entropy seems to suggest I should favour the non-layered null? Thank you for your clarification. BW James _______________________________________________ graph-tool mailing list -- graph-tool(a)skewed.de To unsubscribe send an email to graph-tool-leave(a)skewed.de

2 2

All Pairs Shortest Path with limitations
by Monecke, Stephan 28 Nov '21

28 Nov '21

Hi together, I have a question on how you would tackle the following: I have a graph and want to calculate all possible shortest paths but exclude a few nodes as starting / stopping positions. I can not filter out those vertices, since paths should be allowed to pass them - just not start or terminate there. Calculating all possible shortest paths manually is computationally infeasible. Thanks a lot! Stephan _______________________________________________ graph-tool mailing list -- graph-tool(a)skewed.de To unsubscribe send an email to graph-tool-leave(a)skewed.de

4 11

Modelling with community structure data
by James Ruffle 23 Nov '21

23 Nov '21

Dear Tiago / community, We are using the stochastic block model in a research project and trying to formulate how we would best utilise the community structure results downstream, and would welcome any suggestions. We fit a nested stochastic block model with an edge weight, which gives us a hierarchical partition. From this, we want to report not just the underlying community structure, but also some form of corresponding weights of given blocks, how ‘important' a given block is with respect to the edge weight, say. Considering an example on the weighted foodweb network: import graph_tool.all as gt; import numpy as np; import matplotlib; g = gt.collection.ns["foodweb_baywet"] state = gt.minimize_nested_blockmodel_dl(g, state_args=dict(recs=[g.ep.weight], rec_types=["real-exponential"])) This yields a hierarchical community structure, but how would you most suitably determine what communities were ‘most’ or ‘least’ important/influential/correlated with respect to the edge weight? I have considered whether this might be done with centrality metrics on the blocks (or perhaps vcount and ecount data from a condensation graph on the hierarchical blocks), but was keen to see if you had a more innovative idea... Thank you for your advice! James _______________________________________________ graph-tool mailing list -- graph-tool(a)skewed.de To unsubscribe send an email to graph-tool-leave(a)skewed.de

3 4

Vertex pointer not updated on graph filtering
by Monecke, Stephan 17 Nov '21

17 Nov '21

Hi together! I just noticed that vertices that had been saved within an external list are not being updated when filtering the graph: >>> G.set_edge_filter( G.edge_properties[ 'e_isbus'], inverted=True) >>> G.set_vertex_filter(G.vertex_properties['v_isbus'], inverted=True) >>> print( [ int(n) for n in node.all_neighbors() ] ) [101, 22, 265, 496, 518, 22, 265, 496, 101, 518] >>> print( [ int(n) for n in G.vertex( int(node) ).all_neighbors() ] ) [101, 22, 265, 22, 265, 101] Did I miss something or is this a bug? Thanks a lot for any ideas! Stephan _______________________________________________ graph-tool mailing list -- graph-tool(a)skewed.de To unsubscribe send an email to graph-tool-leave(a)skewed.de

3 2

Help - Unable to make install
by Samuel Fusato 13 Nov '21

13 Nov '21

Hello everyone, I apologize if this is not the right place to post this issue. I am trying to install graph-tool on a RHEL7 within a virtualenv (I have Jupyterhub running on it). ================================================================================ CONFIGURATION SUMMARY ================================================================================ Using python version: 3.6.3 Python interpreter: /jupyter/bin/python Installation path: /jupyter/lib/python3.6/site-packages/graph_tool C++ compiler (CXX): g++ -std=gnu++17 C++ compiler version: 7 Prefix: /root/.local Pkgconfigdir: ${libdir}/pkgconfig Python CPP flags: -I/jupyter/lib/python3.6/site-packages/cairo/include -I/opt/rh/rh-python36/root/usr/include/python3.6m Python LD flags: -L/opt/rh/rh-python36/root/usr/lib64 -lpython3.6m Boost CPP flags: -pthread -I/usr/include Boost LD flags: -L/usr/lib64 -lboost_iostreams-mt -lboost_python36 -lboost_regex-mt -lboost_context-mt Numpy CPP flags: -I/jupyter/lib/python3.6/site-packages/numpy/core/include Sparsehash CPP flags: CGAL CPP flags: -I/usr/include CGAL LD flags: Expat CPP flags: Expat LD flags: -lexpat Cairomm CPP flags: -I/usr/include/cairomm-1.0 -I/usr/lib64/cairomm-1.0/include -I/usr/include/cairo -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/uuid -I/usr/include/libdrm Cairomm LD flags: -lcairomm-1.0 -lcairo -lsigc-2.0 OpenMP compiler flags: -fopenmp OpenMP LD flags: Extra CPPFLAGS: -DNDEBUG Extra CXXFLAGS: -fopenmp -O3 -fvisibility=default -fvisibility-inlines-hidden -Wno-deprecated -Wall -Wextra -ftemplate-backtrace-limit=0 Extra LDFLAGS: Using OpenMP: yes Using sparsehash: yes Using cairo: yes ================================================================================ However, when trying to install it, I receive the following errors (I truncated the output by adding the ellipsis): (...) blockmodel/graph_blockmodel_emat.hh:126:12: error: ‘graph_tool::EHash<boost::adj_list<long unsigned int> >::ehash_t {aka class gt_hash_map<long unsigned int, boost::detail::adj_edge_descriptor<long unsigned int>, std::hash<long unsigned int>, std::equal_to<long unsigned int>, std::allocator<std::pair<const long unsigned int, boost::detail::adj_edge_descriptor<long unsigned int> > > >}’ has no member named ‘min_load_factor’; did you mean ‘max_load_factor’? _h.min_load_factor(.25); ~~~^~~~~~~~~~~~~~~ max_load_factor (...) blockmodel/graph_blockmodel_gibbs.cc:55:49: required from here blockmodel/graph_blockmodel_emat.hh:126:12: error: ‘graph_tool::EHash<boost::undirected_adaptor<boost::adj_list<long unsigned int> > >::ehash_t {aka class gt_hash_map<long unsigned int, boost::detail::adj_edge_descriptor<long unsigned int>, std::hash<long unsigned int>, std::equal_to<long unsigned int>, std::allocator<std::pair<const long unsigned int, boost::detail::adj_edge_descriptor<long unsigned int> > > >}’ has no member named ‘min_load_factor’; did you mean ‘max_load_factor’? _h.min_load_factor(.25); ~~~^~~~~~~~~~~~~~~ max_load_factor In file included from blockmodel/graph_blockmodel_util.hh:25:0, from blockmodel/graph_blockmodel_gibbs.cc:23: blockmodel/graph_blockmodel_entries.hh:453:6: error: ‘void graph_tool: (...) td::vector<std::vector<double, std::allocator<double> >, std::allocator<std::vector<double, std::allocator<double> > > >, std::vector<double, std::allocator<double> >, std::vector<double, std::allocator<double> >, std::vector<double, std::allocator<double> >}; size_t = long unsigned int]::<lambda(auto:127&)>’, is used but never defined [-fpermissive] void move_entries(Vertex v, size_t r, size_t nr, VProp& _b, Graph& g, ^~~~~~~~~~~~ blockmodel/graph_blockmodel_entries.hh:453:6: error: ‘void graph_tool::m (...) int> > > >, boost::adj_list<long unsigned int>, std::vector<double, std::allocator<double> >, std::vector<double, std::allocator<double> > >]::<lambda(auto:99, auto:100, auto:101&, auto:102, auto:103& ...)>’, is used but never defined [-fpermissive] void entries_op(MEntries& m_entries, EMat& emat, OP&& op) ^~~~~~~~~~ blockmodel/graph_blockmodel_entries.hh:485:6: error: ‘void graph_tool: (...) :vector<double, std::allocator<double> > >]::<lambda(auto:99, auto:100, auto:101&, auto:102, auto:103& ...)>’, is used but never defined [-fpermissive] make[3]: *** [blockmodel/graph_blockmodel_gibbs.lo] Error 1 make[3]: Leaving directory `/jupyter/grapth-tool/graph-tool-2.43/src/graph/inference' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/jupyter/grapth-tool/graph-tool-2.43/src/graph' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/jupyter/grapth-tool/graph-tool-2.43/src' make: *** [install-recursive] Error 1 (jupyter) [root@workstation /jupyter/grapth-tool/graph-tool-2.43]# Please, let me know if it is possible to make any assumptions based on the above logs I shared. If not, let me know what you need and I will do my best to provide. Thank you, SAMUEL FUSATO red hat CERTIFIED SYSTEM ADMINISTRATOR - RHCSA 8 Certification ID 210-168-829 <https://rhtapps.redhat.com/certifications/badge/verify/D5UDWS5NEBPLMO5ZTQQZ…> <https://redhat.com/trusted> _______________________________________________ graph-tool mailing list -- graph-tool(a)skewed.de To unsubscribe send an email to graph-tool-leave(a)skewed.de

2 2

Graph-tool support on apple silicon ARM
by James Ruffle 13 Nov '21

13 Nov '21

Dear community/Tiago, Please could you advise if the current graph-tool builds are supported on the Apple silicon ARM chips? Apologies if this has already been answered elsewhere. Many thanks. James _______________________________________________ graph-tool mailing list -- graph-tool(a)skewed.de To unsubscribe send an email to graph-tool-leave(a)skewed.de

2 4

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

graph-tool November 2021