SBC-Utrecht / PyTom

PyTom software for cryo-tomogram processing
GNU General Public License v2.0
33 stars 8 forks source link

PyTom installation on CentOS 7 #7

Open sunchang1990 opened 1 year ago

sunchang1990 commented 1 year ago

Dear developers, we would like to setup PyTom on our lab workstations (CentOS 7) for cryo-ET processing. I followed the Github installation instructions by 1) creating a conda environment; 2) building the backend.

Both steps went fine without any error. However, when I tried to start pytomGUI, the command failed with the following error.

======================================================================================= The C-functionality of PyTom failed to load. For full functionality, please run pytom or ipytom. Traceback (most recent call last): File "/goliath/sw/conda4.10/envs/pytom_env/lib/python3.8/site-packages/pytom_volume.py", line 14, in swig_import_helper return importlib.import_module(mname) File "/goliath/sw/conda4.10/envs/pytom_env/lib/python3.8/importlib/init.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1014, in _gcd_import File "", line 991, in _find_and_load File "", line 975, in _find_and_load_unlocked File "", line 657, in _load_unlocked File "", line 556, in module_from_spec File "", line 1166, in create_module File "", line 219, in _call_with_frames_removed ImportError: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /goliath/sw/conda4.10/envs/pytom_env/lib/python3.8/site-packages/_pytom_volume.so)

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/goliath/sw/pytom/pytom/gui/pytomGUI.py", line 58, in from pytom.gui.guiFunctions import create_project_filestructure File "/goliath/sw/conda4.10/envs/pytom_env/lib/python3.8/site-packages/pytom/gui/guiFunctions.py", line 7, in from pytom_volume import read File "/goliath/sw/conda4.10/envs/pytom_env/lib/python3.8/site-packages/pytom_volume.py", line 17, in _pytom_volume = swig_import_helper() File "/goliath/sw/conda4.10/envs/pytom_env/lib/python3.8/site-packages/pytom_volume.py", line 16, in swig_import_helper return importlib.import_module('_pytom_volume') File "/goliath/sw/conda4.10/envs/pytom_env/lib/python3.8/importlib/init.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) ImportError: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /goliath/sw/conda4.10/envs/pytom_env/lib/python3.8/site-packages/_pytom_volume.so)

It is likely to be caused by the low version of gcc shipped with CentOS 7, which only has GLIBCXX version up to 3.4.19. So, I tried to build the back end (step 2) with gcc 7.3 using devtoolset-7 (with a new conda environment because I don't know how to remove the unfunctional pytom cleanly), but the pytomGUI would fail with the same error, as if it was unaware of the dev-version of gcc library (/opt/rh/devtoolset-7/root/usr/lib64).

What is your advice to resolve this installation issue? Thank you!

McHaillet commented 1 year ago

Hi! Thanks for your detailed report. The conda environment that pytom builds already comes with gcc 7.3.0 as a dependency. So, after loading the environment and running the pytom setup, the correct gcc version should be on the path. Could you try which gcc and gcc --version after doing conda activate pytom_env in a fresh terminal? which gcc should return a path to the bin folder of the environment.

sunchang1990 commented 1 year ago

Thank you for getting back to me! After activating the pytom_env, the default gcc is /goliath/sw/conda4.10/envs/pytom_env/bin/gcc, which is version 7.3.0. But apparently, the installed pytomGUI still relies on the libstdc++.so.6 under /lib64.

How would you recommend to mitigate this issue? For instance, is there options available during the python setup.py step that can build a statically linked package?

McHaillet commented 1 year ago

I am trying to find a solution, but it turns out to be not so easy. What is on your LD_LIBRARY_PATH ? This issue seems similar. Perhaps /lib64 comes first on your LD_LIBRARY_PATH?

Its also possible that we havent noticed this issue yet as for me locally, and on our cluster, the libstdc++.so.6 in /usr/lib64 are of the correct version. So even if the gcc compiler finds those the static libraries are still fine.

sunchang1990 commented 1 year ago

Thank you for pointing me in the right direction! I experimented with the LD_LIBRARY_PATH idea and found that the path to include is /goliath/sw/conda4.10/envs/pytom_env/x86_64-conda_cos6-linux-gnu/lib. This way, the pytom_GUI can start without the GLIBCXX issue.

sunchang1990 commented 1 year ago

With the LD_LIBRARY_PATH patch, the test of pytom still doesn't work. Details are listed below. Any idea what is causing this?

BTW, what are the hardware/software configurations used in your lab? Thank you!

====================================================================== ERROR: test_GUIWidgets (unittest.loader._FailedTest)

ImportError: Failed to import test module: test_GUIWidgets Traceback (most recent call last): File "/goliath/sw/conda4.10/envs/pytom_env/lib/python3.8/unittest/loader.py", line 436, in _find_test_path module = self._get_module_from_name(name) File "/goliath/sw/conda4.10/envs/pytom_env/lib/python3.8/unittest/loader.py", line 377, in _get_module_from_name import(name) File "/goliath/sw/pytom/tests/test_GUIWidgets.py", line 5, in from PyQt5.QtWidgets import * ImportError: /goliath/sw/conda4.10/envs/pytom_env/lib/python3.8/site-packages/PyQt5/QtWidgets.abi3.so: symbol _ZdlPvm, version Qt_5 not defined in file libQt5Core.so.5 with link time reference


Ran 56 tests in 60.612s

FAILED (errors=1)

McHaillet commented 1 year ago

Hi, thanks again for the feedback.

Something is wrong with this test (it also does not contain any test cases) so please skip it. I will set it up for removal in the dev branch.

For running the tests you can call ./runPyTomUnitTests from the tests directory and see if that returns OKs (it will probably print some warnings).

two questions:

sunchang1990 commented 1 year ago

Thank you for your reply! After some testing, the right path order that solved both the GLIBC and the QtWidgets issues is the following. export LD_LIBRARY_PATH='/goliath/sw/conda4.10/envs/pytom_env/lib/python3.8/site-packages/PyQt5/Qt5/lib':'/goliath/sw/conda4.10/envs/pytom_env/lib':'/goliath/sw/pytom/pytom/lib':$LD_LIBRARY_PATH

And I think I found the reason for the different behavior between the "pytom" and "pytomGUI". pytomGUI directly inherits the shell environment variables, while pytom is a script that made additional changes to the environment variables based on a path.sh file.

To make both pytomGUI and pytom work, I modified the LD_LIBRARY_PATH using the conda activate routine. This way, with or without additional changes by the path.sh, python/pytom/pytomGUI would work. This way, both pytom unittest and ./runPyTomUnitTests worked.

One more thing, what tutorial do you recommend for learning pytom? Thanks!

McHaillet commented 1 year ago

Glad to hear that you managed to get it to work! Thanks again for your detailed report, that's very helpful for us.

The tutorial is present on the github wiki, along with other documentation.

sunchang1990 commented 1 year ago

Thank you for sharing the tutorial! I am following it to test the functionality of our installation. It worked fine until the "5.5 Reconstructing tomograms", which would cause the pytomGUI to crash with an error message about the queuing system even without checking the queue checkbox. Our workstation currently doesn't have a queuing system, but it should be possible to set it up. Is there a workaround to run the reconstruction job without invoking the queuing system?

McHaillet commented 1 year ago

Thanks for notifying us of the bug. A previous colleague designed the GUI with cluster systems in mind and some of the things are hard coded, especially for the batch submission. It's fixable but I wont be able to immediately do that. If you go to the single reconstruction tab and run it one by one for each tilt-series, it should work. For the tutorial that would be the easiest fix because I can imagine you dont want to set up a queueing system on the workstation. For larger datasets it might be more annoying.

This bug is also gonna appear for the batch template matching/candidate extraction/subtomogram reconstruction. In case you really need to run template matching in batch on your workstation it might be more effective to write some bash scripts around the command line functions from pytom.

rdrighetto commented 1 year ago

Hi,

I experimented similar issues installing PyTOM v1.1. under CentOS 7.9 and just wanted to share how I got it to work. I was going to open a new issue but I think it fits better here 🙂

First, by following the installation instructions on the main repo page I stumbled upon this issue:

The C-functionality of PyTom failed to load. For full functionality, please run pytom or ipytom.
Traceback (most recent call last):
  File "/scicore/home/engel0006/GROUP/pool-engel/soft/pytom/pytom/pytom/gui/pytomGUI.py", line 62, in <module>
    from pytom.gui.guiFunctions import create_project_filestructure
  File "/scicore/home/engel0006/GROUP/pool-engel/soft/miniconda/miniconda3/envs/pytom_env/lib/python3.11/site-packages/pytom/gui/guiFunctions.py", line 10, in <module>
    from pytom.lib.pytom_volume import read
  File "/scicore/home/engel0006/GROUP/pool-engel/soft/miniconda/miniconda3/envs/pytom_env/lib/python3.11/site-packages/pytom/lib/pytom_volume.py", line 10, in <module>
    from . import _pytom_volume
ImportError: libpython3.8.so.1.0: cannot open shared object file: No such file or directory

...meaning some packages were expecting python 3.8 instead of the 3.11 that was installed, as the pytom_full.yaml file just points to a generic python=3 version. Then I noticed in the environments/ folder there is also a .yaml file for python 3.8, so I recreated the environment like this:

conda env create -f environments/pytom_py3.8_cu10.6.yaml --name pytom_env

and then:

conda activate pytom_env
python setup.py install --prefix [CONDA_INSTALL_DIR]/envs/pytom_env

next up I ran into this other issue with libstdc++.so.6:

The C-functionality of PyTom failed to load. For full functionality, please run pytom or ipytom.
Traceback (most recent call last):
  File "/scicore/home/engel0006/GROUP/pool-engel/soft/pytom/pytom/pytom/gui/pytomGUI.py", line 62, in <module>
    from pytom.gui.guiFunctions import create_project_filestructure
  File "/scicore/home/engel0006/GROUP/pool-engel/soft/miniconda/miniconda3/envs/pytom_env/lib/python3.8/site-packages/pytom/gui/guiFunctions.py", line 10, in <module>
    from pytom.lib.pytom_volume import read
  File "/scicore/home/engel0006/GROUP/pool-engel/soft/miniconda/miniconda3/envs/pytom_env/lib/python3.8/site-packages/pytom/lib/pytom_volume.py", line 10, in <module>
    from . import _pytom_volume
ImportError: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /scicore/home/engel0006/GROUP/pool-engel/soft/miniconda/miniconda3/envs/pytom_env/lib/python3.8/site-packages/pytom/lib/_pytom_volume.so)

but since I'm used to this problem in CentOS 7, I just pointed it to an existing libstdc++.so.6 compiled on this system via LD_PRELOAD: export LD_PRELOAD=/scicore/soft/apps/GCCcore/10.3.0/lib64/libstdc++.so.6

and then it worked (as in: I managed to open pytomGUI) 🙂

McHaillet commented 1 year ago

If you're only interested in using GPU template matching, we now also provide a command line module based on the PyTOM code: https://github.com/SBC-Utrecht/pytom-template-matching-gpu . I made some optimizations and would recommend to use that.

rdrighetto commented 1 year ago

Thank you, I am actually interested in the whole PyTOM package 🙂

btw: is the functionality of the TM module entirely included in the full PyTOM package, or is there any difference? in other words, if I have only full PyTOM, can I run TM in the same way as if I was using the separate TM module?