Re: [Libmesh-users] hp elements

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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 high-order
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 non-product 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 (non-infinite) 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 p-FEM, but with
> >anisotropic p-order, 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 p-FEM, but with only constant
> >  p-order throughout the mesh.  This order is (currently) determined
> >  once for all through the FEType that you have to create in the
> >  EquationSystems/SystemBase-child 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:
> >         o----o----o
> >  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 first-order element, then number the dofs on the
> >  second-order-nodes (this is particularly helpful when having a 2nd-order
> >  mesh, but you only want to use 1st-order 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 --enable-expensive (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 p-FEM 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 variable-order-p-FEM 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/
> >>_______________________________________________
> >>Libmesh-users mailing list
> >>Lib...@li...
> >>https://lists.sourceforge.net/lists/listinfo/libmesh-users
> >>
> >>    
> >>
> >
> >
> >-------------------------------------------------------
> >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
> >_______________________________________________
> >Libmesh-users mailing list
> >Lib...@li...
> >https://lists.sourceforge.net/lists/listinfo/libmesh-users
> >  
> >
> 
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
> 