Re: [SciPy-dev] Callback feature for iterative solvers
Ed Schofield wrote:
On 1/24/07, *Nils Wagner* <nwagner@iam.uni-stuttgart.de <mailto:nwagner@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 -- the iter_ return parameter from gmresrevcom() is never incremented for this example. I'm not familiar with the algorithm -- perhaps it really does converge in one iteration? If not, it's just a bug. Could you file a bug against gmres() in Tracker?
-- Ed
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 Cheers, Nils
On 1/24/07, Nils Wagner <nwagner@iam.uni-stuttgart.de> wrote:
Ed Schofield wrote:
On 1/24/07, *Nils Wagner* <nwagner@iam.uni-stuttgart.de <mailto:nwagner@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 !!
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? 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? -- Ed
Ed Schofield wrote:
On 1/24/07, *Nils Wagner* <nwagner@iam.uni-stuttgart.de <mailto:nwagner@iam.uni-stuttgart.de>> wrote:
Ed Schofield wrote: > > On 1/24/07, *Nils Wagner* <nwagner@iam.uni-stuttgart.de <mailto:nwagner@iam.uni-stuttgart.de> > <mailto:nwagner@iam.uni-stuttgart.de <mailto:nwagner@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 iter input is set in the FORTRAN to MAXIT only when IJOB=1 (i.e. the first time through). Every-other time the fortran code is called, it's looking for the output of either the function-call, or the function-call with gradient.
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?
Sometimes, the iteration returns looking for a matrix-times vector result. Other times it wants a right-multiplication, and other times it may be looking for a pre-conditioning result. Basically, any-time the FORTRAN code needs to call a Python function, it returns from the Fortran code. Then, the Python code can be called. I don't see why the callback function can't either be integrated into the get_matvec classes or called only when the matvec is requested. Best, -Travis
Ed Schofield wrote:
On 1/24/07, *Nils Wagner* <nwagner@iam.uni-stuttgart.de <mailto:nwagner@iam.uni-stuttgart.de>> wrote:
Ed Schofield wrote: > > On 1/24/07, *Nils Wagner* <nwagner@iam.uni-stuttgart.de <mailto:nwagner@iam.uni-stuttgart.de> > <mailto:nwagner@iam.uni-stuttgart.de <mailto:nwagner@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
participants (4)
-
Bart Vandereycken -
Ed Schofield -
Nils Wagner -
Travis Oliphant