You can subscribe to this list here.
2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(2) 
_{Oct}
(2) 
_{Nov}
(27) 
_{Dec}
(31) 

2004 
_{Jan}
(6) 
_{Feb}
(15) 
_{Mar}
(33) 
_{Apr}
(10) 
_{May}
(46) 
_{Jun}
(11) 
_{Jul}
(21) 
_{Aug}
(15) 
_{Sep}
(13) 
_{Oct}
(23) 
_{Nov}
(1) 
_{Dec}
(8) 
2005 
_{Jan}
(27) 
_{Feb}
(57) 
_{Mar}
(86) 
_{Apr}
(23) 
_{May}
(37) 
_{Jun}
(34) 
_{Jul}
(24) 
_{Aug}
(17) 
_{Sep}
(50) 
_{Oct}
(24) 
_{Nov}
(10) 
_{Dec}
(60) 
2006 
_{Jan}
(47) 
_{Feb}
(46) 
_{Mar}
(127) 
_{Apr}
(19) 
_{May}
(26) 
_{Jun}
(62) 
_{Jul}
(47) 
_{Aug}
(51) 
_{Sep}
(61) 
_{Oct}
(42) 
_{Nov}
(50) 
_{Dec}
(33) 
2007 
_{Jan}
(60) 
_{Feb}
(55) 
_{Mar}
(77) 
_{Apr}
(102) 
_{May}
(82) 
_{Jun}
(102) 
_{Jul}
(169) 
_{Aug}
(117) 
_{Sep}
(80) 
_{Oct}
(37) 
_{Nov}
(51) 
_{Dec}
(43) 
2008 
_{Jan}
(71) 
_{Feb}
(94) 
_{Mar}
(98) 
_{Apr}
(125) 
_{May}
(54) 
_{Jun}
(119) 
_{Jul}
(60) 
_{Aug}
(111) 
_{Sep}
(118) 
_{Oct}
(125) 
_{Nov}
(119) 
_{Dec}
(94) 
2009 
_{Jan}
(109) 
_{Feb}
(38) 
_{Mar}
(93) 
_{Apr}
(88) 
_{May}
(29) 
_{Jun}
(57) 
_{Jul}
(53) 
_{Aug}
(48) 
_{Sep}
(68) 
_{Oct}
(151) 
_{Nov}
(23) 
_{Dec}
(35) 
2010 
_{Jan}
(84) 
_{Feb}
(60) 
_{Mar}
(184) 
_{Apr}
(112) 
_{May}
(60) 
_{Jun}
(90) 
_{Jul}
(23) 
_{Aug}
(70) 
_{Sep}
(119) 
_{Oct}
(27) 
_{Nov}
(47) 
_{Dec}
(54) 
2011 
_{Jan}
(22) 
_{Feb}
(19) 
_{Mar}
(92) 
_{Apr}
(93) 
_{May}
(35) 
_{Jun}
(91) 
_{Jul}
(32) 
_{Aug}
(61) 
_{Sep}
(7) 
_{Oct}
(69) 
_{Nov}
(81) 
_{Dec}
(23) 
2012 
_{Jan}
(64) 
_{Feb}
(95) 
_{Mar}
(35) 
_{Apr}
(36) 
_{May}
(63) 
_{Jun}
(98) 
_{Jul}
(70) 
_{Aug}
(171) 
_{Sep}
(149) 
_{Oct}
(64) 
_{Nov}
(67) 
_{Dec}
(126) 
2013 
_{Jan}
(108) 
_{Feb}
(104) 
_{Mar}
(171) 
_{Apr}
(133) 
_{May}
(108) 
_{Jun}
(100) 
_{Jul}
(93) 
_{Aug}
(126) 
_{Sep}
(74) 
_{Oct}
(59) 
_{Nov}
(145) 
_{Dec}
(93) 
2014 
_{Jan}
(38) 
_{Feb}
(45) 
_{Mar}
(26) 
_{Apr}
(41) 
_{May}
(125) 
_{Jun}
(70) 
_{Jul}
(61) 
_{Aug}
(66) 
_{Sep}
(60) 
_{Oct}
(110) 
_{Nov}
(27) 
_{Dec}
(30) 
2015 
_{Jan}
(43) 
_{Feb}
(67) 
_{Mar}
(71) 
_{Apr}
(92) 
_{May}
(39) 
_{Jun}
(15) 
_{Jul}
(46) 
_{Aug}
(63) 
_{Sep}
(84) 
_{Oct}
(82) 
_{Nov}
(69) 
_{Dec}
(45) 
2016 
_{Jan}
(92) 
_{Feb}
(91) 
_{Mar}
(148) 
_{Apr}
(43) 
_{May}
(58) 
_{Jun}
(117) 
_{Jul}
(92) 
_{Aug}
(140) 
_{Sep}
(49) 
_{Oct}
(33) 
_{Nov}
(85) 
_{Dec}
(40) 
2017 
_{Jan}
(41) 
_{Feb}
(36) 
_{Mar}
(44) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(17) 
2
(2) 
3
(6) 
4
(5) 
5
(1) 
6
(1) 
7

8
(6) 
9
(16) 
10

11
(3) 
12
(8) 
13
(2) 
14
(1) 
15
(3) 
16
(1) 
17

18
(2) 
19
(1) 
20

21

22
(2) 
23

24

25
(5) 
26
(14) 
27
(5) 
28

29
(7) 
30

31
(3) 






From: Derek Gaston <friedmud@gm...>  20080826 17:23:48

On Aug 26, 2008, at 9:27 AM, David Knezevic wrote: > But the L2, H1 etc errors in ExactSolution are computed using > quadrature > rules, so they are just approximations as well. They are not approximations if both your FE solution and the analytic solution you are comparing against can be integrated exactly by the quadrature rule you choose. Otherwise, yep, you're right... it's an approximation. Definitely in the case of comparing two different FE solutions together it's almost always an approximation, unless both solutions have the exact same mesh.... because otherwise you are trying to integrate piecewise continuous functions with Gaussian quadrature rules.... which we all know isn't quite right... but if you squint a little it looks right ;) Derek 
From: David Knezevic <dave.knez@gm...>  20080826 16:57:49

> Well... yeah but it still feels it's a different class of > approximation deserving a different enum. Errors in computing the L2 > and H1 errors are due to quadrature error, which can be bounded in > terms of higherorder derivatives of the exact solution. The > approximate L_INF norm calculation (as we have defined it here) may > not have an error representation which is quite so welldefined ... > then again maybe it does? Seems to me it would depend strongly on the > number of sampling points as well. Yeah, I see what you mean. I suppose the ideal thing (I'm not saying this should be done in practice) would be to compute the interpolant of the error based on values at the quadrature points, and take the L_INFTY norm of the interpolant. Given a regularity assumption on the error, I'm sure there are bounds for the L_INFTY error of the interpolant. However, I think in some cases the maximum of the values at the interpolation points would be a good approximation to the supremum of the interpolant of the error. For example, if the interpolation points are Gauss quadrature points in 1D (or any points that are clustered like Chebyshev points), then I believe that the supremum of the polynomial interpolant will (asympotically) be very close to the maximum of the sampled values, and both of these would converge "spectrally" to the exact L_INFTY error. On the other hand, if we're using bad interpolation points, e.g. equally spaced points in 1D, then the supremum of the interpolant grows exponentially fast compared to the values at the interpolation points, so in that case the heuristic would fail horribly. Anyway, I guess what I'm saying is that I think you're right John, the quadrature point samples need not be a good approximation to the continuous L_INFTY norm, but perhaps it's OK as a heuristic...? >> Also, regarding the superconvergence issue, if we have superconvergence in >> the L_INF norm at the quadrature points, and we use that quadrature rule to >> compute the L2 error, then won't we just get the same superconvergence in >> the quadraturebased L2 error as well? > > I think you are right, so in general one should always use a different > quadrature rule, unless I am mistaken about that superconvergence > property. For the life of me, I can't remember where I heard that and > I'm starting to wonder if I may have made it up :) It seems plausible to me. Or, at a minimum, I've definitely heard about superconvergence at the nodes of the mesh, and the user could use the nodes as quadrature points...  Dave 
From: John Peterson <jwpeterson@gm...>  20080826 15:54:25

On Tue, Aug 26, 2008 at 10:27 AM, David Knezevic <dave.knez@...> wrote: > Hi all, > >>> What about returning this value as the DISCRETE_L_INF norm instead? In >>> particular since the FEMNormType enum offers this norm anyway. >> >> I think this might be confusing ... the DISCRETE_ versions are meant >> to be for R^n vectors, and in this case of course you can get the >> "exact" L_INF. I'd prefer adding a new enum called APPROXIMATE_L_INF >> (or something similar). The user would know immediately that he was >> getting an approximation to the true Linfty norm, and in the >> documentation we could mention (as Derek said) that one can improve >> the approximation by increasing the number of quadrature points. > > > But the L2, H1 etc errors in ExactSolution are computed using quadrature > rules, so they are just approximations as well. As a result, it seems to me > that the L_INF norm based on sampling at quadrature points is the natural > counterpart for the Sobolev norms currently available in ExactSolution. Well... yeah but it still feels it's a different class of approximation deserving a different enum. Errors in computing the L2 and H1 errors are due to quadrature error, which can be bounded in terms of higherorder derivatives of the exact solution. The approximate L_INF norm calculation (as we have defined it here) may not have an error representation which is quite so welldefined ... then again maybe it does? Seems to me it would depend strongly on the number of sampling points as well. > Also, regarding the superconvergence issue, if we have superconvergence in > the L_INF norm at the quadrature points, and we use that quadrature rule to > compute the L2 error, then won't we just get the same superconvergence in > the quadraturebased L2 error as well? I think you are right, so in general one should always use a different quadrature rule, unless I am mistaken about that superconvergence property. For the life of me, I can't remember where I heard that and I'm starting to wonder if I may have made it up :)  John 
From: John Peterson <jwpeterson@gm...>  20080826 15:39:24

On Tue, Aug 26, 2008 at 10:22 AM, Tim Kroeger <tim.kroeger@...> wrote: > Dear John, > > On Tue, 26 Aug 2008, John Peterson wrote: > >> On Tue, Aug 26, 2008 at 9:20 AM, Tim Kroeger >>> >>> On Tue, 26 Aug 2008, John Peterson wrote: >>> >>>> I'm not sure about your implementation of L_INF. You're taking >>>> >>>> e_{\infty} = max_q e(x_q) >>>> >>>> where x_q are the quadrature points. In fact, isn't the solution >>>> sometimes superconvergent at the quadrature points, and therefore this >>>> approximation could drastically underpredict the Linfty norm? >>> >>> Oh, I see, I (again) forgot that people are using different ansatz >>> functions >>> than piecewise linear (for which this is obviously correct). >> >> Sorry, I'm a little slow. The formula above is correct for piecewise >> linears? I can see this for linear elements in 1D, with a 1point >> quadrature rule. But this implies it's not true for a 2point rule... >> etc. > > Oops, I'm very sorry. I mixed up quadrature points and nodes. What I meant > was that for a linear function on a tetrahedron, its maximal value can be > obtained by evaluating it at the corners of the tetrahedron only (and taking > the max of these values). Unfortunately the error is not a linear function in general, even though the approximate solution may be.  John 
From: Tim Kroeger <tim.kroeger@ce...>  20080826 15:36:44

Dear John, On Tue, 26 Aug 2008, John Peterson wrote: > On Tue, Aug 26, 2008 at 9:20 AM, Tim Kroeger >> >> On Tue, 26 Aug 2008, John Peterson wrote: >> >>> I'm not sure about your implementation of L_INF. You're taking >>> >>> e_{\infty} = max_q e(x_q) >>> >>> where x_q are the quadrature points. In fact, isn't the solution >>> sometimes superconvergent at the quadrature points, and therefore this >>> approximation could drastically underpredict the Linfty norm? >> >> Oh, I see, I (again) forgot that people are using different ansatz functions >> than piecewise linear (for which this is obviously correct). > > Sorry, I'm a little slow. The formula above is correct for piecewise > linears? I can see this for linear elements in 1D, with a 1point > quadrature rule. But this implies it's not true for a 2point > rule... etc. Oops, I'm very sorry. I mixed up quadrature points and nodes. What I meant was that for a linear function on a tetrahedron, its maximal value can be obtained by evaluating it at the corners of the tetrahedron only (and taking the max of these values). >> What about returning this value as the DISCRETE_L_INF norm instead? In >> particular since the FEMNormType enum offers this norm anyway. > > I think this might be confusing ... the DISCRETE_ versions are meant > to be for R^n vectors, and in this case of course you can get the > "exact" L_INF. I'd prefer adding a new enum called APPROXIMATE_L_INF > (or something similar). The user would know immediately that he was > getting an approximation to the true Linfty norm, and in the > documentation we could mention (as Derek said) that one can improve > the approximation by increasing the number of quadrature points. Yes, I agree with that. Also, there is a different error in my patch: In parallel, I sum up the Linfty norms of all the processors, instead of taking their max value. I will send you a corrected patch tomorrow. Sorry again. Best Regards, Tim  Dr. Tim Kroeger Phone +494212187710 tim.kroeger@..., tim.kroeger@... Fax +494212184236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.O. Peitgen 
From: John Peterson <jwpeterson@gm...>  20080826 15:36:29

On Tue, Aug 26, 2008 at 10:22 AM, Tim Kroeger <tim.kroeger@...> wrote: > > Also, there is a different error in my patch: In parallel, I sum up the > Linfty norms of all the processors, instead of taking their max value. Ah very true, there is a Parallel::sum for the error_vals at the end of _compute_error(). > I will send you a corrected patch tomorrow. Sounds good. > Sorry again. Not a problem! We are having a (what I find to be) very useful discussion.  John 
From: David Knezevic <dave.knez@gm...>  20080826 15:27:25

Hi all, >> What about returning this value as the DISCRETE_L_INF norm instead? In >> particular since the FEMNormType enum offers this norm anyway. > > I think this might be confusing ... the DISCRETE_ versions are meant > to be for R^n vectors, and in this case of course you can get the > "exact" L_INF. I'd prefer adding a new enum called APPROXIMATE_L_INF > (or something similar). The user would know immediately that he was > getting an approximation to the true Linfty norm, and in the > documentation we could mention (as Derek said) that one can improve > the approximation by increasing the number of quadrature points. But the L2, H1 etc errors in ExactSolution are computed using quadrature rules, so they are just approximations as well. As a result, it seems to me that the L_INF norm based on sampling at quadrature points is the natural counterpart for the Sobolev norms currently available in ExactSolution. Also, regarding the superconvergence issue, if we have superconvergence in the L_INF norm at the quadrature points, and we use that quadrature rule to compute the L2 error, then won't we just get the same superconvergence in the quadraturebased L2 error as well?  Dave 
From: John Peterson <jwpeterson@gm...>  20080826 15:05:37

On Tue, Aug 26, 2008 at 9:20 AM, Tim Kroeger <tim.kroeger@...> wrote: > Dear John, > > On Tue, 26 Aug 2008, John Peterson wrote: > >> I'm not sure about your implementation of L_INF. You're taking >> >> e_{\infty} = max_q e(x_q) >> >> where x_q are the quadrature points. In fact, isn't the solution >> sometimes superconvergent at the quadrature points, and therefore this >> approximation could drastically underpredict the Linfty norm? > > Oh, I see, I (again) forgot that people are using different ansatz functions > than piecewise linear (for which this is obviously correct). Sorry, I'm a little slow. The formula above is correct for piecewise linears? I can see this for linear elements in 1D, with a 1point quadrature rule. But this implies it's not true for a 2point rule... etc. > What about returning this value as the DISCRETE_L_INF norm instead? In > particular since the FEMNormType enum offers this norm anyway. I think this might be confusing ... the DISCRETE_ versions are meant to be for R^n vectors, and in this case of course you can get the "exact" L_INF. I'd prefer adding a new enum called APPROXIMATE_L_INF (or something similar). The user would know immediately that he was getting an approximation to the true Linfty norm, and in the documentation we could mention (as Derek said) that one can improve the approximation by increasing the number of quadrature points.  John 
From: John Peterson <jwpeterson@gm...>  20080826 14:40:54

On Tue, Aug 26, 2008 at 9:15 AM, Derek Gaston <friedmud@...> wrote: > In Encore at Sandia you get the choice to either compute L_Inf at the > quadrature points or at the nodes. > > There really isn't a good way to give L_Inf for a finite element > calculation.... because our solutions are continuous functions. The finite > difference guys would just take the difference at all the nodes and find the > largest one.... but that doesn't quite work for us (especially with higher > order elements). Given the exact solution and gradient, one could presumably come up with a little function optimization scheme which finds (a local) max on each element. The trouble would still be knowing whether the max found was actually the global max for that element... > Personally, I prefer finding the L_Inf error at quadrature points... one > nice thing about this is that if you want a better calculation of your > error... you just up your number of quadrature points. This is essentially > the same thing as comparing to a nonpolynomial exact solution (one you > can't integrate exactly).... you do _something_ that will give you a good > answer... but if you want a better answer you crank up the quadrature rule. Good point about increasing the number of quadrature points to get a better Linfty approximation. And as long as you are using a different quadrature rule for estimating the error than was used when computing the FE solution, I don't think the error can possibly be superconvergent at the quadrature points any more.  John 
From: Tim Kroeger <tim.kroeger@ce...>  20080826 14:20:14

Dear John, On Tue, 26 Aug 2008, John Peterson wrote: > I'm not sure about your implementation of L_INF. You're taking > > e_{\infty} = max_q e(x_q) > > where x_q are the quadrature points. In fact, isn't the solution > sometimes superconvergent at the quadrature points, and therefore this > approximation could drastically underpredict the Linfty norm? Oh, I see, I (again) forgot that people are using different ansatz functions than piecewise linear (for which this is obviously correct). What about returning this value as the DISCRETE_L_INF norm instead? In particular since the FEMNormType enum offers this norm anyway. Best Regards, Tim  Dr. Tim Kroeger Phone +494212187710 tim.kroeger@..., tim.kroeger@... Fax +494212184236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.O. Peitgen 
From: Derek Gaston <friedmud@gm...>  20080826 14:17:03

In Encore at Sandia you get the choice to either compute L_Inf at the quadrature points or at the nodes. There really isn't a good way to give L_Inf for a finite element calculation.... because our solutions are continuous functions. The finite difference guys would just take the difference at all the nodes and find the largest one.... but that doesn't quite work for us (especially with higher order elements). Personally, I prefer finding the L_Inf error at quadrature points... one nice thing about this is that if you want a better calculation of your error... you just up your number of quadrature points. This is essentially the same thing as comparing to a nonpolynomial exact solution (one you can't integrate exactly).... you do _something_ that will give you a good answer... but if you want a better answer you crank up the quadrature rule. Derek On Aug 26, 2008, at 8:10 AM, John Peterson wrote: > On Tue, Aug 26, 2008 at 5:02 AM, Tim Kroeger > <tim.kroeger@...> wrote: >> Dear John, >> >> On Mon, 25 Aug 2008, John Peterson wrote: >> >>> On Mon, Aug 25, 2008 at 8:28 AM, Tim Kroeger >> >>>> Would you please be so kind and check that changes in (provided >>>> you like >>>> them)? >>> >>> I'll take a look at this patch today. Thanks! >> >> So, what was the result of looking at the patch? > > I'm not sure about your implementation of L_INF. You're taking > > e_{\infty} = max_q e(x_q) > > where x_q are the quadrature points. In fact, isn't the solution > sometimes superconvergent at the quadrature points, and therefore this > approximation could drastically underpredict the Linfty norm? I > don't know of an efficient, simple algorithm for estimating Linfty > error ... perhaps there is something out there? > > My preference would be to leave out the L_INF calculation rather than > return a potentially wrong value, but I would like the other > developers (esp. Roy, who is on holiday now) to comment as well. > >  > John > >  > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblincontest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: John Peterson <jwpeterson@gm...>  20080826 14:10:50

On Tue, Aug 26, 2008 at 5:02 AM, Tim Kroeger <tim.kroeger@...> wrote: > Dear John, > > On Mon, 25 Aug 2008, John Peterson wrote: > >> On Mon, Aug 25, 2008 at 8:28 AM, Tim Kroeger > >>> Would you please be so kind and check that changes in (provided you like >>> them)? >> >> I'll take a look at this patch today. Thanks! > > So, what was the result of looking at the patch? I'm not sure about your implementation of L_INF. You're taking e_{\infty} = max_q e(x_q) where x_q are the quadrature points. In fact, isn't the solution sometimes superconvergent at the quadrature points, and therefore this approximation could drastically underpredict the Linfty norm? I don't know of an efficient, simple algorithm for estimating Linfty error ... perhaps there is something out there? My preference would be to leave out the L_INF calculation rather than return a potentially wrong value, but I would like the other developers (esp. Roy, who is on holiday now) to comment as well.  John 
From: Tim Kroeger <tim.kroeger@ce...>  20080826 13:43:38

Dear libMesh developer team, Could someone please tell me what the current state about the item mentioned below is? I just want to know, so that I can decide whether I should wait or get around somehow or whatever. (In the current state, my code does not show any speedup on 20 processors compared with 1 processor, because it spends apparently 95% of the time in EquationSystems::reinit().) Best Regards, Tim On Wed, 16 Apr 2008, Roy Stogner wrote: > > On Wed, 16 Apr 2008, Tim Kroeger wrote: > >> As I'm just so much in asking questions, here's another one: How will >> the performance of EquationSystems::reinit() behave when ParallelMesh >> is ready for use by user application? > > At first, just as badly as before. System::project_vector() is still > one of the things we use a serial vector for, and while that's on the > list of ParallelMesh items to be fixed, it's not high enough on the > list. > >> The reason for my question is that for my code on a large number of >> processors, EquationSystems::reinit() is quite a bottle neck. > > You're not the only one seeing that. We'll definitely fix the poor > scaling there before we consider ParallelMesh "done", but there will > probably be a 0.6.9 release first once ParallelMesh is in a "correct > but not yet complete" state. >  > Roy >  Dr. Tim Kroeger Phone +494212187710 tim.kroeger@..., tim.kroeger@... Fax +494212184236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.O. Peitgen 
From: Tim Kroeger <tim.kroeger@ce...>  20080826 10:09:41

Dear John, On Mon, 25 Aug 2008, John Peterson wrote: > On Mon, Aug 25, 2008 at 8:28 AM, Tim Kroeger >> Would you please be so kind and check that changes in (provided you like >> them)? > > I'll take a look at this patch today. Thanks! So, what was the result of looking at the patch? Best Regards, Tim  Dr. Tim Kroeger Phone +494212187710 tim.kroeger@..., tim.kroeger@... Fax +494212184236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.O. Peitgen 