vertex_to_dof_map in 2017.1.0.dev0 returns strange volatile result

Question

My old code using vertex_to_dof_map for output doesn't work anymore.
vertex_to_dof_map seems to return only a nondeterministic garbage result.
A little piece of code that reproducably yields garbage for m0, m1.

from dolfin import *
mesh = UnitSquareMesh(2,2)
VV = FunctionSpace(mesh,'CG',1)
m0 = vertex_to_dof_map(VV)
n0 = dof_to_vertex_map(VV)
print(m0)
print(n0)
m1 = vertex_to_dof_map(VV)
n1 = dof_to_vertex_map(VV)
print(m1)
print(n1)

with m0,m1 giving different results and wrong indices.

[25769803779 4294967304 30064771076 8589934592 5 3 1 3 2]
[6 3 7 0 4 8 1 5 2]
[25769803779 4294967304 30064771076 8589934592 5 0 0 0 0]
[6 3 7 0 4 8 1 5 2]

Problem showed up for me after upgrade from 1.6 to lastest 2017.1.0dev0.

Comments

I cannot reproduce this bug with your code.

In [3]: dolfin.__version__
Out[3]: '2017.1.0.dev0'

---

If invert dof_to_vertex_map is working, you can use argsort() to make a temporary fix.

---

This is not reproducible even in the latest FEniCS dev docker image: quay.io/fenicsproject/dev:latest

---

Thx for the workaround.

It must be something strange with our install on our cluster then.
It allow us to reproduce the error effortlessly, though with varying numbers.

I have no idea where to even start looking for the problem.

import dolfin, sys, os, numpy

print(dolfin.dolfin_version())
print(sys.version)
print(numpy.version.full_version)
os.system('swig -version')

yields

2017.1.0.dev0
3.5.2 (default, Nov 17 2016, 17:05:23)
[GCC 5.4.0 201606090]
1.12.0

SWIG Version 3.0.8

Compiled with g++ [x86_64-pc-linux-gnu]

Configured options: +pcre

Also theres boost/version.hpp

#define BOOST_LIB_VERSION "1_58"

That should be around everything that affects the result no?

---

dof_to_vertex_map is really implemented in C++ as an inversion of vertex_to_dof_map. Since the former works, it implies that the latter works on C++ layer too. The difference between the two is just the return type. It could mean that the typemap for std::vector<std::size_t> works but std::vector<dolfin::la_index> does not. That could mean that something is wrong with Python/SWIG/NumPy. Maybe mixed up headers or linked shared libs when there are more versions of those on your system.

To confirm the idea I'd try the same code in pure C++.

---

Thanks for the info, especially the pointer to check out "dolfin::la_index".
After trying some unfruitful reinstalls of swig/Python/numpy, in the end, I found out that my issue stemmed from a cmake configuration issue combined with having a 32bit integer petsc-3.7.6 install on a 64bit machine.
32bit ints are required by mumps according to PETSc configure.

The FindPETSC.cmake module lines 193,194

set(CMAKE_EXTRA_INCLUDES petscsys.h)
check_type_size("PetscInt" PETSC_INT_SIZE)

do not seem to be working as intended, and yield the type not found result "".
Maybe there is some issue with PetscInt only being properly defined in petscsys.h when definitions from petscconf.h are present?

CMakeLists.txt from root, line 676

list(APPEND DOLFIN_CXX_DEFINITIONS "-DDOLFIN_LA_INDEX_SIZE=${PETSC_INT_SIZE}")

turned this into

... g++ -DDOLFIN_LA_INDEX_SIZE="" -DDOLFIN_SIZE_T=8 -DDOLFIN_VERSION= ...

which lead to the dolfin/swig/typemaps/*.i assuming 64 bit ints which appears to be the standard except if DOLFIN_LA_INDEX_SIZE=4.

I could fix my problems by either reinstalling petsc --with-64-bit-indices=1, and, thus, without mumps or passing -DPETSC_INT_SIZE=4 to cmake/ccmake for the configuration of dolfin.
I am using cmake version 3.8.1 btw.