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? 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. 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. The big catch may be stabilized formulations. Adding (f,v) to the residual is one thing; adding (f,v(u)) is another. I've thought of some FEMSystem refactoring that might make this possible, but I'm not sure what we could do for a general NonlinearSystem. Any ideas? --- 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
