-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Solver doesn't provide way to retrieve iteration counts #366
Comments
This could be embedded in There are two other options. The first is to pass 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 |
Yeah - the callback is the clear workaround, but having either a more complete info, or stashing the iteration count in |
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 |
An easy thing to do is to change the definition of Would we want additional info or just iterations? |
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 |
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: ***@***.***>
|
@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):
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? |
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 |
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.The text was updated successfully, but these errors were encountered: