Solver doesn't provide way to retrieve iteration counts

[ScottMacLachlan]

MultilevelSolver computes an iteration count while it iterates, but that count is not stored after the solve, for a later query. It would be nice if this had a simple routine to store and access iteration counts.

[lukeolson]

This could be embedded in info (which is fairly thin right now, and modeled after the solvers in scipy.sparse).

There are two other options. The first is to pass res=[] to residuals=res and count the length. The other is with a callback:

def mysolver(A, b):
    its = 0
    def cb(x):
        nonlocal its
        its += 1
    res = []
    ml = pyamg.smoothed_aggregation_solver(A)
    x, info = ml.solve(b, callback=cb, return_info=True)
    # x, info = sp.sparse.linalg.cg(A, b, callback=cb)
    return x, info, its

A = pyamg.gallery.poisson((100, 100), format='csr')
b = np.random.rand(A.shape[0])
x, info, its = mysolver(A, b)

That said, I like the idea of more complete info to avoid a callback (complex) or a residual list (costly).

[ScottMacLachlan]

Yeah - the callback is the clear workaround, but having either a more complete info, or stashing the iteration count in self so that it can be retrieved after the solve would be preferable... Thanks!

[bensworth]

Ya I agree this is worth adding; also adding average and final convegence factor for most recent solve would be nice. @lukeolson thoughts? I have the same little code block I copy to all my scripts to get this info

[lukeolson]

An easy thing to do is to change the definition of info. (but this would be inconsistent with scipy and others)

Would we want additional info or just iterations?

[bensworth]

I vote at least include information on convergence, trivial cost and more useful in my mind than any downsides of being inconsistent with scipy. We could also just include the operator and cycle complexity in info too, so you get a pretty complete picture of your solver in the info struct

[jbschroder]

Hi All, I also vote to include a little information. I might vote for storing the residual history and iteration count. There are multiple definitions of convergence factor, so providing the residual history is probably the most flexible. Regarding complexity, I think you can run ml.operator_complexity() and ml.cycle_complexity(), which perhaps suffices? - Jacob

…

On Mon, Dec 12, 2022 at 5:11 PM Ben Southworth ***@***.***> wrote: I vote at least include information on convergence, trivial cost and more useful in my mind than any downsides of being inconsistent with scipy. We could also just include the operator and cycle complexity in info too, so you get a pretty complete picture of your solver in the info struct — Reply to this email directly, view it on GitHub <#366 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABEMHY4K726YIR5DINAP3ZTWM65MXANCNFSM6AAAAAAS34K2RA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bensworth]

@jbschroder what do you mean by multiple definitions? There's only one way to define the convergence factor over some number of iterations. The only question is which residual you use and which iterations you use I think, but which residual should be a function of your outer solver (GMRES, FP, etc.) anyways?

I always have a little code that prints something like this at the end of my scripts (the alignment is right in terminal):

Ruge Stuben
	Operator complexity         =  1.17
	Cycle complexity            =  2.33
	Most recent iteration count =  8
	Average convergence factor  =  0.06
	Final convergence factor    =  0.05

I think it would be nice to automate this with a function, maybe save these numbers in .info and have some form of print function to print like this. Thoughts?

[bensworth]

The CC could just be included in the current output w/ operator and grid complexity. But we could have a different output that tells about the solve, even as default at the end of the solve function