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: Luca Antiga <lantiga@im...>  20031202 06:46:54

Hi guys, congratulations for the great job you're doing. I need to implement hp elements on unstructured grids. Are there any limitations in the design of libMesh that would make it impractical to build hp elements on the existing framework? Thank you in advance Luca 
From: John Peterson <peterson@cf...>  20031202 14:39:30

Luca Antiga writes: > Hi guys, > Are there any > limitations in the design of libMesh that would make it impractical to > build hp elements on the existing framework? There shouldn't be. libMesh was designed to (someday) be capable of the hp version of finite elements. The theoretical issues of hp, e.g. what error indicators are appropriate, how to implement anisotropic h refinement, etc. are still research topics however. I think Ben has some plans in mind on how he would implement p refinement, which he might post to the mailing list as well. John 
From: Daniel Dreyer <d.dreyer@tu...>  20031202 21:37:41

As already mentioned by Ben, there is no obstacle in the way. Actually, here some more details that arose during the implementation of the infinite elements (which are actually also pFEM, but with anisotropic porder, therefore we have _two_ Order enums, namely the radial_order and the base_order in FEType, when ENABLE_INFINITE_ELEMENTS is active):  momentarily, libmesh already offers pFEM, but with only constant porder throughout the mesh. This order is (currently) determined once for all through the FEType that you have to create in the EquationSystems/SystemBasechild context, when you say add_variable(). (note that there is also the simplified variant of add_variable() which only takes an order, and assumes LAGRANGE as family, which only goes up to p=2, use instead e.g. HIERARCHIC). In the FEType, you say what order = p you want. This information is then broadcasted to all objects that may handle a degree of freedom: The DofObject. Each DofObject may hold _multiple_ components per dof... E.g. you have an EDGE3, but you want to use p=3. Then you have 4 dof: ooo dof: 0 2,3 1 node: 0 2 1 This is also the numbering scheme in libmesh, first number the nodes that belong to the firstorder element, then number the dofs on the secondordernodes (this is particularly helpful when having a 2ndorder mesh, but you only want to use 1storder shapes). the DofObject>n_comp() gives then for: Node(0) = 1 Node(1) = 1 Node(2) = 2 And since both Node and Elem derive from DofObject, you may easily handle bubble shapes etc, consult the HIERARCHIC family.  note that you have to enableexpensive (or so) in ./configure to get the full support.  GOOD news: the truly tedious work of coding the shapes is already in progress, _several_ new pFEM families are underway: Steffen and Hendrik have already come a long way implementing them, like the ones that want to orthogonalize the stiffness matrix (integrated Legendre), improved variants (by Adjerid), and two more pretty interesting families that also seem to work well on simplices. I suggest you contact Steffen directly for more information. As far as i know, he almost finished debugging 2D, and wants to proceed to 3D. So perhaps some collab' may be possible.  extending to variableorderpFEM is an issue i already thought of in the context of the infinite elements, and also talked to Ben about it. So, feel free to contact for a more detailed discussion. Daniel >  > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Benjamin S. Kirk <benkirk@cf...>  20031205 20:36:14

Thanks, Daniel, for that complete overview! As Daniel said, right now (noninfinite) finite elements are defined by an order (p) and a family. The order simply defines the polynomial degree that is used for the approximation space, and the family defines the type of shape functions that are used. Right now both are constant for the entire mesh. Unless someone has a good reason I haven't thought of, I see no need to support variable *families*. That is, if you want to use hierarchic shape functions, you will use hierarchic shape functions on all elements. This will greatly simplify matters... Can you imagine what a pain it would be to handle solution projection in an efficient manner when there may be h,p, *and* family changes going on?? However, the constant p restriction is probably the one you want removed, and the good news is that it shouldn't be that hard. There are just a few things that need to happen: 1.) each DofObject (and, by inheritance, elements) should get an order() that defines the approximation order on the element. The order() for nodes is determined by the elements connected to them.  easy 2.) The reinit() member in the finite element objects will need to get a little smarter & recompute data every time P changes. This could be implemented carefully to be really efficient. For example, behind the scenes we should probably cache element types of various orders so that everything does not get recomputed for each element.  tricky 3.) Hanging node constraints must be generalized for all families and orders  not trivial 4.) The solution projection algorithm needs to be generalized  easy That's it, as I see it... there might be some complications for the infinite elements that I am not aware of? Ben Daniel Dreyer wrote: >As already mentioned by Ben, there is no obstacle in the way. >Actually, here some more details that arose during the implementation >of the infinite elements (which are actually also pFEM, but with >anisotropic porder, therefore we have _two_ Order enums, namely the >radial_order and the base_order in FEType, when ENABLE_INFINITE_ELEMENTS >is active): > > > momentarily, libmesh already offers pFEM, but with only constant > porder throughout the mesh. This order is (currently) determined > once for all through the FEType that you have to create in the > EquationSystems/SystemBasechild context, when you say add_variable(). > (note that there is also the simplified variant of add_variable() > which only takes an order, and assumes LAGRANGE as family, which > only goes up to p=2, use instead e.g. HIERARCHIC). > > In the FEType, you say what order = p you want. This information is > then broadcasted to all objects that may handle a degree of freedom: > The DofObject. Each DofObject may hold _multiple_ components per > dof... > > E.g. you have an EDGE3, but you want to use p=3. Then you have > 4 dof: > ooo > dof: 0 2,3 1 > node: 0 2 1 > > This is also the numbering scheme in libmesh, first number the nodes > that belong to the firstorder element, then number the dofs on the > secondordernodes (this is particularly helpful when having a 2ndorder > mesh, but you only want to use 1storder shapes). > the DofObject>n_comp() gives then for: > > Node(0) = 1 > Node(1) = 1 > Node(2) = 2 > > And since both Node and Elem derive from DofObject, > you may easily handle bubble shapes etc, consult the HIERARCHIC family. > > > note that you have to enableexpensive (or so) in ./configure to > get the full support. > > > GOOD news: the truly tedious work of coding the shapes is already > in progress, _several_ new pFEM families are underway: Steffen and > Hendrik have already come a long way implementing them, like the ones > that want to orthogonalize the stiffness matrix (integrated Legendre), > improved variants (by Adjerid), and two more pretty interesting > families that also seem to work well on simplices. > > I suggest you contact Steffen directly for more information. As far > as i know, he almost finished debugging 2D, and wants to proceed to 3D. > So perhaps some collab' may be possible. > > > extending to variableorderpFEM is an issue i already thought of > in the context of the infinite elements, and also talked to Ben about > it. So, feel free to contact for a more detailed discussion. > >Daniel > > > >> >>This SF.net email is sponsored by: SF.net Giveback Program. >>Does SourceForge.net help you be more productive? Does it >>help you create better code? SHARE THE LOVE, and help us help >>YOU! Click Here: http://sourceforge.net/donate/ >>_______________________________________________ >>Libmeshusers mailing list >>Libmeshusers@... >>https://lists.sourceforge.net/lists/listinfo/libmeshusers >> >> >> > > > >This SF.net email is sponsored by OSDN's Audience Survey. >Help shape OSDN's sites and tell us what you think. Take this >five minute survey and you could win a $250 Gift Certificate. >http://www.wrgsurveys.com/2003/osdntech03.php?site=8 >_______________________________________________ >Libmeshusers mailing list >Libmeshusers@... >https://lists.sourceforge.net/lists/listinfo/libmeshusers > > 
From: Luca Antiga <lantiga@im...>  20031205 22:48:05

Thanks for the complete feedback. It was very helpful. I agree with Ben that one probably wouldn't need to generalize up to the point of having different families in the same mesh (although this could potentially be a cool feature, thinking about large scale problems). I'm interested in implementing Dubiner's orthogonal basis (see Sherwin and Karniadakis, Int J Num Meth Eng 1995). I noticed that the highorder Gaussian quadrature rules implemented in libMesh already use the same kind of shifted product. It's not so aesthetically pleasing as it doesn't produce a symmetric nodal distribution, but it's nice as it's the product of 1D Jacobi polynomials, which is what I need. Is there any particular families you guys were thinking about? I'm looking right now into Adjerid's base mentioned by Daniel. There's also a nonproduct basis employed by Hesthaven and Warburton based on the 3d multivariate Legendre polynomials which preserves symmetry. Probably the choice should be oriented towards the basis which makes it easier to express the hanging node constraints. Luca On Fri, 5 Dec 2003, Benjamin S. Kirk wrote: > Thanks, Daniel, for that complete overview! > > As Daniel said, right now (noninfinite) finite elements are defined by > an order (p) and a family. The order simply defines the polynomial > degree that is used for the approximation space, and the family defines > the type of shape functions that are used. Right now both are constant > for the entire mesh. > > Unless someone has a good reason I haven't thought of, I see no need to > support variable *families*. That is, if you want to use hierarchic > shape functions, you will use hierarchic shape functions on all > elements. This will greatly simplify matters... Can you imagine what a > pain it would be to handle solution projection in an efficient manner > when there may be h,p, *and* family changes going on?? > > However, the constant p restriction is probably the one you want > removed, and the good news is that it shouldn't be that hard. There are > just a few things that need to happen: > > 1.) each DofObject (and, by inheritance, elements) should get an > order() that defines the approximation order on the element. The > order() for nodes is determined by the elements connected to them.  easy > > 2.) The reinit() member in the finite element objects will need to get a > little smarter & recompute data every time P changes. This could be > implemented carefully to be really efficient. For example, behind the > scenes we should probably cache element types of various orders so that > everything does not get recomputed for each element. >  tricky > > 3.) Hanging node constraints must be generalized for all families and > orders  not trivial > > 4.) The solution projection algorithm needs to be generalized  easy > > > That's it, as I see it... there might be some complications for the > infinite elements that I am not aware of? > > Ben > > > > Daniel Dreyer wrote: > > >As already mentioned by Ben, there is no obstacle in the way. > >Actually, here some more details that arose during the implementation > >of the infinite elements (which are actually also pFEM, but with > >anisotropic porder, therefore we have _two_ Order enums, namely the > >radial_order and the base_order in FEType, when ENABLE_INFINITE_ELEMENTS > >is active): > > > > > > momentarily, libmesh already offers pFEM, but with only constant > > porder throughout the mesh. This order is (currently) determined > > once for all through the FEType that you have to create in the > > EquationSystems/SystemBasechild context, when you say add_variable(). > > (note that there is also the simplified variant of add_variable() > > which only takes an order, and assumes LAGRANGE as family, which > > only goes up to p=2, use instead e.g. HIERARCHIC). > > > > In the FEType, you say what order = p you want. This information is > > then broadcasted to all objects that may handle a degree of freedom: > > The DofObject. Each DofObject may hold _multiple_ components per > > dof... > > > > E.g. you have an EDGE3, but you want to use p=3. Then you have > > 4 dof: > > ooo > > dof: 0 2,3 1 > > node: 0 2 1 > > > > This is also the numbering scheme in libmesh, first number the nodes > > that belong to the firstorder element, then number the dofs on the > > secondordernodes (this is particularly helpful when having a 2ndorder > > mesh, but you only want to use 1storder shapes). > > the DofObject>n_comp() gives then for: > > > > Node(0) = 1 > > Node(1) = 1 > > Node(2) = 2 > > > > And since both Node and Elem derive from DofObject, > > you may easily handle bubble shapes etc, consult the HIERARCHIC family. > > > > > > note that you have to enableexpensive (or so) in ./configure to > > get the full support. > > > > > > GOOD news: the truly tedious work of coding the shapes is already > > in progress, _several_ new pFEM families are underway: Steffen and > > Hendrik have already come a long way implementing them, like the ones > > that want to orthogonalize the stiffness matrix (integrated Legendre), > > improved variants (by Adjerid), and two more pretty interesting > > families that also seem to work well on simplices. > > > > I suggest you contact Steffen directly for more information. As far > > as i know, he almost finished debugging 2D, and wants to proceed to 3D. > > So perhaps some collab' may be possible. > > > > > > extending to variableorderpFEM is an issue i already thought of > > in the context of the infinite elements, and also talked to Ben about > > it. So, feel free to contact for a more detailed discussion. > > > >Daniel > > > > > > > >> > >>This SF.net email is sponsored by: SF.net Giveback Program. > >>Does SourceForge.net help you be more productive? Does it > >>help you create better code? SHARE THE LOVE, and help us help > >>YOU! Click Here: http://sourceforge.net/donate/ > >>_______________________________________________ > >>Libmeshusers mailing list > >>Libmeshusers@... > >>https://lists.sourceforge.net/lists/listinfo/libmeshusers > >> > >> > >> > > > > > > > >This SF.net email is sponsored by OSDN's Audience Survey. > >Help shape OSDN's sites and tell us what you think. Take this > >five minute survey and you could win a $250 Gift Certificate. > >http://www.wrgsurveys.com/2003/osdntech03.php?site=8 > >_______________________________________________ > >Libmeshusers mailing list > >Libmeshusers@... > >https://lists.sourceforge.net/lists/listinfo/libmeshusers > > > > > > > >  > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
Sign up for the SourceForge newsletter:
No, thanks