I am implementing a simulation where I invoke python in lammps scripts. I have tested the script on my MacOS and it works well. However, I would like to use more CPU cores and put the script on my ubuntu cluster. Confusing bugs started to emerge.
In the begining, I encourted the same problem with one in a previously discussed topic (AttributeError: lmp_mpi: undefined symbol, see Problem on building Lammps with Python) . Having followed your suggestions in the page step by step, I still can not fix it.
The error messages are as follows:
Traceback (most recent call last):
File “”, line 6, in get_dt
File “/home/andrew/lammps-7Feb2024/python/lammps/core.py”, line 285, in init
self.lib.lammps_set_string_variable.argtypes = [c_void_p, c_char_p, c_char_p]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/home/andrew/software/anaconda3/envs/mylammps/lib/python3.11/ctypes/init.py”, line 389, in getattr
func = self.getitem(name)
^^^^^^^^^^^^^^^^^^^^^^
File “/home/andrew/software/anaconda3/envs/mylammps/lib/python3.11/ctypes/init.py”, line 394, in getitem
func = self._FuncPtr((name_or_ordinal, self))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: lmp_mpi: undefined symbol: lammps_set_string_variable. Did you mean: ‘lammps_set_variable’?
ERROR on proc 3: Python evaluation of function get_dt failed (src/PYTHON/python_impl.cpp:361)
Last command: variable
By saying “your suggestions”, I mean “To make this work, you need to delete the lmp_mpi binary and recompile/link it in shared mode. Then you need to copy liblammps_mpi.so to a more permanent location, e.g. into the lib folder inside your virtual environment and then extend the LD_LIBRARY_PATH environment variable to include that folder.”, as shown in the previous discussion.
This looks like you have two different versions of the LAMMPS shared library on your system.
This path is suspicious. How did you get python to read the LAMMPS python module from its original source. If you install the LAMMPS python module with “make install-python” you would be importing it from some location that has either something like lib/python3.12/site-packages/lammps in the path or the location of your python virtual environment.
This confirms my hypothesis. The “lammps_set_string_variable()” function was added to the library interface only recently (and “lammps_set_variable()” deprecated), so if the ctypes loader cannot find the former, then it must be trying to read from a shared library created for an older version of LAMMPS.
Thank you for your response. I checked my environment and abondoned the virtual environment “mylammps” because I installed the lammps via source code. Now the problem becomes “AttributeError: lmp_mpi: undefined symbol: lammps_extract_setting”.
Let me explain what I have done after reading your response. Fristly I recomplied the source code (with path being /home/andrew/Downloads/lammps-7Feb2024) in shared mode using “sudo make mpi -j 4 mode=shlib” to obtain liblammps_mpi.so. I noticed that the last line of the messages shown was “mpicxx -g -O3 -std=c++11 main.o -L. -llammps_mpi -L/usr/lib/python3.8/config-3.8-x86_64-linux-gnu -L/usr/lib -lpython3.8 -lcrypt -lpthread -ldl -lutil -lm -lm -ldl -o …/lmp_mpi”.
Then I modified the /etc/profile and set two paths, which are:
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/home/andrew/Downloads/lammps-7Feb2024/lib
First off, compiling software with “sudo” is a very, VERY, VERY bad idea. There is no need.
So is modifying /etc/profile. If at all, you should modify ${HOME}/.profile
But for using the LAMMPS python module that should not be needed. If you unset those changes and instead do (after compiling with mode=shilib): make install-python
After that you should be able to import lammps without any special setup as follows:
Python 3.10.11 (main, Apr 5 2023, 00:00:00) [GCC 12.2.1 20221121 (Red Hat 12.2.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from lammps import lammps
>>> lmp = lammps()
LAMMPS (7 Feb 2024 - Development - patch_7Feb2024_update1-361-gf0c1ebec2f)
using 1 OpenMP thread(s) per MPI task
>>> print('LAMMPS version ', lmp.version())
LAMMPS version 20240207
>>> lmp.close()
Total wall time: 0:00:35
>>>
A lot of the problems you are seeing seem to be compounded by how you manage your machine and that is not something for which we can provide help or anticipate how to address problems. On a cleanly maintained machine, things should “just work”.
Thank again for your response. Before opening the discussion, I have tested the usage of Python in LAMMPS through typing “python\n import lammps” in the command line and things went on well. So I think the problem is probably due to linking (sorry for my lacking of experience in maintaining the machine).
I have tested several times “ldd ./lmp_mpi” and the machine always says that it can not find it. I am still wondering where should I put liblammps_mpi.so since I do not have virtual environment and utilize the in-place usage. Choosing the path “/home/andrew/downloads/lammps-7Feb2024//lib” is one of the failed trial.
You are mixing two different things: 1) running LAMMPS from Python, 2) running LAMMPS from the command line.
To do 1) you don’t need 2) to work.
That will only show you whether the Python code is in the right place. To do a proper test, you have to do what I have down as shown in my previous post.
This is not recommended unless you are a developer of the LAMMPS source code. …and even then I would recommend using the CMake based build instead of the GNU make based approach. It has several benefits.
At any rate, it is practically impossible to give detailed step-by-step advice because of the uncertainties of your non-standard setup of your machine.
And just like that, your session is cooked, for multiple reasons:
LD_LIBRARY_PATH is searched from left to right, so appending the correct path does nothing to eliminate the wrong path that’s clearly left over from some shenanigans.
But if you add the correct path to the start of LD_LIBRARY_PATH, the runtime linker will now search that path every time any dynamically-linked executable starts up. This is suboptimal.
If I understand correctly, the runtime linker ignores most or all environment variables if a program is executed across user boundaries. I wonder if this includes compiling a program as root and running it as a regular user …
Do everything again properly: recompile as a regular user, sudo only for make install, and then use ldconfig instead of mucking around with environment variables.