ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Jul 07, 2009 at 10:23:30PM +0200, Martin Sandve Alnæs wrote:
> On Tue, Jul 7, 2009 at 9:47 PM, Anders Logg<logg@xxxxxxxxx> wrote:
> > On Tue, Jul 07, 2009 at 08:48:17PM +0200, Martin Sandve Alnæs wrote:
> >> 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?
> >> >> >
> >> >>
> >> >> 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.
> >>
> >> > 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.
> >>
> >> My guess is that this task will require some
> >> design iterations to make it good.
> >>
> >> I won't be around to see this through though,
> >> since I'm beginning in another job in august.
> >
> > Where?
> >
> 
> At TANDBERG, as audio programmer for video conferencing systems.
> 
> Martin

Sounds cool, but I'm very sorry we will loose the designer, maintainer
and driving force behind UFL/UFC. Do you plan to be involved with UFL
or UFC in any way?

-- 
Anders

Attachment: signature.asc
Description: Digital signature