Glad to hear that LAPACK served you well for six years.
I suspect N=20,000 (about) is the limit for our Divide and Conquer
interface unfortunately. This needs some more investigation. There is
a related post at:
And this is bug report #0020 at
If you do a worspace query (LWORK=-1) what is the workspace needed? (
WORK(1) ). Is this value not above the integer overflow (2^31)? So that
when you feed it to the 32-bit integer LWORK for the real run actually it
does not work. I do not quite get it. Because that should not be the case
Another possible problem is that it is not clear that WORK(1) (double
precision) convert correctly to LWORK (integer), you might be missing a
"one". If you do a workspace query can you try LWORK = LWORK + 1 (and
allocate with this plus one!).
I am positive that you can not use dpsevd for matrices bigger than 46,000
(sqrt(2^31)). LAPACK should be using 64-bit integer for this.
(There is another limitation from packed format itself but it will hit us
later at N=2^16=65,536.)
Please keep in touch, to summarize, you can:
* check that the value LWORK before calling LAPACK "makes some sense" by
* add +1 to the LWORK before allocating the workspace
Yes, yes, 64-bit integers in LAPACK ...
On Sat, 13 Feb 2010, Carolina Brito wrote:
I have been using CLAPACK in the past 6 years to diagonalize matrices up to
size 2000 x 2000 and I did not have any problem.
I am currently? using the routine? dspevd_()
I now want to diagonalize a matrix of size 20000 x 20000 and the routine
returns "segmentation fault".
I would like to know if there is a limit of size that this routine can
diagonalize of if this is a limitation of my computer (memory problems). This
important because I do not know if I should keep tying to use CLAPACK or if
it has some limitation that would not allow me to diagonalize such a big
Thanks a lot.
Veja quais s?o os assuntos do momento no Yahoo! + Buscados: Top 10 -
Celebridades - M?sica - Esportes