My first choice is to remove the TaoGradientNorm() wrapper if there is not anyone using it. It seems like a hack that would need more significant thought to turn it into "not a hack". Maybe Patrick F. can comment, as he is the one that added it. FWIW, I think the user can already change the inner products by writing their own using a VecShell. Todd.

On Apr 12, 2018, at 2:17 PM, Smith, Barry F. <[email protected]> wrote:

I don't know if we are ready for this dramatic change. I wouldn't do it until there was a clear need (not just potential future usage) that would be cumbersome to do without this generality. I am a little scared of this without demonstrated general need.

I would start by having an abstract inner product object (which includes a norm function) that has the standard l2 implementation, then another implementation that is based on passing in a matrix, maybe one based on passing in a vector. Then each solver would have a XXXSetInnerProduct() while defaulting to l2.

Barry

...

On Apr 12, 2018, at 12:21 PM, Munson, Todd <[email protected]> wrote:

There is a bit of code in TAO that allows the user to change the norm to a matrix norm. This was introduced to get some mesh independent behavior in one example (tao/examples/tutorials/ex3.c). That norm, however, does not propagate down into the KSP methods and is only used for testing convergence of the nonlinear problem.

A few questions then: Is similar functionality needed in SNES? Are TAO and SNES even the right place for this functionality? Should it belong to the Vector class so that you can change the inner products and have all the KSP methods (hopefully) work correctly?

Note: that this discussion brings us to the brink of supporting an optimize-then-discretize approach. I am not convinced we should go down that rabbit hole.

Thanks, Todd.