Re: [Libmesh-devel] ManufacturedSolution class

[John P. <pet...@cf...>]

On Fri, Oct 2, 2009 at 9:33 AM, Roy Stogner <roy...@ic...> wrote:
>
> Ben had an excellent idea the other day:
>
> 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, optional
> 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?

Theoretically it doesn't, but as Derek was mentioning, if you want
efficiency I think it does... since our assembly is just handled
through function pointers we can never autotmatically do stuff like
this in the middle of assembly unless the user explicitly calls the
function themselves.  Sure, you can do something after or before the
fact, but this at least doubles the number of element loops which have
to be performed.

On the other hand, maybe you don't care quite so much about efficiency
when testing a manufactured solution, in which case the additional
set_forcing_function() interface seems like a reasonable way to go.
For problems where v depends on u I don't see any easy way of doing
it, meaning, I think the user has to explicitly add the forcing term
in their matrix assembly in this case.

In FEMSystem systems, it might be cool if there was an additional
virtual function, something like

virtual std::vector<std::vector<Real> >& user_test_function(DiffContext&);

which could be overloaded in derived classes to compute any "custom"
test function the user desired, given current values in a DiffContext.
 This, combined with a user-provided forcing, could conceivably then
be used to add an "automatic" forcing.  Also, this code could be
re-used in normal assembly as well so there would be no duplication.

-- 
John