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 better-named)
> 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 yet-again 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 ill-posed system. (The "double normal
displacement on a corner node" would be a good test case for this.)
David
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
