bugGNU Octave - Bugs: bug #41305, eigs: error -14 in dneupd when...

 
 

bug #41305: eigs: error -14 in dneupd when requesting fewer eigenvalues

Submitter:  None
Submitted:  Wed 22 Jan 2014 02:16:49 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Max Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 02 Dec 2017 11:35:42 AM UTC, comment #21: 

-14 in XYeupd is "did not find any eigenvalues to sufficient accuracy". It is just non-convergence with the given parameters. The error message comes from eigs-base.cc, so it can be modified. I do not think (anymore) it is a bug in arpack, but rather a possible defect in the "implicitely restarted Arnoldi method". We could change the error message to something like: "It was not possibile to find any eigenvalues to sufficient accuracy. Try to increase the tolerance, the maximum number of iterations, or the number of requested eigenvalues".

Marco Caliari <caliari>
Group Member
Tue 11 Apr 2017 02:40:09 PM UTC, comment #20: 

I checked with 4.2.0 the sweepseed test in comment #17 and I confirm the results (about 2% failures with both Octave and Matlab). I also think this is an issue in Arpack:

If possible, it is best to avoid setting nev (k in Octave) in a way that will split clusters of eigenvalues. [ARPACK Users' Guide, p.16]

A workaround could be to set k at least to 6 (which is the default value) and to return the desired number of eigenvalues. I worked on something similar in #45153, it should be not that difficult to implement.

Marco Caliari <caliari>
Group Member
Tue 28 Jan 2014 12:32:42 PM UTC, comment #19: 

Sorry I have to moderate one of my comments :

Arpack routines return the number of converged eigen values and a warning is emited by octave if it is not equal to the actual number of requested ones. So it seems the convergence criterion is applied on a per value basis (so I was completely wrong, I should learn to avoid guesses).

In this example:

>There are cases, where  eigs(M,1,'LM')  fails, but eigs(M,6,'LM')  successfully returns.


we see no warning when requesting 6 values instead of one , so it looks like Arpack satisfactorily converged for all individual values and it should be able to return one value.

Finally the above mentioned behavior, plus the fact that matlab has the same issue, make me think that there is indeed a bug in Arpack, not in octave.

There is an obvious workaround for octave users: ask for more values than needed when the error appears.


Pantxo Diribarne <pantxo>
Group Member
Mon 27 Jan 2014 10:42:17 PM UTC, comment #18: 

Sorry Max, I totally missed the important part of your comment #13, and indeed that I was able to confirm earlier now that I review the whole history here.

I honestly don't know enough about what's going on under the hood here, but going back to my comment #1, I show that eigs can fail to return 1 or 2 eigenvalues with a given matrix, but successfully returns 3. This does seem like a bug to me.

I'll open a separate report for better error reporting.

Mike Miller <mtmiller>
Group Member
Mon 27 Jan 2014 10:41:34 PM UTC, comment #17: 

Sorry, I may have been a bit to fast here, you are right. However, here are the reasons that make me think octave does the right thing:

1 - I you care enough to see if it's a bug from  octave, you may want to check _eigs_.cc and eig-base.cc. The number k of requested eigen values is directly (this should be double checked) passed to xnaupd arpack functions. From this quick browse, I'd say if there is a bug it is in arpack.

2 - I tested the attached modified sweepseed.m in matlab and octave 3.8 using


nval = 1;
failed = sweepseed (1:600, nval);
sum (failed)/600

And for this particular set of seeds I see about 1-2% failures in both  matlab and octave (and with the same error).


>There are cases, where  eigs(M,1,'LM')  fails, but eigs(M,6,'LM')  successfully returns.


3 - Wild guess: the convergence criterion (based on opt.tol) may well not be satisfied for one large eigen value, and satisfied for 6 smaller in average values (e.g. if the criterion is a simple algebraic mean error). Anyway matlab behaves the same: for a failing seed if I increase nval, the error disappears.

>Also, failure seem to be version dependent, as comment 2 states.


If you add comment 1 you'll see that the error is not simply octave version dependent, it may be machine/architecture  dependent also.


(file #30393)

Pantxo Diribarne <pantxo>
Group Member
Mon 27 Jan 2014 07:01:17 PM UTC, comment #16: 

I'm very sorry, but I totally disagree with all renaming, assigning as feature request and the pursued solution.

There are cases, where +verbatim+ eigs(M,1,'LM') -verbatim- fails, but +verbatim+ eigs(M,6,'LM') -verbatim- successfully returns.
Also, failure seem to be version dependend, as comment 2 states.

That cannot be handled by extended error messages, albeit they were great. That is a plain inconsistent behaviour, that has to be fixed!

Max Görner <maxg>
Mon 27 Jan 2014 02:35:04 PM UTC, comment #15: 

Retitled and assigned as a feature request.

Mike Miller <mtmiller>
Group Member
Mon 27 Jan 2014 12:49:07 PM UTC, comment #14: 

This report could now be retitled, e.g. 'turn arpack error codes into strings' as Mike suggested.

Pantxo Diribarne <pantxo>
Group Member
Mon 27 Jan 2014 12:36:31 PM UTC, comment #13: 

I reinstalled Octave. Now the very odd behaviour is gone. I'm very sorry.

All what remains is that there are calls to eigs which fail if one requests to few eigenvalues, as reported by me and in comment 1.

Max Görner <maxg>
Thu 23 Jan 2014 01:43:39 PM UTC, comment #12: 

I could check that, for me, the failure is deterministic: by varying the opt.tol  parameter I could define the threshold tolerance t_tol for a particular seed (137 on octave 3.6.4).

The probability of failure (computed over 100 trials) is either 0 with "opt.tol = t_tol + eps/2" or 1 with "opt.tol = t_tol - eps/2".




Pantxo Diribarne <pantxo>
Group Member
Thu 23 Jan 2014 10:52:19 AM UTC, comment #11: 

I did so. The Matrices are identical. But it's getting even more weird.

Error occurs 1 time:

$ octave -q
warning: function /usr/share/octave/packages/statistics-1.2.0/fstat.m shadows a core library function
octave:1> for it = 136:139
> rand('state',it);
> W = rand(200);
> W(W < 0.9) = 0;
> W(W != 0) = rand(size(W(W != 0))) - 0.5;
> eigs(W,1,'LM');
> endfor
error: eigs: error -14 in dneupd
octave:1>
octave:1> w1 = W;
octave:2> rand('state',it); W = rand(200); W(W < 0.9) = 0; W(W != 0) = rand(size(W(W != 0))) - 0.5; eigs(W,1,'LM');
octave:3> all(all(w1 == W))
ans =  1


Error occurs 2 times:

$ octave -q
warning: function /usr/share/octave/packages/statistics-1.2.0/fstat.m shadows a core library function
octave:1> for it = 136:139
> rand('state',it);
> W = rand(200);
> W(W < 0.9) = 0;
> W(W != 0) = rand(size(W(W != 0))) - 0.5;
> eigs(W,1,'LM');
> endfor
error: eigs: error -14 in dneupd
octave:1>
octave:1> w1 = W;
octave:2>
octave:2> rand('state',it);
octave:3> W = rand(200);
octave:4> W(W < 0.9) = 0;
octave:5> W(W != 0) = rand(size(W(W != 0))) - 0.5;
octave:6> eigs(W,1,'LM');
error: eigs: error -14 in dneupd
octave:6>
octave:6> all(all (W == w1))
ans =  1


Please note that both versions differ just in the amount of newlines.

Since some can't reproduce my results:
I use vanilla XUbuntu 13.10 as 32bit version. I installed Octave, octave-signal and octave-statistics from the standard repositories.

Max Görner <maxg>
Thu 23 Jan 2014 10:15:10 AM UTC, comment #10: 

I forgot to say the last reported issue may not be related to the OP's issue but rather to the random number generation inaccuracy.

Max, can you check that the random sparse matrix is the consistent e.g. using the following ?


for it = 136:139
rand('state',it);
W = rand(200);
W(W < 0.9) = 0;
W(W != 0) = rand(size(W(W != 0))) - 0.5;
eigs(W,1,'LM');
endfor

w1 = W;

rand('state',it);
W = rand(200);
W(W < 0.9) = 0;
W(W != 0) = rand(size(W(W != 0))) - 0.5;
eigs(W,1,'LM');

all (W == w1)


Pantxo Diribarne <pantxo>
Group Member
Thu 23 Jan 2014 09:51:50 AM UTC, comment #9: 

I can't reproduce this behavior neither on 3.6.4 (from fink) nor on 3.8.0 : a particular seed fails reliably but failing seeds may not be the same in 3.6.4 and 3.8.0.

I used the attached testeig.m for the test and I also tried manually at the prompt.



(file #30352)

Pantxo Diribarne <pantxo>
Group Member
Thu 23 Jan 2014 08:16:03 AM UTC, comment #8: 

I'm amazed about the reception this bug has found here.

Unfortunately, I don't see this beeing resolved by a mere errno2string-function.

The behaviour of eigs is quite weird, as I try to demonstrate in the command line excerpt:

max@xmscusb:~$ octave -q
warning: function /usr/share/octave/packages/statistics-1.2.0/fstat.m shadows a core library function
octave:1> for it = 115:20000 rand('state',it); W = rand(200); W(W < 0.9) = 0; W(W != 0) = rand(size(W(W != 0))) - 0.5; eigs(W,1,'LM'); endfor
error: eigs: error -14 in dneupd
octave:1> it
it =  137
octave:2> for it = 136:20000 rand('state',it); W = rand(200); W(W < 0.9) = 0; W(W != 0) = rand(size(W(W != 0))) - 0.5; eigs(W,1,'LM'); endfor
error: eigs: error -14 in dneupd
octave:2> it
it =  137
octave:3> for it = 137:20000 rand('state',it); W = rand(200); W(W < 0.9) = 0; W(W != 0) = rand(size(W(W != 0))) - 0.5; eigs(W,1,'LM'); endfor
error: eigs: error -14 in dneupd
octave:3> it
it =  182
octave:4> rand('state',137); W = rand(200); W(W < 0.9) = 0; W(W != 0) = rand(size(W(W != 0))) - 0.5; eigs(W,1)
ans = -0.12943 - 1.26169i
octave:5> rand('state',136); W = rand(200); W(W < 0.9) = 0; W(W != 0) = rand(size(W(W != 0))) - 0.5; eigs(W,1)
ans =  1.06808 - 0.73793i
octave:6> rand('state',138); W = rand(200); W(W < 0.9) = 0; W(W != 0) = rand(size(W(W != 0))) - 0.5; eigs(W,1)
ans =  1.3301
octave:7> max@xmscusb:~$
max@xmscusb:~$ octave -q
warning: function /usr/share/octave/packages/statistics-1.2.0/fstat.m shadows a core library function
octave:1> rand('state',138); W = rand(200); W(W < 0.9) = 0; W(W != 0) = rand(size(W(W != 0))) - 0.5; eigs(W,1)
ans =  1.3301
octave:2> rand('state',137); W = rand(200); W(W < 0.9) = 0; W(W != 0) = rand(size(W(W != 0))) - 0.5; eigs(W,1)
ans = -0.12943 - 1.26169i
octave:3> rand('state',136); W = rand(200); W(W < 0.9) = 0; W(W != 0) = rand(size(W(W != 0))) - 0.5; eigs(W,1)
ans =  1.06808 - 0.73793i
octave:4> for it = 136:20000 rand('state',it); W = rand(200); W(W < 0.9) = 0; W(W != 0) = rand(size(W(W != 0))) - 0.5; eigs(W,1,'LM'); endfor
error: eigs: error -14 in dneupd
octave:4> it
it =  137


I use a for loop to find seeds that trigger the error. If the for loop starts at it=115 or at it=136, the error occurs at seed 137.  If the for loop starts at it=137, the error occurs at seed 182. If I try to trigger the error by hand, knowing the seed, the error does not occur at all.

The errno2string function would be helpful, I'm glad to know a workaround, but I think there is a real error hidden somewhere.Octave, errors coming from Arpack dneupd look like:
"error: eigs: error -14 in dneupd" see e.g. [1]

This is not helpful and it would be good to have a convenient way to
print error messages from Arpack itself?

Maybe a convenience function like "errno2string" or

Max Görner <maxg>
Wed 22 Jan 2014 09:34:35 PM UTC, comment #7: 

Done at [1].

Actually, some error number signification are not  consistent across all functions (see e.g. INFO = -12 in [2] and [3]) but it shouldn't be hard to handle either in octave or in arpack.


[1] http://forge.scilab.org/index.php/p/arpack-ng/issues/1390/
[2] http://www.mathkeisan.com/UsersGuide/man/dneupd.html
[3] http://www.mathkeisan.com/UsersGuide/man/dnaupd.html

Pantxo Diribarne <pantxo>
Group Member
Wed 22 Jan 2014 05:34:52 PM UTC, comment #6: 

This seems like a reasonable feature request for Arpack.

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Wed 22 Jan 2014 05:21:47 PM UTC, comment #5: 

@Mike: Sure this would be very helpful considering that eigs interface lets the user properly solve the reported issue with tolerance.

@Jordi: After a quick browse in Arpack documentation, I can't find a function that handles something like "errno2string". It seems to be left to the user so that this is not a bug in Arpack but a feature request as here in Octave. Am I wrong?

Pantxo Diribarne <pantxo>
Group Member
Wed 22 Jan 2014 04:57:50 PM UTC, comment #4: 

Feel free to bounce this bug off to arpack-ng:

http://forge.scilab.org/index.php/p/arpack-ng/issues/

Jordi Gutiérrez Hermoso <jordigh>
Group Member
Wed 22 Jan 2014 04:53:27 PM UTC, comment #3: 

Thanks for finding that discussion of the equivalent problem in Matlab.

So maybe turn this into a feature request to turn arpack error codes into strings that might make more sense to the user, as Matlab apparently does as shown in the referenced question?

Mike Miller <mtmiller>
Group Member
Wed 22 Jan 2014 04:42:14 PM UTC, comment #2: 

Just a comment : looks like the "error -14 in dneupd" (actually , "DNAUPD did not find any eigenvalues to sufficient accuracy", see [1]) is also encountered in matlab (see e.g. [2]). Decreasing tolerance I obtain in 3.6.4:


>> function x = func(n)
x = rand (n);
x(x < 0.9) = 0;
x(x != 0) = rand (size (x(x != 0))) - 0.5;
endfunction
>> opt.tol = 1e-5;
>> rand ("state", 137); w = func (200); eigs (w, 1)
error: eigs: error -14 in dneupd
>> rand ("state", 137); w = func (200); eigs (w, 1, "lm") %default
error: eigs: error -14 in dneupd
>> rand ("state", 137); w = func (200); eigs (w, 1, "lm", opt)
ans = -0.12943 + 1.26169i


Interestingly I don't have to decrease tolerance using the octave 3.8 (mac dmg from octave-forge): I obtain the same complex value as in 3.6.4 with decreased tolerance.

Having the original error message instead of the error number would help here.


[1] http://www.mathkeisan.com/UsersGuide/man/dneupd.html
[2] http://www.mathworks.com/matlabcentral/answers/100649

Pantxo Diribarne <pantxo>
Group Member
Wed 22 Jan 2014 03:35:35 PM UTC, comment #1: 

Thanks for your bug report. I don't have Octave 3.4.2 to test with at the moment. However, with 3.6.4 I actually get the reverse behavior, are you sure you didn't swap those two rand initializers?

Someone with more insight into the eigs algorithm than me will have to comment on this, but here's what I see with Octave 3.8.0 (same as with 3.6.4). Asking for more eigenvalues works, but limiting it to 1 or 2 makes arpack fail to return any in this case.


octave:1> function x = func(n)
> x = rand (n);
> x(x < 0.9) = 0;
> x(x != 0) = rand (size (x(x != 0))) - 0.5;
> endfunction
octave:2> rand ("state", 137); w = func (200); eigs (w, 1)
error: __eigs__: eigs: error -14 in dneupd
error: called from:
error:   /usr/share/octave/3.8.0/m/sparse/eigs.m at line 260, column 18
octave:2> rand ("state", 137); w = func (200); eigs (w, 2)
error: __eigs__: eigs: error -14 in dneupd
error: called from:
error:   /usr/share/octave/3.8.0/m/sparse/eigs.m at line 260, column 18
octave:2> rand ("state", 137); w = func (200); eigs (w, 3)
ans =

  -0.12943 + 1.26169i
  -0.12943 - 1.26169i
  -1.25249 - 0.18251i


Mike Miller <mtmiller>
Group Member
Wed 22 Jan 2014 02:16:49 PM UTC, original submission:  

I'm using GNU Octave for research and need to randomly initialise matrices and then calculate their eigenvalues. Sometimes I get the following error

error: eigs: error -14 in dneupd


In Version 3.4.2 and 3.6.4 the following line triggers the error:

rand('state',114); W = rand(200); W(W < 0.9) = 0; W(W != 0) = rand(size(W(W != 0))) - 0.5; eigs(W,1)


The following line triggers the error only in version 3.4.2:

rand('state',137); W = rand(200); W(W < 0.9) = 0; W(W != 0) = rand(size(W(W != 0))) - 0.5; eigs(W,1)


Please note that calling +verbatim+ eigs(W) -verbatim-, leaving away the >>1<<, works correctly.

If eigs works correctly, the error should occur in both versions and the error message should be more informative.
I think, something has to be done to fix eigs or its librarys.

sincerely

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #30393:  sweepseed.m added by pantxo (390B - text/x-objcsrc)
file #30352:  testeig.m added by pantxo (516B - text/x-objcsrc)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by caliari (Posted a comment)
  • -email is unavailable- added by maxg (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-27 mtmiller Severity1 - Wish 3 - Normal
        Item GroupFeature Request Incorrect Result
        Summarygenerate human-readable error strings from arpack error codes eigs: error -14 in dneupd when requesting fewer eigenvalues
    2014-01-27 pantxo Attached File- Added sweepseed.m, #30393
    2014-01-27 mtmiller Severity3 - Normal 1 - Wish
        Item GroupOther Feature Request
        Release3.6.4 dev
        Operating SystemGNU/Linux Any
        Summaryerror: eigs: error -14 in dneupd generate human-readable error strings from arpack error codes
    2014-01-23 pantxo Attached File- Added testeig.m, #30352
    2014-01-22 mtmiller StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code