I have recently updated to dolfinx 0.8.0 and have checked that ffcx, basix and ufl are the correct version corresponds to the release page. However, whenever I try to import anything from dolfinx, it gives:
Traceback (most recent call last):
File “/home/xx/demo_stokes.py”, line 1, in
import dolfinx
File “/home/xx/.local/lib/python3.10/site-packages/dolfinx/init.py”, line 25, in
from dolfinx import fem, geometry, graph, io, jit, la, log, mesh, nls, plot, utils
File “/home/xx/.local/lib/python3.10/site-packages/dolfinx/fem/init.py”, line 40, in
from dolfinx.fem.element import CoordinateElement, coordinate_element
File “/home/xx/.local/lib/python3.10/site-packages/dolfinx/fem/element.py”, line 54, in
variant=int(basix.LagrangeVariant.unset),
File “/home/xx/.local/lib/python3.10/site-packages/basix/utils.py”, line 49, in int
return int(self.value)
TypeError: int() argument must be a string, a bytes-like object or a real number, not ‘LagrangeVariant’
You’ll need to tell us how you installed dolfinx (and its dependencies).
Wild guess: is it possible that you have nanobind 2.0? If so, 0.8.0 is compatible only with < 2.0, so make sure to downgrade.
Sorry was just about to add this in my post. Thanks for the reminder! I updated from 0.8.0.dev0 by reinstalling dolfinx, ffcx, ufl, basix from the source. In terms of the other dependencies, I installed them a few months ago and I remember using pip whenever possible. I also checked that my nanobind version was 1.9.2 so probably something else is in play. Also, I’m working under WSL2 and hopefully this is not the problem.
Try by manually applying the patch at Mark all `nanobind` enums as `nb::is_arithmetic()` for compatibility with `nanobind` 2.x by francesco-ballarin · Pull Request #825 · FEniCS/basix · GitHub, and then rebuild basix. That change should only be necessary for nanobind 2.0, but wouldn’t hurt with nanobind 1.9.2. It would also be helpful to double check if that 1.9.2 is really the released version, or if it was a development version post-release (yes, nanobind pre-2.0.0 didn’t happend .dev0 or a similar string to its version, so if you installed nanobind from source you may have accidentatily installed a development version which contains the commit linked in the PR).
Thanks for the suggestion! If I am understanding this correctly, I have changed the lines manually to include nb::is_arithmetic(). This time I can import dolfinx with no problem but it throws another error:
Traceback (most recent call last):
File “/home/xx/compute_flow_field.py”, line 14, in compute_flow_field
from dolfinx import fem
File “/home/xx/.local/lib/python3.10/site-packages/dolfinx/init.py”, line 23, in
from dolfinx import common
File “/home/xx/.local/lib/python3.10/site-packages/dolfinx/common.py”, line 11, in
from dolfinx import cpp as _cpp
ImportError: /home/xx/.local/lib/python3.10/site-packages/dolfinx/cpp.cpython-310-x86_64-linux-gnu.so: undefined symbol: _ZNK7dolfinx3fem13FiniteElementIfE9symmetricEv
I have also tried to replace the wrapper.cpp file directly from the PR you sent (I guess this is not what you meant), and basix wont build at all.
I also downgraded nanobind to 1.8.0 just in case it was the problem.
That shouldn’t happen, unless you (or, most probably, a pip install some-package) upgrade nanobind. Did you happen to install new packages who may have upgraded nanobind?
Thank you for getting back to me so quickly! I haven’t upgraded anything since it last worked. Fortunately, it is now running with no problems after another rebuild and reinstallation. The only thing that comes to mind is that I might have been messing around with environment variables in ~/.bashrc, given that I have little knowledge of working with Linux and WSL2.