OS X Mavericks?

[David Minh]

Has anybody successfully installed and run OpenMM on a Mac using OS X Mavericks? I am using the Apple version of gcc.

bash-3.2$ gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

After installing OpenMM including the python API, I keep on getting a segmentation fault:

bash-3.2$ python testInstallation.py
Segmentation fault: 11

It seems to occur during the following command:

system = forcefield.createSystem(pdb.topology, nonbondedMethod=PME, nonbondedCutoff=1*nanometer, constraints=HBonds)

Also I encounter problems with the C++ API as follows:

bash-3.2$ make HelloArgon
g++ -g -I/usr/local/openmm/include HelloArgon.cpp -L/usr/local/openmm/lib -lOpenMM -o HelloArgon
Undefined symbols for architecture x86_64:
"OpenMM::Context::setPositions(std::__1::vector<OpenMM::Vec3, std::__1::allocator<OpenMM::Vec3> > const&)", referenced from:
simulateArgon() in HelloArgon-9lTul0.o
"OpenMM::Platform::loadPluginsFromDirectory(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
simulateArgon() in HelloArgon-9lTul0.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [HelloArgon] Error 1

[Peter Eastman]

I haven't tried Mavericks yet, but it's on my to-do list. Are you using the precompiled OS X binaries, or did you compile OpenMM from source?

Peter

[David Minh]

I used the precompiled libraries. Maybe I can try a recompile.

[David Minh]

On another machine without CUDA:

pauling14:examples admin$ python testInstallation.py
Failed to import OpenMM packages: dlopen(/Library/Python/2.7/site-packages/simtk/openmm/_openmm.so, 2): Symbol not found: __ZN6OpenMM13CustomGBForce11addFunctionERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEERKNS1_6vectorIdNS5_IdEEEEdd
Referenced from: /Library/Python/2.7/site-packages/simtk/openmm/_openmm.so
Expected in: flat namespace
in /Library/Python/2.7/site-packages/simtk/openmm/_openmm.so
Make sure OpenMM is installed and the library path is set correctly.

[Charles Brooks]

For what its worth, we installed the pre-compiled OpenMM 5.2 libraries on a MacBook Pro running Mavericks without a lot of luck. First, we noted that we could get our app (CHARMM/OpenMM) to run through the CHARMM/OpenMM interface, but it would only use OpenCL (yeah, OpenCL seems to work under Mavericks). We tried forcing the CUDA so library and got an error that there was no such device. We had already downloaded and installed the Cuda 5.5 drivers/toolkit, etc. and tested that the GPU card was able to run some of the Cuda examples from Nvidia. Alas, we haven't been able to get the Cuda so libraries to load.

Also, we tried to compile OpenMM 5.2 from source, which I have yet to be successful doing on a Mac that I own, although we do it all the time on Linux. My record remains unbroken. the new clang compiler suite in the latest Xcode does not seem to play well with the code c++ code in OpenMM. If someone gets a formula for the configuration in ccmake that successfully builds, please post some real instructions about how to do it!

On another note, it also seems that the use of CustomNonbondedForce(s) are working differently than with OpenMM 5.1. I had written a bunch of code that utilized these functions, it works fine in OpenMM 5.1 but produces really large energies and forces, non-sensible ones, on OpenMM 5.2. No diagnostics to suggest where the problem is. Any ideas?

What specifically is happening is that I have implemented all of CHARMM's relevant switching/shifting functions in the CHARMM/OpenMM interface by using only part or none of OpenMM's normal nonbonded functions (all cases where I use some form of OpenMM's electrostatic interactions but my own custom nonbonded forces for L-J work fine), when I try to replace (and hence never create a "normal" non-bonded force) both the LJ and electrostatic and create my own custom function for this, in OpenMM 5.2 I get non-sense, as noted above, whereas the same code works fine in OpenMM 5.1. I expect it has something to do with the addition of the interaction groups in OpenMM 5.2, but it's not obvious (to me) from the doc files why what I'm doing shouldn't (keep) working in OpenMM 5.2.

Any ideas would be really appreciated.

[Peter Eastman]

Ok, sounds like I really need to upgrade my computer and track down what's happening. I'll add that to my list for next week.

On another note, it also seems that the use of CustomNonbondedForce(s) are working differently than with OpenMM 5.1.

I'll reply to this question in a separate thread since it isn't directly related to this one.

Peter

[Peter Eastman]

I've just checked in some changes for OS X 10.9. With these changes, I can now mostly compile (except for the C and Fortran wrappers - I haven't gotten gccxml to work so far). However, I can't test running anything that uses CUDA, because Nvidia has dropped support for all compute capability 1.x GPUs in their driver for 10.9. They say they'll bring it back in a future update to the driver.

Peter

[Peter Eastman]

I'm kind of stumped on the Python import problem. The error message says that it's looking for a symbol called

Code: Select all

__ZN6OpenMM13CustomGBForce11addFunctionERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEERKNS1_6vectorIdNS5_IdEEEEdd

and not finding it. So is that symbol defined in the OpenMM library? I used

nm /usr/local/openmm/lib/libOpenMM.dylib

to list all the symbols in the OpenMM library. And sure enough, that symbol is not there. Instead it contains

Code: Select all

__ZN6OpenMM13CustomGBForce11addFunctionERKSsRKSt6vectorIdSaIdEEdd

That means more or less the same thing (you can use http://demangler.com to translate them into something more readable), but it's getting mangled in a different way. But why? Both the library and the Python extension are getting compiled on the same computer with (presumably) the same compiler, and getting that symbol from the same header file. So why are they mangling it differently?

Any ideas?

Peter

[Peter Eastman]

Ok, I've fixed the Python problem. This turned out to be rather complicated. Apparently OS X has two different versions of the C++ standard library. There's the old version, called libstdc++, and a new version they introduced in 10.7 called libc++. They've been gradually migrating over from the old version to the new one. So in previously OS releases, Python was linked against libstdc++, but in 10.9 it's linked against libc++. And that means it can only load libraries that are also linked against libc++.

The only thing that still isn't working is the C and Fortran wrappers. I'm working on that now.

Peter

[Charles Brooks]

Just wanted to check whether anyone has had success in running CUDA apps through OpenMM on OSX 10.9 (Mavericks). We are still unable to get anything to run via CUDA. I am running on a MacBook Pro with CUDA ToolKit and drivers version 5.5 and have the NVIDIA GeForce GT 650M 1024 MB GPU, which I believe should be supported. The CUDA examples under the Nvidia example directories work, but testInstallation.py in OpenMM5.2-Mac/examples only runs Reference and OpenCL tests. I remain highly puzzled as to why this is the case. I also note, prior to upgrading from 10.7 to 10.9 the same binaries (from OpenMM5.2-MAC.zip) with the same CUDA drivers ran CUDA and Reference but not OpenCL.

Any ideas/advice would be appreciated.

Charles Brooks

This is a follow-up to this post. I have now tried both precompiled OpenMM5.2-Mac and pre-release OpenMM6.0-Mac on a clean, brand new, MacBook Pro w/ Mavericks (OSX 10.9), latest Xcode, clang compilers, NVIDIA GTX 750M GPU and latest CUDA )(5.5) ToolKit and driver without success in getting the CUDA platform to be recognized. I was able to compile and run the NVIDIA examples to verify it found and could use the GPU card. I have ensured that the power-saver was "off". The characteristics are:

OpenMM5.2

python test testInstallation.py does not run, but gives a missing library error

> python testInstallation.py
Failed to import OpenMM packages: dlopen(/Library/Python/2.7/site-packages/simtk/openmm/_openmm.so, 2): no suitable image found. Did find:
/Library/Python/2.7/site-packages/simtk/openmm/_openmm.so: mach-o, but wrong architecture
Make sure OpenMM is installed and the library path is set correctly.

A similar problem occurs when trying to build HelloArgon.cpp w/ just use of the make command in the examples directory.

The HellowArgonInC.c compiles and runs, but only on the OpenCL platform

OpenMM6.0

In this case, testInstallation.py works but produces results only for Reference, CPU and OpenCL platforms - does not find CUDA:

python testInstallation.py
There are 3 Platforms available:

1 Reference - Successfully computed forces
2 CPU - Successfully computed forces
3 OpenCL - Successfully computed forces

Median difference in forces between platforms:

Reference vs. CPU: 3.41782e-06
Reference vs. OpenCL: 0.00462904
CPU vs. OpenCL: 0.0046304

The example code HelloArgon.cpp also compiles fine with default make command, but runs on the OpenCL platform, as does the HelloArgonInC.

Conclusion: CUDA platform is not recognized for some reason in either OpenMM5.2 or OpenMM6.0 pre-compiled binaries running on current MacBook Pro with supported NVIDIA GPU. Additionally, there are library compatibility problems with the OpenMM5.2 binaries after the switch to the latest OSX (10.9) and clang compilers.

Any help here would be appreciated as we have also found erroneous results coming from the PME routines on OpenCL (which I'll report elsewhere after I get a bit more information) and this makes developing on my Mac platform questionable.