Hi Robert,
2009/7/23 Robert Cimrman cimr...@ntc.zcu.cz: <snip> On my machine (a quad-core 64bit, gentoo), all tests
pass in:
32 test file(s) executed in 41.48 s, 0 failure(s) of 42 test(s)
you should get similar results.
In fact on a dual core ubuntu machine I run all the test in less then a minute.
On fedoracore8 I don't know how slow is but surely more than 20min (I interrupted the tests) that is definitely too much.
It definitely looks like umfpack is not used.
Is possible that is another library that is not used causing the long runtime? For example atlas/lapack?
<snip> >>> To verify umfpack installaion: try to go to sfepy/solvers/ls.py and try >>> in a python shell the imports starting at line 56 - one of them should >>> import umfpack. >> >> The imports you cite are these four: >> >> import scipy.linsolve.umfpack as um >> import scipy.splinalg.dsolve.umfpack as um >> import scipy.sparse.linalg.dsolve.umfpack as um >> import scikits.umfpack as um >> >> the first two fail while the last two succeed. Does this mean that the >> problem lies in the scipy installation, not in the umfpack scikits? > > At least one should succeed, so it's ok - this is just because umfpack > is a moving target depending on scipy version. > > Try to hardcode that umfpack should be used - modify line 77: > if True: > self.sls.use_solver(useUmfpack=True, > assumeSortedIndices=True)
Done, and the tests are still slow...
Now I'm timing the tests and found a segfault after 12 minutes during the test_lcbc_3d.py but only if I run all the tests. On the contrary, if run only the test_lcbc_3d.py test it passes in 6.6 seconds.
A test like test_elasticity_small_strain.py passes but after 9 minutes of running.
Thanks,
~ Antonio