You can subscribe to this list here.
2003 
_{Jan}
(4) 
_{Feb}
(1) 
_{Mar}
(9) 
_{Apr}
(2) 
_{May}
(7) 
_{Jun}
(1) 
_{Jul}
(1) 
_{Aug}
(4) 
_{Sep}
(12) 
_{Oct}
(8) 
_{Nov}
(3) 
_{Dec}
(4) 

2004 
_{Jan}
(1) 
_{Feb}
(21) 
_{Mar}
(31) 
_{Apr}
(10) 
_{May}
(12) 
_{Jun}
(15) 
_{Jul}
(4) 
_{Aug}
(6) 
_{Sep}
(5) 
_{Oct}
(11) 
_{Nov}
(43) 
_{Dec}
(13) 
2005 
_{Jan}
(25) 
_{Feb}
(12) 
_{Mar}
(49) 
_{Apr}
(19) 
_{May}
(104) 
_{Jun}
(60) 
_{Jul}
(10) 
_{Aug}
(42) 
_{Sep}
(15) 
_{Oct}
(12) 
_{Nov}
(6) 
_{Dec}
(4) 
2006 
_{Jan}
(1) 
_{Feb}
(6) 
_{Mar}
(31) 
_{Apr}
(17) 
_{May}
(5) 
_{Jun}
(95) 
_{Jul}
(38) 
_{Aug}
(44) 
_{Sep}
(6) 
_{Oct}
(8) 
_{Nov}
(21) 
_{Dec}

2007 
_{Jan}
(5) 
_{Feb}
(46) 
_{Mar}
(9) 
_{Apr}
(23) 
_{May}
(17) 
_{Jun}
(51) 
_{Jul}
(41) 
_{Aug}
(4) 
_{Sep}
(28) 
_{Oct}
(71) 
_{Nov}
(193) 
_{Dec}
(20) 
2008 
_{Jan}
(46) 
_{Feb}
(46) 
_{Mar}
(18) 
_{Apr}
(38) 
_{May}
(14) 
_{Jun}
(107) 
_{Jul}
(50) 
_{Aug}
(115) 
_{Sep}
(84) 
_{Oct}
(96) 
_{Nov}
(105) 
_{Dec}
(34) 
2009 
_{Jan}
(89) 
_{Feb}
(93) 
_{Mar}
(119) 
_{Apr}
(73) 
_{May}
(39) 
_{Jun}
(51) 
_{Jul}
(27) 
_{Aug}
(8) 
_{Sep}
(91) 
_{Oct}
(90) 
_{Nov}
(77) 
_{Dec}
(67) 
2010 
_{Jan}
(25) 
_{Feb}
(36) 
_{Mar}
(98) 
_{Apr}
(45) 
_{May}
(25) 
_{Jun}
(60) 
_{Jul}
(17) 
_{Aug}
(36) 
_{Sep}
(48) 
_{Oct}
(45) 
_{Nov}
(65) 
_{Dec}
(39) 
2011 
_{Jan}
(26) 
_{Feb}
(48) 
_{Mar}
(151) 
_{Apr}
(108) 
_{May}
(61) 
_{Jun}
(108) 
_{Jul}
(27) 
_{Aug}
(50) 
_{Sep}
(43) 
_{Oct}
(43) 
_{Nov}
(27) 
_{Dec}
(37) 
2012 
_{Jan}
(56) 
_{Feb}
(120) 
_{Mar}
(72) 
_{Apr}
(57) 
_{May}
(82) 
_{Jun}
(66) 
_{Jul}
(51) 
_{Aug}
(75) 
_{Sep}
(166) 
_{Oct}
(232) 
_{Nov}
(284) 
_{Dec}
(105) 
2013 
_{Jan}
(168) 
_{Feb}
(151) 
_{Mar}
(30) 
_{Apr}
(145) 
_{May}
(26) 
_{Jun}
(53) 
_{Jul}
(76) 
_{Aug}
(33) 
_{Sep}
(23) 
_{Oct}
(72) 
_{Nov}
(125) 
_{Dec}
(38) 
2014 
_{Jan}
(47) 
_{Feb}
(62) 
_{Mar}
(27) 
_{Apr}
(8) 
_{May}
(12) 
_{Jun}
(2) 
_{Jul}
(22) 
_{Aug}
(22) 
_{Sep}

_{Oct}
(17) 
_{Nov}
(20) 
_{Dec}
(12) 
2015 
_{Jan}
(25) 
_{Feb}
(2) 
_{Mar}
(16) 
_{Apr}
(13) 
_{May}
(21) 
_{Jun}
(5) 
_{Jul}
(1) 
_{Aug}
(8) 
_{Sep}
(9) 
_{Oct}
(30) 
_{Nov}
(8) 
_{Dec}

2016 
_{Jan}
(16) 
_{Feb}
(31) 
_{Mar}
(43) 
_{Apr}
(18) 
_{May}
(21) 
_{Jun}
(11) 
_{Jul}
(17) 
_{Aug}
(26) 
_{Sep}
(4) 
_{Oct}
(16) 
_{Nov}
(5) 
_{Dec}
(6) 
2017 
_{Jan}
(1) 
_{Feb}
(2) 
_{Mar}
(5) 
_{Apr}
(4) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2
(5) 
3

4

5
(8) 
6
(2) 
7

8
(7) 
9
(1) 
10

11

12

13

14

15
(3) 
16
(1) 
17

18
(2) 
19
(2) 
20
(1) 
21
(11) 
22
(7) 
23

24

25

26
(9) 
27
(3) 
28
(18) 
29
(6) 
30
(4) 
31

From: Kirk, Benjamin (JSCEG311) <benjamin.kirk1@na...>  20091006 13:54:30

> My usual strategy is to dump the physics into a symbolic math program > (sympy is usually adequate) and generate exact forcing terms using the > 'ccode' function, then paste this output into my source. Thanks for that! I need to learn a symbolic math program and was unaware of sympy  I'll check it out. Ben 
From: Jed Brown <jed@59...>  20091006 10:04:51

A couple comments as I'm catching up on this thread. On Mon, Oct 5, 2009 at 18:36, Kirk, Benjamin (JSCEG311) <benjamin.kirk1@...> wrote: >> Would it really be completely distinct? Flow users, for example, >> aren't going to be tempted to call existing functions to evaluate >> intermediate terms like mixing rules, Reynolds stresses, etc. that >> appear in both strong and weak forms of the equations? My usual strategy is to dump the physics into a symbolic math program (sympy is usually adequate) and generate exact forcing terms using the 'ccode' function, then paste this output into my source. If the user provides the strong form in C++, you can skip some of the symbolic math, but you still need to obtain derivatives of their manufactured solution. This could be done with AD, but that requires heavy templating or very experimental source transformation (source transformation is mature for Fortran, not for C/C++) and of course adds dependencies and the temptation above. Also, AD is not sufficient to apply MMS to integrodifferential equations (something I was doing a few years ago, albeit not with libmesh). I don't think you should worry at all about speed while in verification, manufactured solutions often involve enough transcendental functions to dominate the cost of residual evaluation anyway. Jed 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk1@na...>  20091005 16:36:27

> Would it really be completely distinct? Flow users, for example, > aren't going to be tempted to call existing functions to evaluate > intermediate terms like mixing rules, Reynolds stresses, etc. that > appear in both strong and weak forms of the equations? Of course we will ;). Hopefully, though, those "simple things" will be checked through their own unit tests. > Like I said, it's certainly better than nothing  I just don't want > anyone to have a false sense of security about it. No doubt. It is not a panacea, but I can certainly think back on a number of discretization bugs I have eventually tracked down which this approach would have caught. On a related note, who has a good working knowledge of mathematica or maple that we can begin abusing with coming up with a *real* firstprinciples forcing function? Ben 
From: Roy Stogner <roystgnr@ic...>  20091005 16:28:20

On Mon, 5 Oct 2009, Kirk, Benjamin (JSCEG311) wrote: > Well, the saving grace might be that we would *require* R_strong which is > separate and distinct from R_weak where the errors you are looking for may > lie. Would it really be completely distinct? Flow users, for example, aren't going to be tempted to call existing functions to evaluate intermediate terms like mixing rules, Reynolds stresses, etc. that appear in both strong and weak forms of the equations? Like I said, it's certainly better than nothing  I just don't want anyone to have a false sense of security about it.  Roy 
From: John Peterson <peterson@cf...>  20091005 16:26:28

On Mon, Oct 5, 2009 at 11:17 AM, Kirk, Benjamin (JSCEG311) <benjamin.kirk1@...> wrote: >> 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. > > Well, the saving grace might be that we would *require* R_strong which is > separate and distinct from R_weak where the errors you are looking for may > lie. Of course, you can still break R_strong and screw yourself, but as > McLay says "genius has its limits, but stupidity knows no bounds...". > > If nothing else, when coding R_strong there is no reference to shape > functions, quadrature, anything... You go straight from u and its > derivatives to the residual you think you are solving. In terms of syntax > it should be very clear, and you are *not* inheriting errors from your > discretized residual if the strong form of the residual is required as a > separate function. > > I am thinking something like > > Real R_strong (...) > { > const Real factor = ...; > const Real u = u_exact(xyz,t); > const Real u_xx = d2u_exact(xyz,t); > > const Real R_strong_homogeneous_helmholtz = factor*u  u_xx; > > return R_strong_homogeneous_helmholtz; > } One possible longterm problem with strong residuals: we've never properly implemented second derivatives on nonaffine elements (fe_map.C, line 485). We're talking test problems here, so that may not be an issue...  John 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk1@na...>  20091005 16:18:10

> 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. Well, the saving grace might be that we would *require* R_strong which is separate and distinct from R_weak where the errors you are looking for may lie. Of course, you can still break R_strong and screw yourself, but as McLay says "genius has its limits, but stupidity knows no bounds...". If nothing else, when coding R_strong there is no reference to shape functions, quadrature, anything... You go straight from u and its derivatives to the residual you think you are solving. In terms of syntax it should be very clear, and you are *not* inheriting errors from your discretized residual if the strong form of the residual is required as a separate function. I am thinking something like Real R_strong (...) { const Real factor = ...; const Real u = u_exact(xyz,t); const Real u_xx = d2u_exact(xyz,t); const Real R_strong_homogeneous_helmholtz = factor*u  u_xx; return R_strong_homogeneous_helmholtz; } Ben 
From: Derek Gaston <friedmud@gm...>  20091005 16:14:40

On Oct 5, 2009, at 10:07 AM, Roy Stogner wrote: > 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. Wait... if f is built from the strong form... then it might catch problems with R right? At least you will need to code up two different forms of your equations and then you will be checking them against each other. If you make the same mistake in both... well it won't catch that.... but if you forgot to multiply by a test function or something in R it might pick it up. Derek 
From: Roy Stogner <roystgnr@ic...>  20091005 16:07:48

On Mon, 5 Oct 2009, Kirk, Benjamin (JSCEG311) 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) userprovided 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 physicsdependent error estimators via physicsindependent code.  Roy 
From: Derek Gaston <friedmud@gm...>  20091005 15:01:04

Now _this_ idea I like! Might even make _me_ use MMS! ;) Derek On Oct 5, 2009, at 7:30 AM, Kirk, Benjamin (JSCEG311) wrote: >> Ben had an excellent idea the other day: > > (i'd classify this as another one of my barelycomprehensible 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 nonphysical, >> 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 highorder 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 912, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Libmeshdevel mailing list > Libmeshdevel@... > https://lists.sourceforge.net/lists/listinfo/libmeshdevel 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk1@na...>  20091005 14:06:07

> Ben had an excellent idea the other day: (i'd classify this as another one of my barelycomprehensible 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 nonphysical, 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 highorder 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 showstopper. 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 
From: Roy Stogner <roystgnr@ic...>  20091002 20:29:39

On Fri, 2 Oct 2009, John Peterson wrote: > In FEMSystem systems, it might be cool if there was an additional > virtual function, something like > > virtual std::vector<std::vector<Real> >& user_test_function(DiffContext&); > > which could be overloaded in derived classes to compute any "custom" > test function the user desired, given current values in a DiffContext. > This, combined with a userprovided forcing, could conceivably then > be used to add an "automatic" forcing. Also, this code could be > reused in normal assembly as well so there would be no duplication. This is exactly what I was thinking about, but I think it needs one more userprovided function: if the user also supplies derivatives of test functions with respect to components of the (fixed) solution, then stabilized formulations might get a bit simpler: in addition to reducing some of the complexity in time_derivative and constraint methods, you ought to be able to forgo overriding mass_residual entirely.  Roy 
From: Roy Stogner <roystgnr@ic...>  20091002 19:55:53

On Fri, 2 Oct 2009, Derek Gaston wrote: > 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.... You didn't number this, but let's call it 3: 3. The ability to add additional operators to a System should be generalized. Then "add a spatially dependent forcing function" would just be a special case of that. > 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?). This isn't a problem for us on verification runs, but it interacts with issue 3, in that a general system that adds redundant loops would have an overhead that for some codes would be unacceptable for production runs. C++ makes it possible to do generalized compiletime dialanoperator without redundant loops, recalculations, or even much heavy parsing in the inner loop, but the necessary template tricks may not look pretty. I'd want to experiment with creating such an API quite a bit before considering adding anything like that to the library, and it would be difficult to apply to existing code. I think the fundamental problem may be that we don't have a clear separation between the System (which handles allocation of variables, vectors, matrices) and the Physics (which would express the equations that are evaluated to find residual and jacobian components). FEMSystem gives a little more abstraction to physics in libMesh applications, but it doesn't separate this intertwining. If people could create two Physics objects that operated on the same System's data, then we would never consider adding a new method like add_forcing_function(). Just call the constructor SumPhysics(Physics &A, Physics &B), where B is a special case that assembles your forcing function. > 2. Speaking of coupling... how are you going to handle that (but maybe > people don't do coupled manufactured solutions... I don't know). We're planning on doing things fully coupled, so (other than making sure that f(x) can be called by variable name) there are no worries there. For people doing loosely coupled solves, it would be necessary for them to override EquationSystems::solve() to call each system in the right order and to loop until convergence. That's the sort of code everyone tends to just shove in main() now, but EquationSystems is designed to be subclassable for just that reason. (also for use with UniformErrorEstimator). How to do the API for transient problems properly (for the adjoint methods, too) is another similar question. Let's call that "4." Still thinking about that one.  Roy 
From: John Peterson <peterson@cf...>  20091002 19:46:38

On Fri, Oct 2, 2009 at 9:33 AM, Roy Stogner <roystgnr@...> 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 nonphysical, 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? Theoretically it doesn't, but as Derek was mentioning, if you want efficiency I think it does... since our assembly is just handled through function pointers we can never autotmatically do stuff like this in the middle of assembly unless the user explicitly calls the function themselves. Sure, you can do something after or before the fact, but this at least doubles the number of element loops which have to be performed. On the other hand, maybe you don't care quite so much about efficiency when testing a manufactured solution, in which case the additional set_forcing_function() interface seems like a reasonable way to go. For problems where v depends on u I don't see any easy way of doing it, meaning, I think the user has to explicitly add the forcing term in their matrix assembly in this case. In FEMSystem systems, it might be cool if there was an additional virtual function, something like virtual std::vector<std::vector<Real> >& user_test_function(DiffContext&); which could be overloaded in derived classes to compute any "custom" test function the user desired, given current values in a DiffContext. This, combined with a userprovided forcing, could conceivably then be used to add an "automatic" forcing. Also, this code could be reused in normal assembly as well so there would be no duplication.  John 
From: Derek Gaston <friedmud@gm...>  20091002 18:34:45

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 showstoppers (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 nonphysical, 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 912, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Libmeshdevel mailing list > Libmeshdevel@... > https://lists.sourceforge.net/lists/listinfo/libmeshdevel 
From: Roy Stogner <roystgnr@ic...>  20091002 14:33:35

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 nonphysical, 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 