From: KIRK, BENJAMIN (JSCEG) (NASA) <benjamin.kirk1@na...>  20050119 17:53:33

Right, the local numbering does not match, but the global numbering should (which is all that really matters). I just added an assertion to, uh, assert this. I would continue with the implementation as you have it planned... I would like to keep the implementation in terms of parentchild relationships wherever possible to protect locality. We can handle the complications with recursive constraints later. As for the FE template madness, I don't have a good answer... :) Just something that seemed like a good idea at the time. Like anything else, though, it could be changed. There are very few (none?) things in the library I consider set in stone... Ben Original Message From: Roy Stogner [mailto:roystgnr@...] Sent: Wednesday, January 19, 2005 11:11 AM To: KIRK, BENJAMIN (JSCEG) (NASA) Cc: libmeshdevel@... Subject: RE: [Libmeshdevel] compute_constraints On Wed, 19 Jan 2005, KIRK, BENJAMIN (JSCEG) (NASA) wrote: > Excellent! Will this be the default behavior and then let specific > finite elements (e.g. LAGRANGE) overload or reimplement the method? At the moment I'm making this a Cloughspecific 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 hprefinable 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 12 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.e6 * u_2 + 1.e6 * 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 