I'm not sure if I got my point across. My point was that the ATLAS
installation that numpy linked against was broken on Mac OS X but not on
Linux (afaik). Hence, your code may run better on your supercomputer. So,
try linking against a different BLAS/LAPACK implementation, and, with some
luck, your
As Paul suggested I'd try compiling numpy with something other than the
BLAS/LAPACK libraries currently in use. Here is a good place to start:
http://www.scipy.org/Installing_SciPy/Linux.
Charanpal
On Thu, 1 Sep 2011 12:20:46 -0600, Rick Muller wrote:
> Yes, as I pointed out, the problem does ru
Yes, as I pointed out, the problem does run on the Macintosh systems. But
I'd like to be able to run these on our linux supercomputers. Surely this is
possible, right?
On Mon, Aug 29, 2011 at 9:31 AM, Paul Anton Letnes <
paul.anton.let...@gmail.com> wrote:
> I recently got into trouble with these
I recently got into trouble with these calculations (although I used scipy). I
actually got segfaults and "bus errors". The solution for me was to not link
against ATLAS, but rather link against Apple's blas/lapack libraries. That got
everything working again. I would suggest trying to install a
I posted a similar question about the non-convergence of
numpy.linalg.svd a few weeks ago. I'm not sure I can help but I wonder
if you compiled numpy with ATLAS/MKL support (try numpy.show_config())
and whether it made a difference? Also what is the condition number and
Frobenius norm of the ma
I'm bumping into the old "Eigenvalues did not converge" error using
numpy.linalg.eigh() on several different linux builds of numpy (1.4.1). The
matrix is 166x166. I can compute the eigenvalues on a Macintosh build of
numpy, and I can confirm that there aren't degenerate eigenvalues, and that
the ma
