Interface to OptimizationSolver

[roystgnr]

Given the sensitivities work we've already done, and the simplicity of the interface demonstrated in https://github.com/libMesh/libmesh/blob/master/examples/optimization/optimization_ex1/optimization_ex1.C , it shouldn't be more than a few hundred lines to add an optimization solver capability to GRINS.

It sounds like we might be able to sucker @nicholasmalaya into this - he was looking at DAKOTA for optimization, which is reasonable too, but IMHO Tao support would be easier to add and easier to use.

[pbauman]

Indeed. I'd always wanted to plug into TAO for this. We should see if we need to do anything to have it play nice with FEMSystem (or at least I haven't looked, maybe you have @roystgnr), but it's basically a PETSc-style interface. In fact, since PETSc 3.5, I think, TAO is shipped as part of PETSc, so you don't even need a separate thing anymore.

[roystgnr]

FEMSystem is pretty much irrelevant for the use cases we're talking about. We're not trying to find "solution which optimizes functional" (which would be an 'optimization solver' that more closely parallels our steady solver, unsteady solver, etc), but rather "parameters which optimize qoi" (which would be an outer loop around one of our existing PDE solvers).

[nicholasmalaya]

I'm interested in playing around with this, and it could be a 'explore' option in my proposal. As in, 'will try this but not guarantee success'. However, I'm wondering if we have to assume no gradient (let alone higher order) information, and are stuck with pure black box optimization, or gradient-less algos (e.g. genetic algorithms) or finite differencing?

I'm looking at DAKOTA and TAO's user manuals to get a sense of what is even available, out of the box.