Just a quick observation that this could continue to get extended... for instance "we know what a diffusion operator looks like... we can assemble that for you!".... which starts to look a lot like the system I've grown here at INL....
Nothing wrong with that...... just saying ;-) For that same reason it personally wouldn't be useful to me (ie I can already do that). But I do see how it could be useful to others. I can foresee a couple of issues though. 1. Speed. As soon as you do this you're going to introduce another set of element loops, FE reinits, quadrature point location recalculations, and possibly variable calculations (for coupled manufactured solutions?). 2. Speaking of coupling... how are you going to handle that (but maybe people don't do coupled manufactured solutions... I don't know). Ok - I guess just those two come to mind... and they're probably not show-stoppers (on verification runs... do you really care so much about speed?). But I did think I'd bring them up... Derek On Oct 2, 2009, at 8:33 AM, Roy Stogner wrote: > > 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 ------------------------------------------------------------------------------ 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
