Conflicting HDF5 Libraries

I am trying to combine a few bits of software that make use of HDF5 (MOAB and Cubit) and I appear to be running into HDF5 conflicts. I was wondering:

Does Cubit 2021.5 make use of the existing system HDF5 when installed?
Does Cubit 2021.5 replace the system HDF5 in anyway?
Is there a way to install Cubit 2021.5 and make use of existing HDF5 already on the system?

Many thanks

We do not use the system HDF5 and we do not modify the system HDF5. We are currently using HDF5 1.8.10 with netcdf 4.4.1.1

We do not provide a mechanism to use the existing HDF5 on the system.

1 Like

Interestingly enough I get an import error if I import Cubit first then import pymoab but not the other way around

import sys
cubit_path: str = "/opt/Coreform-Cubit-2021.5/bin/"
sys.path.append(cubit_path)
import cubit
cubit.init([])
from pymoab import core, types

However this next code block works fine

from pymoab import core, types

import sys
cubit_path: str = "/opt/Coreform-Cubit-2021.5/bin/"
sys.path.append(cubit_path)
import cubit
cubit.init([])

Interesting. It appears that pymoab is able to use the Cubit installation of HDF5. I’m not a fan of using a random version of the library to save and restore mission critical models across platforms. I’m glad that works for pymoab, but I’m not inclined to make it work for Cubit. Do you have any thoughts on that?

Perhaps slight changes to the patch or minor version number are more acceptable than changes to a jump in major version numbers.

Quite often I see that compiled codes allow the user to specify the HDF5 path to use when compiling. This helps provide series or parallel versions of hdf5 as well as different version numbers.

I guess the installation for cubit could in theory allow users to specify HDF5 versions.

Perhaps something like this dpkg -i Cubit.deb --path-include /path/to/preferred/system/hdf5