dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Jun 22, 2006 at 05:42:14PM +0200, Garth N. Wells wrote:
> On Thu, 2006-06-22 at 17:31 +0200, Anders Logg wrote:
> > On Thu, Jun 22, 2006 at 03:35:38PM +0200, Garth N. Wells wrote:
> > > On Thu, 2006-06-22 at 15:01 +0200, Anders Logg wrote:
> > > > Boundaries have now been added to the new mesh library. The name has
> > > > changed from Boundary to BoundaryMesh, for two reasons: 
> > > > 
> > > >     1. We may want to add a new class Boundary later (and a class Domain)
> > > >        that represents a geometry (like a CAD model) rather than a mesh
> > > >        of a geometry.
> > > > 
> > > >     2. A BoundaryMesh is also a Mesh (NewMesh until we port everything
> > > >        to the new mesh library).
> > > 
> > > Great! Can we think now about distinguishing between spatial and
> > > topological dimension in FFC? Then boundary conditions functions can be
> > > defined on elements one topological dimension lower. 
> > 
> > I'm not sure we can do that. The functions on the boundary are
> > restrictions of what we have on the interior and it may be difficult
> > to separate. Why would we need this?
> > 
> 
> We need to work with the traces of the test functions defined on the
> interior (and trial too if we have solution-dependent bc's), but the
> function providing the boundary condition should be defined using an
> element one topological dimension lower. A very common case is a
> boundary condition which is discontinuous from one element to the next.
> If it's not discontinuous, it's not possible to apply a boundary
> condition to only one face of a polygon - the bc "creeps" around the
> corner. Other examples are the normal vector and elements which might
> not have nodes on the element facet (like a P0 element). 
> 
> Garth

ok, I understand now. We need to be able to compute both with
functions that are defined on the entire domain and take the trace
when we compute integrals over the boundary (what we have now) and
also with functions that are only defined on the boundary.

This should not be a problem with the new mesh. There are two
options for this. We either define a function on the boundary as
something defined on a special shape, like "tetrahedron facet" or we
just define it on a "triangle" which might be the easiest way forward.

I can't point out exactly what we need to change, so we just need to
try it out and see what changes we need to make. One thing we need to
modify is to extend the computation of the affine mapping so it
supports embedding into a higher-dimensional space and not assuming
everything is in 2D for a triangle etc.

We should probably wait until things are ported to the new mesh.

/Anders


> > > > 
> > > > Just as before, the boundary mesh is created as follows:
> > > > 
> > > >     BoundaryMesh boundary(mesh);
> > > > 
> > > > Note that a new boundary mesh is computed every time and that the
> > > > boundary mesh is separate from the interior mesh. The connection
> > > > between the two will be through a MeshFunction (not added yet).
> > > > 
> > > 
> > > Is this all that's needed for integration of boundary conditions with
> > > the new mesh library?
> > 
> > Yes, plus some other minor missing functionality we will discover when
> > we try to do the assembly with the new mesh. We'll be able to remove
> > the templates from FEM since we can now iterate over facets.
> > 
> > /Anders
> > 
> > 
> > > Garth 
> > > 
> > > > In the old mesh library, a Boundary was a special object which shared
> > > > its data with the interior mesh.
> > > > 
> > > > Since a BoundaryMesh is just as much a mesh as the interior mesh (but
> > > > embedded in a higher dimension), it's perfectly ok to do things like
> > > > 
> > > >     BoundaryMesh boundary(mesh);
> > > >     boundary.refine();
> > > > 
> > > > I probably won't push any more major updates to the new mesh library
> > > > before the next release. Let's try to get 0.6.2 ready and then go on
> > > > vacation. Garth has been doing a good job cleaning out a lot of PETSc
> > > > ifdefs but some remain.
> > > > 
> > > > /Anders
> > > > 
> > > > _______________________________________________
> > > > DOLFIN-dev mailing list
> > > > DOLFIN-dev@xxxxxxxxxx
> > > > http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> > > 
> > > 
> > > _______________________________________________
> > > DOLFIN-dev mailing list
> > > DOLFIN-dev@xxxxxxxxxx
> > > http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> > 
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev