Hi, thanks for your answer!
On Fri, 12 Mar 2010, James Demmel wrote:
(1) can you supply the input matrix that caused the problem?
I'm afraid that may not be possible. The thing is that when the original
bug report was made, I had made an effort to get the problem nicely
reproducable, and I had traced it all the way inside the stevx routine and
to the info=0 returned from stebz. But since then I changed computer and I
had forgotten about this issue and the files I had with the specific case
causing this problem have been lost.
As I remember it the problem happened for some rare case and it took a
while to figure out what went wrong. It was one of those difficult
cases when the program works fine *almost* always but then some
strange circumstances make this problem appear.
Right now I changed back to using
stevx in my code and I'm running some tests to see if I can reproduce the
problem, but I doubt it because I think it was really happening very
rarely.
(2) what are the input flags (whether you just wanted part of the
spectrum, accuracy tolerance, etc.)
Again, I'm sad to say this information has been lost. All I know is that I
used the values "V" and "I" for the first two parameters.
(3) can you say what computing platform/compiler/compiler flags you used?
If I remember correctly I was able to reproduce the problem on my local
computer after it first appeared on a remote machine. The local machine I
think was an Intel Xeon where I compiled with gcc. The other machine I'm
not sure about, possibly that was also some Intel architecture. I don't
think I was using any fancy compiler options (no extra-fast-sloppy math
routines or such) but I don't know exactly.
My guess is that the particular matrix that happened to appear in my
calculation had some property that made DSTEBZ go wrong, and that it was
not due to any extreme/dangerous compiler options since I could reproduce
in different ways.
In the short run, I suggest you use a different LAPACK routine, DSTEVR, which
is supposed to be faster and generally more accurate than DSTEVX. If you
have trouble with it too, we'd like to hear about it.
Okay. Thanks for the tip about DSTEVR.
Sorry I could not answer better. I'll get back to you if I manage to
reproduce the problem again.
Best regards,
Elias
Thanks,
Jim Demmel
Elias Rudberg wrote:
Hello!
Have you had time to look at this issue yet?
As far as I can tell, the bug is still there in lapack version 3.2.1.
This is important for me because it severely affects the performance of my
code. I have a workaround to avoid the stevx bug but that makes my program
much slower. Please help!
/ Elias
On Sun, 1 Jul 2007, Julien Langou wrote:
Hello,
Do you agree that this is a problem?
this looks like a serious problem, you are right.
[lapackers: I can have a look in two weeks for myself.]
Thanks for reporting the problem,
Best wishes, Julien.
On Fri, 29 Jun 2007, Elias Rudberg wrote:
Hello!
I have some troubles with the dstevx LAPACK routine; it sometimes
returns
wrong results, while the "info" variable is zero which should mean
success.
I think the problem originates somewhere deep down in the routines
called
internally by stevx, but in the stevx code itself there is anyway a
problem with error handling: the routine should not return with
info=0 if
problems were encountered. Part of the stevx code looks like this:
CALL DSTEBZ( RANGE, ORDER, N, VLL, VUU, IL, IU, ABSTOL, D, E, M,
$ NSPLIT, W, IWORK( INDIBL ), IWORK( INDISP ),
$ WORK( INDWRK ), IWORK( INDIWO ), INFO )
*
IF( WANTZ ) THEN
CALL DSTEIN( N, D, E, M, W, IWORK( INDIBL ), IWORK( INDISP
),
$ Z, LDZ, WORK( INDWRK ), IWORK( INDIWO ), IFAIL,
$ INFO )
END IF
Here, if the call to DSTEBZ fails, an error code != 0 is placed in
INFO.
However, that error code is ignored and the program proceeds to call
DSTEIN regardless. DSTEIN will then overwrite the error code from
DSTEBZ
so the information that something was wrong is lost.
Do you agree that this is a problem?
Best regards
Elias
-----------------------------
Elias Rudberg
elias@Domain.Removed
Department of Theoretical Chemistry
Royal Institute of Technology
S-106 91 Stockholm, Sweden
----------------------------
_______________________________________________
Lapack mailing list
Lapack@Domain.Removed
http://lists.cs.utk.edu/listinfo/lapack
_______________________________________________
Lapack mailing list
Lapack@Domain.Removed
http://lists.eecs.utk.edu/mailman/listinfo/lapack
|