num_edges returns wrong numbers

[Elmar Zander]

The function num_edges (or num_entities(1) or size(1)) returns wrong results until certain other functions (e.g. rmax) have been called:

In [3]: from dolfin import *
In [4]: mesh = UnitSquareMesh(2,2)
In [5]: print(mesh.num_entities(1))
0
In [6]: print(mesh.num_edges())
0
In [7]: print(mesh.rmax())
0.146446609407
In [8]: print(mesh.num_entities(1))
16
In [9]: print(mesh.num_edges())
16
In [10]: print DOLFIN_VERSION_STRING
2016.1.0
In [11]: print DOLFIN_VERSION_RELEASE
1

[Anders Logg (Chalmers)]

Yes, this is because the edges (and other mesh connectivity like the vertex neighbors of a vertex) are not computed/stored until explicitly asked for to save time and memory.

You can generate the edges by calling mesh.init(1).

[Elmar Zander]

Then the function should just throw an exception, or call mesh.init(1) itself. This is a responsibility of the library, not of the calling code. Returning incorrect results without notice is no acceptable behavior.

[Anders Logg (Chalmers)]

Perhaps. This feature/behavior has been around for 10 years but perhaps it should throw an error. Opinions? @garth-wells ?

[Elmar Zander]

BTW: doesn't calling num_edges() fall under the heading "until explicitly asked for"? IMHO it does, and so I would expect the library to spend time and memory to compute this information.

[Prof Garth Wells]

It would require a flag to track whether or not entities have been computed. Checking that the container is not empty is not sufficient since mesh entities may have been computed, but there may be none on a given process.

A flag(s) would deal with #751 - we probably need one for the local initialisation, and one for the global (parallel) numbering.

We shouldn't call mesh.init(x) silently because it is potentially an expensive operation.