On Wed, May 6, 2009 at 2:11 PM, Roy Stogner <firstname.lastname@example.org> wrote:
Oh, I missed something in all that: not only do we have yet to
automate \partial R / \partial p, but we leave it up to the user to
evaluate the quantity of interest derivative \partial Q / \partial u.
Trying to automate that is uglier because, unlike R, in general we
can't necessarily express Q as a sum of Q_e on each element. That
means finite differencing or automatic differencing is probably out of
the question, and that means there's probably nothing we can do to
make the users' task any simpler. I'd be happy to be contradicted,
The one thing you can do is provide some standard QuantitiyOfInterest objects that do things like integrate (or average) a variable over a subdomain or a boundary (which are pretty standard quantities of interest). Also, the "point" QoI (where you are just interested in the solution at one point) can be easily generalized.
This is the direction we took in Encore at Sandia. We had a small suite of QoI objects that people could choose from... and if you needed something more specific you wrote your own QoI object....
In fact... we made things even more general than that. We had a general concept of a Postprocessor... any operation that you do to compute a quantity based on a solution. Each postprocessor object could compute it's value... but could also optionally provide quantity of interest calculations for an adjoint solve.
All of this might be too specific to go into libMesh itself... just thought I would give some insight into some options. My personal feeling is that I'll engineer something that looks like this system inside our applications... but I'm not sure everyone in the world would want a system like this. Just providing a callback function for filling in the RHS of an adjoint solve is probably enough...