Subject: Re: [FFC-dev] [UFL-dev] [HG UFL] Added ElementRestriction class with notation 'Vr = V[dx(k)]'.

From: "Garth N. Wells" <[email-masked]>
Date: Tue, 30 Jun 2009 15:16:35 +0100

Martin Sandve Alnæs wrote:
> On Wed, Jun 17, 2009 at 5:15 PM, Anders Logg<[email-masked]> 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 <[email-masked]>" 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.
> 

Looks ok to me at first inspection. Now we just need it in FFC :).

Garth

> Martin _______________________________________________ UFL-dev
> mailing list [email-masked] 
> http://fenics.org/mailman/listinfo/ufl-dev

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 07 Jul 2009 17:52:30 +0200

Quoting Martin Sandve Alnæs <[email-masked]>:

> >> changeset:   908:ef256e35e417096ae9b9d3a7e915e27e6971ae3f
> >> tag:         tip
> >> user:        "Martin Sandve Alnæs <[email-masked]>"
> >> date:        Wed Jun 17 15:32:01 2009 +0200
> >> files:       test/newtests/test_demos/test_demos.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)]".
> >
> > --
> > 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)
>
> Of course, this is useless without support in the rest of
> FEniCS, so it's only a proof of concept for input syntax.
>

First of all, any ideas on how to implement support for this in say FFC?

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

> Martin
> _______________________________________________
> UFL-dev mailing list
> [email-masked]

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 7 Jul 2009 20:48:17 +0200

> 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.

> and dump them in a list of dofs that should be ignored when generating all the

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.

Martin

---

From: Anders Logg <[email-masked]>
Date: Tue, 7 Jul 2009 21:47:50 +0200

> since I'm beginning in another job in august.

Where?

-- 
Anders

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 7 Jul 2009 22:23:30 +0200

>> since I'm beginning in another job in august.

At TANDBERG, as audio programmer for video conferencing systems.

Martin

---

From: Anders Logg <[email-masked]>
Date: Tue, 7 Jul 2009 23:01:35 +0200

> At TANDBERG, as audio programmer for video conferencing systems.

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

---

From: Johan Hake <[email-masked]>
Date: Tue, 7 Jul 2009 23:06:55 +0200

On Tuesday 07 July 2009 23:01:35 Anders Logg wrote:
> > >> > 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?
> > >> > But then what should the syntax be for only considering dofs that
> > >> > live internally on the cell?
> > >> >
> > >> > 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
> > >>
> and driving force behind UFL/UFC. 

Agree!

> Do you plan to be involved with UFL 
> or UFC in any way?

Aren't there any PDEs to solve using FEM in audio signal processing ;)

Johan

---

From: Kristian Oelgaard <[email-masked]>
Date: Wed, 08 Jul 2009 08:36:55 +0200

Quoting Anders Logg <[email-masked]>:

> interior dofs.
> could get

You almost make it sound like he actually has a choice.... :)

Kristian

---

From: Kristian Oelgaard <[email-masked]>
Date: Wed, 08 Jul 2009 09:03:47 +0200

> complicated design task to get it general enough.

OK.

> 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.

> 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

---

From: Anders Logg <[email-masked]>
Date: Wed, 8 Jul 2009 09:05:00 +0200

> You almost make it sound like he actually has a choice.... :)

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

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 08 Jul 2009 08:06:46 +0100

> I'm willing to give case 2) a go, if nobody objects or have

Sounds good to me. Should be simpler and it will deal with the common 
case of function that live only on facets.

Garth

> FFC-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/ffc-dev

---

From: Shawn Walker <[email-masked]>
Date: Wed, 8 Jul 2009 09:28:00 -0400 (EDT)

On Wed, 8 Jul 2009, Anders Logg wrote:

>>> On Tue, Jul 07, 2009 at 10:23:30PM +0200, Martin Sandve Aln?s wrote:
>>>>> On Tue, Jul 07, 2009 at 08:48:17PM +0200, Martin Sandve Aln?s wrote:
>>>>>>> Quoting Martin Sandve Aln?s <[email-masked]>:
>>>>>>>
>>>>>>>>>> user:        "Martin Sandve Aln?s <[email-masked]>"

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

---

From: Shawn Walker <[email-masked]>
Date: Wed, 8 Jul 2009 09:31:24 -0400 (EDT)

> Unless, of course, this falls under one of his two categories 'simple or

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!

- Shawn

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 08 Jul 2009 14:33:29 +0100

Shawn Walker wrote:
>>>> but to
>>> the
>>>> interior
>>> dofs.
>>>> It would even be possible to do V['vertex']. If we also allow this 
>>>> syntax
>>> we can
>>>> 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
>>>
> Will it be possible to use this new functionality that you plan on 
> adding for implementing finite element spaces that only live on certain 

In the first instance it will be possible to restrict to cell facets, 
but not arbitrary subdomains.

Garth

> ------------------------------------------------------------------------
>

---

From: Kristian Oelgaard <[email-masked]>
Date: Wed, 08 Jul 2009 15:55:54 +0200

Quoting Shawn Walker <[email-masked]>:

> >>> and dump them in a list of dofs that should be ignored when generating
> all
> >> the
> >>> code.
> >>>
> >>> Kristian
> >>

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