On Fri, Oct 2, 2009 at 9:33 AM, Roy Stogner <[email protected]> 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 ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
