Now _this_ idea I like! Might even make _me_ use MMS! ;-) Derek
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 > 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 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? 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 high-order 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 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 ------------------------------------------------------------------------------ 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
