Agreed; we find the Hilbert space inner product improves the convergence a great deal when doing mesh refinement studies with quasi-Newton methods in a discretize-then-optimize approach.
The best example I can think of to argue against “hiding” the inner product inside of a DM instead of a Mat is that it could be used for automatically scaling the KKT systems solved in interior point methods (e.g., IPOPT); poorly-scaled problems arise sometimes in applications. Admittedly, these inner products tend to be diagonal, and thus there may be a better interface or abstraction for this functionality. > On Apr 12, 2018, at 13:28, Stefano Zampini <stefano.zamp...@gmail.com> wrote: > > The gradient norm is the one induced by the mass matrix of the DM associated > with the control. > In principle, TaoGradientNorm() can be replaced by DMCreateMassMatrix() + > solve with the mass matrix. > > For PDE constrained optimization, the “gradient norm” is crucial, since we > consider optimization problems in Banach spaces. > We should keep supporting it, maybe differently than as it is now, but keep > it. > >> On Apr 12, 2018, at 11:21 PM, Jed Brown <j...@jedbrown.org> wrote: >> >> Are you thinking about this PR again? >> >> https://bitbucket.org/petsc/petsc/pull-requests/506 >> >> There's an issue here that Krylov methods operate in the discrete inner >> product while some higher level operations are of interest in >> (approximations of) continuous inner products (or norms). The object in >> PETSc that endows continuous attributes (like a hierarchy, subdomains, >> fields) on discrete quantities is DM, so my first inclination is that >> any continuous interpretation of vectors, including inner products and >> norms, belongs in DM. >> >> "Munson, Todd" <tmun...@mcs.anl.gov> writes: >> >>> 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. >