Hi there, 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.
Like Andrew says there will be a slight difference in the boundary conditions that result if the order is reversed. The effect on the solution will probably be small in most cases but if users are comparing solution files using diff they will be recognized as different. Regards, Michael On Wed, Sep 15, 2010 at 11:16 AM, Andrew McBride <[email protected]> wrote: > >> >>> 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 > _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
