garbage values in adapted FacetFunction

[Jaroslav Hron]

the new edges in adapted facet function are not initialized to a sensible values (0 would be better?)

from dolfin import *
parameters["refinement_algorithm"] = "plaza_with_parent_facets"

mesh = UnitSquareMesh(1, 1)
mesh1 = refine(mesh)

f = FacetFunction("size_t", mesh)
f.set_all(0)
f.array()[1] = 1
print f.array()

f1 = adapt(f, mesh1)
print f1.array()

plot(f,interactive=True)
plot(f1,interactive=True)

[Martin Sandve Alnæs]

0 is not better because 0 may have a specific meaning in the user application. Therefore we use some numeric limits value. Don't remember off the top of my head how to fetch that value but there is a simple way.

[Jaroslav Hron]

ok, thanks for the explanation - any number may have a specific meaning in user application, but somehow 0 would seem more natural and expected placeholder value.... i should have checked the source.

[Prof Garth Wells]

Problem is that zero is commonly used (it used to be the 'default'). We could add an extra argument for the value on entities that are not otherwise set.

[Jan Blechta]

The returned value is np.uintp(-1) on my system. This should be fine as long as it is documented.

[Jan Blechta]

Maybe think also of #377 when/if fixing this. It could cause unusability of the Python interface.

[Chris Richardson]

Maybe we can transition to using signed integer types in MeshFunction, which would solve the problem (use -1). MeshFunction already supports int, so it would just be a case of moving size_t to int64 or something.

[Jan Blechta]

The problem will be the same as long as a new value is not documented. I'm quite reluctant to adding another integer type while not necessary.

FWI, we have been discussing integer types clean-up in fem and la code recently with Garth and figured out that the current situation is probably the best (not ideal but best while considering PETSc restrictions). So we quit changing int types there. Anyway we could still change size_t to signed int64 but that does not far consequences in dofmap and la code and was not priority.

So I would not be against introducing int64 if getting rid of size_t in whole DOLFIN.

[Martin Sandve Alnæs]

I like Garths idea of introducing a user-settable default value. Kind of like python's defaultdict.

[Chris Richardson]

Well, maybe not a priority, but there are good reasons for using signed integers. -1 is always -1 in either integer size, for example... agree we should document whatever we decide.

[Jan Blechta]

Issue #557 was marked as a duplicate of this issue.