Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
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}
(11) 
_{Jul}
(5) 
_{Aug}

_{Sep}
(3) 
_{Oct}
(1) 
_{Nov}
(7) 
_{Dec}

2018 
_{Jan}
(8) 
_{Feb}
(8) 
_{Mar}
(1) 
_{Apr}

_{May}

_{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...>  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 