geovista: Unable to run examples with geovista

Oh you can also do pip install --no-binary pykdtree pykdtree to force the installation from source.

would it be possible for you to try installing geovista using conda or mamba on macOS instead? Does that work?

Installing from conda does not fix the issue for me, unfortunately. I get the same import error with pykdtree.

pip install pykdtree in an isolated environment, then try python -c "from pykdtree.kdtree import KDTree as pyKDTree"

This also generates the same error. So not likely not a geovista issue then, it seems! I’ll close this issue accordingly.

I’ll have to look into it further/elsewhere… seems like it may have something to do with incompatible pre-compiled C++ libraries with the M1 chip used in macs.

I’ve created an issue and pinned it here: https://github.com/storpipfugl/pykdtree/issues/106

@bjlittle Yeah I’m not confident updating the macos version would do anything. Neither the macos-11 nor the 12 image documentation say anything about OpenMP, but some dependency is bringing it in and it is found by pykdtree at build time in the CI.

As far as a hit to the macos/pykdtree community for removing that wheel, that suggests that in your experience most users don’t have compilers installed and ready to use on macos, right? That’s the thing I either:

1. Always require the user to build from source on macos (requires a compiler)
2. Provide a no OpenMP version which will install, but not perform as well as it could and users might expect.
3. Keep the OpenMP-based wheel and have some users run into runtime issues if they don’t have OpenMP installed.

I just don’t feel super good about any of those.

@bjlittle Yes very likely. I think the bigger question is if I should just drop the pykdtree wheels for mac from PyPI. I could tell them to be built without openmp, but then you never get openmp performance from pykdtree on mac (unless you do the same --no-binary trick).

If I remove the wheels and don’t generate them anymore then you, the user, don’t need to do any special installation instructions except you need to have a compiler locally that can build pykdtree.

@djhoese @Minerallo @user27182 Brilliant, thanks!

Glad that we managed to find a pattern that works 🥳

When people come together like this, it reminds me of how much I love open-source software and the ecosystem we live in 😁

I’m just spinning up the geovista docs, so I’ll see if there is an appropriate place to document this behaviour for macOS arm64 users.

@djhoese Is this pattern worth sharing over on pykdtree for the macOS arm64 users?

I would have thought -U for upgrading would have had a similar result, but I suppose if the version number is the same maybe it doesn’t automatically reinstall.

I tested with --upgrade as well and found that it isn’t sufficient and would still produce the error (likely due to the same version number, as you mention).

Note that in my testing I was also running pip cache purge before installing pykdtree.

I would have thought -U for upgrading would have had a similar result, but I suppose if the version number is the same maybe it doesn’t automatically reinstall. Good to know. Thanks for testing.

pip install --no-binary pykdtree pykdtree worked for me too. I wasn’t prompted to install a compiler, perhaps I have one already installed ?

One issue I’ve found with this though is that if you run this command in an environment where pykdtree is already installed, it will not be updated, e.g.

pip install pykdtree
pip install --no-binary pykdtree pykdtree
python -c "from pykdtree.kdtree import KDTree"

will still yield

ImportError: dlopen(/venv/lib/python3.12/site-packages/pykdtree/kdtree.cpython-312-darwin.so, 0x0002): symbol not found in flat namespace '___kmpc_for_static_fini'

And so adding the --force-reinstall flag is probably a more robust solution. Installing this way fixes the import error, e.g.:

pip install pykdtree
pip install --no-binary pykdtree --force-reinstall pykdtree
python -c "from pykdtree.kdtree import KDTree"

And so the specific fix to address the bug reported in my initial post may be:

pip install --no-binary pykdtree --force-reinstall pykdtree
pip install geovista
geovista examples --run from_unstructured__tri_hammer

which will run without issue and output an image as expected.

I tried the force installation from the source using pip install --no-binary pykdtree pykdtree, Successfully installed pykdtree-1.3.10 and it worked fine when importing geovista 👍 I would prefer to not mess with brew and openMP right now, sorry ^^’

Yes. I thought I had fixed this. The mac wheels for arm are being built with OpenMP support. If a user installs pykdtree without a system-level OpenMP installation (ex. homebrew) then you’ll get error/exceptions like this. The alternative is to require users to have compilers and not distribute ARM wheels for pykdtree. Let me know what you think.

The current workaround I believe, if you have homebrew, is to do brew install omp.

Hi, I am trying to use Geovista for the first time on a Mac M2 and ran into the same problem, It seems that what fixed it is to install older version of pykdtree so I tried with pykdtree 1.3.10 and pykdtree 1.3.9 but it didn’t work, finally it worked with pykdtree 1.3.7.post0 (using pip install pykdtree==1.3.7.post0).

I’ll provide an update here if I do ever find out what the problem was/is.

As an aside related to macOS testing, if you’d like to test GeoVista with macOS (or even Windows), I think it should be possible to update PyVista’s integration test workflow accordingly, i.e. make a PR with changes to https://github.com/pyvista/pyvista/blob/main/.github/workflows/integration-tests.yml