dolfin team mailing list archive

[Shawn Walker <walker@xxxxxxxxxxxxxxx>]

On Mon, 20 Apr 2009, kent-and@xxxxxxxxx wrote:

> > On Mon, 20 Apr 2009, Anders Logg wrote:
> >
> > > On Thu, Apr 16, 2009 at 09:19:51PM -0400, Shawn Walker wrote:
> > > > On Fri, 17 Apr 2009, Garth N. Wells wrote:
> > > >
> > > > > kent-and@xxxxxxxxx wrote:
> > > > > > I would also like this capability! It is  something that often shows
> > > > > > up
> > > > > > in inverse/optimal control problems.
> > > > > >
> > > > > > Written in FFC/UFL your first equation reads:
> > > > > >
> > > > > > dot(u,v)*dx - p*div(v)*dx + lmbda*dot(v,n)*ds
> > > > > >
> > > > > > where u, p, lmbda are trial functions.
> > > > > >
> > > > > > You could form one system or create a block matrix. Anyhow
> > > > > > the term
> > > > > >   lmbda*dot(v,n)*ds
> > > > > > would lead to a matrix with a very big kernel since you are not able
> > > > > > to
> > > > > > restrict the dofs of lmbda only to the boundary.
> > > > > >
> > > > > > What you can currently do is to restrict the functionspace for lmbda
> > > > > > to
> > > > > > all the cells
> > > > > > associated with the boundary.
> > > > > >
> > > > > > Using restricted functionspaces (in a simpler fashion) can be found
> > > > > > in
> > > > > > demo/function/restriction.
> > > > > >
> > > > > > The restriction does only work on cells for now.
> > > > > >
> > > > > > We could discuss Uzawa and/or block matrices for this problem but I
> > > > > > think
> > > > > > the simplest start is to create one system to begin with.
> > > > > >
> > > > > > Whether it makes sense that lmbda lives on the whole cell associated
> > > > > > with
> > > > > > the boundary, I don't know.
> > > > >
> > > > > It should live only on the boundary. In practice this only becomes an
> > > > > issue for higher-order elements with internal dofs.
> > > > >
> > > > > Garth
> > > >
> > > > Yes, I agree.
> > > >
> > > > So how ridiculous is it to enable FFC/DOLFIN to have finite element
> > > > functions that are only defined on the boundary of the domain?  I'm
> > > > guessing there would be some special DoFmappings to go from the global
> > > > domain numbering to a boundary numbering only.  This would be really
> > > > nice
> > > > to have.  There are lots of cases in practice that have these kinds of
> > > > boundary functions.
> > > >
> > > > - Shawn
> > >
> > > It's not impossible but it requires some thought. I think Garth has
> > > asked about this for a long time as well (to have function spaces that
> > > only live on facets). I don't really know how to best handle it.
> > >
> > > --
> > > Anders
> >
> > ok.  I just implemented what I needed in MATLAB and that formulation
> > works.  But it would certainly be great to have it in FENICS.
> >
> > - Shawn
>
> A possible way to do it with not to much work (?) in FEniCS would be to
> to create the matrix on the space with to many degrees of freedom and
> a large kernel. Then create a projection matrix based on the degrees
> of freedom you want. You may then project the matrix onto the space you
> want. This is similar to what is currently done in the function restriction
> (allthought it is between the lines here). Both PETSc and Trilinos support
> matrix matrix multiplication (I think).
>
> This is maybe not the most elegant solution, but it is not all bad.
>
> Kent

Is it really that bad to put this directly into FENICS?  It seems that all 
you need is a separate DoFmap for the variables that live on the boundary 
only.  Is it not possible to setup a DoF numbering on the boundary only? 
Maybe, in addition, have a way of mapping the DoF's on the boundary to the 
corresponding DoF's in the global numbering?

Wasn't something like this done for the parallel stuff?  I seem to 
remember something about having mapping between DoF's on different 
sub-domains, but I wasn't really paying attention.

If someone could summarize the difficulties here, that would be great. 
I am not that familiar with this aspect of FENICS.

- Shawn