num_edges returns wrong numbers
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
Comments (6)
-
-
- changed status to invalid
-
reporter 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. -
Perhaps. This feature/behavior has been around for 10 years but perhaps it should throw an error. Opinions? @garth-wells ?
-
reporter 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. -
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. - Log in to comment
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)
.