← Back to team overview

ufl team mailing list archive

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

 



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.

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

Garth

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



_______________________________________________
FFC-dev mailing list
FFC-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/ffc-dev




References