I've just installed Modeller 9v5. I ran the examples in the automodel directory. All of them finished fine with the exception of model-parallel. All of them output an "'import site' failed; use -v for traceback" message though.
mod9v5 model-parallel.py 'import site' failed; use -v for traceback Traceback (most recent call last): File "model-parallel.py", line 4, in ? from modeller.parallel import * File "/usr/people/trippm/bin/modeller9v5/modlib/modeller/parallel/__init__.py", line 1, in ? from job import job File "/usr/people/trippm/bin/modeller9v5/modlib/modeller/parallel/job.py", line 1, in ? import socket, random, os, select
Is this because something is missing in my python libraries?
thanks!
Mauricio Carrillo Tripp wrote: > I've just installed Modeller 9v5. I ran the examples in the automodel > directory. All of them finished fine with the exception of model-parallel. > All of them output an "'import site' failed; use -v for traceback" message > though.
See http://salilab.org/modeller/release.html#issues for your "import site failed" warning.
model-parallel failed because it requires the Python standard library.
Both of these issues have the same solution - don't use the mod9v5 script to run Modeller, but use "python" directly instead. See the install instructions at that URL for more information.
Ben Webb, Modeller Caretaker
This must be a dumb error from my part, but I followed directions to run the scripts and now I'm getting a different error on all scripts. Here's the
output:
/modeller9v5/bin/modpy.sh python model-parallel.py Traceback (most recent call last): File "model-parallel.py", line 2, in ? from modeller import * File "/usr/people/trippm/bin/modeller9v5/modlib/modeller/__init__.py", line 59, in ? import _modeller ImportError: /usr/people/trippm/bin/modeller9v5/lib/x86_64-intel8/libmodeller.so.4: undefined symbol: __svml_cosf4
> python Python 2.3.4 (#1, Oct 13 2006, 15:53:00) [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2
Same happens if I declare ENV Variables first: export -p PYTHONHOME=/usr/lib64/python2.3/ export MODINSTALL9v5=/modeller9v5 export EXECUTABLE_TYPE9v5=x86_64-intel8 export -p LIBS_LIB9v5=${MODINSTALL9v5}/modlib/libs.lib export KEY_MODELLER9v5=**** export -p PATH=${PATH}:${MODINSTALL9v5}/bin
On Thu, Dec 4, 2008 at 11:37 AM, Modeller Caretaker < modeller-care@salilab.org> wrote:
> Mauricio Carrillo Tripp wrote: > > I've just installed Modeller 9v5. I ran the examples in the automodel > > directory. All of them finished fine with the exception of > model-parallel. > > All of them output an "'import site' failed; use -v for traceback" > message > > though. > > See http://salilab.org/modeller/release.html#issues for your "import > site failed" warning. > > model-parallel failed because it requires the Python standard library. > > Both of these issues have the same solution - don't use the mod9v5 > script to run Modeller, but use "python" directly instead. See the > install instructions at that URL for more information. > > Ben Webb, Modeller Caretaker > -- > modeller-care@salilab.org http://www.salilab.org/modeller/ > Modeller mail list: http://salilab.org/mailman/listinfo/modeller_usage >
Mauricio Carrillo Tripp wrote: > This must be a dumb error from my part, but I followed directions to run > the scripts and now I'm getting a different error on all scripts. Here's > the output: ... > ImportError: > /usr/people/trippm/bin/modeller9v5/lib/x86_64-intel8/libmodeller.so.4: > undefined symbol: __svml_cosf4
Interesting - that symbol is part of the Intel runtime (libsvml.so). There should be a copy of that library in the same directory as libmodeller.so.4. Do you perhaps have the LD_LIBRARY_PATH variable set? If so, perhaps there is another libsvml.so library in that path (that will take precedence over the copy bundled with Modeller). Maybe you have the Intel C or Fortran compilers installed on your computer? If so, you should either unset the LD_LIBRARY_PATH variable when running Modeller with Python, or take the paths containing libsvml.so out of that variable and put them in /etc/ld.so.conf instead.
Ben Webb, Modeller Caretaker
You where right, I unset the LD_LIBRARY_PATH variable and the error went away. libsvml.so is indeed in the same location as libmodeller.so.4 However, it took me back to the initial problem:
export -p LD_LIBRARY_PATH= export -p PYTHONHOME=/usr/lib64/python2.3/ export MODINSTALL9v5=/****/modeller9v5 export EXECUTABLE_TYPE9v5=x86_64-intel8 export -p LIBS_LIB9v5=${MODINSTALL9v5}/modlib/libs.lib export KEY_MODELLER9v5=**** export -p PATH=${PATH}:${MODINSTALL9v5}/bin ## limit stacksize unlimited
echo "Running model-fast.py" Running model-fast.py modpy.sh python model-fast.py > model-fast.log 'import site' failed; use -v for traceback
echo "Running model-parallel.py" Running model-parallel.py modpy.sh python model-parallel.py > model-parallel.log 'import site' failed; use -v for traceback Traceback (most recent call last): File "model-parallel.py", line 4, in ? from modeller.parallel import * File "/****/modeller9v5/modlib/modeller/parallel/__init__.py", line 1, in ? from job import job File "/****/modeller9v5/modlib/modeller/parallel/job.py", line 1, in ? import socket, random, os, select ImportError: No module named socket
On Thu, Dec 4, 2008 at 5:23 PM, Modeller Caretaker < modeller-care@salilab.org> wrote:
> Mauricio Carrillo Tripp wrote: > > This must be a dumb error from my part, but I followed directions to run > > the scripts and now I'm getting a different error on all scripts. Here's > > the output: > ... > > ImportError: > > /usr/people/trippm/bin/modeller9v5/lib/x86_64-intel8/libmodeller.so.4: > > undefined symbol: __svml_cosf4 > > Interesting - that symbol is part of the Intel runtime (libsvml.so). > There should be a copy of that library in the same directory as > libmodeller.so.4. Do you perhaps have the LD_LIBRARY_PATH variable set? > If so, perhaps there is another libsvml.so library in that path (that > will take precedence over the copy bundled with Modeller). Maybe you > have the Intel C or Fortran compilers installed on your computer? If so, > you should either unset the LD_LIBRARY_PATH variable when running > Modeller with Python, or take the paths containing libsvml.so out of > that variable and put them in /etc/ld.so.conf instead. > > Ben Webb, Modeller Caretaker > -- > modeller-care@salilab.org http://www.salilab.org/modeller/ > Modeller mail list: http://salilab.org/mailman/listinfo/modeller_usage >
Mauricio Carrillo Tripp wrote: > You where right, I unset the LD_LIBRARY_PATH variable and the error went > away. > libsvml.so is indeed in the same location as libmodeller.so.4 > However, it took me back to the initial problem: > > export -p LD_LIBRARY_PATH= > export -p PYTHONHOME=/usr/lib64/python2.3/ > export MODINSTALL9v5=/****/modeller9v5 > export EXECUTABLE_TYPE9v5=x86_64-intel8 > export -p LIBS_LIB9v5=${MODINSTALL9v5}/modlib/libs.lib > export KEY_MODELLER9v5=**** > export -p PATH=${PATH}:${MODINSTALL9v5}/bin > ## limit stacksize unlimited
This problem is most likely caused by your setting PYTHONHOME. You don't actually need to set *any* of the environment variables you have above (except PATH, I guess, unless you want to put in the full path to modpy.sh) - clear them all and the problem should go away.
BTW, there is also no need to set any of these variables to run the mod9v5 script - it sets them itself anyway. Maybe you are reading a very old version of the Modeller documentation? We certainly don't recommend setting any environment variables these days.
Ben Webb, Modeller Caretaker
Thanks for your help. Actually that's another question I had you just answered!. I have removed all env variables. I'm getting a new error now though, and to me it looks like I have an incomplete installation of python2.3, but I could be wrong...
#!/bin/bash -v
export -p LD_LIBRARY_PATH= export -p PATH=${PATH}:/usr/people/trippm/bin/modeller9v5/bin ## limit stacksize unlimited
echo "Running model-fast.py" Running model-fast.py modpy.sh python model-fast.py > model-fast.log
echo "Running model-parallel.py" Running model-parallel.py modpy.sh python model-parallel.py > model-parallel.log Traceback (most recent call last): File "model-parallel.py", line 4, in ? from modeller.parallel import * File "/usr/people/trippm/bin/modeller9v5/modlib/modeller/parallel/__init__.py", line 1, in ? from job import job File "/usr/people/trippm/bin/modeller9v5/modlib/modeller/parallel/job.py", line 1, in ? import socket, random, os, select File "/usr/lib64/python2.3/random.py", line 42, in ? from math import log as _log, exp as _exp, pi as _pi, e as _e ImportError: /usr/lib64/python2.3/lib-dynload/math.so: undefined symbol: PyFPE_jbuf
On Fri, Dec 5, 2008 at 12:56 PM, Modeller Caretaker < modeller-care@salilab.org> wrote:
> Mauricio Carrillo Tripp wrote: > > You where right, I unset the LD_LIBRARY_PATH variable and the error went > > away. > > libsvml.so is indeed in the same location as libmodeller.so.4 > > However, it took me back to the initial problem: > > > > export -p LD_LIBRARY_PATH= > > export -p PYTHONHOME=/usr/lib64/python2.3/ > > export MODINSTALL9v5=/****/modeller9v5 > > export EXECUTABLE_TYPE9v5=x86_64-intel8 > > export -p LIBS_LIB9v5=${MODINSTALL9v5}/modlib/libs.lib > > export KEY_MODELLER9v5=**** > > export -p PATH=${PATH}:${MODINSTALL9v5}/bin > > ## limit stacksize unlimited > > This problem is most likely caused by your setting PYTHONHOME. You don't > actually need to set *any* of the environment variables you have above > (except PATH, I guess, unless you want to put in the full path to > modpy.sh) - clear them all and the problem should go away. > > BTW, there is also no need to set any of these variables to run the > mod9v5 script - it sets them itself anyway. Maybe you are reading a very > old version of the Modeller documentation? We certainly don't recommend > setting any environment variables these days. > > Ben Webb, Modeller Caretaker > -- > modeller-care@salilab.org http://www.salilab.org/modeller/ > Modeller mail list: http://salilab.org/mailman/listinfo/modeller_usage >
Mauricio Carrillo Tripp wrote: > I'm getting a new error now though, and to me it looks like I have an > incomplete installation of python2.3, > but I could be wrong... ... > File "/usr/lib64/python2.3/random.py", line 42, in ? > from math import log as _log, exp as _exp, pi as _pi, e as _e > ImportError: /usr/lib64/python2.3/lib-dynload/math.so: undefined symbol: > PyFPE_jbuf
That's an odd one - my searches suggest that it's a version mismatch somewhere - are you sure that math.so and your Python interpreter are the same version? To be absolutely sure it's not some odd conflict with Modeller, you could just run "python" by itself (no modpy.sh prefix) and then type "import math" at the >>> prompt. "python" also reports its version number when it starts. (Then try the same thing *with* the modpy.sh prefix.) The error message shows you're using Python 2.3 modules - check to make sure the interpreter is also reporting it's 2.3. If there's a mismatch, perhaps you still have the PYTHONHOME variable set.
Ben Webb, Modeller Caretaker
It seems you're on the right track, but still I have no clue why modpy.sh /usr/bin/python is using /usr/lib64/python2.3/lib-dynload/math.so if all env variables seem to be pointing to the modeller install only, or is that even the problem? (I added echoes to modpy.sh):
> ls $PYTHONHOME PYTHONHOME: Undefined variable.
> /usr/bin/python Python 2.3.4 (#1, Oct 13 2006, 15:53:00) [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>>
>modpy.sh /usr/bin/python LD_LIBRARY_PATH /gremlin/people/trippm/modeller9v5/lib/x86_64-intel8 DYLD_LIBRARY_PATH /gremlin/people/trippm/modeller9v5/lib/x86_64-intel8 PYTHONPATH /gremlin/people/trippm/modeller9v5/lib/x86_64-intel8:/gremlin/people/trippm/modeller9v5/modlib LIBPATH /gremlin/people/trippm/modeller9v5/lib/x86_64-intel8 ORIGPYPATH Python 2.3.4 (#1, Feb 15 2006, 18:08:24) [GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: /usr/lib64/python2.3/lib-dynload/math.so: undefined symbol: PyFPE_jbuf >>>
On Mon, Dec 8, 2008 at 9:09 AM, Modeller Caretaker < modeller-care@salilab.org> wrote:
> Mauricio Carrillo Tripp wrote: > > I'm getting a new error now though, and to me it looks like I have an > > incomplete installation of python2.3, > > but I could be wrong... > ... > > File "/usr/lib64/python2.3/random.py", line 42, in ? > > from math import log as _log, exp as _exp, pi as _pi, e as _e > > ImportError: /usr/lib64/python2.3/lib-dynload/math.so: undefined symbol: > > PyFPE_jbuf > > That's an odd one - my searches suggest that it's a version mismatch > somewhere - are you sure that math.so and your Python interpreter are > the same version? To be absolutely sure it's not some odd conflict with > Modeller, you could just run "python" by itself (no modpy.sh prefix) and > then type "import math" at the >>> prompt. "python" also reports its > version number when it starts. (Then try the same thing *with* the > modpy.sh prefix.) The error message shows you're using Python 2.3 > modules - check to make sure the interpreter is also reporting it's 2.3. > If there's a mismatch, perhaps you still have the PYTHONHOME variable set. > > Ben Webb, Modeller Caretaker > -- > modeller-care@salilab.org http://www.salilab.org/modeller/ > Modeller mail list: http://salilab.org/mailman/listinfo/modeller_usage >
Mauricio Carrillo Tripp wrote: > It seems you're on the right track, but still I have no clue why > modpy.sh /usr/bin/python is using /usr/lib64/python2.3/lib-dynload/math.so > if all env variables seem to be pointing to the modeller install only, > or is that even the problem? (I added echoes to modpy.sh):
No, that's what it's supposed to be doing. Modeller isn't supposed to "break" your regular Python (it just adds its own Python modules to the search path by setting PYTHONPATH), so you should be loading /usr/lib64/python2.3/lib-dynload/math.so in both cases.
>> ls $PYTHONHOME > PYTHONHOME: Undefined variable.
That's good. You should generally *not* set PYTHONHOME, because that also changes the location where Python looks for standard packages. So changing that will often break all sorts of things.
>> /usr/bin/python > Python 2.3.4 (#1, Oct 13 2006, 15:53:00) > [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> import math
Hmm, so it works fine, but simply adding the Modeller modules to the path breaks it. That's very odd, and I can't explain why it only happens here and not with the 'mod9v5' script. But every hit I can find regarding this problem says that it's a Python 2.2/2.3 issue, so one possible solution would be to upgrade Python on your machine. Modeller will also work with the newer Python 2.4 or 2.5.
>>modpy.sh /usr/bin/python > LD_LIBRARY_PATH /gremlin/people/trippm/modeller9v5/lib/x86_64-intel8 > DYLD_LIBRARY_PATH /gremlin/people/trippm/modeller9v5/lib/x86_64-intel8 > PYTHONPATH > /gremlin/people/trippm/modeller9v5/lib/x86_64-intel8:/gremlin/people/trippm/modeller9v5/modlib > LIBPATH /gremlin/people/trippm/modeller9v5/lib/x86_64-intel8 > ORIGPYPATH
Right, these look fine. The modpy.sh script simply adds the Modeller Python libraries to PYTHONPATH (binary files in the lib/x86_64-intel8/ directory; pure Python code in modlib/) and the underlying low-level dynamic libraries to the search path (LD_LIBRARY_PATH). (It also sets DYLD_LIBRARY_PATH and LIBPATH to the same thing so that it also works on Macs and AIX.)
Ben Webb, Modeller Caretaker
participants (2)
-
Mauricio Carrillo Tripp -
Modeller Caretaker