ufl team mailing list archive

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

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

> I won't be around to see this through though,
> since I'm beginning in another job in august.
>
> Martin
>