Modify FAccess to Compute a Final Residual Norm

[jbschroder]

FAccess already computes an F-relaxtion. So why not use it to compute a final residual
norm? This would be useful.

[jbschroder]

After some discussions, I think we should give the user two options in FAccess

1. The current light-weight F-relax only access to each time-point
2. A heavier duty option that carries out (a) FC-relax (basically the first 200 lines of FRestrict, up until the residual is restricted to the coarse grid), (b) computes a final residual norm, and (c) calls the user's access function (just like in FRestrict).

This last option (2) also has the benefit of calling the Step function one last time at every F and C point. This is needed for efficient gradient computations in TorchBraid (the motivation here).

There's also an issue with (1) that if access_level == 0, then an F-relax is still done, but never used. This should be fixed.

Downside to all of this, is that it would duplicate FCrelax code and residual computation code, to create the new final FC-relax+compute-final-residual code.

What do you think Rob? @rfalgout

[rfalgout]

Hi @jbschroder . Are you basically wanting the option to do _braid_ComputeFullRNorm? Maybe an alternative is to have the call to FAccess() be inside an if/else based on the option you are looking for. Some rearranging of where ComputeFullRNorm is called in the driver along with some additional tweaks of the routine itself might also be in order.

One concern have with modifying FAccess() is that it changes the meaning of the routine. FAccess() is simply providing access to the current solution values. The fact that the F-values are not stored explicitly means that they have to be computed. If we do add a residual feature to FAccess(), then I would argue that we should eliminate ComputeFullRNorm and use the new FAccess(). Maybe this is a good way to go.

One question about your gradient computation comment. Are you planning to save the new C-point value computed by Step? That would change the MGRIT algorithm by adding a post C relaxation. Actually, I guess I should ask if you are mainly concerned about the final-final call to FAccess() here (there are two calls to it in the driver).

If it would be easier to chat in person, just let me know. Thanks!

[jbschroder]

Hi @rfalgout
I wanted to avoid _braid_ComputeFullRNorm, because I was thinking it would be better to have the residual computed only at C-points, so that the reported residual norm was consistent with previous residual norms.

The whole issue that is driving this, is that Stefanie and Eric need to call Step() at each time point (C and F) after the cycle ends, to do gradient computations. Stefanie right now has inserted an extra call to FCrelax (to replace her final-final call to FAccess), and this seems to work OK. This does change the algorithm and add a final C-point post-relaxation. Essentially, they want to compute the gradient based on the updated solution that you get from the coarse-grid correction, and to do that they need to have Step() called. ( There might be other ways to compute the gradient, but this is what made sense to them, and this makes me think other "users" may choose this path in the future, too. )

So as of right now, an if-else statement controls whether to do a final-final call to FCrelax, or to FAccess in Stefanie's code.

But I was thinking that by doing a final C-relax, one could also generate a residual norm for the final Braid solution. This could be nice (but isn't necessary).

Some thoughts...

• Should the final FCrelax in this case be saved, and actually change the Braid algorithm? Probably (?), but we should see what makes the most sense from the perspective of gradient computations. That is, is the gradient "correct" for the state vector before, or after the FC-relaxation. I think after, but we could check
• If the final C-relax is saved, while computing the residual, this would be different than FRestrict, and might require more code to let us compute a residual while saving the result of that C-relax used to compute the residual. This could be a vote against computing a residual here.

Anyway, I'm mostly trying to collect all my thoughts here, but a chat could be good. We might want to drag Stefanie and Eric into it, too. We actually have a regular zoom meeting at 1pm Mountain Time (12/9), and I bet you could drop in to chat. If you want to do that, just let me know.

[jbschroder]

We just had a discussion on Zoom, and the current feeling is to just do an if/else at the end of Drive to control whether to call FCrelax or FAccess. This won't allow for a residual computation at the end of the cycle, but this way is "clean" and doesn't involve much new/duplicated code. We can add a residual computation later, if needed