[SciPy-dev] Callback feature for iterative solvers

[Bart Vandereycken]

Ed Schofield wrote:
> 
> On 1/24/07, *Nils Wagner* <nwagner at iam.uni-stuttgart.de 
> <mailto:nwagner at iam.uni-stuttgart.de>> wrote:
> 
>     Ed Schofield wrote:
>      >
>      > On 1/24/07, *Nils Wagner* <nwagner at iam.uni-stuttgart.de
>     <mailto:nwagner at iam.uni-stuttgart.de>
>      > <mailto:nwagner at iam.uni-stuttgart.de
>     <mailto:nwagner at iam.uni-stuttgart.de>>> wrote:
>      >
>      >     Hi Ed,
>      >
>      >     Great !
>      >     Thank you very much !
>      >     It seems to work well with the exception of GMRES.
>      >     Please find attached a short test.
>      >     Am I missing something ?
> 
>      >
>      >
>      > No, I agree. It seems that there's something wrong with GMRES
> 
>      > ...
>     Hi Ed,
> 
>     Done. Maybe you can add some comments.
>     Again thank you very much for the new functionality !!
> 
>     http://projects.scipy.org/scipy/scipy/ticket/360
> 
> 
> Actually, I'm mystified about the meaning of iter_ in gmres() and the 
> others. Can anyone shed any light on this? Why is the output value of 
> iter_ from revcom() used as the *input* value in the next iteration? Why 
> is the maxiter argument only used once, for the first call to revcom(), 
> and then apparently ignored for all subsequent calls?

The meaning of iter_ is the number of restarted GMRES iterations, not 
the total number.

The bottom line is the nice property of GMRES that it can compute the 
residuals without updating the iterate x.

> 
> I'm inclined to revert the callback patch -- it seems broken. But if the 
> revcom Fortran functions can perform multiple iterations each, we can't 
> easily call back Python functions each iteration. Is there a better 
> solution?

I've made a patch in http://projects.scipy.org/scipy/scipy/ticket/360 
that gives the relative residual to the callback routine.

-- bart