ffc team mailing list archive

[Kristian Oelgaard <k.b.oelgaard@xxxxxxxxxx>]

Quoting Shawn Walker <walker@xxxxxxxxxxxxxxx>:

>
> On Wed, 8 Jul 2009, Kristian Oelgaard wrote:
>
> > Quoting Martin Sandve Aln?s <martinal@xxxxxxxxx>:
> >
> >> On Tue, Jul 7, 2009 at 5:52 PM, Kristian
> >> Oelgaard<k.b.oelgaard@xxxxxxxxxx> wrote:
> >>> Quoting Martin Sandve Aln?s <martinal@xxxxxxxxx>:
> >>>
> >>>> On Wed, Jun 17, 2009 at 5:15 PM, Anders Logg<logg@xxxxxxxxx> wrote:
> >>>>> On Wed, Jun 17, 2009 at 03:32:03PM +0200, UFL wrote:
> >>>>>> One or more new changesets pushed to the primary ufl repository.
> >>>>>> A short summary of the last three changesets is included below.
> >>>>>>
> >>>>>> changeset:   908:ef256e35e417096ae9b9d3a7e915e27e6971ae3f
> >>>>>> tag:         tip
> >>>>>> user:        "Martin Sandve Aln?s <martinal@xxxxxxxxx>"
> >>>>>> date:        Wed Jun 17 15:32:01 2009 +0200
> >>>>>> files:       test/newtests/test_demos/test_demos.py
> >>>> test/newtests/test_elements/test_elements.py
> >>>> test/newtests/test_exprbasics/test_construction.py ufl/__init__.py
> >>>> ufl/exproperators.py ufl/finiteelement.py ufl/function.py
> >>>>>> description:
> >>>>>> Added ElementRestriction class with notation "Vr = V[dx(k)]".
> >>>>>
> >>>>> What does this mean? What is V?
> >>>>>
> >>>>> --
> >>>>> Anders
> >>>>
> >>>> The restriction of a function space to a domain.
> >>>> Obviously the use of the measure "dx" is an
> >>>> abuse of concepts, but it's convenient to reuse it.
> >>>>
> >>>> Consider:
> >>>>
> >>>> V1 = FiniteElement("CG", cell, 1)
> >>>> V0 = FiniteElement("DG", cell, 0)
> >>>> V = V1 + V0[ds(2)]
> >>>> u, lamda = TrialFunctions(V)
> >>>>
> >>>> Here lamda lives only on boundary 2.
> >>>>
> >>>> Of course, this is useless without support in the rest of
> >>>> FEniCS, so it's only a proof of concept for input syntax.
> >>>>
> >>>> Feel free to suggest alternative syntax and naming.
> >>>
> >>> First of all, any ideas on how to implement support for this in say FFC?
> >>
> >> No. It will probably require non-trivial extensions to
> >> UFC and DOLFIN as well, and seems like a fairly
> >> complicated design task to get it general enough.
> >
> > OK.
> >
> >>> In relation to this new functionality.
> >>> If we want to restrict an element, not to a particular subdomain, but to
> >> the
> >>> exterior of each element, i.e., only consider the dofs that live on
> facets,
> >>> would that also fit in this framework?
> >>> Should the syntax for this be V[ds + dS]?
> >>> But then what should the syntax be for only considering dofs that live
> >>> internally on the cell?
> >>>
> >>> Or, if V is defined on 'triangle', then one could do
> >>> V['interval'] to get the facet dofs, and V['triangle'] to get the
> interior
> >> dofs.
> >>> It would even be possible to do V['vertex']. If we also allow this syntax
> >> we can
> >>> restrict elements with respect to either Cells or Measure.
> >>> Could this work?
> >>>
> >>> How can this be implemented in FFC? In the case of V['interval'], we
> could
> >> get
> >>> the finite element from FIAT as usual, and then find all dofs NOT on the
> >> facet
> >>> and dump them in a list of dofs that should be ignored when generating
> all
> >> the
> >>> code.
> >>>
> >>> Kristian
> >>
> >> The use of Measure to represent a domain didn't feel
> >> right to begin with. Seems like it's not general enough
> >> anyway, so I suggest designing a separate abstraction
> >> for description of subdomains or subsets of dofs.
> >
> > I think that Measure might be OK as a first try for one of the restriction
> > cases.
> >
> > Normally, dofs are active in the entire domain, but
> >
> > 1) Measure can be used to restrict dofs to be active only on say domain
> dx(2) or
> > ds(1).
> > The complicated thing here is that practically all functions in UFC needs
> to
> > be aware of the subdomain.
> >
> > 2) Cell can be used to restrict dofs to be active only on e.g., the facets
> of
> > all cells in the domain.
> > This is simpler to handle as the restriction will apply to the all elements
> in
> > the entire domain.
> >
> > Syntax and interpretation:
> >
> > element = FiniteElement("CG", triangle, 4)
> > will have dofs on the facets as well as on the interior, but
> >
> > element[interval]
> > will only have dofs on the facets.
> >
> >> My guess is that this task will require some
> >> design iterations to make it good.
> >
> > Yes, I think so too.
> > I'm willing to give case 2) a go, if nobody objects or have
> > comments/suggestions.
> > But I guess since you are starting in a new job and Anders is on holidays,
> I can
> > do whatever I want :)
> > Unless, of course, this falls under one of his two categories 'simple or
> > urgent'.
> >
> > Kristian
>
> Will it be possible to use this new functionality that you plan on adding
> for implementing finite element spaces that only live on certain
> subdomains?.  e.g. like having a lagrange multiplier that lives on the
> boundary only.  This would be really nice!

What you're asking is related to case 1) as described above. The basic
functionality (to make it work in a first iteration) is already available in
UFL, but as Martin has pointed out quite big changes/extensions will be needed
in UFC and potentially DOLFIN.
I have no short term intentions of implementing this.

Case 2) which I'll be implementing should, however, only involve changes to the
interior of FFC as I see it.

Kristian

> - Shawn
>
> >> I won't be around to see this through though,
> >> since I'm beginning in another job in august.
> >>
> >> Martin
> >>
> >
> >
> > _______________________________________________
> > UFL-dev mailing list
> > UFL-dev@xxxxxxxxxx
> > http://fenics.org/mailman/listinfo/ufl-dev
> >
> >