ffc team mailing list archive

[Shawn Walker <walker@xxxxxxxxxxxxxxx>]

On Wed, 8 Jul 2009, Anders Logg wrote:

> On Wed, Jul 08, 2009 at 08:36:55AM +0200, Kristian Oelgaard wrote:
> > Quoting 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?
> >
> > You almost make it sound like he actually has a choice.... :)
> >
> > Kristian
>
> I'm saying I'm sorry he didn't have a choice to continue working on
> UFL. But working at TANDBERG may also be a very good option, and as
> Johan says, Martin may convince them that they need to start solving
> PDEs. :-)
>
> --
> Anders

I'll bet Martin is more than happy to be free of this ridiculous project 
and all the looney tunes that work on it!  :)   haha!

- Shawn