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 > > 