Hi again,
> Just a comment that when using the original > interpolate_boundary_values methods (that did not use the > ConstraintMatrix class) the values that were interpolated last were > the ones that were applied when there was contention. It sounds like > the current suggestion is to reverse the order of precedence so that > constraints already specified are not changed. The original implementation without ConstraintMatrix results in the same matrix as when we use the new method and construct the ConstraintMatrix first with hanging nodes and then with boundary conditions, but do not actually new constraints in case the dof is already constrained (as Luca and I proposed to do now). So I think this will be uncritical. > Like Andrew says there will be a slight difference in the boundary > conditions that result if the order is reversed. Well, it will still be possible to first call interpolate_boundary_values and then make the hanging node constraints (which do not add anything to dofs already constrained). The reverse order, which should be the mathematically correct one when you need H1 conformity, did actually produce completely weird results before as soon as an inhomogeneity was involved. Whereas the former does fine for constant functions on the boundary. I would appreciate if some of you (Luca, Andrew, Michael) could have a look at the new version that I just checked in, especially the documentation in deal.II/include/numerics/vectors.h and lac/include/lac/constraint_matrix.h where I wrote about mixing hanging nodes with Dirichlet conditions. One question remains: What should we do with the other methods that operate on the ConstraintMatrix with inhomogeneities, like project_boundary_values_curl_conforming? Best regards, Martin _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
