On Sat, Apr 07, 2007 at 02:35:07PM +0200, Garth N. Wells wrote:
Any further thoughts on how to apply Dirichlet boundary conditions? I've
been playing around with it, and with the new UFC interface I don't see
how we can retain the simplicity of the old approach.
Garth
How about the following:
- A boundary condition can be applied in one of two ways: either by
overloading eval() in the class BoundaryCondition, or by suppliying a
Function that defines the boundary condition.
- In the first case, the eval() function looks the same as the eval()
method in Function, but instead of real we have BoundaryValue:
void eval(BoundaryValue* values, const real* x);
When using this method, one sets the values of dofs direcly, so for a
BDM element, one would specify the value of the normal component, not
the function value.
- The class BoundaryValue remains the same as today. So if one does
values[0] = 3.5;
then the value is set. Otherwise it remains Neumann.
- In the second case, one specifies that the boundary condition should
be u = g on the boundary for g a given Function. For a BDM element,
one would then say that the normal component of u should be the same
as the normal component of g on the boundary. Or do we want to say
that g should be the Dirichlet values of u, so that g would be a
scalar that returns the normal components in the case of BDM?
- So two different ways of specifying boundary conditions, one for dof
values (by overloading eval) and one Function-based. The first case
makes use of tabulate_facet_dofs and tabulate_coordinates and the
second makes use of tabulate_facet_dofs and evaluate_dof.
- In both cases, one should be able to say that the boundary condition
is valid only for a certain sub domain. We could either require an
argument uint sub_domain in the constructor to BoundaryCondition, or
we make it an extra argument to the apply() methods. I'm not sure
which is the best.
- I also suggest we rename the methods in BoundaryCondition from
applyBC to just apply:
bc.apply(A, b, mesh, form);
- Also, isn't it a little problematic to just have a single form
argument? The A and the b are assembled from different forms.
/Anders
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev
