LAPACK 2.0 and 3.0 differences

[Desargues]

I am running ARPACK to diagonalize matrices. ARPACK is packaged with LAPACK 2.0 which is the current bottleneck in the program. I would like to be able to use a modern and ultimately threaded version of LAPACK. I have tried LAPACK 3.4 and 3.0, but the results are not the same. Modern BLAS works fine.

It's a long shot, but is there any way to find out what has changed since 2.0?

The eigenvalue results that I get are not completely wrong, so the change is probably subtle, perhaps a slightly altered mathematical definition? Aside from this, I have no further insight.

Thanks

[admin]

Which LAPACK / ARPACK routines are you actually calling?

eigenvalue results that I get are not completely wrong

How do you define "not completely wrong"?
Best is not to compare results digit to digit but to test the correctness of the result.

[Julien Langou]

Hello,

This is a reasonable request. So you are asking for moving ARPACK from using LAPACK 2.0 to LAPACK 3.0. Well I think it should be done.

(We have maintained backward compatibility since 3.0, so if 3.0 works, 3.4 should ... reciprocally if 3.0 does not work, 3.4 should not ...)

I am not sure when we will have time to work on this on our end. I can have a quick look over the week-end.

The LAPACK 2.0 files needed by ARPACK are included in the ARPACK tar ball so this is the one you want to use for now.

And yes it might be a pain to link these files if you use another third party library that uses LAPACK 3.0 on the other hand ...
So this is one reason to try to move ARPACK to LAPACK 3.0. Another one is that
we made quite a few improvement in LAPACK since 2.0 and ARPACK users' would benefit from the change.
LAPACK 3.4 should be substantially faster than 2.0.

Cheers,
Julien.

[Desargues]

Which LAPACK / ARPACK routines are you actually calling?

eigenvalue results that I get are not completely wrong

How do you define "not completely wrong"?
Best is not to compare results digit to digit but to test the correctness of the result.

ARPACK outputs three columns of data. Real part of ev, imaginary part of ev and estimated residuals (errors). On a successful run, the residuals should be on the order of 10^-14 to 10^-15, which is as I have specified. This is achieved with LAPACK 2.0.

Modern LAPACK versions result in some eigenvalues which are the same as my bench case, but some eigenvalues are skipped or are different. The residuals of some eigenvalues are not within the specified criterian (the program should not stop running until the eigenvalues have converged to the residue criteria, or should exit with an error).

Thanks for the responses.

[Desargues]

The difference between 3.0 and 2.0 are bug fixes and a few
new functions that compute faster than the older functions
(like divide and conquer SVD). Note: no functions have been
deleted (though some of the aux functions were consolidated),
so the interface to LAPACK has been extended, but should
still be backward compatable.

Something is definitely not quite right. In some instances, Lapack 3.4 gives substantially different answers than 2.0.
In the test case that I ran, Arpack with lapack 2.0 matched the full diagonalization results from matlab and arpack with lapack 3.4 was substantially off.

This seems to be a problem in non-symmetric and complex matrix routines. The symmetric examples work fine with both versions of lapack.

[Desargues]

I worked my way through the double precision non-symmetric matrix routine and I believe that dlahqr.f is the only problem. A rough, but effective workaround is to simply rename the subroutine dlahqr to something else, replace all of the calls in the ARPACK code and include this code into the source code for ARPACK. This allows the compilation of ARPACK without BLAS or LAPACK, so that optimized libraries can be used. I have tested this with LAPACK 3.4.0 and parallel acml, both of which resulted in eigenvalues which were within machine precision of the original. I still have to test whether the eigenvectors come out properly.

I have been comparing LAPACK 3.0 to 2.0 and the only thing that has seemed to change in dlahqr is the addition of "Francis' double shift". I have no idea what this actually means, or what the implications are for ARPACK. Was dlahqr meant only to be used as a standalone subroutine?

[Julien Langou]

Hi Callen,

Thanks a lot for going through the hassle of finding which LAPACK routines needed to be 2.0 and which could be 3.x.

So you downed it to one file: xLAHQR. (Or four depends on how you count: s,d,c,z.) Great. Thanks! And a quick fix
as you suggest is to rename xLAHQR-2.0 as xLAHQR20 (say), add xLAHQR20 in the ARPACK package, and make sure
ARPACK calls xLAHQR20 (as opposed to xLAHR). Easy enough and actually that's a pretty good fix.

As you mentioned, there were some changes made from 3.0 to 3.1 in xLAHQR, the changes are pretty major and basically
the algorithm in 3.1 is way better than the one in 3.0. The changes came from late Ralf Byers. It incorporates (1) small
bulge multi-shift QR algorithm (2) together with aggressive early deflation. However there was no change in interface.
The algorithm is simply faster but should not alter the semantic of the interface.

It would be nice if ARPACK could use the new xLAHQR so we will look into that. I am in contact with a former ARPACK
developer so we plan on working on this. I think ARPACK is using some "hidden" features of xLAHQR-2.0 which are not in
xLAHQR-3.0. By "hidden features" I mean properties which were respected by the the 2.0 subroutine but were not part of
the interface per se. So the change from 2.0 to 3.0 was legit. But this broke the ARPACK compatibility. It might get tricky,
but we would like to fix this. It would be nicer to be able to use the xLAHQR-3.1 from ARPACK.

Cheers,
Julien.

[jrodrig]

I just experienced the same exact problem! In my case, it was only revealed at very large DxD complex Hermitian matrices with D = 300,540,195 . My bottleneck is the matrix transformation, new vector = matrix * old vector , which I accelerate with OpenMP. I'm therefore happy to use the LAPACK version 2 that ARPACK supplies.
Jose Rodriguez, L.A.