Strange save / load_graph behaviour

Hi list, hi Tiago,

First thank you for graph tool, that's a great package.

I run in a very strange problem when reloading a xml graph file with an
'internalized' PropertyMap.
the minimum script does the following:
* test1: create, internalize the PropertyMap pos1, save the graph in xml
* test2: load the graph from xml, read the internalized PropertyMap pos2

Depending whether the two tests are ran in separate processes are in the
same process, the two Propertymaps will not have the same values:

test1 and 2 in the same process:
pos1 == pos2
test1 and test2 in different processes
pos1 != pos2

I don't know if my previous message past.

I forgot to say I'm using a standard ubuntu 12.04
python+numpy+scipy+graph-tool setup installed with apt-get

Can this be a compiler issue?

Guillaume

Here is a minimal code that shows this behaviour:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import sys
from numpy import array

import graph_tool.all as gt

print 'Graph_tool version : %s' % gt.__version__

def test1():
     print ('\n'
            'Performing test1:\n'
            '-----------------')
     graph1 = gt.lattice((2,2), periodic=False)
     pos = graph1.new_vertex_property('float')
     pos.a = array([0.0,0.1,
                    1.0, 1.1])
     graph1.vertex_properties['pos'] = pos

     print ('\n'
            'original pos: %s\n'
            'reload graph property:\n'
            ' %s\n') % (str(pos.a),
str(graph1.vertex_properties['pos'].a))
     graph1.save("graph_tool_io_test1.xml")
     return graph1

def test2():
     print ('\n'
            'Performing test2:\n'
            '-----------------')
     graph2 = gt.load_graph("graph_tool_io_test1.xml")
     pos = array([0.0,0.1,
                  1.0, 1.1])
     print ('\n'
            'original pos: %s\n'
            'reload graph property:\n'
            ' %s\n') % (str(pos),
str(graph2.vertex_properties['pos'].a))
     return graph2

def test3():

     graph3 = gt.lattice((2,2), periodic=False)
     pos = graph3.new_vertex_property('float')
     pos.a = array([0.0,0.1,
                    1.0, 1.1])

     graph3.load("graph_tool_io_test1.xml")
     print ('\n'
            'original graph property: %s\n'
            'reload graph property: %s\n') % (str(pos.a),
str(graph3.vertex_properties['pos'].a))
     return graph3

if __name__ == '__main__':
     switch = sys.argv[1]
     if switch == 'all':
         graph1 = test1()
         graph2 = test2()
         graph3 = test3()
     elif switch == 'test1':
         graph1 = test1()
     elif switch == 'test2':
         graph2 = test2()
     elif switch == 'test3':
         graph3 = test3()
     elif switch == 'import-only':
         print 'Imports only'
     else:
         print 'Usage: python test.py {all|test1|test2|test3}'

##### End

Hi Guillaume,

Hi Tiago

attachment.html (6.19 KB)

It seems you are not using the most current git version... Please try
with it, since I fixed the problem you reported previously.

Cheers,
Tiago

Hi Tiago, hi list,

Trying to compile from the github repo, I run into this error with make:

make[4]: entrant dans le répertoire «
/home/guillaume/Python/src/graph-tool/src/graph/layout »
   CXX graph_sfdp.lo
virtual memory exhausted: Cannot allocate memory
make[4]: *** [graph_sfdp.lo] Erreur 1

I tried to pump up virtual memory with ulimit -n 4096 but that didn't
help, also I can see the allocated memory steadily rising while make is
executed.

Any hint?

Cheers,

Guillaume

It takes quite a bit of memory to compile graph-tool, due to the heavy
use of template metaprogramming. Current compilers such as GCC still use
much more memory than optimal... However if you have more than 4G ram,
you should be able to compile it with a current GCC version. Just make
sure there are no other programs using significant amounts of memory.

If you still don't have enough ram, you can try compiling with clang
which manages to use less memory than GCC.

If you want to artificially increase the amount of virtual memory you
have, you have to increase your swap. But note that if you rely too
heavily on this, the compilation time will become very, very high.

Cheers,
Tiago

I have just 4 Gb.

I am not directly using the layout algorithms. Is it possible to compile
all but that?

I tried to modify configure.ac and Makefile.am to remove reference to
those, but make fails.

If not I guess I'am in for some shopping.

Guillaume

attachment.html (5.56 KB)

Test passes with the current git version...

Guillaume

attachment.html (4.25 KB)