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
