On Thu, 2 Dec 2010, Boyce Griffith wrote:
> So, uhh, merely 7 months after bringing this up, here is a patch that adds
> support for inhomogeneous DOF constraints.
Ignoring said patch for 3 months was not an attempt to punish or mimic
your own delay, just a sad commentary on the state of my outbox. I
actually got into a discussion about inhomogeneous DoF constraints
last week in which I'd completely forgotten your patch *existed*...
> 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.
This looks good. I'd keep the existing function as-is for backwards
compatibility; I don't use it myself but I know other user codes do.
> 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?).
ParallelMesh doesn't work with adaptive coarsening. It worked with
unrefined meshes and adaptive refinement, but hasn't been tested in a
while. I'll see if I can get that into continuous integration soon.
> I've verified that ex4 and ex10 still work, both in serial and in parallel.
The other examples seem to work fine; I'll check a bit more thoroughly
before committing. If anyone else wants to look at, comment on, or
veto the patch, that'll give them time to do so.
> 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.
Thanks!
> 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.
Thanks for the heads-up. I've got some FEMSystem-based codes that
could probably be adjusted pretty easily to test that case, which we'd
want to fix before committing.
---
Roy
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
