> You're right. That is a real problem. It is also problematic in case we > mix hanging node constraints with Dirichlet boundary values. In 3D, the > current implementation actually is not H1-conforming when the boundary > function is not a simple function: We should use hanging node > constraints on the boundary and _not_ the boundary values, otherwise > we're not conforming... This wasn't a problem with the old > implementation with apply_boundary_values because there constrained DoF > on the boundary were completely isolated, having no effect on the > computation, and afterwards the constraints.distribute() function set > the correct (conforming) value.
Mmmm... I'm not sure I'm following you. If we are on the boundary, then the definition itself of "hanging node" is a little fuzzy, since, technically, on the boundary, there is no neighbor that could be refined on a different level, hence, there should be no hanging nodes. Maybe I'm just confused or maybe we simply mean different things... > I just checked the documentation of interpolate_boundary_values with the > ConstraintMatrix argument and we actually claim that old entries in a > line that might be constrained are deleted. But right now we neither do > this, nor would this be the right thing in any case. Anyway, I think we > really need this kind of interface for the ConstraintMatrix. However, we > must be careful with hanging nodes: these should dominate over Dirichlet > boundary conditions. How should we proceed there? Unless a boundary is really *not* a boundary (i.e., there are neighbors on the other side of the cell, which could be refined one level less), I don't see why this should be a problem. Can you elaborate on when this should be a problem? L. _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
