← Back to team overview

dolfin team mailing list archive

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

 



Anders Logg wrote:
On Sun, Oct 18, 2009 at 11:43:03PM +0200, Johan Hake wrote:
On Sunday 18 October 2009 21:10:08 Anders Logg wrote:
On Sun, Oct 18, 2009 at 08:37:21PM +0200, Johan Hake wrote:
On Sunday 18 October 2009 20:31:41 Garth N. Wells wrote:
Johan Hake wrote:
On Sunday 18 October 2009 20:07:41 Garth N. Wells wrote:
On Oct 18 2009, Johan Hake wrote:
On Sunday 18 October 2009 18:21:23 Garth N. Wells wrote:
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?
Not when we return a SubSpace which is a compiled C++ structure. To
be able to construct the ufl.FiniteElement (done in the class
FunctionSpaceFromCpp in functionspace.py) we use the signature of
the cpp.FiniteElement.

If I do

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

are u0 and u1 UFL Functions, or just cpp Functions?
They should be both. Their FunctionSpaces (self._V) are constructed
using the the FunctionSpace.sub(i) (operator[]) method, which
returns the compiled SubSpace I am talking about above.
OK, but if we have

  U = pde.solve()

and U is a UFL Function, can't the UFL finiteelement for U be
accessed, and then the UFL sub-element(s) accessed and then
compiled?
Yes, this should be possible! (Did not think of getting the sub
element from a mixed ufl.element :P)

However we do not have to compile them, as we needed to go the other
way, from compiled to UFL.
OK. Now the situation is clear to me.

I still think the signature() -> UFL object is a neat feature!
The problem is that there is nothing that says that a form compiler
that uses UFL and produces UFC-compliant code must return the UFL
signature (repr) in ufc::finite_element::signature().
True. However that is something we discussed a year ago when we
implemented the transition to FunctionSpace in PyDOLFIN. I thought this
went into the ufc documentation, but I now see that this is not the case.
For now...

Lets get a blueprint at ufc and here what folks says.

Johan
How about adding an optional function to the UFC interface for
returning the UFL string:

  virtual std::string ufl_repr() const { return ""; }
Look like this is already described as a Blueprint, which comes from an old
point in the TODO file.

  <https://blueprints.launchpad.net/ufc/+spec/string-description>

I think Martin added it when we discussed this a while back.

ok. I've added some comments to that blueprint now.


For the time being FFC is using the UFL repr(element) string in ufc::finite_element::signature.

Garth

--
Anders


------------------------------------------------------------------------

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




References