On 4/28/10 1:38 PM, Roy Stogner wrote:
>
> On Wed, 28 Apr 2010, Boyce Griffith wrote:
>
>> On 4/28/10 1:26 PM, Roy Stogner wrote:
>>>
>>> On Wed, 28 Apr 2010, Boyce Griffith wrote:
>>>
>>>> For AMR meshes, should these sorts of constraints be applied only for
>>>> the nodes of level 0 elements? Or is this something that I don't have
>>>> to worry about explicitly?
>>>
>>> You need to apply your constraints for all dofs that aren't already
>>> constrained - everything except hanging nodes in adaptive h refinement
>>> and their equivalent high-p dofs in adaptive p refinement. In your
>>> case it shouldn't matter whether or not you constrain hanging nodes as
>>> well, but if you do then turn off forbid_constraint_overwrite when
>>> adding them; by default we assume adding two different constraints to
>>> the same node is a bug.
>>
>> Looking ahead to inhomogenous boundary conditions ---
>
> A patch for that would be very appreciated, even if it only worked for
> LAGRANGE variables at first, as long as the API was general enough to
> be extensible later. This has *forever* been on our list of ideas
> that are important/interesting enough to design but not quite
> important/urgent enough to implement.
So, uhh, merely 7 months after bringing this up, here is a patch that
adds support for inhomogeneous DOF constraints. I think that most of it
is pretty straightforward. Basically, I changed the DofConstraints
typedef to keep track of both the rows of the constraint matrix, and a
right-hand-side value, which defaults to zero for the existing version
of add_constraint_row(), and I added a new version of
add_constraint_row() that allows for the specification of a RHS value.
Of course, these could be rolled into a single function.
The main gotcha, which took me a while to track down, is that
process_constraints() was not expecting a constrained DOF to be
"constrained to itself." I added a check in process_constraints() to
prevent such DOFs from being added to the list of expandable BCs ---
otherwise, the self-constraint winds up being removed from the row of
the constraint equation. Similar checks may be needed in
allgather_recursive_constraints(), but I have not added them, in part
because I don't know how to test this function (ParallelMesh doesn't
work yet, right?).
I've verified that ex4 and ex10 still work, both in serial and in
parallel. I've also made a version of ex4 that uses the DOF constraints
to impose Dirichlet BCs, which is attached, and which I've verified to
work in serial and in parallel.
If this seems useful, there is at least one issue that may warrant some
API changes:
The patched code does the "right thing" only when
asymmetric_constraint_rows=true when calling
DofMap::constrain_element_{matrix,vector,matrix_and_vector}(). This is
the default, but if asymmetric_constraint_rows=false, the code will
silently do the "wrong thing," probably yielding bizarre results. One
approach would be to keep track of whether a particular constraint row
is provided by the user or not, and to require
asymmetric_constraint_rows==true when such constraints are present.
-- Boyce