From: Roy Stogner <roystgnr@ic...>  20140407 20:08:36

On Mon, 7 Apr 2014, David Knezevic wrote: > On 04/06/2014 11:50 PM, Roy Stogner wrote: >> >> 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? All reasonable. >> 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. Nope. The solver should easily handle multiple constraints *affecting* a dof, but since we write each constraint row into the matrix in place of the row corresponding to some dof's test function, we need to have a way of choosing which dof gets used for which constraint. > 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.) The first nasty case I can think of is the combination of a simple constraint on a vertical or horizontal wall (deltax = 0 or deltay = 0, obviously gets applied to the deltax dof or the deltay dof respectively) with a previously applied compound constraint on a neighboring diagonal wall. Do we try to make sure that the compound constraint gets set on the dof which won't be subsequently constrained? Do we try to "move" compound constraints automatically when we're overwriting them?  Roy 