Hi!
I’m trying to import ovito in a headless CI enviroment. Specifically, I import the function from ``ovito.io`` import import_file. However, that seems like it needs GUI libraries, since an OpenGL error is raised.
I’ve tried working around this using the approach in ovito.vis ( ovito.vis — OVITO Python Reference 3.15.5 documentation ), as follows:
import os; os.environ[‘OVITO_GUI_MODE’] = ‘0’; from ovito.io import import_file
which raises
Traceback (most recent call last):
File “”, line 1, in
File “/usr/local/lib/python3.11/site-packages/ovito/init.py”, line 22, in
import ovito._extensions
File “/usr/local/lib/python3.11/site-packages/ovito/_extensions/init.py”, line 6, in
importlib.import_module(modinfo.name)
File “/usr/local/lib/python3.11/importlib/init.py”, line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/site-packages/ovito/_extensions/anari.py”, line 2, in
import ovito._extensions.pyscript
File “/usr/local/lib/python3.11/site-packages/ovito/_extensions/pyscript.py”, line 2, in
import ovito.plugins.PyScript
File “/usr/local/lib/python3.11/site-packages/ovito/plugins/init.py”, line 40, in
from ovito.qt_compat import QtGui
File “/usr/local/lib/python3.11/site-packages/ovito/qt_compat.py”, line 29, in getattr
module = import_module(f’PySide6.{name}')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/importlib/init.py”, line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ImportError: libGL.so.1: cannot open shared object file: No such file or directory
I’ve tested this for python 3.11, 3.12, 3.13, and 3.14, and it is present in all versions. Any guidance on how to run ovito in a headless enviroment would be much appreciated!
Here is a docker oneliner for reproducing the issue:
docker run -t python:3.12 sh -c “pip install ovito && python3 -c “import os; os.environ[‘OVITO_GUI_MODE’] = ‘0’; from ovito.io import import_file””
Hi,
Yes, the OVITO Python module includes image rendering functions that require an OpenGL shared library—even if you are not actively using these rendering functions. The best way to avoid this error is to install the missing system library, libGL.so.1, in your system environment using your Linux distro’s package manager. Please follow the troubleshooting instructions for Linux found here:
1 Like
Thank you for the reply! I had missed that part of the manual.
I tried installing OpenGL per the instructions in the python 3:13 docker image, but since the image is quite minimal some extra steps seems to be required to actually get OpenGL installed. For example, the libgl1-mesa-glx is not available even though the image is debian-based.
Will report back here once I’ve figured out how to get OpenGL installed in such a minimal container.
Hi Alex,
Do you think there is any clean small way to refactor or rewrite small parts of ovito python API such that one can use e.g. trajectory reading (and some analysis etc) without needing the graphical libraries.
The performance and functionality of ovito-readers is really strong and useful for us in many settings, for example in dynasor , but also just when doing standalone structrual analysis of MD simulations.
In for example HPC/cluster settings sometimes maybe graphical libs are not available and thus the question if this is possible or it would be a large substantial rewrite of the code?
1 Like
Hi Erik,
Thank you very much for your question. Please give us a few days to come up with a full answer. The situation is very complex and requires a more detailed analysis. I will take a closer look at it on the Linux platform.
OVITO uses the Qt framework at all levels. For example, Qt’s cross-platform functions are used for file I/O. In addition, remote file access in OVITO uses Qt network functions for HTTPS and SSH. Basic functions for UTF-8 string processing in OVITO’s core framework come from Qt. I think it would be extremely difficult to completely eliminate Qt from the OVITO core.
Qt, in turn, consists of several layers: QtCore, QtGUI, and QtWidgets. The latter is only relevant for the GUI of OVITO.
The functions mentioned earlier are all found in QtCore, but QtGUI is also very important for the OVITO Python module; for example, it provides font handling, image file I/O, and off-screen drawing functions that are part of OVITO’s core rendering framework. These capabilities are also deeply coupled with OVITO’s core, since, for example, file readers must, to a certain extent, be able to preconfigure the visualization of loaded data.
Even though Qt itself has this modular structure, PyPI (PySide6 package) and conda-forge (qt-main package) only provide monolithic packages that contain every Qt module. I think this results in problematic dependencies on system libraries such as libGL.1.so - despite the fact that, since version 3.16.0, OVITO no longer uses OpenGL for 3D rendering, but rather Qt’s QRhi abstraction layer and Vulkan (on Linux).
I’ll take a closer look at the mechanism and see if there’s anything we can do to improve the runtime behavior. I’ll get back to you with more details hopefully soon.
2 Likes
Hi Erik,
I’m following up because there’s been an update regarding improvements to the compatibility of the OVITO Python wheel. On Monday, we’ll release OVITO 3.16.1, which will now be significantly less demanding in terms of the system libraries needed on Linux.
It’s important to distinguish between the OVITO Pro/Basic tarballs that are available on our website and the pip wheels on PyPI, which we offer separately. With the latter, the situation has been a bit more challenging, since the OVITO package uses the PySide6 wheel from the Qt Company as a dependency, which in turn provides the Qt shared libraries. Since we cannot patch these libs, the only solution was to bundle copies of all the necessary system libraries required by Qt with our ovito wheel. These are now preloaded when the ovito module is imported if the corresponding libraries are not present on the user’s system (the system’s libs always take precedence).
Rendering images still requires a Vulkan driver to be present on the system (can be software-based, e.g. lavapipe). If none is installed, OVITO now names the system package to install instead of reporting that no graphics driver was found.
Furthermore, our Linux wheels are now tagged manylinux_2_34 (glibc 2.34 or newer, that’s RHEL 9, Ubuntu 22.04, Debian 12, openSUSE Leap 15.4 and later), which is actually the requirement imposed by the PySide6 wheels we depend on. The previous tag promised compatibility that we could not honour due to this dependency, and pip responded by silently installing an outdated OVITO release on such systems rather than reporting a problem.
On even older distributions, e.g. RHEL 8, we recommend using the Python interpreter bundled with OVITO Pro (this doesn’t require a paid license) or the ovito conda package instead; both bring their own Qt/PySide6 and run on glibc 2.28 systems.
The bottom line is that the OVITO Python module should now work out of the box, i.e., import ovito will succeed on most bare Linux distributions. We’ve tested this on Docker images python:3.11-slim and almalinux:9 for example.
1 Like
That sounds great Alex!
Thank so much for the effort, we will try it out and hopefully it works smoothly.