dolfin team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxx>]

On Fri, 2006-06-23 at 09:49 +0200, Anders Logg wrote:
> 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.
> 

This should all be relatively simple from the DOLFIN side. More complex
will be FFC. Perhaps a good start is to allow the definition of
functions on elements whose topological dimension is one (or two)
order(s) lower than the space dimension? This would be useful for a
range of problems (shells, etc). Then later we can look at the
interaction between the traces of functions on elements of dimension d
and functions on elements of dimension d-1. 

Garth

> 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
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev