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)
From: Minq Q <micavn@gm...>  20100322 22:29:53

Hi again, > assume you mean P2P1 TaylorHood elements? Check out libMesh examples 13 and 18. I am sorry, The elements I am asking is not P1isoP2. The correct is P1isoP2/P1 element. Here, the pressure and velocity variables are discrete by the linear elements. But the velocity elements are "twice finer" than the pressure element. That mean, 4 velocity elements = 1 pressure element. Can I do it with libMesh? Thanks a lot, / Ming Q. 
From: Roy Stogner <roystgnr@ic...>  20100323 02:23:53

On Mon, 22 Mar 2010, Minq Q wrote: > I am sorry, The elements I am asking is not P1isoP2. The correct is > P1isoP2/P1 element. Here, the pressure and velocity variables are discrete > by the linear elements. But the velocity elements are "twice finer" than the > pressure element. That mean, 4 velocity elements = 1 pressure element. > > Can I do it with libMesh? Only with some difficulty  we don't have those elements right now, so you'd have to create a new FEType, code the shape functions, and add a new macroelement quadrature rule for the integration. None of that is easy, but it's definitely doable. Coincidentally, that all describes my own first contributions to libMesh, in the CLOUGH finite elements. You'd have it a bit easier than I did: the CloughTocher shape functions are hairier, you've now got a macroelement quadrature rule (QClough) to use as an example, and now adaptivity works with arbitrary C0 elements without any special effort on your part. That may be more work than you wanted, but if you do give it a try, let us know and we'd be happy to add it in to the main library.  Roy 
From: Liang <goeasyon@gm...>  20100323 02:54:46

> > Only with some difficulty  we don't have those elements right now, so > you'd have to create a new FEType, code the shape functions, and add a > new macroelement quadrature rule for the integration. > > None of that is easy, but it's definitely doable. Coincidentally, > that all describes my own first contributions to libMesh, in the > CLOUGH finite elements. You'd have it a bit easier than I did: the > CloughTocher shape functions are hairier, you've now got a > macroelement quadrature rule (QClough) to use as an example, and now > adaptivity works with arbitrary C0 elements without any special effort > on your part. > > That may be more work than you wanted, but if you do give it a try, > let us know and we'd be happy to add it in to the main library. >  > Roy > > Sounds a difficult work. I have a question on the quadrature rule of integration, doesn't the libmesh use the unified gausslegendre quadrature for all elements? I knew some FEA packages use the gausslegendre for any element, or it is a different concept between the macroelement and the single element? Liang 
From: Roy Stogner <roystgnr@ic...>  20100323 03:08:15

On Mon, 22 Mar 2010, Liang wrote: > Sounds a difficult work. I have a question on the quadrature rule of > integration, doesn't the libmesh use the unified gausslegendre quadrature > for all elements? I knew some FEA packages use the gausslegendre for any > element, or it is a different concept between the macroelement and the single > element? GaussLegendre rules of high enough order give exact results for polynomial nonmacroelements, but on a macroelement the reduced smoothness between subelements hurts you. The easiest (albeit not the most efficient) solution for piecewisepolynomial macroelements is to just combine a (translated and reweighted) Gauss rule on each subelement. libMesh has a bunch of nonGaussLegendre rules for general elements available too; some for verification and underintegration, some just because there are multiple ways to do quadrature in 2D/3D with different tradeoffs. Check the source code first if you're curious; John has most of it pretty well documented.  Roy 
From: Liang <goeasyon@gm...>  20100323 03:18:39

> > GaussLegendre rules of high enough order give exact results for > polynomial nonmacroelements, but on a macroelement the reduced > smoothness between subelements hurts you. The easiest (albeit not the > most efficient) solution for piecewisepolynomial macroelements is to > just combine a (translated and reweighted) Gauss rule on each > subelement. > > libMesh has a bunch of nonGaussLegendre rules for general elements > available too; some for verification and underintegration, some just > because there are multiple ways to do quadrature in 2D/3D with > different tradeoffs. Check the source code first if you're curious; > John has most of it pretty well documented. >  > Roy > Interesting, I appreciate your clear explanation, yes I just know something about basic nonmacroelement from the textbook. it is obvious that libmesh is not only a software but also a wonderful modern FEA tutorial. there are already lots of libmesh source codes on my list. Thanks! Liang 
From: John Peterson <peterson@cf...>  20100323 19:29:03

I failed to copy my reply to the list yesterday; obviously Roy has already responded to this question. Roy: Is my memory correct in that this is the same "perfectly unnested" element (with respect to hrefinement) we looked at for shallow water equations a while back?  John  Forwarded message  From: John Peterson <peterson@...> Date: Mon, Mar 22, 2010 at 6:18 PM Subject: Re: [Libmeshusers] P2isoP1 To: Minq Q <micavn@...> On Mon, Mar 22, 2010 at 5:29 PM, Minq Q <micavn@...> wrote: > Hi again, > >> assume you mean P2P1 TaylorHood elements? Check out libMesh examples 13 > and 18. > > I am sorry, The elements I am asking is not P1isoP2. The correct is > P1isoP2/P1 element. Here, the pressure and velocity variables are discrete > by the linear elements. But the velocity elements are "twice finer" than the > pressure element. That mean, 4 velocity elements = 1 pressure element. Yeah, according to Gresho and Sani, this is like a P1 P1 (triangular) element on a 4patch macroelement in 2D, and something equivalent in 3D. I'm not sure what the benefit is though, since they also say it's a 1storder element. I think this is an element we looked at while doing shallowwater equations a while back, but we abandoned the idea because the function spaces don't nest under refinement... > Can I do it with libMesh? Not asis, but I'll let Roy comment further. He has implemented what I would consider much more complicated macroelements in Libmesh, and would probably be able to give you a much better answer. 
From: Roy Stogner <roystgnr@ic...>  20100323 19:42:11

On Tue, 23 Mar 2010, John Peterson wrote: > Roy: Is my memory correct in that this is the same "perfectly > unnested" element (with respect to hrefinement) we looked at for > shallow water equations a while back? You're thinking of the P1NC "P1 NonConforming" element, right? No, that one was simpler in some ways (only 1 dof per edge, instead of 1 per edge and 1 per vertex, and it was linear on the whole element with no subelements) and horribly more complex (did we *ever* figure out the right way to do hanging node refinement with it?) in others. This one's a plain C0 element, 6 nodes on triangles, Lagrange basis; the distinction from our LAGRANGE quadratic is that the function space is linear on each of the 4 subelements rather than a quadratic on the whole element. You're right that it's a lowerorder element; I don't recall what the advantage over P1/P0 is supposed to be.  Roy 
From: John Peterson <peterson@cf...>  20100323 19:47:40

On Tue, Mar 23, 2010 at 2:41 PM, Roy Stogner <roystgnr@...> wrote: > > On Tue, 23 Mar 2010, John Peterson wrote: > >> Roy: Is my memory correct in that this is the same "perfectly >> unnested" element (with respect to hrefinement) we looked at for >> shallow water equations a while back? > > You're thinking of the P1NC "P1 NonConforming" element, right? No, > that one was simpler in some ways (only 1 dof per edge, instead of 1 > per edge and 1 per vertex, and it was linear on the whole element with > no subelements) and horribly more complex (did we *ever* figure out > the right way to do hanging node refinement with it?) in others. > > This one's a plain C0 element, 6 nodes on triangles, Lagrange basis; > the distinction from our LAGRANGE quadratic is that the function space > is linear on each of the 4 subelements rather than a quadratic on the > whole element. > > You're right that it's a lowerorder element; I don't recall what the > advantage over P1/P0 is supposed to be. P1/P0 is not LBBstable. Gresho & Sani also say "sometimes locks" and "rarely, if ever, usable." Ouch. iso P2  P1 on the other hand, is LBBstable.  John 
From: Vasilis Vavourakis <vasvav@gm...>  20100323 19:49:16

2010/3/23 John Peterson <peterson@...> > On Tue, Mar 23, 2010 at 2:41 PM, Roy Stogner <roystgnr@...> > wrote: > > > > On Tue, 23 Mar 2010, John Peterson wrote: > > > >> Roy: Is my memory correct in that this is the same "perfectly > >> unnested" element (with respect to hrefinement) we looked at for > >> shallow water equations a while back? > > > > You're thinking of the P1NC "P1 NonConforming" element, right? No, > > that one was simpler in some ways (only 1 dof per edge, instead of 1 > > per edge and 1 per vertex, and it was linear on the whole element with > > no subelements) and horribly more complex (did we *ever* figure out > > the right way to do hanging node refinement with it?) in others. > > > > This one's a plain C0 element, 6 nodes on triangles, Lagrange basis; > > the distinction from our LAGRANGE quadratic is that the function space > > is linear on each of the 4 subelements rather than a quadratic on the > > whole element. > > > > You're right that it's a lowerorder element; I don't recall what the > > advantage over P1/P0 is supposed to be. > > P1/P0 is not LBBstable. Gresho & Sani also say "sometimes locks" and > "rarely, if ever, usable." Ouch. > > iso P2  P1 on the other hand, is LBBstable. > what about the P2P0 case? any opinions/experience on that? regards, Vasilis >  > John > > >  > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and finetune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intelswdev > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: John Peterson <peterson@cf...>  20100323 19:58:27

On Tue, Mar 23, 2010 at 2:49 PM, Vasilis Vavourakis <vasvav@...> wrote: > > what about the P2P0 case? any opinions/experience on that? No experience, but G&S says: LBB stable, "simple," "only first order accurate," and "better than P2 P{1} in some tests*. *Thompson, "Average and complete incompressibility in the finite element method," IJNME 9:925932, 1975  John 
From: Roy Stogner <roystgnr@ic...>  20100323 19:51:56

On Tue, 23 Mar 2010, John Peterson wrote: > On Tue, Mar 23, 2010 at 2:41 PM, Roy Stogner <roystgnr@...> wrote: > >> You're right that it's a lowerorder element; I don't recall what the >> advantage over P1/P0 is supposed to be. > > P1/P0 is not LBBstable. Gresho & Sani also say "sometimes locks" and > "rarely, if ever, usable." Ouch. Gah! I must be slipping. I could have sworn there was an LBBstable way of using discontinuous constants for pressure without adding any stabilization term. Q1/P0??  Roy 
From: Jed Brown <jed@59...>  20100323 19:59:48

On Tue, 23 Mar 2010 14:51:49 0500 (CDT), Roy Stogner <roystgnr@...> wrote: > Gah! I must be slipping. I could have sworn there was an LBBstable > way of using discontinuous constants for pressure without adding any > stabilization term. Q1/P0?? Also not stable, but used pretty frequently (usually with penalty). Nonconforming Q_1 velocity (dofs at face centers) works. As far as I know, the only reason to use iso P2P1 is to get a sparser velocity system than P2 (or Q2) velocities. Jed 
From: John Peterson <peterson@cf...>  20100323 20:00:20

On Tue, Mar 23, 2010 at 2:51 PM, Roy Stogner <roystgnr@...> wrote: > > On Tue, 23 Mar 2010, John Peterson wrote: > >> On Tue, Mar 23, 2010 at 2:41 PM, Roy Stogner <roystgnr@...> >> wrote: >> >>> You're right that it's a lowerorder element; I don't recall what the >>> advantage over P1/P0 is supposed to be. >> >> P1/P0 is not LBBstable. Gresho & Sani also say "sometimes locks" and >> "rarely, if ever, usable." Ouch. > > Gah! I must be slipping. I could have sworn there was an LBBstable > way of using discontinuous constants for pressure without adding any > stabilization term. Q1/P0?? Aka Q1Q0. Not LBB stable, but "simple" and "penalty method works". "Mathematicians hate it", "firstorder usually".  John 
Sign up for the SourceForge newsletter:
No, thanks