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.

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.

Dear Tiago,
I have a directed graph of about half a million nodes and approximately a
million edges following scale free behaviour and a power law degree
distribution. To test some of my hypothesis, I would like to generate random
smaller graphs (about 50 up to 200 nodes) representative of the big one.
When I used a sample function that samples straight away from the real
distribution of the big network, I have following problems:
- I generate unconnected nodes with both 0 in AND out degree.
- I generate small sub parts of a few nodes that are not connected to the
main graph.
- If only sampling from nodes with at least 1 degree, the generated graph is
coherent, but not representative anymore as I need a big portion of nodes
with either only one in or one out degree.
Here is the part of my script I used for that, where samples are drawn from
dictionaries of the degrees:
def sample_in():
a=np.random.randint(num)
k_in = in_degrees[a]
return k_in
def sample_out():
if sample_in()==0:
b=np.random.randint(num_out)
k_out=out_zero_zeros.values()[b]
return k_out
else:
b=np.random.randint(num)
k_out=out_degrees[b]
return k_out
N=200
g=gt.random_graph(N, lambda:(sample_in(), sample_out()),
model="constrained-configuration", directed=True)
I also tried sampling from a list of tuples as you have mentioned before in
the forum, but I didn't receive any results, as the tuples randomly drawn
from my list might not be combinable.
degs=[(7,1),(4,3),(5,6),(2,4),(6,8),(2,0),(3,5),(0,3),(2,7),(2,1)]
g = gt.random_graph(4, lambda i: degs[i], directed=True)
- Is there any option I could active that would help me in those cases I
described above?
- Is there a better way how to create representative small networks?
Any help on that issue will be much appreciated.
Best wishes,
Jana
--
Sent from: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/

I am curious what is being used to calculate the standard deviation of the
average in gt.vertex_average and gt.edge_average
>>> t2=gt.Graph()
>>> t2.add_vertex(2)
>>> t2.add_edge(t2.vertex(0), t2.vertex(1))
>>> gt.vertex_average(t2, "in")
(0.5, 0.35355339059327373)
Now, shouldn't std be σ(n)=sqrt(((0-0.5)^2+(1-0.5)^2)/2)=0.5 ?
also q(n-1)=sqrt((0.5^2+0.5^2)/(2-1))~=0.70710
0.3535 is sqrt(2)/4 which happens to be σ(n-1)/2, so it seems there is some
relation to that.
A little bigger graph.
>>> t3=gt.Graph()
>>> t3.add_vertex(5)
>>> t3.add_edge(t3.vertex(0), t3.vertex(1))
>>> gt.vertex_average(t3, "in")
(0.2, 0.17888543819998318)
Now, we should have 0,1,0,0,0 series for vertex incoming degree.
So Windows calc gives σ(n)=0.4 and σ(n-1)~=0.44721, so where does 0.1788854
come from ?
Reason, I am asking because, I have a large graph, where the average looks
quite alright but the std makes no sense, as going by the histogram, degree
values are quite a bit more distributed than the std would indicate.
--
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.

Hi,
I was wondering if there is any way to assign vertex properties while
adding edges to the graph. for example using "add_edge_list" I can assign
edge properties but later I have to iterate through all vertices again to
assign their properties.
I know this is not a problem when the vertex property is of the type "int"
or "float" because then one can use "vprop.a = values", but in case of
"string" and "object" this method doesn't work
What would be the best/fastest way to handle this situation.
I guess it would be very helpful to extend the "add_edge_list" function to
accept vertex property in some way.
cheers,
--
Mohsen

I ran mcmc_equilibrate on a nested block state model in a weighted graph. As
per instructions, I copied the initially computed state in another object
with increased hierarchy depth to 10. However, this fixed the depth to 10.
Everything computed afterwards has depth 10 even if is clear that after 3 or
4 levels the nodes converge to one.
There are many empty branches and when I try to plot it with empty_branches
= False, I get an error stating it is not a tree.
RuntimeError: Invalid hierarchical tree: No path from source to target.
Did anybody perform any similar analyses?
The hierarchy after mcmc_equilibrate:
<NestedBlockState object, with base <BlockState object with 24 blocks (24
nonempty), degree-corrected, with 1 edge covariate, for graph <Graph
object, undirected, with 230 vertices and 11230 edges, edges filtered by
(<PropertyMap object with key type 'Edge' and value type 'bool', for
Graph 0x7fc3a89f1210, at 0x7fc3a64911d0>, False), vertices filtered by
(<PropertyMap object with key type 'Vertex' and value type 'bool', for Graph
0x7fc3a89f1210, at 0x7fc3a64912d0>, False) at 0x7fc3a89f1210>, at
0x7fc3a6491950>, and 10 levels of sizes [(230, 24), (24, 5), (5, 1), (1, 1),
(1, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 1)] at 0x7fc3a6491590>
--
Sent from: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/

Hello,
I have been trying to install graph-tool 2.27 using python 3.7.3 from
source.
I obtained the following error in the ./configure phase :
checking python module: numpy... yes
checking for numpy/arrayobject.h... yes
checking for CAIROMM... yes
checking python module: cairo... yes
checking pycairo/py3cairo.h usability... no
checking pycairo/py3cairo.h presence... no
checking for pycairo/py3cairo.h... no
configure: error: pycairo headers not found
These were my settings:
GRAPH-TOOL: (python/3.7.3 loads gcc/5.4.0)
==========
module purge
module load cmake
module load python/3.7.3
setenv CGAL_DIR /uufs/chpc.utah.edu/sys/installdir/cgal/4.13.1
setenv BOOST_DIR /uufs/
chpc.utah.edu/sys/installdir/boost/1.68.0-5.4.0g-3.7.3py
setenv SPARSE_DIR /uufs/chpc.utah.edu/sys/installdir/sparsehash/2.0.2
setenv PATH $SPARSE_DIR/lib:$PATH
setenv CC gcc
setenv CFLAGS " -m64 -O2 -fPIC -I$CGAL_DIR/include -I$SPARSE_DIR/include
-I$BOOST_DIR/include "
setenv CXX g++
setenv CXXFLAGS " $CFLAGS -std=c++14 "
setenv LDFLAGS " -Wl,-rpath=$CGAL_DIR/lib64 -L$CGAL_DIR/lib64 -lCGAL
-Wl,-rpath=$BOOST_DIR/lib -L$BOOST_DIR/lib
-lboost_iostreams -lboost_context-mt
-lboost_regex -lboost_graph -lboost_coroutine
-lboost_thread-mt "
cd /uufs/chpc.utah.edu/sys/srcdir/graph-tool
wget https://downloads.skewed.de/graph-tool/graph-tool-2.27.tar.bz2
tar -jxvf graph-tool-2.27.tar.bz2
mv graph-tool-2.27 2.27; cd 2.27
./configure --prefix=/uufs/chpc.utah.edu/sys/installdir/graph-tool/2.27 \
--with-pic --with-boost=$BOOST_DIR \
--with-boost-python=yes \
--with-cgal=$CGAL_DIR \
--with-sparsehash-prefix=/uufs/
chpc.utah.edu/sys/installdir/sparsehash/2.0.2/include/sparsehash
Note: pycairo was properly installed.
[hpcapps@centos7 2.27]$ which python3
/uufs/chpc.utah.edu/sys/installdir/python/3.7.3/bin/python3
[hpcapps@centos7 2.27]$ python3
Python 3.7.3 (default, Apr 4 2019, 12:25:30)
[GCC 5.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cairo
>>>
I also appended the corresponding config.log
Any help would be appreciated.
Thanks,
Wim

Hello:
I am new to graph_tool (4 weeks)
Today I attempted to use all_paths to evaluate the strength of connection between classes in a large program.
The output contained (see attached sample) many repetitions of the same path.
What am I missing?
Thanks
JP
(jrpaillet)

Hi Tiago,
If I understood minimize_blockmodel_dl() correctly, the success of its
inference comes from the following KEYs:
KEY-1. Agglomerative membership initialization
KEY-2. Smarter MCMC proposal moves + successful MCMC
equilibration/optimization
KEY-3. Correct expression of the SBM entropy
For (1), the tunable parameters are:
a) shrink_args[“niter”]: attempted block merges for each block node
b) mcmc_multilevel_args[“r”]: the greediness of the agglomeration.
For (2), the tunable parameters are:
c) mcmc_args[“c”]: controls how the proposed move respects the current block
configuration
d) mcmc_args[“d”]: the probability to move to a new and vacant group
e) mcmc_args[“beta”]: the inverse temperature
f) mcmc_args[“niter”]: the number of sweeps to perform. During each sweep, a
move attempt is made for each node
g) mcmc_equilibrate_args[“wait”]: the number of iterations to wait for a
record-breaking event
h) mcmc_equilibrate_args[“nbreaks”]: the number of iteration intervals (of
size `wait`) without record-breaking events necessary to stop the algorithm.
i) anneal_args[“niter”]: the number of steps (in logspace) from the starting
temperature to the final one.
And for (3), the tunable parameters are hidden in the
mcmc_args.entropy_args, whose default settings are clear to me. They
implement the flat prior as detailed in Phys. Rev. E 95, 012317.
I have the following 4 questions.
FIRST - If I just run minimize_blockmodel_dl(g), where g is the graph, what
are the default numbers used by (a)-(i)? I found that many parameters do not
match the default numbers as stated in the documentation. For example, b) is
set to 1.3, where the documentation says 2. And g) is set to 1, where the
documentation says 1000. With `verbose` turned on, reverse engineering
helps. But I would like to hear your response.
SECOND - To prevent bad merges in (KEY-1.), we also allow individual node
moves between each sweep. This means (KEY-1) + (KEY-2) is applied
alternatively. Between each merge (from B’ to B), what is the annealing
scheme used? Is it abrupt cooling all the way through? Or does it let the
MCMC equilibrates first, followed by the abrupt cooling?
THIRD - Followed from the SECOND, It seems that the latter implementation is
best but computationally expensive. However, for the last stage of the merge
algorithm (when we reached the desired B), the latter [equilibration +
cooling] algorithm must be applied. How can we customize the arguments in
minimize_blockmodel_dl() such that we only do abrupt merges between stages
except for the last?
FOURTH - Bisection is an important ingredient to the efficiency of
successful optimization. What is the default formula to determine the
desired block number B to be merged from B0 = N (number of nodes)? In other
words, how do we determine the first rightmost state to bracket the search?
It seems that either N^0.5 or E^0.5 (the resolution limit via the flat prior
for edge count) does not match what I observed.
I hope my questions were not annoying. Thank you again for designing the
many detailed auxiliary functions. They helped me a lot to catch bugs by
these “reverse engineerings”. You are so sweet.
Sincerely,
Tzu-Chi
--
Sent from: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/

When I install a new Ubuntu on a device and want to install graph-tool,
following the instructions:
https://git.skewed.de/count0/graph-tool/wikis/installation-instructions#deb…
at the moment with bionic version of Ubuntu (18.04), but I always get the
error message:
W: GPG error: http://downloads.skewed.de/apt/bionic bionic Release: The
following signatures couldn't be verified because the public key is not
available: NO_PUBKEY 7A80C8ED4FCCBE09
If I run the:
If you want to verify the packages, you should use the public key
612DEFB798507F25, which can be done with the command:
apt-key adv --keyserver pgp.skewed.de --recv-key 612DEFB798507F25
command, I still get the same error.
If I change the key to the one it is complaining about,
7A80C8ED4FCCBE09
still complaining.
What do I have to do?