[Libmesh-devel] RE: Recursive hanging node constraints are broken? From: Kirk, Benjamin \(JSC-EG\) - 2006-05-26 16:46:40 ```I'm looking at it now. Unfortunately, I still cannot access the CVS server from work so I will get the new code when I get home... Also, I think you are right, the problem is that create_dof_constraints() is only looking at the *active* elements, while for level>1 mismatch you also need to consider that *inactive* elements may also have constraints which need to be computed. Using ViewCVS, it looks like the change occurred between 1.14 and 1.15 for dof_map_constraints.C. Let me try to explain the way I think it should work, and let me know what you think. Of course, when I get CVS write access at home I should probably put this in the comments... I'm posting it to the devel list for archival. - In general, face mismatch will result in constraints - An element is constrained in terms of its parents degrees of freedom. U_e =3D C_e U_p - For edges in 3D or mismatch>1 in any-D the parent's degrees of freedom may themselves be constrained in terms of other "grandparent" degrees of freedom: U_p =3D C_p U_gp --> U_e =3D C_e C_p U_gp So, the implementation is as follows: - For *any* element with a face mismatch compute constraints between its degrees of freedom and those of its parent. Currently, "face mismatch" is defined as a level mismatch, but this will need to be generalized before we can support anisotropic h-refinement. Note that when the level-1 rule is not enforced face mismatch may occur for non-active elements. - when constructing the constraint matrix for a given element recursion is used. The element's dofs constraints are written in terms of other dofs (obviously). However, these other dofs may themselves be constrained in terms of still more dofs (see above). Hence, the constraint matrix creation is a recursive process which terminates when the local element degrees of freedom is expressed as a linear combination of entirely *unconstrained* dofs. -Ben ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~ (Below are some ramblings before I realized only active elements were considered for constraints) I'm not so opposed to using neighbors, but what I am concerned about is the following case which can arise in 3D: Consider the 2D Cartesian quadrants I,II,III,IV. Suppose there is a hex element in each one, so they are face neighbors across the x & y axes. - refine the element in quadrant III. =20 (no problem. Level-1 mismatch with those in II and IV). - refine the elements in quadrant III again. (when enforcing level-1, will require elements in Q II & IV to be refined. QI still at coarse level) - The edge shared between the elements in QIII and QI now has a level-II mismatch even though the level-1 face neighbor restriction is met. - The code is _supposed_ to work in this case, and the "recursive magic" which should work here should extend to the mismatch case as well. At any rate, I'll keep you posted. -Ben =20 -----Original Message----- From: Roy Stogner [mailto:roystgnr@...]=20 Sent: Friday, May 26, 2006 10:49 AM To: Kirk, Benjamin (JSC-EG) Subject: RE: Recursive hanging node constraints are broken? On Fri, 26 May 2006, Kirk, Benjamin (JSC-EG) wrote: > Do you mean when we get more than a level-1 mismatch? Whoops - yes, of course. Level 1 is fine; level 2 breaks. > Also, can you tell if it is confined to elements on the boundary? > Perhaps an interaction with the boundary conditions? I can't easily verify that (the first non-level-1 mesh I get has non-level-1 connections between boundary elements as well as between interior elements), but I really doubt it. Example 14 does penalty boundary conditions by integration now, and there shouldn't be any constrained basis functions that have any support on the boundary. To me it looks like the problem is simply that we only do constraints between active elements (the only elements which create_dof_constraints() loops through) and their parents (the only elements which compute_constrains() constrains to). I thought there was supposed to be some recursive magic so that on level-2 mismatches elements would be constrained to their parents and parents would be constrained to their grandparents, etc. but I can't find it. Perhaps it may be best to just constrain elements to their neighbors. That way we don't have to worry about how many levels of difference there are. That might make parallelizing Mesh harder, but I don't think so - there's so many functions like error estimators that will require actual solution data on ghost elements, we might as well just assume every processor has geometric data on neighboring elements too. Let me know what you think, though - I'm not feeling very well this week and I'm afraid I might be unwittingly talking nonsense. ;-) --- Roy ```
 Re: [Libmesh-devel] RE: Recursive hanging node constraints are broken? From: Roy Stogner - 2006-05-27 00:05:22 ```On Fri, 26 May 2006, Kirk, Benjamin (JSC-EG) wrote: > Using ViewCVS, it looks like the change occurred between 1.14 and 1.15 > for dof_map_constraints.C. Okay, now I remember breaking things! ;-) The projection-based hanging node constraint calculations rely on dof_indices(), which didn't always work on inactive elements. I didn't realize how important constraining inactive elements could be, so I turned it off. I'm not sure how to fix it, either. Suppose you have a level two mismatch when using a finite element type that has distinct edge and vertex DoFs (e.g. the Hierarchics for p > 1): *---*---*---*---*-------*-------* | | | | | | * | | | | | * * * * * | | | | | | | * | | | | | *---*---*-*-*-*-* * * | | | | | | * * * * * | | | | | | * * *-*-*-*-A | | | | | | | * * * * B | | | | | | *---*---*-*-*-*-*-------*-------* Take a look at node A. It's not an edge node of any element, so currently there's no reason to give it any edge degrees of freedom. If we try to recursively constrain the DoFs on node B, though, then suddenly we'll need edge DoFs on node A as intermediate constraints. --- Roy ```
 Re: [Libmesh-devel] RE: Recursive hanging node constraints are broken? From: Roy Stogner - 2006-05-27 10:56:31 ```On Fri, 26 May 2006, Roy Stogner wrote: > The projection-based hanging node constraint calculations rely on > dof_indices(), which didn't always work on inactive elements. I > didn't realize how important constraining inactive elements could be, > so I turned it off. > > I'm not sure how to fix it, either. "Doctor, it hurts when I move my arm like this!" "So stop moving it like that!" I can't figure out how to make the projection-based constraint matrices work recursively, so I'm copping out: the DoFMap now calls compute_constraints() on inactive elements and so allows the LAGRANGE elements to recursively constrain hanging node elements to their parents - but the projection-based compute_constraints() implementation now ignores inactive elements and non-recursively constrains hanging node elements to their neighbors. --- Roy ```