LAPACK Archives

[Lapack] stevx error handling

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




<Prev in Thread] Current Thread [Next in Thread>


For additional information you may use the LAPACK/ScaLAPACK Forum.
Or one of the mailing lists, or