FFC generates invalid C++ code

1

I’m somewhat new to FEniCS, but have used it for roughly half a year successfully with Python. I need to start using the C++ API but have been running into an issue. The following UFL code is compiled and then the resulting header file included. Note that simply including the header file triggers the error.

element = FiniteElement("Lagrange", triangle, 1)

T = Coefficient(element)
rho = Coefficient(element)
h = Coefficient(element)
eta = Coefficient(element)

dt = Coefficient(element)

v = TestFunction(element)
u = TrialFunction(element)

# Define the previous solutions which are used for the time derivative portion
z_nm1 = Coefficient(element)
z_nm2 = Coefficient(element)

p = Coefficient(element) 

a = - inner(grad(u), grad(v)) * dx
a += ((eta * h * v * ((u) / dt)) / T) * dx 
a -= ((rho / T) * (u / (dt**2)) * v) * dx

L = (- (p * v) / T) * dx
L += ((eta * h * v * ((- z_nm1) / dt)) / T) * dx 
L -= ((rho / T) * ((-2 * z_nm1 + z_nm2) / (dt**2)) * v) * dx

The error:

In file included from src/main.cpp:1:
src/Slater/SlaterModel.h:2652:8: error: ‘void slatermodel_cell_integral_0_otherwise::tabulate_tensor(double*, const double* const*, const double*, int, std::size_t) const’ marked ‘final’, but is not virtual
 2652 |   void tabulate_tensor(double * A,
      |        ^~~~~~~~~~~~~~~
In file included from src/main.cpp:1:
src/Slater/SlaterModel.h:2798:8: error: ‘void slatermodel_cell_integral_1_otherwise::tabulate_tensor(double*, const double* const*, const double*, int, std::size_t) const’ marked ‘override’, but does not override
 2798 |   void tabulate_tensor(double * A,
      |        ^~~~~~~~~~~~~~~
src/Slater/SlaterModel.h:2798:8: error: ‘void slatermodel_cell_integral_1_otherwise::tabulate_tensor(double*, const double* const*, const double*, int, std::size_t) const’ marked ‘final’, but is not virtual
src/Slater/SlaterModel.h: In member function ‘virtual ufc::cell_integral* slatermodel_form_0::create_default_cell_integral() const’:
src/Slater/SlaterModel.h:3128:54: error: invalid new-expression of abstract class type ‘slatermodel_cell_integral_0_otherwise’
 3128 |     return new slatermodel_cell_integral_0_otherwise();

I’m compiling with g++ using the C++17 standard.

Thanks.

2

I think this is due to the C++ standard you are using (as I cannot reproduce it in the docker container: quay.io/fenicsproject/dev:latest, which I am quite certain uses the C++11 standard: Bitbucket

The development version of dolfin, dolfinx uses the C++ 17 standard .

1 Like
3

Unfortunately I tried all standards post 2000. I happen to be using anaconda to manage the installation. I link and include against the libraries provided by anaconda. Could this possibly be part of the issue? I doubt it but who knows… I might add that the examples provided by dolfin also have this same issue. I’m going to try compiling it from scratch using the link you provided to see what happens.

1 Like
4

would be useful to see which versions of everything your compiler is seeing. Perhaps ufc is being picked up from a different install somewhere? Looking at the verbose make or cmake output should help with this.

E.g. make sure it complies with what python sees.

python3 -c "import ffc, dolfin; print(f'ffc version and path: {ffc.__version__} | {ffc.__path__}\n DOLFIN version and path: {dolfin.__version__} | {dolfin.__path__}')"
>>> ffc version and path: 2019.2.0.dev0 | ['$HOME/local/lib/python3.8/site-packages/fenics_ffc-2019.2.0.dev0-py3.8.egg/ffc']
>>> DOLFIN version and path: 2019.2.0.dev0 | ['$HOME/local/lib/python3.8/site-packages/fenics_dolfin-2019.2.0.dev0-py3.8-linux-x86_64.egg/dolfin']
5

Here are the results.

ffc version and path: 2019.2.0.dev0 | ['/home/user/.conda/envs/standard/lib/python3.8/site-packages/ffc']
 DOLFIN version and path: 2019.1.0 | ['/home/user/.conda/envs/standard/lib/python3.8/site-packages/dolfin']

I include the following:

/home/user/.conda/envs/standard/include
/home/user/.conda/envs/standard/include/eigen3

I looked at the verbose outputs and saw nothing out of the ordinary (i.e. just the usual search directories).

6

We’re particularly interested in where it’s picking up ufc, not Eigen. Also, your DOLFIN build is older than FFC.

7

Yeah I saw the dolfin build being older. That is what is in the conda repositories and it works perfectly in Python.

I’ve searched for ffc and ufc, ffc is located at
/home/user/.conda/envs/standard/lib/python3.8/site-packages/ffc

I know that ufc is related to the form language standard, but I thought that ffc was the package that actually implements the standard.

8

yep. It would be useful to make sure ufc is being picked up by cmake and make from your ffc install directory.

9

Its picked up here:

~/.conda/envs/standard/lib/python3.8/site-packages/ffc/backends/ufc

10

looks fine then. The only idea I have for checking I can come up with is the mismatch of DOLFIN and ffc versions.

11

I didn’t find the issue, but I found a solution. I removed the conda installation of fenics and simply re-installed. However, I needed to completely deactivate all conda environments before it took the changes. Very strange. Thanks to all that helped.