lammps.py no longer working with __init__(name)?

I’m using the latest (git) version of the lammps src, and I’ve been using the ability to specify the library name in creating the lammps() object. This trivial program shows the problem:

tin 1110 : cat t.py
#!/usr/bin/env python

import lammps

lmp = lammps.lammps(name=“tin_comm_self”)

tin 1111 : python t.py
Traceback (most recent call last):
File “/home_radon/bernstei/lib/python/lammps.py”, line 32, in init
else: self.lib = CDLL(join(modpath,"/liblammps_s.so" name),RTLD_GLOBAL)
File “/opt/rh/python27/root/usr/lib64/python2.7/ctypes/init.py”, line 360, in init
self._handle = _dlopen(self._name, mode)
OSError: /liblammps_tin_comm_self.so: cannot open shared object file: No such file or directory
Traceback (most recent call last):
File “t.py”, line 5, in
lmp = lammps.lammps(name=“tin_comm_self”)
File “/home_radon/bernstei/lib/python/lammps.py”, line 36, in init
raise OSError,“Could not load LAMMPS dynamic library”
OSError: Could not load LAMMPS dynamic library

tin 1112 : ls ~/lib/python/lammps.py ~/lib/python/liblammps_tin_comm_self.so
/home_radon/bernstei/lib/python/lammps.py /home_radon/bernstei/lib/python/liblammps_tin_comm_self.so*

As you can see from the error, when looking for a library with a name the module path is not concatenated to the beginning of the .so file name. I think that the “/“ preceding the filename in line 32 of lammps.py is causing the problem, because when I remove it, it seems to work. Must be something about how “join” deals with apparently absolute pathnames?

Noam

I’m using the latest (git) version of the lammps src, and I’ve been using
the ability to specify the library name in creating the lammps() object.
This trivial program shows the problem:

tin 1110 : cat t.py
#!/usr/bin/env python

import lammps

lmp = lammps.lammps(name="tin_comm_self")

tin 1111 : python t.py
Traceback (most recent call last):
  File "/home_radon/bernstei/lib/python/lammps.py", line 32, in __init__
    else: self.lib = CDLL(join(modpath,"/liblammps_s\.so"
name),RTLD_GLOBAL)
  File "/opt/rh/python27/root/usr/lib64/python2.7/ctypes/__init__.py", line
360, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: /liblammps_tin_comm_self.so: cannot open shared object file: No
such file or directory
Traceback (most recent call last):
  File "t.py", line 5, in <module>
    lmp = lammps.lammps(name="tin_comm_self")
  File "/home_radon/bernstei/lib/python/lammps.py", line 36, in __init__
    raise OSError,"Could not load LAMMPS dynamic library"
OSError: Could not load LAMMPS dynamic library

tin 1112 : ls ~/lib/python/lammps.py ~/lib/python/liblammps_tin_comm_self.so
/home_radon/bernstei/lib/python/lammps.py
/home_radon/bernstei/lib/python/liblammps_tin_comm_self.so*

As you can see from the error, when looking for a library with a name the
module path is not concatenated to the beginning of the .so file name. I
think that the “/“ preceding the filename in line 32 of lammps.py is causing
the problem, because when I remove it, it seems to work. Must be something
about how “join” deals with apparently absolute pathnames?

your observation is correct, the '/' needs to be removed. that was an
oversight by me, when i sent steve the update to simplify the
installation and avoid having to set LD_LIBRARY_PATH.

axel.

Thanks. Once I figured out what you did, I was happy with the new behavior. I guess it could wait for someone to request it specifically, but it might useful to fail over to the default CDDL path (i.e. pass it just the library filename, without a full path), if the new default fails to find it.

Noam

your observation is correct, the '/' needs to be removed. that was an
oversight by me, when i sent steve the update to simplify the
installation and avoid having to set LD_LIBRARY_PATH.

Thanks. Once I figured out what you did, I was happy with the new behavior.
I guess it could wait for someone to request it specifically, but it might
useful to fail over to the default CDDL path (i.e. pass it just the library
filename, without a full path), if the new default fails to find it.

not sure if this is always desired. what if dlopen() picks up a DSO
from the wrong location, because LD_LIBRARY_PATH is messed up.
i'd rather have LAMMPS fail directly than have a much more difficult
to debug and track down behavior.

axel.