On Tue, 24 Apr 2012, Robert wrote:
> I need to change my boundary conditions during the calculation, more
> precisely I need to remove or disable a dirichlet bc, which was added
> through DofMap.add_dirichlet_boundary(..). As far as I can see there is
> no .remove_dirichlet_boundary(..). Is there some special value like NAN
> that my FunctionBase<> subclass can return to indicate that no
> constraints should be applied?
At the moment, no. You're not the only person who wants a
remove_dirichlet_boundary() type method; the reason it doesn't exist
isn't because there's some more esoteric way to get the same
functionality, it's just because I didn't realize people would start
doing more complicated things with this class so fast!
Any preferences for the remove API?
It could take a DirichletBoundary and then remove any matching
boundary, but that would be misleading: since there's no way to
compare functor objects for equivalence, this sort of remove() would
only be testing the boundary id set and variable number set for
equality. I'm still leaning towards this, though; we're already
assuming (although perhaps not yet asserting) that each combination of
a variable number and a boundary id has at most one corresponding
Alternatively remove could take just a boundary id set and/or variable
set, but that's still misleading: of course we remove any
DirichletBoundary that matches the set exactly, but what about
boundaries that merely overlap the set? Do they get trimmed down so
that they only apply on the non-overlapping set difference afterward?
> I have another issue with DirichletBoundaries when using together with
> PeriodicBoundary conditions: Supposed there is a cube with periodic bc
> on the left and right side and dirichlet bc on the top side, the nodes
> on the edge between the left and upper side as well as the nodes on the
> edge between right and upper side will always have periodic bc.
This doesn't make sense - that would be a circular constraint even
aside from the dirichlet BCs, and that's not how we apply periodic
BCs. Only one of the sides ought to be constrained to the other.
> As far as I found out this is because the PR-BC were applied when
> add_periodic_bc is called and the dirichlet-BC were applied when
> reiniting the equation-systems. So I found no way to get all nodes
> on the upper side to be constrained with dirichlet-bc in this
> scenario, is there any way to do this?
Sounds like we've got a bug; can you put together a test code
demonstrating it (with as little code and as few elements as possible)
and send it to me?