RE: [Libmesh-devel] compute_constraints

[Roy S. <roy...@ic...>]

On Wed, 19 Jan 2005, KIRK, BENJAMIN (JSC-EG) (NASA) wrote:

> Excellent!  Will this be the default behavior and then let specific finite
> elements (e.g. LAGRANGE) overload or re-implement the method?

At the moment I'm making this a Clough-specific behavior, but making
it the default after it's tested is my plan - reimplementation will
just require adding more cases to the switch statements in
fe_interface.C too.  Remind me again why the finite element types are
using template specialization instead of inheritance?  ;-)

> The L2 projection method is perfect since it addresses the problem for
> arbitrary element types.  In fact, it can be extended to use the normal
> equations to handle p mismatch on an edge as well.

I'd certainly like to see continuous hp-refinable function spaces in
libMesh, but I'm not sure how much of a help this will be.  Shouldn't
the hierarchic basis functions be able to handle p mismatch for C0
elements?  If element 1 has a polynomial degree p and adjacent element
2 has higher degree q, then isn't the constraint just "element 2 shape
functions with degree p+1 through q and support on edge 1-2 get
dropped"?

No, on second thought it's more complicated than that - basis
functions can have higher polynomial degree perpendicular to a face
than they do in the face, and the case of simultaneous h refinement
gets even uglier.

Should I be preparing for this case in the automatic code, then?
Right now I'm just doing the projection between parent and child
degrees of freedom; perhaps I should be doing neighbor and child
instead.

> directly. Line 622 in fe_lagrange.C simply says keep constraints that look
> like this:
>
> u_1 = 0.5*u_2 + 0.5*u_3
>
> and ignore ones that look like this:
>
> u_1 = 0.9999 * u_1 + 1.e-6 * u_2 + 1.e-6 * u_3
>
> Which we can recognize as u_1 = u_1, which is not a constraint at all...

What about lines that look like this?

u_1 = 0.99999 * u_3

That's not on the identity diagonal, yet it's the sort of situation I
would expect to happen when a nodal degree of freedom on a Lagrangian
quadratic child element corresponds to a midedge or midface DoF on the
parent: the coefficient is still 1, but the local numbering doesn't
match.
---
Roy Stogner