CHARMM Development Project Forums User Discussion & Questions Installation and Testing Problem installing openmm on C46b1 (Free Version)

Hello and Happy, Safe, and Healthy New Year 2022.

I have successfully created serial and openmpi versions of CHARMM C46b1 f(ree version), but have lots of problems adding OPENMM.

I am an early user of perlmutter at NERSC, and so this is a fantastic opportunity for me to get a really fast version of CHARMM running.

But , first things first. I am trying all this locally on my Debian xeon laptop.

I emphasize that I am trying to simply include OPENMM without CUDA.

I have attached a file of what I did, and the problems that occurred. Can you help, please?

Thanks so much.

Kind regards,

Angelo

I'm not sure what is causing undefined symbols in your case, but I can tell you how I use OpenMM installed from anaconda when I compile charmm.

When I use OpenMM from anaconda, I set the environment variables to subdirectories of
~/anaconda3/pkgs/openmm-7.6.0-py39h8d72adf_0_khronos
rather than
anaconda3/lib

So you could try
ls -d ~/miniconda3/pkgs/*openmm*
to find your OpenMM directory and set your environment variables accordingly.

Dear Josh Buckner,

Thanks so much for replying so quickly.

But, I tried all your instructions, and I still receive undefined references.

I tired it twice. Once as you stated; and once with the same instructions but with export LD_LIBRARY_PATH= .... to ensure the libraries are there.

I am really frustrated. I must be missing something important.

Regards,

Angelo

Have you checked that OpenMM works with a python script maybe?

Thanks again, Josh. But all seems normal.


(base) Thu Jan 06 15:38:33 [rossi@debian OpenMM]$python -m openmm.testInstallation

OpenMM Version: 7.6
Git Revision: ad113a0cb37991a2de67a08026cf3b91616bafbe

There are 2 Platforms available:

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

Median difference in forces between platforms:

Reference vs. CPU: 6.29529e-06

All differences are within tolerance.


(base) Thu Jan 06 15:41:00 [rossi@debian OpenMM]$cat test.py
from openmm.app import *
from openmm import *
from openmm.unit import *
from sys import stdout

pdb = PDBFile('ala10_alpha_helix.pdb')
forcefield = ForceField('amber99sb.xml', 'tip3p.xml')
#system = forcefield.createSystem(pdb.topology, nonbondedMethod=PME, nonbondedCutoff=1*nanometer, constraints=HBonds)
system = forcefield.createSystem(pdb.topology, nonbondedMethod=NoCutoff, nonbondedCutoff=1*nanometer, constraints=HBonds)
integrator = LangevinIntegrator(300*kelvin, 1/picosecond, 0.002*picoseconds)
simulation = Simulation(pdb.topology, system, integrator)
simulation.context.setPositions(pdb.positions)
simulation.minimizeEnergy()
simulation.reporters.append(PDBReporter('ala10_alpha_helix_min.pdb', 1000))
simulation.reporters.append(StateDataReporter(stdout, 1000, step=True, potentialEnergy=True, temperature=True))
simulation.step(10000)

(base) Thu Jan 06 15:41:07 [rossi@debian OpenMM]$python test.py
#"Step","Potential Energy (kJ/mole)","Temperature (K)"
1000,258.91266317191355,272.75141627363786
2000,203.67630450515202,319.98679054107197
3000,68.21097523395304,345.6628953119614
4000,38.90754197987599,300.7646384178367
5000,56.467820030818984,342.89423856812635
6000,3.801844918903953,296.0012974574869
7000,10.447999160997483,339.06622379510867
8000,-5.852643457431668,375.56343717500573
9000,-16.808856477929567,312.84014723348895
10000,-31.31914165982721,295.00262720199896

SUCCESS!! IT WORKED!

Here is the problem. In September 2021, I installed the MDAnalysis (https://www.mdanalysis.org/) software which can be used to analyze trajectories from applications such as OpenMM, CHARMM, Gromacs, etc

The CMAKE procedure used an OpenMM library in the directory /usr/lib/x86_64-linux-gnu/libOpenMM.so placed there by the previous MDAnalysis install procedure.

That is the library that CMAKE procedure used, ALTHOUGH all the needed libraries were defined BEFORE using the CMAKE procedure:

(base) Fri Jan 07 08:48:02 [rossi@debian charmm]$env | grep OPENMM
OPENMM_DIR=/home/rossi/miniconda3/pkgs/openmm-7.6.0-py39h33ab577_0
OPENMM_LIBRARY=/home/rossi/miniconda3/pkgs/openmm-7.6.0-py39h33ab577_0/lib
OPENMM_PLUGIN_DIR=/home/rossi/miniconda3/pkgs/openmm-7.6.0-py39h33ab577_0/lib/plugins
OPENMM_INCLUDE_DIRS=/home/rossi/miniconda3/pkgs/openmm-7.6.0-py39h33ab577_0/include
OPENMM_HOME=/home/rossi/miniconda3/pkgs/openmm-7.6.0-py39h33ab577_0

I think that, if the CMAKE procedure had used only the defined environment variables above, then this conflict of an incorrect libOpenMM.so would not have arisen.

Thanks for the update. I'm glad you were able to get things to work.

How exactly did you get it to work in the end?

off the topic: is there any known compatibility problem for charmm and openmm versions? I am still using openmm 7.3. Thinking to move to new version of openmm (now is 7.7). Thanks.

At least with the OpenMMFortranModule.f90 that gets generated for me when I build OpenMM 7.7.0, there are some errors during the CHARMM compile process.

I edited this file and replaced all occurances of 'long long' which is not a valid fortran type with 'integer'.

Then the compile completed successfully.

It seems that the anaconda3 package for OpenMM 7.7.0 contains the same errors in OpenMMFortranModule.f90