On Sun, Jul 20, 2008 at 8:16 PM, rpmu...@gmail.com rpmu...@gmail.com wrote:

...

When you were installing scipy, do you have umfpack installed? SciPy needs to be compiled with it.

E.g. do you have

/usr/lib/python2.5/site-packages/scipy/linsolve/umfpack/__umfpack.so

? (It should be in some similar path on mac)

I have experience with Debian/Ubuntu and Robert with gentoo. We don't use Mac OS X, but a lot of people on scipy-users do, so they may help as well.

Just installed UMFPack, and rebuild scipy from scratch, but something is going wrong in the build, and, although I have the directory:

$ ls /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ site-packages/scipy/linsolve/umfpack/ __init__.py _umfpack.py info.pyc tests/ __init__.pyc _umfpack.pyc setup.py umfpack.py __umfpack.so info.py setup.pyc umfpack.pyc

For some reason I can't import it:

s886301{rmuller}[1]: import scipy.linsolve.umfpack as um

AttributeError Traceback (most recent call last)

/Users/rmuller/<ipython console> in <module>()

AttributeError: 'module' object has no attribute 'umfpack'

However, I'll pursue this on scipy-users. Thanks for your help.

Hm, could you try:

In [1]: import scipy.linsolve

In [2]: dir(scipy.linsolve) Out[2]: ['NumpyTest', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '_csuperlu', '_dsuperlu', '_ssuperlu', '_superlu', '_zsuperlu', 'asarray', 'factorized', 'isUmfpack', 'isspmatrix', 'isspmatrix_csc', 'isspmatrix_csr', 'linsolve', 'spdiags', 'splu', 'spsolve', 'test', 'umfpack', 'useUmfpack', 'use_solver']

In [3]: scipy.linsolve.isUmfpack Out[3]: True

The umfpack doesn't seem to be imported. See also scipy/linsolve/__init__.py and scipy/linsolve/umfpack/__init__.py

Ondrej

On Jul 21, 3:24 am, Robert Cimrman cimr...@ntc.zcu.cz wrote:

It is an umfpack installation issue, as Ondrej has pointed out.

I have read your messages at scipy-users and it seems that you have some path problems. Do you have any updates on this? What if you manually add the umfpack directory to your sys.path?

r.

Update: I now get the same errors on the Mac and on RHEL4.

I don't know whether they're path features or not. The umfpack libraries are static (.a) rather than dynamic (.so) libraries, which normally means you don't have to worry about path, right?

Thus far I haven't gotten any replies on the scipy lists, so I'm still waiting on both platforms.

Ondrej Certik wrote:

On Mon, Jul 21, 2008 at 7:19 PM, rpmu...@gmail.com rpmu...@gmail.com wrote:

...

On Jul 21, 3:24 am, Robert Cimrman cimr...@ntc.zcu.cz wrote:

...

It is an umfpack installation issue, as Ondrej has pointed out.

I have read your messages at scipy-users and it seems that you have some path problems. Do you have any updates on this? What if you manually add the umfpack directory to your sys.path?

r.

Update: I now get the same errors on the Mac and on RHEL4.

I don't know whether they're path features or not. The umfpack libraries are static (.a) rather than dynamic (.so) libraries, which normally means you don't have to worry about path, right?

On Debian, the umfpack is an .so package: /usr/lib/libumfpack.so.3.1.0

The python extension modules must be dynamic .so libraries. This may be the problem... See http://www.python.org/doc/ext/compilation.html

The umfpack library can be static though, you just have to have something like scipy/sparse/linalg/dsolve/umfpack/__umfpack.so in your scipy installation, i.e. the umfpack wrappers I wrote for scipy, and the .a lib must be linked to it. The exact path depends on your scipy version, the newest is to have umfpack module as a scikit.

Have a look at http://projects.scipy.org/pipermail/scipy-user/2008-February/015500.html See also http://www.scipy.org/Installing_SciPy/Linux, maybe it helps.

...

Thus far I haven't gotten any replies on the scipy lists, so I'm still waiting on both platforms.

I am sorry for these problems. The umfpack is needed though. Doesn't RHEL have a scipy package already build with umpack?

All these things makes me happy I chose Debian for all my computers, it just works.

Same on gentoo.

The problem is that umfpack is the default solver in sfepy, as it can solve any system (symmetric positive definite or completely general, as far as it is not singular) that fits in memory and is very fast.

You can play with the code without it, but the other interfaced solvers (e.g. iterative solvers shipped with SciPy) are not so robust and one usually must do some preconditioning.

For example, a Poisson equation can be solved very fast with

solver_0 = { 'name' : 'ls', 'kind' : 'ls.scipy_iterative',

 'method' : 'cg',
 'i_max'      : 1000,
 'eps_a'      : 1e-12,

}

instead of the default

solver_0 = { 'name' : 'ls', 'kind' : 'ls.umfpack', }

r.

Hi Rick,

Quoting "rpmu...@gmail.com" rpmu...@gmail.com:

Quick update...

Thanks for all the support. I just installed Ubuntu 8.04 on a Parallels virtual machine, and sfepy appears to run out of the box in that configuration. I'm still figuring out what to do now, and I'll start by looking at what Ondrej has already done in schrodinger.py.

But the good news is that I can use sfepy!

Great, just ask if you stumble upon some problems. Ondrej will surely
answer schrodinger.py and physics related ones and I will take care of
the rest.

If you have some updates concerning running sfepy in your original
configuration, tell us - we will put it somewhere on our wiki.

r.