From: Derek Gaston <friedmud@gm...>  20091005 15:01:04

Now _this_ idea I like! Might even make _me_ use MMS! ;) Derek On Oct 5, 2009, at 7:30 AM, Kirk, Benjamin (JSCEG311) wrote: >> Ben had an excellent idea the other day: > > (i'd classify this as another one of my barelycomprehensible word > streams > 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 nonphysical, >> 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? It's just a distinct integral that needs to be added to >> your >> 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 >> takes >> 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 > ExactSolution > 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 > string > which is provided to exact_solution (in this case > manufactured_forcing_function()) or whatever to get to whichever > component > 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. > > Specifically, > > 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* > residual, > 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, > probably > finer mesh. project the strong residual onto f which is defined on > this > 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 > sense... > Maybe it could even be highorder DG, each projection should be > local, no? > > This could impose some restrictions for the kinds of manufactured > solutions > you use, but since the favorites seem to be sin()cos() etc... (since > they > are generally *not* contained in the discretization basis but also > do not > get worse with differentiation.) this does not seem to be a show > stopper. > > Anyway, if we could flesh out some of the details I think the payoff > would > 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 > problems). > > Thoughts? > > Ben > > >  > 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 912, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Libmeshdevel mailing list > Libmeshdevel@... > https://lists.sourceforge.net/lists/listinfo/libmeshdevel 