![[ChimeraX Issue Tracking System]](/trac/ChimeraX/chrome/site/ChimeraX-icon.svg){kind=icon}
#3756 closed defect (fixed)
OpenMM 7.5 beta fails to load on Linux, C++ library not found
| Reported by: | Owned by: | Tom Goddard | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Platform | Version: | |
| Keywords: | Cc: | Greg Couch, Tristan Croll | |
| Blocked By: | Blocking: | ||
| Notify when closed: | Platform: | all | |
| Project: | ChimeraX |
Description
The following bug report has been submitted:
Platform: Linux-5.4.0-48-generic-x86_64-with-glibc2.14
ChimeraX Version: 1.2.dev202009241801 (2020-09-24 18:01:11 UTC)
Description
Tug mouse mode not working on Linux with Python 3.8 and OpenMM 7.5 beta. This OpenMM version uses a different C++ compiler than ChimeraX uses.
Log:
UCSF ChimeraX version: 1.2.dev202009241801 (2020-09-24)
© 2016-2020 Regents of the University of California. All rights reserved.
How to cite UCSF ChimeraX
> open 1mtx format mmcif fromDatabase pdb
1mtx title:
Determination of the three-dimensional structure of margatoxin by 1H, 13C, 15N
triple-resonance nuclear magnetic resonance spectroscopy [more info...]
Chain information for 1mtx
---
Chain | Description
1.1/A 1.2/A 1.3/A 1.4/A 1.5/A 1.6/A 1.7/A 1.8/A 1.9/A 1.10/A 1.11/A 1.12/A
1.13/A 1.14/A 1.15/A 1.16/A 1.17/A 1.18/A 1.19/A 1.20/A 1.21/A 1.22/A 1.23/A |
margatoxin
> ui tool show Shell
/home/goddard/ucsf/chimerax/ChimeraX.app/lib/python3.8/site-
packages/IPython/core/history.py:226: UserWarning: IPython History requires
SQLite, your history will not be saved
warn("IPython History requires SQLite, your history will not be saved")
> open 10676 format ccp4 fromDatabase emdb
Opened emd_10676.map, grid size 320,320,320, pixel 0.805, shown at level
0.0051, step 2, values float32
> volume #2 level 0.03627
> lighting soft
> lighting simple
> close #1.2-30
> show atoms
> hide cartoons
> ui mousemode right tug
Traceback (most recent call last):
File "/home/goddard/ucsf/chimerax/ChimeraX.app/lib/python3.8/site-
packages/chimerax/mouse_modes/mousemodes.py", line 635, in <lambda>
gw.mousePressEvent = lambda e, s=self: s._dispatch_mouse_event(e,
"mouse_down")
File "/home/goddard/ucsf/chimerax/ChimeraX.app/lib/python3.8/site-
packages/chimerax/mouse_modes/mousemodes.py", line 535, in
_dispatch_mouse_event
f(MouseEvent(event, modifiers=modifiers))
File "/home/goddard/ucsf/chimerax/ChimeraX.app/lib/python3.8/site-
packages/chimerax/tug/tugatoms.py", line 76, in mouse_down
self._pick_atom(pick)
File "/home/goddard/ucsf/chimerax/ChimeraX.app/lib/python3.8/site-
packages/chimerax/tug/tugatoms.py", line 85, in _pick_atom
self._tugger = st = StructureTugger(a.structure)
File "/home/goddard/ucsf/chimerax/ChimeraX.app/lib/python3.8/site-
packages/chimerax/tug/tugatoms.py", line 247, in __init__
self._create_openmm_system()
File "/home/goddard/ucsf/chimerax/ChimeraX.app/lib/python3.8/site-
packages/chimerax/tug/tugatoms.py", line 404, in _create_openmm_system
self._topology = openmm_topology(atoms, bonds)
File "/home/goddard/ucsf/chimerax/ChimeraX.app/lib/python3.8/site-
packages/chimerax/tug/tugatoms.py", line 561, in openmm_topology
from simtk.openmm.app import Topology, Element
File "/home/goddard/ucsf/chimerax/ChimeraX.app/lib/python3.8/site-
packages/simtk/openmm/__init__.py", line 19, in <module>
from simtk.openmm.openmm import *
File "/home/goddard/ucsf/chimerax/ChimeraX.app/lib/python3.8/site-
packages/simtk/openmm/openmm.py", line 13, in <module>
from . import _openmm
ImportError: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
`GLIBCXX_3.4.26' not found (required by
/home/goddard/ucsf/chimerax/ChimeraX.app/lib/python3.8/site-
packages/simtk/openmm/../../../../libOpenMM.so.7.5)
ImportError: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
`GLIBCXX_3.4.26' not found (required by
/home/goddard/ucsf/chimerax/ChimeraX.app/lib/python3.8/site-
packages/simtk/openmm/../../../../libOpenMM.so.7.5)
File "/home/goddard/ucsf/chimerax/ChimeraX.app/lib/python3.8/site-
packages/simtk/openmm/openmm.py", line 13, in
from . import _openmm
See log for complete Python traceback.
OpenGL version: 4.6 (Core Profile) Mesa 20.0.8
OpenGL renderer: Mesa DRI Intel(R) HD Graphics 6000 (BDW GT3)
OpenGL vendor: Intel Open Source Technology Center
Manufacturer: unknown
Model: unknown
OS: Ubuntu 18.04 bionic
Architecture: 64bit ELF
CPU: 4 Intel(R) Core(TM) i5-5250U CPU @ 1.60GHz
Cache Size: 3072 KB
Memory:
total used free shared buff/cache available
Mem: 15G 1.6G 4.0G 451M 9.9G 13G
Swap: 2.0G 0B 2.0G
Graphics:
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 6000 [8086:1626] (rev 09)
Subsystem: Intel Corporation HD Graphics 6000 [8086:2057]
Kernel driver in use: i915
PyQt version: 5.12.3
Compiled Qt version: 5.12.4
Runtime Qt version: 5.12.9
Installed Packages:
alabaster: 0.7.12
appdirs: 1.4.4
Babel: 2.8.0
backcall: 0.2.0
blockdiag: 2.0.1
certifi: 2020.6.20
cftime: 1.2.1
chardet: 3.0.4
ChimeraX-AddH: 2.1.1
ChimeraX-AlignmentAlgorithms: 2.0
ChimeraX-AlignmentHdrs: 3.2
ChimeraX-AlignmentMatrices: 2.0
ChimeraX-Alignments: 2.1
ChimeraX-Arrays: 1.0
ChimeraX-Atomic: 1.8.2
ChimeraX-AtomicLibrary: 1.0
ChimeraX-AtomSearch: 2.0
ChimeraX-AtomSearchLibrary: 1.0
ChimeraX-AxesPlanes: 2.0
ChimeraX-BasicActions: 1.1
ChimeraX-BILD: 1.0
ChimeraX-BlastProtein: 1.1
ChimeraX-BondRot: 2.0
ChimeraX-BugReporter: 1.0
ChimeraX-BuildStructure: 2.2
ChimeraX-Bumps: 1.0
ChimeraX-BundleBuilder: 1.0
ChimeraX-ButtonPanel: 1.0
ChimeraX-CageBuilder: 1.0
ChimeraX-CellPack: 1.0
ChimeraX-Centroids: 1.1
ChimeraX-ChemGroup: 2.0
ChimeraX-Clashes: 2.1
ChimeraX-ColorActions: 1.0
ChimeraX-ColorGlobe: 1.0
ChimeraX-CommandLine: 1.1.3
ChimeraX-ConnectStructure: 2.0
ChimeraX-Contacts: 1.0
ChimeraX-Core: 1.2.dev202009241801
ChimeraX-CoreFormats: 1.0
ChimeraX-coulombic: 1.0.1
ChimeraX-Crosslinks: 1.0
ChimeraX-Crystal: 1.0
ChimeraX-DataFormats: 1.0
ChimeraX-Dicom: 1.0
ChimeraX-DistMonitor: 1.1
ChimeraX-DistUI: 1.0
ChimeraX-Dssp: 2.0
ChimeraX-EMDB-SFF: 1.0
ChimeraX-ExperimentalCommands: 1.0
ChimeraX-FileHistory: 1.0
ChimeraX-FunctionKey: 1.0
ChimeraX-Geometry: 1.1
ChimeraX-gltf: 1.0
ChimeraX-Graphics: 1.0
ChimeraX-Hbonds: 2.1
ChimeraX-Help: 1.0
ChimeraX-HKCage: 1.0
ChimeraX-IHM: 1.0
ChimeraX-ImageFormats: 1.0
ChimeraX-IMOD: 1.0
ChimeraX-IO: 1.0
ChimeraX-Label: 1.0
ChimeraX-LinuxSupport: 1.0
ChimeraX-ListInfo: 1.0
ChimeraX-Log: 1.1.1
ChimeraX-LookingGlass: 1.1
ChimeraX-Map: 1.0.1
ChimeraX-MapData: 2.0
ChimeraX-MapEraser: 1.0
ChimeraX-MapFilter: 2.0
ChimeraX-MapFit: 2.0
ChimeraX-MapSeries: 2.0
ChimeraX-Markers: 1.0
ChimeraX-Mask: 1.0
ChimeraX-MatchMaker: 1.1
ChimeraX-MDcrds: 2.1
ChimeraX-MedicalToolbar: 1.0.1
ChimeraX-Meeting: 1.0
ChimeraX-MLP: 1.0
ChimeraX-mmCIF: 2.2
ChimeraX-MMTF: 2.0
ChimeraX-Modeller: 1.0
ChimeraX-ModelPanel: 1.0
ChimeraX-ModelSeries: 1.0
ChimeraX-Mol2: 2.0
ChimeraX-Morph: 1.0
ChimeraX-MouseModes: 1.0
ChimeraX-Movie: 1.0
ChimeraX-Neuron: 1.0
ChimeraX-Nucleotides: 2.0
ChimeraX-OpenCommand: 1.2.1
ChimeraX-PDB: 2.1.1
ChimeraX-PDBBio: 1.0
ChimeraX-PDBLibrary: 1.0
ChimeraX-PickBlobs: 1.0
ChimeraX-Positions: 1.0
ChimeraX-PresetMgr: 1.0
ChimeraX-PubChem: 2.0.1
ChimeraX-Read-Pbonds: 1.0
ChimeraX-Registration: 1.1
ChimeraX-RemoteControl: 1.0
ChimeraX-ResidueFit: 1.0
ChimeraX-RestServer: 1.0
ChimeraX-RNALayout: 1.0
ChimeraX-RotamerLibMgr: 2.0
ChimeraX-RotamerLibsDunbrack: 2.0
ChimeraX-RotamerLibsDynameomics: 2.0
ChimeraX-RotamerLibsRichardson: 2.0
ChimeraX-SaveCommand: 1.2
ChimeraX-SchemeMgr: 1.0
ChimeraX-SDF: 2.0
ChimeraX-Segger: 1.0
ChimeraX-Segment: 1.0
ChimeraX-SeqView: 2.2.1
ChimeraX-Shape: 1.0.1
ChimeraX-Shell: 1.0
ChimeraX-Shortcuts: 1.0
ChimeraX-ShowAttr: 1.0
ChimeraX-ShowSequences: 1.0
ChimeraX-SideView: 1.0
ChimeraX-Smiles: 2.0.1
ChimeraX-SmoothLines: 1.0
ChimeraX-SpaceNavigator: 1.0
ChimeraX-StdCommands: 1.1
ChimeraX-STL: 1.0
ChimeraX-Storm: 1.0
ChimeraX-Struts: 1.0
ChimeraX-Surface: 1.0
ChimeraX-SwapAA: 2.0
ChimeraX-SwapRes: 2.0
ChimeraX-TapeMeasure: 1.0
ChimeraX-Test: 1.0
ChimeraX-Toolbar: 1.0
ChimeraX-ToolshedUtils: 1.0
ChimeraX-Tug: 1.0
ChimeraX-UI: 1.3
ChimeraX-uniprot: 2.0
ChimeraX-ViewDockX: 1.0
ChimeraX-Vive: 1.1
ChimeraX-VolumeMenu: 1.0
ChimeraX-VTK: 1.0
ChimeraX-WavefrontOBJ: 1.0
ChimeraX-WebCam: 1.0
ChimeraX-WebServices: 1.0
ChimeraX-Zone: 1.0
colorama: 0.4.3
comtypes: 1.1.7
cxservices: 1.0
cycler: 0.10.0
Cython: 0.29.21
decorator: 4.4.2
distlib: 0.3.1
distro: 1.5.0
docutils: 0.16
filelock: 3.0.12
funcparserlib: 0.3.6
grako: 3.16.5
h5py: 2.10.0
html2text: 2020.1.16
idna: 2.10
ihm: 0.17
imagecodecs: 2020.5.30
imagecodecs-lite: 2020.1.31
imagesize: 1.2.0
ipykernel: 5.3.4
ipython: 7.18.1
ipython-genutils: 0.2.0
jedi: 0.17.2
Jinja2: 2.11.2
jupyter-client: 6.1.7
jupyter-core: 4.6.3
kiwisolver: 1.2.0
line-profiler: 2.1.2
lxml: 4.5.2
MarkupSafe: 1.1.1
matplotlib: 3.3.2
msgpack: 1.0.0
netCDF4: 1.5.4
netifaces: 0.10.9
networkx: 2.5
numexpr: 2.7.1
numpy: 1.19.2
numpydoc: 1.1.0
openvr: 1.12.501
packaging: 20.4
parso: 0.7.1
pexpect: 4.8.0
pickleshare: 0.7.5
Pillow: 7.2.0
pip: 20.2.3
pkginfo: 1.5.0.1
prompt-toolkit: 3.0.7
psutil: 5.7.2
ptyprocess: 0.6.0
pycollada: 0.7.1
pydicom: 2.0.0
Pygments: 2.7.1
PyOpenGL: 3.1.5
PyOpenGL-accelerate: 3.1.5
pyparsing: 2.4.7
PyQt5-commercial: 5.12.3
PyQt5-sip: 4.19.19
PyQtWebEngine-commercial: 5.12.1
python-dateutil: 2.8.1
pytz: 2020.1
pyzmq: 19.0.2
qtconsole: 4.7.7
QtPy: 1.9.0
RandomWords: 0.3.0
requests: 2.24.0
scipy: 1.5.2
setuptools: 50.3.0
sfftk-rw: 0.6.6.dev0
six: 1.15.0
snowballstemmer: 2.0.0
sortedcontainers: 2.2.2
Sphinx: 3.2.1
sphinxcontrib-applehelp: 1.0.2
sphinxcontrib-blockdiag: 2.0.0
sphinxcontrib-devhelp: 1.0.2
sphinxcontrib-htmlhelp: 1.0.3
sphinxcontrib-jsmath: 1.0.1
sphinxcontrib-qthelp: 1.0.3
sphinxcontrib-serializinghtml: 1.1.4
suds-jurko: 0.6
tables: 3.6.1
tifffile: 2020.9.3
tinyarray: 1.2.3
tornado: 6.0.4
traitlets: 5.0.4
urllib3: 1.25.10
wcwidth: 0.2.5
webcolors: 1.11.1
wheel: 0.34.2
Attachments (5)
Change History (44)
comment:1 by , 5 years ago
| Cc: | added |
|---|---|
| Component: | Unassigned → Platform |
| Owner: | set to |
| Platform: | → all |
| Project: | → ChimeraX |
| Status: | new → assigned |
| Summary: | ChimeraX bug report submission → OpenMM 7.5 beta fails to load on Linux, C++ library not found |
comment:2 by , 5 years ago
follow-up: 3 comment:3 by , 5 years ago
I don't understand. Couldn't I just provide the missing C++ runtime library to make OpenMM work? And wouldn't that library be needed if we were compiling ChimeraX with gcc 7? Certainly we don't want to twist the whole ChimeraX build process to use centos 6 just because of openmm. But updating to a newer compiler seems like a generally good idea.
comment:4 by , 5 years ago
The problem is that ISOLDE needs to link against both OpenMM and ChimeraX C++ libraries, so they need to use a common C++ runtime. And because of they way they are built, OpenMM and the ChimeraX libraries have different parts of the C++ runtime static linked and dynamically linked due to how support for the newer versions of C++ is implemented.
The newer C++ runtimes use a static layer on top of system shared C++ runtime. That way the program runs without changing the system's C++ runtime and without distributing a potentially conflicting C++ shared library (we've been burned by that in Chimera, not using LD_LIBRARY_PATH is fantastic).
follow-up: 5 comment:5 by , 5 years ago
I think I see. So it is not sufficient that ChimeraX and OpenMM use the same C++ compiler. The OS also matters (CentOS 6 vs 7) for ABI compatibility because the split between static and dynamic library parts of C++ is depends on the OS. What a nightmare. This is not a problem on Windows or macOS. Combining the horrible compatibility properties of C++ with the horrible compatibility proprties of Linux is a perfect storm. Just add one more C++ package into the mix and there would be no hope. I think the clear solution is we get OpenMM compiled to match ChimeraX, not change the ChimeraX build platform to accomodate one package, openmm. Either the openmm developers or Tristan or we can compile. But ChimeraX does need to use a modern enough compiler to handle the OpenMM code. Let’s choose the ChimeraX C++ Linux platform we want and then get someone to build openmm for it.
follow-up: 6 comment:6 by , 5 years ago
I guess I don't understand the dependence of OpenMM on the OS. How is it that to date we can use one OpenMM library on CentOS 7,8, Ubuntu 16,18,20? It seems like the failure of OpenMM 7.5 to load on Ubuntu 18 is simply that it is using a newer C++ library GLIBCXX_3.4.26 that Ubuntu 18 does not have. The solution to that seems to be that our Ubuntu package should depend on that C++ runtime. Of course that does not solve Tristan's problem of needing two C++ compilers to link to OpenMM and to ChimeraX libatomicstruct.
follow-up: 7 comment:7 by , 5 years ago
What's your planned timeframe on this? I should be able to make a devtoolset-{x} build of OpenMM (and hopefully set up a Singularity recipe to rebuild as needed) without too much trouble, but my next 2-3 weeks is going to be really fraught.
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 25 September 2020 17:54
To: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; goddard@sonic.net <goddard@sonic.net>
Cc: gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
#3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
--------------------------------+-------------------------
Reporter: goddard@… | Owner: Tom Goddard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Platform | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
--------------------------------+-------------------------
Comment (by goddard@…):
{{{
I guess I don't understand the dependence of OpenMM on the OS. How is it
that to date we can use one OpenMM library on CentOS 7,8, Ubuntu 16,18,20?
It seems like the failure of OpenMM 7.5 to load on Ubuntu 18 is simply
that it is using a newer C++ library GLIBCXX_3.4.26 that Ubuntu 18 does
not have. The solution to that seems to be that our Ubuntu package should
depend on that C++ runtime. Of course that does not solve Tristan's
problem of needing two C++ compilers to link to OpenMM and to ChimeraX
libatomicstruct.
}}}
--
Ticket URL: <https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/3756#comment:6>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
follow-up: 8 comment:8 by , 5 years ago
There is no urgent need to solve this OpenMM / Linux import problem or the ISOLDE compile problem. We will want to fix it before the 1.2 release which we don't even have a date for and is probably 3-6 months away. Currently there is no ISOLDE for ChimeraX 1.1, so having ISOLDE working with 1.2 nightly builds does not seem like a priority. The only other ChimeraX tool using OpenMM is tug and minimize mouse modes which are really just demo features, so not urgent to fix those. Also I would first pursue whether the problem can be installed by adding a linux dependency on the newer C++ runtime that the standard OpenMM builds are using. If not then it is absurd for OpenMM to be making standard builds with a C++ compiler that Linux users (not using ChimeraX) can't use, and they should change their builds to a usable C++ compiler. I don't understand the Linux C++ runtime issues well enough and that would be the first thing to get straight before trying to build OpenMM.
comment:9 by , 5 years ago
To get linux binaries to work on all version we support, we compile against old versions of libc/libgcc_s/libstdc++. That way, it still works if newer versions of those libraries are present. The problem with C++ code is that the old version it too old. By using CentOS 7 and its layering trick, we avoid that issue. But it only works if all the C++ code is compiled with the same static/shared split.
So the question is which CentOS 7 devtoolset to switch to. OpenMM needs at least devtoolset-7-gcc. I propose going to devtoolset-9-gcc so OpenMM can continue to evolve without us changing the C++ runtime environment on Linux. CentOS 7's end of life will be in June 2024.
follow-up: 10 comment:10 by , 5 years ago
Before we decide which devtoolset to use I think we should figure make sure OpenMM is making sensible distributions from omnia. If what they are distributing is not good we should tell Peter Eastman and he has been very responsive and can fix it. The reason I think OpenMM distributions have a problem is because I try to use their standard OpenMM 7.5 beta for Linux and it fails to load on Ubuntu 18.04 LTS. I would think Ubuntu 18 is a pretty important platform. How does Peter Eastman expect OpenMM to be used on Ubuntu 18? Before pestering him I'd like us to try to answer that question. Suppose I want to use OpenMM distributions from omnia-dev on Ubuntu 18 -- can it be done and how. If I can't figure it out then I'd ask Peter and maybe the answer is that it can't be done and it is just a mistake and Peter is going to change the OpenMM build system. In short, let's not adapt to OpenMM until we understand how the OpenMM library distributions are supposed to function and on which platforms they are intended to function. I want to avoid monkeying with ChimeraX and ISOLDE if the problem is really in Peter Eastman's court.
follow-up: 11 comment:11 by , 5 years ago
As I understand it, all their new builds are designed to be run within a conda environment. If it's installed with:
conda install -c omnia -c conda-forge openmm
... then Anaconda takes care of setting up a controlled environment with all dependencies so it will run happily. That does have the unfortunate side-effect of making it somewhat more challenging to use in a non-conda environment.
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 25 September 2020 19:07
To: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; goddard@sonic.net <goddard@sonic.net>
Cc: gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
#3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
--------------------------------+-------------------------
Reporter: goddard@… | Owner: Tom Goddard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Platform | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
--------------------------------+-------------------------
Comment (by goddard@…):
{{{
Before we decide which devtoolset to use I think we should figure make
sure OpenMM is making sensible distributions from omnia. If what they are
distributing is not good we should tell Peter Eastman and he has been very
responsive and can fix it. The reason I think OpenMM distributions have a
problem is because I try to use their standard OpenMM 7.5 beta for Linux
and it fails to load on Ubuntu 18.04 LTS. I would think Ubuntu 18 is a
pretty important platform. How does Peter Eastman expect OpenMM to be
used on Ubuntu 18? Before pestering him I'd like us to try to answer that
question. Suppose I want to use OpenMM distributions from omnia-dev on
Ubuntu 18 -- can it be done and how. If I can't figure it out then I'd
ask Peter and maybe the answer is that it can't be done and it is just a
mistake and Peter is going to change the OpenMM build system.
In short, let's not adapt to OpenMM until we understand how the OpenMM
library distributions are supposed to function and on which platforms they
are intended to function. I want to avoid monkeying with ChimeraX and
ISOLDE if the problem is really in Peter Eastman's court.
}}}
--
Ticket URL: <https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/3756#comment:10>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
comment:12 by , 5 years ago
As mentioned in ticket #1897, OpenMM 7.5 is compiled using conda-forge's compilation system. See https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml for some details. The docker image with cuda 10.2 is condaforge/linux-anvil-cuda:10.2. And that is CentOS 6.10, but it doesn't appear to have any compilers in it. So for ChimeraX to be compatible with the conda build, we would need to switch our build environment to CentOS 6.10.
comment:13 by , 5 years ago
The missing GNU C++ library GLIBCXX_3.4.26 is from gcc 9.1 and is part of libstdc++.6.0.26 as documented here
But the Ubuntu 18 standard repository only include libstdc++.6.0.25
One can of course get gcc-9 libraries for Ubuntu 18 by using a different package archive such as ppa:ubuntu-toolchain-r/test
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test
but the fact that it is not part of the core Ubuntu 18.04 distribution means this version of OpenMM 7.5.0 beta is simply not easily usable on Ubuntu 18.04. I think the solution is that OpenMM distributions should be compiled by its developers to support older linux distros like Ubuntu 18.04, and the solution for ChimeraX is to ask Peter Eastman to do that. We should tell him how old we think is old enough, ie which gcc version strikes the right balance between supporting many users and having the best modern C++ compiler.
comment:14 by , 5 years ago
Standard Ubuntu 16.04 supports gcc-5.1.0 (libstdc++.6.0.21)
Standard Ubuntu 18.04 repository supports libstdc++.6.0.25, gcc-8.1.0
https://packages.ubuntu.com/bionic/libstdc++6
Standard Ubuntu 20.04 repository supports libstdc++.6.0.28, gcc-10.1.0
The official CentOS 7 repository libstdc++.so supports up to GLIBCXX_3.4.19 which is gcc-4.8.3
https://centos.pkgs.org/7/centos-x86_64/libstdc++-4.8.5-39.el7.x86_64.rpm.html
The official CentOS 8 repostitory offers GLIBCXX_3.4.25 which is gcc-8.1.0
https://centos.pkgs.org/8/centos-baseos-x86_64/libstdc++-8.3.1-5.el8.0.2.x86_64.rpm.html
So the OpenMM 7.5.0 beta library requiring 6.0.26 will only work on the Ubuntu 20.04 ChimeraX distribution. To work with the CentOS 7 would require gcc-4.8 or older and I think Tristan said that OpenMM code now needs newer compilers than gcc-4 because it uses newer C++ features. Since CentOS 7 is common with the researchers OpenMM targets I think the OpenMM developers will need to provide libraries that work on that.
comment:15 by , 5 years ago
Running "objdump -p _openmm.cpython-38-x86_64-linux-gnu.so" on today's build gives the following version dependencies:
Version References:
required from libgcc_s.so.1:
0x0b792650 0x00 12 GCC_3.0
required from libstdc++.so.6:
0x0297f870 0x00 11 GLIBCXX_3.4.20
0x0297f861 0x00 10 GLIBCXX_3.4.11
0x056bafd3 0x00 08 CXXABI_1.3
0x02297f89 0x00 07 GLIBCXX_3.4.9
0x0297f871 0x00 05 GLIBCXX_3.4.21
0x02297f85 0x00 04 GLIBCXX_3.4.5
0x08922974 0x00 03 GLIBCXX_3.4
required from libc.so.6:
0x0d696914 0x00 09 GLIBC_2.4
0x09691a75 0x00 06 GLIBC_2.2.5
0x09691974 0x00 02 GLIBC_2.3.4
CentOS 6 has GCC_4.2.0, GLIBC_2.4, CXXABI 1.3.2, GLIBCXX_3.4.13.
CentOS 7 has GCC_4.2.0, GLIBC_2.14, CXXABI 1.3.7, GLIBCXX_3.4.19.
CentOS 8 has GCC_4.2.0, GLIBC_2.18, CXXABI 1.3.11, GLIBCXX_3.4.25.
Ubuntu 16.04 has GCC_4.2.0, GLIBC_2.18, CXXABI 1.3.9, GLIBCXX_3.4.21.
Ubuntu 18.04 has GCC_4.2.0, GLIBC_2.18, CXXABI 1.3.11, GLIBCXX_3.4.25.
Ubuntu 20.04 has GCC_4.2.0, GLIBC_2.18, CXXABI 1.3.12, GLIBCXX_3.4.28.
So it looks like OpenMM might have been compiled on Ubuntu 16.04. Unfortunately, that is not an option for us.
comment:16 by , 5 years ago
Your objdump output is strange since it suggests only GLIBCXX_3.4.21 is needed by OpenMM but the Python traceback at the start of this ticket says GLIBCXX_3.4.26 was not found. If it really only required 3.4.21 then it should work on Ubuntu 16,18,20 and CentOS 8, but not CentOS 7.
comment:17 by , 5 years ago
I requested Python 3.8 builds with a ticket at the GitHub OpenMM site
I did not specify the exact C++ ABI we want on Linux. I thought it was best to do this in two steps -- first get the OpenMM project to provide Python 3.8 libraries, and then deal with Tristan's need for C++ ABI compatibility between OpenMM libraries and ChimeraX libatomstruct since he compiles against both.
follow-up: 18 comment:18 by , 5 years ago
Also posted to the OpenMM ticket: the attached Singularity recipe and build script successfully build OpenMM (sans documentation - looks like some bug in the current Sphinx version that I don't have time to look into) for Python 3.8, CUDA 10.1 with devtoolset-9. The tests all run successfully in my host CentOS 7 environment.
singularity config fakeroot --add {your linux user name}
singularity build --fakeroot centos-7-devtoolset-9-py38-cuda-openmm.sif centos-7-devtoolset-9-cuda.def
singularity run --fakeroot --bind .:/host centos-7-devtoolset-9-py38-cuda-openmm.sif
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 28 September 2020 22:39
Cc: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; goddard@sonic.net <goddard@sonic.net>; gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
#3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
--------------------------------+-------------------------
Reporter: goddard@… | Owner: Tom Goddard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Platform | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
--------------------------------+-------------------------
Comment (by Tom Goddard):
I requested Python 3.8 builds with a ticket at the GitHub OpenMM site
https://github.com/openmm/openmm/issues/2871
I did not specify the exact C++ ABI we want on Linux. I thought it was
best to do this in two steps -- first get the OpenMM project to provide
Python 3.8 libraries, and then deal with Tristan's need for C++ ABI
compatibility between OpenMM libraries and ChimeraX libatomstruct since he
compiles against both.
--
Ticket URL: <https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/3756#comment:17>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
comment:19 by , 5 years ago
I can provide a tarball of the build if you like.
________________________________
From: Tristan Croll <tic20@cam.ac.uk>
Sent: 29 September 2020 14:35
To: ChimeraX-bugs@cgl.ucsf.edu <ChimeraX-bugs@cgl.ucsf.edu>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
Also posted to the OpenMM ticket: the attached Singularity recipe and build script successfully build OpenMM (sans documentation - looks like some bug in the current Sphinx version that I don't have time to look into) for Python 3.8, CUDA 10.1 with devtoolset-9. The tests all run successfully in my host CentOS 7 environment.
singularity config fakeroot --add {your linux user name}
singularity build --fakeroot centos-7-devtoolset-9-py38-cuda-openmm.sif centos-7-devtoolset-9-cuda.def
singularity run --fakeroot --bind .:/host centos-7-devtoolset-9-py38-cuda-openmm.sif
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 28 September 2020 22:39
Cc: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; goddard@sonic.net <goddard@sonic.net>; gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
#3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
--------------------------------+-------------------------
Reporter: goddard@… | Owner: Tom Goddard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Platform | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
--------------------------------+-------------------------
Comment (by Tom Goddard):
I requested Python 3.8 builds with a ticket at the GitHub OpenMM site
https://github.com/openmm/openmm/issues/2871
I did not specify the exact C++ ABI we want on Linux. I thought it was
best to do this in two steps -- first get the OpenMM project to provide
Python 3.8 libraries, and then deal with Tristan's need for C++ ABI
compatibility between OpenMM libraries and ChimeraX libatomstruct since he
compiles against both.
--
Ticket URL: <https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/3756#comment:17>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
follow-up: 19 comment:20 by , 5 years ago
(I did 'objdump -p' on the wrong library. Instead of the Python wrapper library, should have done in on CHIMERAX/lib/libOpenMM.so.7.5. That does need GLIBCXX_3.4.26.)
Building our own version of OpenMM is the way to go for now. That was we're guaranteed to match our build environment. I'll look at the script. Which version of CUDA should it target? CUDA 11.0 Update 1 just came out.
comment:21 by , 5 years ago
Good question. Over on omnia-dev it looks like they're building for everything from 8.0 through 11.0: https://anaconda.org/omnia-dev/openmm/files. May as well stay up to date and go with 11.0?
To be frank, though, this isn't as big an issue as it might first seem. ISOLDE defaults to the OpenCL platform on MacOS and Windows (Mac because you can't get anything Nvidia on Apple hardware these days; Windows because the CUDA just-in-time compilation requires Visual Studio), and on Linux silently falls back to OpenCL if it can't find the correct CUDA. Running on OpenCL really doesn't seem to care about the specific CUDA version.
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 29 September 2020 18:28
Cc: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; goddard@sonic.net <goddard@sonic.net>; gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
#3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
--------------------------------+-------------------------
Reporter: goddard@… | Owner: Tom Goddard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Platform | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
--------------------------------+-------------------------
Comment (by Greg Couch):
(I did 'objdump -p' on the wrong library. Instead of the Python wrapper
library, should have done in on CHIMERAX/lib/libOpenMM.so.7.5. That does
need GLIBCXX_3.4.26.)
Building our own version of OpenMM is the way to go for now. That was
we're guaranteed to match our build environment. I'll look at the script.
Which version of CUDA should it target? CUDA 11.0 Update 1 just came out.
--
Ticket URL: <https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/3756#comment:20>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
follow-up: 21 comment:22 by , 5 years ago
For the OpenMM project to succeed with the C++ library they produce they need to produce usable builds. So let's have them make those builds if they can. Possibly they will only decide to support the Conda environment which I guess uses its own libstdc++ to work on older Linux. That would be a mistake limiting the usage of OpenMM. I am concerned that OpenMM has no future, they are likely on little to no funding. It is not a good sign when you cannot provide your library for Python 3.8 which has been out for a year. If the best they can do is have everyone compile their own version, then there will be few developers who use OpenMM. So I'd like to see if they can make distributions of OpenMM so that OpenMM has a chance to succeed.
comment:23 by , 5 years ago
I added a few more packages to the .def file: rh-python38-python-numpy rh-python38-python-Cython rh-python38-python-wheel
But I'm missing how the distribution is built. It looks like the INSTALL directory should have everything. But it doesn't have all of the shared libraries that are in the build tree, and the python module is not there. Are the other shared libraries necessary? If I cd into build/python and run "python setup.py install", it tries to install in /opt/rh/rh-python38/root/usr/local/lib64/python3.8/site-packages, not INSTALL/lib/python3.8/site-packages. That can be done by fixed by giving the --install-lib argument. Just wondering how it is supposed to work.
comment:24 by , 5 years ago
Sorry about that - will dig through the documentation a bit more tomorrow to see if I can get it the rest of the way.
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 01 October 2020 22:36
Cc: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; goddard@sonic.net <goddard@sonic.net>; gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
#3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
--------------------------------+-------------------------
Reporter: goddard@… | Owner: Tom Goddard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Platform | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
--------------------------------+-------------------------
Comment (by Greg Couch):
I added a few more packages to the .def file: rh-python38-python-numpy rh-
python38-python-Cython rh-python38-python-wheel
But I'm missing how the distribution is built. It looks like the INSTALL
directory should have everything. But it doesn't have all of the shared
libraries that are in the build tree, and the python module is not there.
Are the other shared libraries necessary? If I cd into build/python and
run "python setup.py install", it tries to install in /opt/rh/rh-
python38/root/usr/local/lib64/python3.8/site-packages, not
INSTALL/lib/python3.8/site-packages. That can be done by fixed by giving
the --install-lib argument. Just wondering how it is supposed to work.
--
Ticket URL: <https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/3756#comment:23>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
follow-up: 24 comment:25 by , 5 years ago
Their documentation on building and installing from source is at http://docs.openmm.org/latest/userguide/library.html#compiling-openmm-from-source-code. Fairly straightforward if you're building using ChimeraX's own Python: just set CMAKE_INSTALL_DIR to $CHIMERAX, then
make
make install # installs compiled libraries to ${CMAKE_INSTALL_DIR}/lib
make PythonInstall # installs Python files to the site-packages directory for the Python used in compilation
If building it separately, things may be a little more complicated - as far as I'm aware, pre-conda it was never distributed as true wheel files, just a tarball with an install.sh script included.
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 01 October 2020 23:17
To: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; goddard@sonic.net <goddard@sonic.net>
Cc: gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
#3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
--------------------------------+-------------------------
Reporter: goddard@… | Owner: Tom Goddard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Platform | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
--------------------------------+-------------------------
Comment (by Tristan Croll):
{{{
Sorry about that - will dig through the documentation a bit more tomorrow
to see if I can get it the rest of the way.
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 01 October 2020 22:36
Cc: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; goddard@sonic.net
<goddard@sonic.net>; gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan
Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++
library not found
#3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
--------------------------------+-------------------------
Reporter: goddard@… | Owner: Tom Goddard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Platform | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
--------------------------------+-------------------------
Comment (by Greg Couch):
I added a few more packages to the .def file: rh-python38-python-numpy
rh-
python38-python-Cython rh-python38-python-wheel
But I'm missing how the distribution is built. It looks like the INSTALL
directory should have everything. But it doesn't have all of the shared
libraries that are in the build tree, and the python module is not there.
Are the other shared libraries necessary? If I cd into build/python and
run "python setup.py install", it tries to install in /opt/rh/rh-
python38/root/usr/local/lib64/python3.8/site-packages, not
INSTALL/lib/python3.8/site-packages. That can be done by fixed by giving
the --install-lib argument. Just wondering how it is supposed to work.
--
Ticket URL:
<https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/3756#comment:23>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
}}}
--
Ticket URL: <https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/3756#comment:24>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
follow-up: 25 comment:26 by , 5 years ago
I hate to keep harping on this, but we really need the OpenMM project to make builds so they can survive. Chimera 1 uses an extremely old numpy 1.7 because the Chimera MMTK molecular dynamics toolkit cannot work with anything newer and has no one to maintain that. If OpenMM also goes into the no funding, hobbyist support only mode, I definitely will not support including it in ChimeraX. I know that would be catastrophic for Tristan and he could take over all the support for OpenMM and I would not interfere. But the best we can do for OpenMM right now is prod them into making usable distributions. If they can't do that then they have one foot in the grave already. If we make our own OpenMM builds it won't change that fact. So if you are going to work on OpenMM builds the aim should be to make something that the OpenMM developers can immediately use for example to produce PyPi wheels or some other suitable distribution channel that they will maintain.
follow-up: 26 comment:27 by , 5 years ago
Playing devil's advocate here: for the vast majority of OpenMM users/developers, the Conda distributions will be just fine for their purposes. As long as they're installed within a Conda environment they'll work just fine on almost any system from CentOS 6 onwards. Since most people will only ever use it as a Python library they'll be perfectly happy working in Conda as long as all their other favourite packages are also available there. It's only the people that need to use it in a non-Conda scenario that will run into trouble. But it would certainly make life much easier if they were to maintain a second distribution channel for those people - but even that doesn't entirely solve things for people like me who need to use its C++ API since the need to match compilers remains. There are only two solutions I can see that would truly solve that:
1. A pure-C interface to OpenMM that's a bit better than the current one (i.e. that at a minimum does something sensible with errors), or
2. I work with the OpenMM developers to get the functionalities that I need incorporated into their code, removing the need to touch their C++ API from ISOLDE.
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 01 October 2020 23:40
To: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; goddard@sonic.net <goddard@sonic.net>
Cc: gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
#3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
--------------------------------+-------------------------
Reporter: goddard@… | Owner: Tom Goddard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Platform | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
--------------------------------+-------------------------
Comment (by goddard@…):
{{{
I hate to keep harping on this, but we really need the OpenMM project to
make builds so they can survive. Chimera 1 uses an extremely old numpy 1.7
because the Chimera MMTK molecular dynamics toolkit cannot work with
anything newer and has no one to maintain that. If OpenMM also goes into
the no funding, hobbyist support only mode, I definitely will not support
including it in ChimeraX. I know that would be catastrophic for Tristan
and he could take over all the support for OpenMM and I would not
interfere. But the best we can do for OpenMM right now is prod them into
making usable distributions. If they can't do that then they have one
foot in the grave already. If we make our own OpenMM builds it won't
change that fact. So if you are going to work on OpenMM builds the aim
should be to make something that the OpenMM developers can immediately use
for example to produce PyPi wheels or some other suitable distribution
channel that they will maintain.
}}}
--
Ticket URL: <https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/3756#comment:26>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
follow-up: 27 comment:28 by , 5 years ago
Conda is one fine distribution method for OpenMM. But I think you are wrong that it will meet the needs of that vast majority of users/developers. There are different Python environments and to compel all your users to use Conda limits the audience. Also, while there will be few C++ OpenMM developers they are an important group whose influence on how widely OpenMM gets used (and how easily it can get funding) is larger than their numbers. For your use in ISOLDE it is reasonable to compile OpenMM yourself, and also your option 2 to get your C++ needs into the Python OpenMM API. My main concern is OpenMM will languish if they don't take usability more seriously. The fact that their production distribution OpenMM 7.4.2 has not been available for the current Python 3.8 for a year now is an alarm bell that this project is in trouble. ChimeraX depends on about 50 third party Python packages and only two were not available or Python 3.8 (the other is GDCM a DICOM library).
follow-up: 28 comment:29 by , 5 years ago
All fair points. The good news is that I've just gotten to the point of building what should be a fully-portable wheel (that in addition to everything else will be able to do away with the need to set the OPENMM_PLUGIN_DIR environment variable in ChimeraX). My current path is a little bit hacky, but it demonstrates that they're really not all that far from a neat solution.
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 02 October 2020 18:34
To: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; goddard@sonic.net <goddard@sonic.net>
Cc: gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
#3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
--------------------------------+-------------------------
Reporter: goddard@… | Owner: Tom Goddard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Platform | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
--------------------------------+-------------------------
Comment (by goddard@…):
{{{
Conda is one fine distribution method for OpenMM. But I think you are
wrong that it will meet the needs of that vast majority of
users/developers. There are different Python environments and to compel
all your users to use Conda limits the audience. Also, while there will
be few C++ OpenMM developers they are an important group whose influence
on how widely OpenMM gets used (and how easily it can get funding) is
larger than their numbers.
For your use in ISOLDE it is reasonable to compile OpenMM yourself, and
also your option 2 to get your C++ needs into the Python OpenMM API. My
main concern is OpenMM will languish if they don't take usability more
seriously. The fact that their production distribution OpenMM 7.4.2 has
not been available for the current Python 3.8 for a year now is an alarm
bell that this project is in trouble. ChimeraX depends on about 50 third
party Python packages and only two were not available or Python 3.8 (the
other is GDCM a DICOM library).
}}}
--
Ticket URL: <https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/3756#comment:28>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
follow-up: 29 comment:30 by , 5 years ago
I've put up a Python 3.8 wheel that appears to be passing all tests at https://drive.google.com/file/d/1Jlmq7ohAYCiLxC86PhWH03ss_XMU2amK/view?usp=sharing. To use it in ChimeraX you'll need to disable your code that sets OPENMM_PLUGIN_DIR - the code knows where to find them as-is, but that mechanism is overridden by the environment variable. Took a bit of fiddling - see https://github.com/openmm/openmm/issues/2871#issuecomment-702903035 for more detail.
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 02 October 2020 19:08
To: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; goddard@sonic.net <goddard@sonic.net>
Cc: gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
#3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
--------------------------------+-------------------------
Reporter: goddard@… | Owner: Tom Goddard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Platform | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
--------------------------------+-------------------------
Comment (by Tristan Croll):
{{{
All fair points. The good news is that I've just gotten to the point of
building what should be a fully-portable wheel (that in addition to
everything else will be able to do away with the need to set the
OPENMM_PLUGIN_DIR environment variable in ChimeraX). My current path is a
little bit hacky, but it demonstrates that they're really not all that far
from a neat solution.
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 02 October 2020 18:34
To: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; goddard@sonic.net
<goddard@sonic.net>
Cc: gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll
<tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++
library not found
#3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
--------------------------------+-------------------------
Reporter: goddard@… | Owner: Tom Goddard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Platform | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
--------------------------------+-------------------------
Comment (by goddard@…):
{{{
Conda is one fine distribution method for OpenMM. But I think you are
wrong that it will meet the needs of that vast majority of
users/developers. There are different Python environments and to compel
all your users to use Conda limits the audience. Also, while there will
be few C++ OpenMM developers they are an important group whose influence
on how widely OpenMM gets used (and how easily it can get funding) is
larger than their numbers.
For your use in ISOLDE it is reasonable to compile OpenMM yourself, and
also your option 2 to get your C++ needs into the Python OpenMM API. My
main concern is OpenMM will languish if they don't take usability more
seriously. The fact that their production distribution OpenMM 7.4.2 has
not been available for the current Python 3.8 for a year now is an alarm
bell that this project is in trouble. ChimeraX depends on about 50 third
party Python packages and only two were not available or Python 3.8 (the
other is GDCM a DICOM library).
}}}
--
Ticket URL:
<https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/3756#comment:28>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
}}}
--
Ticket URL: <https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/3756#comment:29>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
follow-up: 30 comment:31 by , 5 years ago
I was going for a different solution. Just replicating the tar file structure of the existing distribution, so there would no code changes.
comment:32 by , 5 years ago
Well... if you took the contents of simtk/openmm/lib and moved them to $CHIMERAX/lib, I think everything should work just as before. But Tom's right: it would be nice to have a more future-proof system, which justifies some effort going in to working out how to build a proper OpenMM wheel.
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 02 October 2020 21:15
Cc: goddard@cgl.ucsf.edu <goddard@cgl.ucsf.edu>; goddard@sonic.net <goddard@sonic.net>; gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
#3756: OpenMM 7.5 beta fails to load on Linux, C++ library not found
--------------------------------+-------------------------
Reporter: goddard@… | Owner: Tom Goddard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Platform | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
--------------------------------+-------------------------
Comment (by Greg Couch):
I was going for a different solution. Just replicating the tar file
structure of the existing distribution, so there would no code changes.
--
Ticket URL: <https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/3756#comment:31>
ChimeraX <http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
follow-up: 32 comment:33 by , 5 years ago
I've replaced the openmm-7.5.0-linux-py38_cuda110_1.tar.bz2 with one that was built using the revised build script and singularity image in openmm_build2.zip. So it now imports on CentOS 7. But it is using devtoolset-9, so the next step is to updated the CentOS 7 singularity image to devtoolset-9 to match. Will try get installed in the next 30 minutes. Can't remember if it will be in time for tonight's build.
comment:34 by , 5 years ago
Revised build.sh to delete RUNPATH from python module .so's. Added chrpath to singularity definition.
comment:35 by , 5 years ago
Tom, can you try tug mode on Linux with the daily build? It should all be consistent right now.
comment:36 by , 5 years ago
Tug worked in last night's build on Ubuntu 18.04. I used 1mtx, close all but one structure of this nmr ensemble, close #1.2-30, then try tug mode.
comment:37 by , 5 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Updated prereqs/openmm/README.txt
by , 4 years ago
| Attachment: | openmm_build4.tar.gz added |
|---|
Revised singularity recipe and build script for Python 3.9 and CUDA 11.2
comment:38 by , 4 years ago
Corrected a few errors:
- the build script wasn't changing into the openmm directory before checking out 7.5_branch. Since I hadn't done
set -ein the script it was continuing past the error and just building from master. - also modified it to do everything in /tmp rather than the starting directory (user's home directory by default).
Anyway, the resulting build runs fine for me.
follow-up: 36 comment:39 by , 4 years ago
Thanks. I see you attached the OpenMM 7.5.1 linux build to ticket #4661 and I will put that into the daily build.
Note:
See TracTickets
for help on using tickets.
That makes sense. The new OpenMM needs a different C++ runtime library. I suspect that we will need to build OpenMM ourselves. I believe the new OpenMM is built on CentOS 6 with gcc 7.3. We are building everything on CentOS 7 with gcc 4.9. In both cases, the newer C++ runtime is layered on top of the system's older C++ runtime. Both need to be consistent. We can upgrade to gcc 7, 8 or 9. But switching to CentOS 6 may be problematic. We know ChimeraX can't run on CentOS 6, but it might work on CentOS 7 if it is built on CentOS 6.