Datatype issues with ds Measure and Dijitso caching in FEniCS 2017.2.0

Issue #998 invalid
Sigvald created an issue

It appears that an exterior surface Measure (let's call it dss) with subdomain_data provided by a _facet_region.xml file is sensitive to the datatype of its argument. It should be a python int but it does not fail gracefully if it is np.int64. (This may for instance happen if you try to extract the argument of dss from the facet region file using some Python scripting.) Instead it results in incorrect behavior. Consider the following file named mwe_datatypes.py:

from dolfin import *
import numpy as np
import sys

mesh = Mesh("mesh.xml")
bnd  = MeshFunction("size_t", mesh, "mesh_facet_region.xml")

if sys.argv[1] == 'True':
    int_bnd_id = np.int64(59)
else:
    int_bnd_id = 59

print(type(int_bnd_id))

dss = Measure('ds', domain=mesh, subdomain_data=bnd)
print(assemble(1 * dss(int_bnd_id)))

The argument is "True" if we want to use the incorrect datatype. Let's observe the outcome of this:

$ python mwe_datatypes.py True 
<class 'numpy.int64'>
Calling FFC just-in-time (JIT) compiler, this may take some time.
Calling FFC just-in-time (JIT) compiler, this may take some time.
Calling FFC just-in-time (JIT) compiler, this may take some time.
Calling FFC just-in-time (JIT) compiler, this may take some time.
0.0

The result should not be zero. On top of that, there's another bug (or it wouldn't be there if this had failed gracefully, hence I'm not posting a separate issue). Namely that this result got cached, so if I now try using the correct datatype it still does not work unless we also do dijitso clean:

$ python mwe_datatypes.py False 
<class 'int'>
0.0
$ dijitso clean
$ python mwe_datatypes.py False
<class 'int'>
Calling FFC just-in-time (JIT) compiler, this may take some time.
Calling FFC just-in-time (JIT) compiler, this may take some time.
Calling FFC just-in-time (JIT) compiler, this may take some time.
Calling FFC just-in-time (JIT) compiler, this may take some time.
0.5017037613531041

This leads to very hard-to-track-down issues which seems to appear sporadically, such as this one: https://www.allanswered.com/post/ggwxn/#vnlke. I would propose that dss either should accept the datatype np.int64 correctly or raise an error.

Comments (3)

  1. Jan Blechta

    It is very well possible that this bug will not appear any more in the development version, because SWIG was replace by pybind11. To check it, I would suggest MWE which does not require the external files is provided.

  2. Log in to comment