> 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
