From: David Knezevic <dknezevic@se...>  20140407 18:21:23

On 04/06/2014 11:50 PM, Roy Stogner wrote: > > On Sun, 6 Apr 2014, David Knezevic wrote: > >> Is it possible to impose a linear constraint on the variables in a >> system using a DirichletBoundary object? > > Currently, no. > >> The case I'm thinking of is in elasticity, where you want set the >> displacement in the normal (or tangential) direction on a surface. In >> that case we want "n \dot (u,v,w) = normal_displacement" on the >> boundary. >> >> I've only used DirichletBoundary to impose independent conditions on >> each variable, so I assume that a condition like "n \dot (u,v,w) = >> normal_displacement" isn't possible yet? > > The lower level heterogeneous DofConstraints code will correctly > impose such conditions once they've been consistently calculated for > each DoF (this actually gets complicated at corners/edges...), but > there's > no way yet to tell the library to calculate such conditions. > > That's on my TODO list as well, but not high enough that I'd expect to > get to it alone any time soon; I'd love to help you hash it out. OK, sounds good. >> Roy: Do you have any comments on where to start, and how much work >> it would require? > > Where to start is "what do we want the API to look like"; I'm not even > sure if this can cleanly fit in DirichletBoundary or if we'd want to > create some kind of new CoupledDirichletBoundary (or betternamed) > addition. I'd be happy with a CoupledDirichletBoundary class. Or perhaps LinearConstraintDirichletBoundary (if that isn't too verbose...), and if nonlinear couplings are needed later on, they could handled in a NonlinearConstraintDirichletBoundary class? Then, for each boundary constraint we want to apply we could attach functions f_i, i=1,...,n+1 to the the boundary condition object to give the constraint: \sum_{i=1}^{n} f_i(x,y,z) u_i(x,y,z) = f_{n+1}(x,y,z), where u_i is the i^th variable in our system. I guess this could be done with something like: dirichlet_bc.attach_constraint( std::map< unsigned int, FunctionBase* > lhs_functions, FunctionBase* rhs_function) The map keys would indicate which variable each lhs_function applies to, and any "unspecified" function would be assumed to be zero. How does that sound to you? > Most of the hard work in code can be done just by yetagain cloning > (or for God's sake finally refactoring) our constraint loop code. The > only catch I can see is when multiple constraints apply to the same > dof. E.g. if two normal displacements act on a rotated 2D corner, we > want > that to correctly boil down to "the corner position is completely > fixed" rather than "a constraint gets ignored" or "an error gets > thrown"... and I'm not even sure if that's a new catch; I recall > having to deal with the same problem when DirichletBoundary and > PeriodicBoundary mix. But I don't know if there's an analog here to > the solution I ended up going with there. OK, sounds good. I would hope that the solver can handle the case of multiple constraints on a dof. If the constraints are consistent, then the solver should do the right thing (i.e. completely fix the corner position in your example), and if the constraints are inconsistent, then the solver should complain about an illposed system. (The "double normal displacement on a corner node" would be a good test case for this.) David 