← Back to team overview

ffc team mailing list archive

Re: [DOLFIN-dev] [HG DOLFIN] Make Mixed FunctionSpace access more consistant.

 



Johan Hake wrote:
On Sunday 18 October 2009 16:43:28 Garth N. Wells wrote:
Garth N. Wells wrote:
Johan Hake wrote:
On Saturday 17 October 2009 21:08:14 Garth N. Wells wrote:
Garth N. Wells wrote:
DOLFIN wrote:
One or more new changesets pushed to the primary dolfin repository.
A short summary of the last three changesets is included below.

changeset:   7378:e5c921e0293a
tag:         tip
user:        "Johan Hake <hake@xxxxxxxxx>"
date:        Sat Oct 17 15:45:36 2009 +0200
files:       site-packages/dolfin/function.py
site-packages/dolfin/functionspace.py description:
Make Mixed FunctionSpace access more consistant.
  - All methods are now defined in FunctionSpaceBase.
  - We now do not save any spaces in MixedFunctionSpace
This change broke my code. See below.
Seems that the problem arises with spaces which are restricted,

     V = FunctionSpace(mesh, "CG", 1, "facet")
This is an error in the generated FFC code.
   ufc::finite_element::signature()
should return a string that can be executed in a ufl namespace and
then generate the corresponding ufl.FiniteElement.

For a restricted element the signature returns:

   "FiniteElement('Lagrange', 'triangle', 1)|_{<interval of degree 1>}"

where it should return:

   "ElementRestriction(FiniteElement('Lagrange', Cell('triangle', 1,
Space(2)), 1), Cell('interval', 1, Space(1)))"
I've had a look, and while I don't yet follow where UFL defines its
signatures,

  repr(ulf_object)

returns the uniqe signature of an ufl_object.

things are dangerous because FFC formats its own signature
strings, see line 227 of

     ffc/ffc/fem/finiteelement.py

Yes, this is dangerous, at least if we want to use them as we do in PyDOLFIN. However taking repr of the corresponding ufl object is a well defined method that ufl use internally, when for example creating a unique string representation of a form.

We stopped using signature strings in DOLFIN because it gave us all
sorts of problems. Is it desirable to have PyDOLFIN depend on the
generated strings? Can it be avoided?

It is a very nice way of constructing an ufl object when we have the compiled version. As the convention of repr(object) is that:

  new_object = eval(repr(object))

should return a new object of the same kind.

So when we have a SubSpace with its compiled FiniteElement, it is easy to just call its signature method of its element to generate the corresponding ufl element, which is used to construct a full fledged dolfin.FunctionSpace.

Not sure how this could be done another way.


Can't we get the sub-element from the original UFL function? If I do

   (u0, u1) = pde.solve().split()

are u0 and u1 UFL Functions, or just cpp Functions?


Isn't it possible to use what repr(ufl_element) returns to define the signature of an element or isn't the ufl_element available in ffc.FiniteElement?


Yes. I committed this change to FFC a short while ago.

Garth


Johan

If I look at the generated code in Poisson.h (the DOLFIN demo), the
signature is

    "FiniteElement('Lagrange', 'triangle', 1)"

so the restricted one looks consistent to me. How does PyDOFLIN use the
signature?

Garth

Johan

Garth

Garth

   File "solver.py", line 96, in solve
     (uhat, uu) = Uh.split()
   File
"/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/site-pa
cka

ges/dolfin/function.py", line 150, in split
     return tuple(self._sub(i,deepcopy) for i in
xrange(self._V.num_sub_spaces()))
   File
"/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/site-pa
cka

ges/dolfin/function.py", line 150, in <genexpr>
     return tuple(self._sub(i,deepcopy) for i in
xrange(self._V.num_sub_spaces()))
   File
"/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/site-pa
cka

ges/dolfin/function.py", line 135, in _sub
     return Function(self, i)
   File
"/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/site-pa
cka

ges/dolfin/function.py", line 80, in __init__
     self._V = V.sub(i)
   File
"/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/site-pa
cka

ges/dolfin/functionspace.py", line 88, in sub
     return FunctionSpaceFromCpp(cpp.SubSpace(self,i))
   File
"/home/garth/code/fenics/dolfin/dolfin-all/local/lib/python2.6/site-pa
cka

ges/dolfin/functionspace.py", line 101, in __init__
     self._ufl_element = eval(cppV.element().signature(),
ufl.__dict__) File "<string>", line 1
     FiniteElement('Lagrange', 'triangle', 1)|_{<interval of degree
1>}

changeset:   7377:40cca61143c6
user:        "Garth N. Wells <gnw20@xxxxxxxxx>"
date:        Sat Oct 17 13:24:47 2009 +0100
files:       dolfin/mesh/SubDomain.h
description:
Small formatting fix.


changeset:   7376:8ee974ed5f7e
user:        Anders Logg <logg@xxxxxxxxx>
date:        Sat Oct 17 00:05:34 2009 +0200
files:       dolfin/function/Function.cpp
description:
Remove unnecessary lines in Function::eval noted by Marc S.

---------------------------------------------------------------------
- For more details, visit http://www.fenics.org/hg/dolfin
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev



Follow ups

References