From: Kirk, Benjamin \(JSCEG\) <benjamin.kirk1@na...>  20060526 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 anyD 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 hrefinement. Note that when the level1 rule is not enforced face mismatch may occur for nonactive 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. Level1 mismatch with those in II and IV).  refine the elements in quadrant III again. (when enforcing level1, 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 levelII mismatch even though the level1 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 (JSCEG) Subject: RE: Recursive hanging node constraints are broken? On Fri, 26 May 2006, Kirk, Benjamin (JSCEG) wrote: > Do you mean when we get more than a level1 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 nonlevel1 mesh I get has nonlevel1 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 level2 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 