Hi there, That is a very interesting example. Clearly what I was doing is dangerous!
I was mixing inhomogeneous constraints on a boundary with hanging nodes in the fluid. Fortunately I was lucking and since I was working in 2D and had evenly refined cells two deep along the boundary, the inhomogeneous constraints are separated from the hanging nodes. Thanks, Michael On Wed, Jan 12, 2011 at 5:45 PM, Martin Kronbichler <[email protected]> wrote: > Michael, > > >> >> Well, if the boundary conditions change in every time step, I don't >> >> think ConstraintMatrix is very efficient: One would need to hold a >> >> ConstraintMatrix with other constraints (e.g. hanging nodes), copy that >> >> over to the actual constraint matrix _in every time step_, insert the >> >> boundary conditions, and then close that constraint matrix. >> >> If the inhomogeneous part of the constraint is the only part that >> changes after each time step then I found that the method >> set_inhomogeneity (const unsigned int line, const double value) can be >> called even when the ConstraintMatrix is closed. > > Right, but this does not work in general: if the ConstraintMatrix > contains hanging node constraints besides the inhomogeneous (Dirichlet) > constraints, and some hanging nodes are distributed onto boundary dofs > (where you set inhomogeneous conditions), this is not correct. > > Assume x_1 is a dof on a hanging node, and is constrained as > x_1 = 0.5 * (x_0 + x_2) > Assume further that we have an inhomogeneous constraint on x_0 because > it sits on the boundary, while x_2 is unconstrained: > x_0 = 1.234 > Then, the close command transforms this into: > x_0 = 1.234 > x_1 = 0.5 * 1.234 + 0.5 * x_2 > > So suddenly x_1 got an inhomogeneity, even though we didn't set any. It > is possible to keep track of those changes from outside, but very > tedious and I think we should (at some point) implement a generic way to > include this in ConstraintMatrix. With one method to tell the CM which > constraints will be subject to inhomogeneities (and changes of them), > for which the reconstruction will be save. Then one can update these in > a fast way. > >> This saves the >> expense of closing the constraint matrix each time step. (Admittedly I >> am using older versions of the library currently so this might have >> changed recently.) The user still requires the line number of the >> constraint to update which they might not have if they called >> VectorTools::interpolate_boundary_values to create the original >> constraints. > > It is still present, and still valid. But I assume you did not mix this > with hanging nodes, see above. > > Best, > Martin > > _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
