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. <bsm...@mcs.anl.gov> 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 <tmun...@mcs.anl.gov> 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. >> >