Hi,

I doubt this helps but (-2,1) is a non-normalized eigenvector of the system.  Maybe your forced LAPACK was doing the wrong operation.

-DG

--
David Garrison, Ph.D.
Associate Professor and Chair of Physics
University of Houston-Clear Lake
Bayou 3531
Houston, TX 77058

Tel: 281-283-3796
Fax: 281-283-3709
http://sce.uhcl.edu/garrison

For more information about the UHCL Physics Program go to http://www.uhcl.edu/physics or sign up for UHCL newsletters at https://ecommunications.houston.edu/uhcl/join.html

"If we knew what it was we were doing, it would not be called research, would it?" - Albert Einstein.



-----Original Message-----
From: users-bounces@einsteintoolkit.org on behalf of Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORECOUNTY]
Sent: Fri 5/27/2011 11:09 AM
To: users@einsteintoolkit.org
Subject: [Possible Spam: 10%] [Users] Cactus-built LAPACK, BLAS giving incorrect results

Hi all. I recently needed to use a LAPACK routine in a Cactus thorn. Since my local machine's installation of LAPACK & BLAS was old, I decided to force an installation by including the thorns "ExternalLibraries/[BLAS,LAPACK]". This seemed to work, with the resulting .a files ending up in configs/<my config name>/scratch/external/LAPACK, etc. Compiling and running my cactus executable, however, I found the LAPACK gave completely wrong results.

For a much simpler test case that (see attached F90 standalone program), consider the 2x2 system A x = b, where A = (3, 2\\2, 6), and b = (5, 8).

Correct result for "x" is (1,1).

Cactus-forced LAPACK (using routine "dgesv") yields (-2,1).

I later installed LAPACK (v. 3.3.0) + BLAS by hand on my machine. Linking against these yields the correct answer.

I'm on a 32-bit Linux machine, using the Intel 10 compilers.

I'd appreciate any insights on this. Thanks,

Bernard