Now _this_ idea I like! Might even make _me_ use MMS! ;-)
On Oct 5, 2009, at 7:30 AM, Kirk, Benjamin (JSC-EG311) wrote:
>> Ben had an excellent idea the other day:
> (i'd classify this as another one of my barely-comprehensible word
> that plants a seed which Roy then refines, but thanks...)
>> We have an ExactSolution class which is nice for when people build
>> physics applications for which some problems will have a comparable
>> exact analytic solution. However, that's not always true, so to
>> rigorously test convergence, people have to add non-physical,
>> forcing functions to make their physics assembly capable of
>> reproducing a manufactured solution.
>> But why does that forcing function need to be intermingled with your
>> physics? It's just a distinct integral that needs to be added to
>> residual, and even for our lower level implicit system classes the
>> residual evaluation starts in the library. Instead of using
>> ExactSolution, we could create a ManufacturedSolution class that
>> two functions: the analytic solution and the analytic forcing
>> function, and let the library add the forcing function itself before
>> the underlying equations are solved.
> Convenient, but when I suggested it I was thinking just more along
> the lines
> of clas ManufactuedSolution : public ExactSolution + forcing
> function... It
> can then be passed to whatever we already have that expects an
> to get e.g. L2 norms of the error...
>> Some thoughts I've had since:
>> For this to work for nonlinear systems, we need to get in to every
>> residual evaluation; we'd need something like a ManufacturedSystem
>> that derives from NonlinearSystem and that acts as a proxy class to
>> the real NonlinearSystem, keeps a reference to the other system's
>> residual/solution/jacobian vectors, etc. This seems tricky.
>> Adding a
>> "set_forcing_function()" method to the existing System class might be
>> simpler. At that point we don't need a special ManufacturedSolution
>> class either, we just use ExactSolution.
> Throwing efficiency out the window, we should be able to test the
> which is provided to exact_solution (in this case
> manufactured_forcing_function()) or whatever to get to whichever
> we need, right?
> Now, I was thinking this morning, that the real pain with manufactured
> solutions is *getting* f, right? Consider
> R_mf = R_normal + f
> where R_mf is the manufactured solution residual we will solve,
> R_normal is
> the "physics" residual, and f is the crap to make R_mf = 0.
> f = -R_normal.
> Now, the real money would be in helping *create* f.
> ...here's where it gets hopeful, criticism welcome...
> Why not just piece together existing infrastructure to get f? I
> mean, if
> the user has specified the exact solution they want, the library could
> construct a numeric f provided it has access to the *strong form*
> right? Seems like some combination of MeshFunction, multiple
> meshes, and
> solution projection would fit the bill.
> Imagine you have a mesh. Discretize its bounding box with another,
> finer mesh. project the strong residual onto f which is defined on
> bounding mesh. do you have a numeric f that is sufficient for MMS
> work? Of
> course, this bounding box mesh could be hermites, whatever makes
> Maybe it could even be high-order DG, each projection should be
> local, no?
> This could impose some restrictions for the kinds of manufactured
> you use, but since the favorites seem to be sin()cos() etc... (since
> are generally *not* contained in the discretization basis but also
> do not
> get worse with differentiation.) this does not seem to be a show-
> Anyway, if we could flesh out some of the details I think the payoff
> be huge. The biggest new notion is the strong residual which I
> think is
> needed to make it work. Now, if the user provides exact_solution and
> exact_gradient that should be enough to be dangerous (for 2nd order
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> developing skills, take BlackBerry mobile applications to market and
> ahead of the curve. Join us from November 9-12, 2009. Register
> Libmesh-devel mailing list