> >> Are there any suggestions on how this issue should be handled? I'm not >> sure it is possible to automate this internally to ConstraintMatrix >> (i.e., transparently to the user). >> >> One quick fix to interpolate_boundary_values, which doesn't require >> major changes in the library, would be to check wether the given dof >> is already constrained, in which case the dirichlet inhomogeineity >> constraint is simply ignored. > > I've been thinking about this procedure, too. Boundary values should > usually be the weakest part (periodic b.c. or hanging nodes should > dominate), and that would work fine for most user codes.
I agree. That's how I generally do the customised mere and it seems to work fine. I can think of a contrived situation where you have a rapid change in Dirichlet boundary condition in the region where you have hanging nodes on a face. There you would want the Dirichlet constraint to dominate. But it's contrived and should be handled via a better initial mesh. > The only thing > we have to make very clear then is that hanging nodes should be inserted > before boundary constraints. And of course document that dofs that > already are constrained are not touched in the > interpolate_boundary_values function. I can make this change if we all > agree on that this is the best way to do things. I agree. Would you want this behaviour to be the default? My only thought is that there is the small chance that someone may actually have implemented boundary conditions in a manner that exploits the current way interpolate_boundary_values works in conjunction with existing constraints. > > Best, > Martin > > > _______________________________________________ > dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
