Hi Just a comment on the issue of competing / multiply defined constraints.
I've had similar problems with hanging nodes that occur on faces where I have Dirichlet constraints. My way of handling this was to create separate ConstraintMatrices for hanging node and Dirichlet constraints and then do a customised merge. The customised merge allows you (the user) to decide which set of constraints should dominate. I don't think this decision should be made by the library. I realise this does not fix the problems raised but if such a customised merge were added to the library and the potential problems associated with multiply defined constraints made clear in the documentation I think it would help a lot. I think Luca's suggestion of removing an existing constraint if a flag is set to true is a good one as it provides the user with more flexibility. Cheers Andrew > Dear Luca, > > >> When calling the above function, what is done is the following: >> >> 1. find out which ones are the boundary dofs >> 2. for each i: >> >> interpolate the function on support point i; >> >> constraints.add_line(i); >> constraints.set_inhomogeneity(i, bv); >> >> Now this is perfect if line(i) does not contain already another >> constraint. If this is not the case, the above does not work as >> expected, because the inhomogeneity is *added* to the already existing >> constraints. > > 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. > >> Now... in the library we cannot remove entries from the constraints (as >> far as I know)... a possible solution would be to add a default >> argument to add_line, for example, reset_existing_entries = false, >> which would behave as normal in the default case (false), and which >> would remove the constraints from the given line if set to true, so >> that we could use this method in interpolate_boundary_values, by doing >> >> constraints.add_line(i, true); >> constraints.set_inhomogeneity(i, bv); > > 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? > > Best, > Martin > > _______________________________________________ > dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
