Arpack solver reports 4294967295 iterations before converging

[Maxi Miller]

I implemented the changes in step-36 suggested in the tutorial for using ARPACK instead of PETSc (as shown in the attachment). Now, the solver reports a convergence in 4294967295 iterations (with correct result), thus I assume a overflow/underflow bug. Is that something which I should report in the github issues?

Thanks!

[Wolfgang Bangerth]

4294967295=-1 when expressed in unsigned int. This usually indicates some kind
of error condition. It would be worth figuring out where this number is
generated because it's pretty clear that that is not the actual number of
iterations performed.

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[Maxi Miller]

This number already comes from solver_control, given as

solver_control.last_step ();

[Wolfgang Bangerth]

On 10/9/19 7:47 AM, 'Maxi Miller' via deal.II User Group wrote:
> This number already comes from solver_control, given as
>
> solver_control.last_step ();

Hm, that's really quite unfortunate. It took me a couple minutes of looking
into the code, but I *think* what is happening is that the ArpackSolver class
simply doesn't use the solver control object at all, and that the -1 for the
number of iterations is simply the (unchanged) initializer the SolverControl
class uses for the number of iterations. So that would mean that it doesn't
actually indicate an error.

Can you check whether my interpretation is correct? If so, we should probably
just remove the argument from the ArpackSolver class's constructor, as well as
the corresponding member variable.

[Maxi Miller]

It is using the SolverControl-class for setting parameters such as the maximum iterations, but the used iterations are never returned (no call to check()). Therefore, was there a reason for setting the control()-object as constant, or can I change it to a non-constant value?

[Wolfgang Bangerth]

On 10/11/19 7:22 AM, 'Maxi Miller' via deal.II User Group wrote:
> It is using the SolverControl-class for setting parameters such as the
> maximum iterations, but the used iterations are never returned (no call
> to check()). Therefore, was there a reason for setting the
> control()-object as constant, or can I change it to a non-constant value?

I think we probably didn't think this through. Do you happen to know
whether ARPACK returns the number of iterations and final
residual/error? If so, then what we should probably call the check()
function with these values, ignoring the return code, just so that the
values are stored in the SolverControl object.

Want to give that a try and make it into a patch?

[Maxi Miller]

Like this: https://github.com/dealii/dealii/pull/8899?

[Wolfgang Bangerth]

On 10/11/19 8:47 AM, 'Maxi Miller' via deal.II User Group wrote:
> Like this: https://github.com/dealii/dealii/pull/8899?

Ha, that was quick -- yes!
Cheers