On Mon, 5 Oct 2009, Kirk, Benjamin (JSC-EG311) wrote: > 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...
I'd like to think that I would have come to that design decision myself *eventually*, even if I should have realized it immediately but didn't... ;-) >> 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? Right. We already do that with exact solutions; the implication is that when you're doing code verification you're not worried about every CPU cycle. > 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... There's lots of room here to debate the specific implementation, but my only criticism is a big one: This isn't really a *complete* Method of Manufactured Solutions test. It could still be worthwhile: you might catch discretization bugs this way, solver bugs, some types of formulation problems, lots of good stuff... But you *wouldn't* catch any mistakes in R(). In my eyes one of the most important things about creating a manufactured solution is that it tests your physics, which is probably the newest and least tested code in your application, which can be some of the most complex code, and which (other than for residual/jacobian consistency) can't be tested by the library. It would be fantastic if your physics *could* be tested by the library, but automatically generating f doesn't do it. Imagine that instead of implementing R_normal you implemented R_broken. Then the library would be evaluating f = -R_broken(u_mf) and (unless R_broken is extremely broken) R_mf(u) will still converge to a zero at u = u_mf. The broken residual would be hidden automatically by the forcing function. If you build f by hand, however, there's a better likelihood that you're working from model documentation that actually describes R_normal, and even if you do make any math errors, they're likely to be different from any errors you made in the code. The manufactured solution test will then catch any discrepancy. > The biggest new notion is the strong residual which I think is > needed to make it work. I like the idea of (optional) user-provided strong residuals in general, regardless of whether we want them for manufactured solutions. Other than via (uniform or bubble) refinement they're pretty much necessary to get physics-dependent error estimators via physics-independent code. --- Roy ------------------------------------------------------------------------------ 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
