[petsc-dev] vector inner products

[Munson, Todd]

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. <bsmith at 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 <tmunson at 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.
>> 
>