Subject: [FFC-dev] [HG FFC] Restrictions appears to be working for the Poisson demo.

From: [email-masked] (FFC)
Date: Tue, 18 Aug 2009 18:58:07 +0200 (CEST)

One or more new changesets pushed to the primary ffc repository.
A short summary of the last three changesets is included below.

changeset:   1612:de211a9d88bce134c4abc2b128283ad35415a529
tag:         tip
user:        "Kristian Oelgaard <[email-masked]>"
date:        Tue Aug 18 17:57:36 2009 +0100
files:       ffc/fem/finiteelement.py
description:
Restrictions appears to be working for the Poisson demo.

changeset:   1611:283c1799fe643b297668dfa5347a7de50fee8555
user:        "Kristian Oelgaard <[email-masked]>"
date:        Tue Aug 18 17:40:05 2009 +0100
files:       ffc/fem/finiteelement.py ffc/fem/quadratureelement.py
description:
Bug fix to make buildbot happy.

changeset:   1610:2d95d63e8281e4f06cb9a24f1895b6e70563d1c5
user:        "Kristian Oelgaard <[email-masked]>"
date:        Tue Aug 18 17:09:17 2009 +0100
files:       ffc/compiler/evaluatebasis.py ffc/compiler/finiteelement.py ffc/fem/createelement.py ffc/fem/finiteelement.py
description:
A first implementation of restrictions work for FiniteElements.

----------------------------------------------------------------------
For more details, visit http://www.fenics.org/hg/ffc

---

From: "Garth N. Wells" <[email-masked]>
Date: Tue, 18 Aug 2009 19:09:43 +0100

> Restrictions appears to be working for the Poisson demo.

Nice. What does the UFL syntax look like?

Garth

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

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 18 Aug 2009 20:35:13 +0200

> Nice. What does the UFL syntax look like?

scalar  = FiniteElement("CG", triangle, 3)
vector  = VectorElement("CG", triangle, 3)

#element = scalar
#element = scalar["interval"]
#element = scalar[interval] + scalar
element = vector[interval]

v = TestFunction(element)
u = TrialFunction(element)

a = inner(grad(v), grad(u))*dx

They should all work.

evaluate_basis and evaluate_basis_derivatives is not implemented for restricted
elements. The reason is that I'm not sure about what should happen when I throw
away basisfunctions.

Kristian

> > files:       ffc/compiler/evaluatebasis.py ffc/compiler/finiteelement.py
> ffc/fem/createelement.py ffc/fem/finiteelement.py
> > description:

---

From: [email-masked]
Date: Tue, 18 Aug 2009 20:38:24 +0200

> element = vector[interval]

What does this mean ?

Kent

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 18 Aug 2009 20:44:04 +0200

> > element = vector[interval]

It's related to this thread

http://www.fenics.org/pipermail/ffc-dev/2009-July/002726.html

the 'scalar' element will have 10 dofs, 3 at the vertices 6 on the edges and 1
inside the cell.

element = scalar[interval]

will not have the dof which is inside the cell, it is restricted to the facets
(which is interval in this case).

Kristian

---

From: "Garth N. Wells" <[email-masked]>
Date: Tue, 18 Aug 2009 19:45:59 +0100

> element = scalar[interval]

Do we have point, edge, face and facet as well?

Garth

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 18 Aug 2009 21:09:51 +0200

> Do we have point, edge, face and facet as well?

No, only interval, triangle, tetrahedron, quadrilateral and hexahedron

is predefined in UFL. I assume simplices and restrictions currently only
supports a restriction to one topological dimension lower i.e.,
tetrahedron -> triangle
triangle -> interval

Kristian

---

From: "Garth N. Wells" <[email-masked]>
Date: Tue, 18 Aug 2009 20:13:22 +0100

> supports a restriction to one topological dimension lower i.e.,

We need a 'facet', which is a triangle in 3D and interval in 2D, so we 
write dimension-independent forms (at least for 2D and 3D).

Garth

---

From: [email-masked]
Date: Tue, 18 Aug 2009 21:23:36 +0200

> (which is interval in this case).

Nice!!!

Will the 'interval' dofs include the vertex dofs ?

Kent

---

From: Anders Logg <[email-masked]>
Date: Tue, 18 Aug 2009 21:33:38 +0200

> >>>>>>> Restrictions appears to be working for the Poisson demo.

Excellent!

> write dimension-independent forms (at least for 2D and 3D).

That should be fairly easy to add to UFL (__getitem__ in finiteelement.py).
You can check if the input argument is facet (which needs to be
added), then look at self._cell and figure out the appropriate value
of index.

Let me know if you have any trouble.

--
Anders

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 18 Aug 2009 21:35:57 +0200

> Will the 'interval' dofs include the vertex dofs ?

Yes, in the current implementation. We can always change this later once we
agree on the interpretation.

Kristian

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 18 Aug 2009 22:36:54 +0200

> Let me know if you have any trouble.

OK, this functionality should be in place now. Do note that the built-in facet
has no meaning on its own, and it only works with restrictions. I don't know
how to make this implementation better at the moment (it's still work in
progress) but feel free to have a look.

Kristian

---

From: Anders Logg <[email-masked]>
Date: Tue, 18 Aug 2009 22:39:13 +0200

> progress) but feel free to have a look.

Really nice. Now we just need a pair of demos (C++/Python). :-)

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Tue, 18 Aug 2009 23:09:21 +0100

> Really nice. Now we just need a pair of demos (C++/Python). :-)

We need to do some work to have it functioning through PyDOLFIN. I think 
the PyDOLFIN FunctionSpace needs to be extended. Any ideas Johan?

Garth

> --
> Anders
> 
> 
> ------------------------------------------------------------------------
>

---

From: Johan Hake <[email-masked]>
Date: Wed, 19 Aug 2009 11:55:14 +0200

On Wednesday 19 August 2009 00:09:21 Garth N. Wells wrote:
> >>>>> is predefined in UFL. I assume simplices and restrictions currently
> >>>>> only supports a restriction to one topological dimension lower i.e.,
> >>>>> tetrahedron -> triangle
> >>>>> triangle -> interval
> >>>>
> >>> That should be fairly easy to add to UFL (__getitem__ in
> >>> finiteelement.py). You can check if the input argument is facet (which
> >>> needs to be added), then look at self._cell and figure out the
> >>> appropriate value of index.
> >>>
> >> OK, this functionality should be in place now. Do note that the built-in
> >> facet has no meaning on its own, and it only works with restrictions. I
> >> don't know how to make this implementation better at the moment (it's
> >> still work in progress) but feel free to have a look.
> >>
> >> Kristian
> >

Not sure what we have to do actually. I suppose I want get any clue from the 

  demo/function/restriction

demo? 

I see that Kent has modified the dolfin.FunctionSpace to reflect the present 
(broken) implementation of restriction, anything in that line? Should such an 
implementation has been done in FunctionSpaceBase instead of FunctionSpace? 
Kent?

Johan

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

---

From: Kent Andre <[email-masked]>
Date: Wed, 19 Aug 2009 13:00:04 +0200

> implementation has been done in FunctionSpaceBase instead of FunctionSpace? 

This restriction is different in the sense that the restriction is made
by the standard element on a sub mesh. 

The restriction in focus now is on the complete mesh but for only
a part of the element. 

Combined, these two features will be very powerful.  I guess the 
sub-mesh restriction stuff is broken due to the parallel mesh. 

Kent

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 19 Aug 2009 12:03:05 +0100

> sub-mesh restriction stuff is broken due to the parallel mesh. 

Yes, we had to clean-up the DofMap in particular to make progress with 
parallel assembly which means that sub-mesh restriction is broken at the 
moment.

Garth

---

From: Kent Andre <[email-masked]>
Date: Wed, 19 Aug 2009 13:07:30 +0200

> parallel assembly which means that sub-mesh restriction is broken at the 

OK, I guess we should also discuss whether sub-mesh type restrictions
should be done in this way (by a mesh and a mesh-function) or if a
sub-mesh should be implemented. 

Kent

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 19 Aug 2009 12:31:56 +0100

> sub-mesh restriction stuff is broken due to the parallel mesh. 

I've attached an example solver. To make it work for P^k with k > 2 we 
need to restrict some functions to cell facets. Using FFC, we do

     scalar  = FiniteElement("Lagrange", "triangle", 3)
     dscalar = FiniteElement("Discontinuous Lagrange", "triangle", 3)

     # This syntax restricts the space 'scalar' to cell facets.
     mixed = scalar["facet"] + dscalar

In PyDOLFIN we could do

     V_dg = FunctionSpace(mesh, "DG", 3)
     V_cg = FunctionSpace(mesh, "CG", 3, "facet")

     mixed = V_cg + V_dg

or

     V_dg = FunctionSpace(mesh, "DG", 3)
     V_cg = FunctionSpace(mesh, "CG", 3)

     mixed = V_cg["scalar"] + V_dg

Garth

> Kent
""" Steady state advection-diffusion equation based on Labeur, R.J. 
and Wells, G.N. (2007), http://dx.doi.org/10.1016/j.cma.2007.06.025

"""

__author__ = "Garth N. Wells ([email-masked]) and Robert Jan Labeur ([email-masked])"
__date__ = "2009-08-19"
__copyright__ = "Copyright (C) 2009 Garth N. Wells and Robert Jan Labeur"
__license__  = "GNU LGPL Version 2.1"

from dolfin import *

class Velocity(Function):
    def eval(self, values, x):
        values[0] = 0.0;
        values[1] = 0.0;
        #values[0] = -1.0;
        #values[1] = -0.4;

class DirichletBoundary(SubDomain):
    def inside(self, x, on_boundary):
        return abs(x[0] - 1.0) < DOLFIN_EPS and on_boundary

# Load mesh
#mesh = Mesh("unstruct-trimesh-2.xml.gz")
mesh = UnitSquare(32, 32)

# Defining the function spaces
V_dg = FunctionSpace(mesh, "DG", 2)
V_cg = FunctionSpace(mesh, "CG", 2)
V_b  = VectorFunctionSpace(mesh, "CG", 1)

mixed = V_cg + V_dg

# Test and trial functions
vhat, v = TestFunction(mixed)
uhat, u = TrialFunction(mixed)

# Set the the method (-1 = symmetric IP, 1 = Baumann-Oden)
method = -1.0

# Diffusivity
kappa = 1.0

# Source term
#f = 1.0
f = Function(V_cg, "500.0 * exp(-(pow(x[0] - 0.5, 2) + pow(x[1] - 0.5, 2)) / 0.02)")

b = Velocity(V_b)

# Penalty term
alpha = 0.0e0

# Mesh-related functions
n = FacetNormal(mesh)
h = CellSize(mesh)

# ( dot(v, n) + |dot(v, n)| )/2.0  = an on outflow,  0 on inflow 
an = (dot(b, n) + abs(dot(b, n)))/2.0

# ( -dot(v, n) + |dot(v, n)| )/2.0  = 0 on outflow,  -an on inflow 
an_min = (-dot(b, n) + abs(dot(b, n)))/2.0

# Standard flux
sigma = -b*u + kappa*grad(u) 

# Interface flux
sigma_a = -dot(b, n)*u + an_min*(uhat - u)
sigma_d = kappa*grad(u) + (alpha/h)*kappa*(uhat -u)*n
sigma_hat = sigma_a + dot(sigma_d, n)

# Bilinear form
a_local = dot(grad(v), sigma)*dx \
         - v('+')*sigma_hat('+')*dS - v('-')*sigma_hat('-')*dS \
         - method*dot(grad(v)('+'), n('+'))*kappa*(uhat('+') - u('+'))*dS \
         - method*dot(grad(v)('-'), n('-'))*kappa*(uhat('-') - u('-'))*dS \
         - v*sigma_hat*ds \
         - method*dot(grad(v), n)*kappa*(uhat - u)*ds

a_global = vhat('+')*sigma_hat('+')*dS + vhat('-')*sigma_hat('-')*dS \
         + vhat*sigma_hat*ds \
         + vhat*an*uhat*ds  # active on outflow boundary
          #+ vhat*hbc*ds  # Flux bc

a = a_local + a_global

# Linear form
L = v*f*dx

# Set up boundary condition (apply strong BCs)
g = Function(V_dg,"sin(pi*5.0*x[1])")
bc = DirichletBC(V_cg, g, DirichletBoundary())

# Solution function
uh = Function(mixed)

# Assemble and apply boundary conditions
A = assemble(a)
b = assemble(L)
bc.apply(A, b)

# Solve system
solve(A, uh.vector(), b)

file = File("u.pvd")
file << uh.sub(0)

# Plot solution
plot(uh.sub(0), interactive=True)

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 19 Aug 2009 13:21:12 +0100

Garth N. Wells wrote:
>>> I see that Kent has modified the dolfin.FunctionSpace to reflect the 
>>> present (broken) implementation of restriction, anything in that 
>>> line? Should such an implementation has been done in 
>>> FunctionSpaceBase instead of FunctionSpace? Kent?
>>>
>>> Johan
>>>
>>

I see now that we need to have the above option since the everything 
(e.g. the dof map) is created and compiled inside functionspace.py.

Garth

---

From: Johan Hake <[email-masked]>
Date: Wed, 19 Aug 2009 14:28:08 +0200

On Wednesday 19 August 2009 13:31:56 Garth N. Wells wrote:
> >> present (broken) implementation of restriction, anything in that line?
> >> Should such an implementation has been done in FunctionSpaceBase instead
> >> of FunctionSpace? Kent?
> >>
> >> Johan
> >

I am inclined to go for alternative 1, but I am a bit confused what a 
restricted MixedFunctionSpace is, and what the supspaces of such a Space would 
be.

Our FunctionSpace design in PyDOLFIN is a bit fragile so we need to think of a 
robust way to implement this.

Johan

---

From: Johan Hake <[email-masked]>
Date: Wed, 19 Aug 2009 14:34:54 +0200

On Wednesday 19 August 2009 14:28:08 Johan Hake wrote:
> > >> Should such an implementation has been done in FunctionSpaceBase
> > >> instead of FunctionSpace? Kent?
> > >>
> > >> Johan
> > >
> I am inclined to go for alternative 1, 

sorry ment 2...

> but I am a bit confused what a
> restricted MixedFunctionSpace is, and what the supspaces of such a Space
> would be.
>
> Our FunctionSpace design in PyDOLFIN is a bit fragile so we need to think
> of a robust way to implement this.
>
>
> Johan
>
> > Garth
> >
> > > Kent
> > >

---

From: Johan Hake <[email-masked]>
Date: Wed, 19 Aug 2009 14:39:58 +0200

> (e.g. the dof map) is created and compiled inside functionspace.py.

We could implement it in FunctionSpaceBase, as an operator, returning a new 
FunctionSpaceBase, with the restricted element as arguemnt.

However my concerns go to a sub space of a restricted mixed space (if such 
exists) see the other email. 

If we go for 1, (as you have already done ;) ), we cannot create a restricted 
mixed space using the addition syntax.

  mixed = V1 + V2

If we want a restricted mixed space we need to use the constructor.

  mixed = MixedFunctionSpace((V1,V2),restriction="facet")

Johan

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 19 Aug 2009 13:57:20 +0100

> mixed space using the addition syntax.

Do you mean to then restrict mixed? I'm already doing

     V0 = FunctionSpace(mesh, "CG", 3, "facet")
     V1 = FunctionSpace(mesh, "DG", 3)

     mixed = V0 + V1

and it works. This type of restriction (we'll need to sort out our 
terminology) impacts the dofmap, which I why I think it needs to be 
involved in the creation of the function space.

Garth

---

From: Johan Hake <[email-masked]>
Date: Wed, 19 Aug 2009 15:07:56 +0200

On Wednesday 19 August 2009 14:57:20 Garth N. Wells wrote:
> >>>> This restriction is different in the sense that the restriction is
> >>>> made by the standard element on a sub mesh.
> > We could implement it in FunctionSpaceBase, as an operator, returning a
> > new FunctionSpaceBase, with the restricted element as arguemnt.
> >
> > However my concerns go to a sub space of a restricted mixed space (if
> > such exists) see the other email.
> >
> > If we go for 1, (as you have already done ;) ), we cannot create a
> > restricted mixed space using the addition syntax.
> >
> >   mixed = V1 + V2
>

Precisely. 

After a second thought I think that doing it in the constructor is more clean. 
Makes life simpler. Is this also possible i UFL, I mean:

  e = FiniteElement("CG",cell,0,"facet")

Should it?

Johan

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 19 Aug 2009 14:12:21 +0100

>   e = FiniteElement("CG",cell,0,"facet")

Is that a PyDOLFIN finite element? If it is, then yes, that's how it 
should work.

Somewhat related, it's a bit annoying in PyDOLFIN that the code is 
recompiled when the mesh is changed. Can we avoid this? Should one then 
create a finite element and a dof map with which to initialise the 
Pythin FunctionSpace?

Garth

---

From: Johan Hake <[email-masked]>
Date: Wed, 19 Aug 2009 15:36:23 +0200

On Wednesday 19 August 2009 15:12:21 Garth N. Wells wrote:
> >>>>>>> I see that Kent has modified the dolfin.FunctionSpace to reflect
> >>>>>>> the present (broken) implementation of restriction, anything in
> >>>>>>> that line? Should such an implementation has been done in
> >>>>> I've attached an example solver. To make it work for P^k with k > 2
> >>>>> we need to restrict some functions to cell facets. Using FFC, we do
> >>>>>
> > After a second thought I think that doing it in the constructor is more
> > clean. Makes life simpler. Is this also possible i UFL, I mean:
> >

I meant UFL.FiniteElement.

> create a finite element and a dof map with which to initialise the

Do you mean when one has refined a mesh? As far as I understand it is the 
reason for this that we need to recompute the dofmap. 

How is this done in the C++ interface. 

Johan

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

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 19 Aug 2009 14:48:43 +0100

> I meant UFL.FiniteElement.

OK. I don't know if that is the syntax. Kristian will know.

> Do you mean when one has refined a mesh? 

Yes, or just changed from one simulation to the next.

As far as I understand it is the
> reason for this that we need to recompute the dofmap. 

In C++ we create a dolfin::FunctionSpace from a dolfin::FiniteElement, a 
dolfin::DofMap and a dolfin::Mesh. The FiniteElement and DofMap are 
created with a ufc::finite_element and a ufc::dof_map, respectively.

In the Python interface, in addition to what we have now, we would need 
FiniteElement and DofMap objects, with which we could create a 
FunctionSpace (together with a Mesh). Then, hopefully we could avoid 
recompilation when just the mesh is changed.

Garth

---

From: Johan Hake <[email-masked]>
Date: Wed, 19 Aug 2009 16:03:52 +0200

On Wednesday 19 August 2009 15:48:43 Garth N. Wells wrote:
> >>>>> We could implement it in FunctionSpaceBase, as an operator, returning
> >>>>> a new FunctionSpaceBase, with the restricted element as arguemnt.
> >>>>>

Are you sure we get a recompilation, or is the module just loaded from cache? 

> recompilation when just the mesh is changed.

If a mesh is refined it is the same mesh, and then it would be cool to just 
reinitialize the FunctionSpace, or the DofMap. Wouldn't this also be a feature 
in C++? 

  FunctionSpace::reinitialize()
  FunctionSpace::reinitialize(shared_ptr<Mesh> Mesh)

or something like that. The first one when the same mesh is being used, for 
example after a refinement, and the second one when another mesh is being 
used. Then we do not have to create a new FunctionSpace.

Johan

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

---

From: Kristian Oelgaard <[email-masked]>
Date: Wed, 19 Aug 2009 16:18:48 +0200

> >>>   e = FiniteElement("CG",cell,0,"facet")

No, and the above element is not even legal, for CG the degree must be >=1 :)

You have to use the __getitem__ operator of FiniteElementBase

a = element[cell]

or do

e = ElementRestriction(element, domain)

where domain is either a Measure or Cell and only Cell is supported in FFC.

In FFC I might consider adding a default 'domain=None' to the argument list of a
FiniteElement since it will make some things easier. Maybe we should add this in
UFL too?

Kristian

---

From: Johan Hake <[email-masked]>
Date: Wed, 19 Aug 2009 16:26:28 +0200

On Wednesday 19 August 2009 16:18:48 Kristian Oelgaard wrote:
> > >>>>>>>>> I see that Kent has modified the dolfin.FunctionSpace to
> > >>>>>>>>> reflect the present (broken) implementation of restriction,
> > >>>>>>>>> anything in that line? Should such an implementation has been
> > >>>>>>>>> done in FunctionSpaceBase instead of FunctionSpace? Kent?
> > >>>>>>>>>
> > >>>>>>>>> Johan
> > >>>>>>>>
> > >>>>>>>> This restriction is different in the sense that the restriction
> > >>>>>>>> is made by the standard element on a sub mesh.
> > >>>>>>>> The restriction in focus now is on the complete mesh but for
> > >>>>>>>> only a part of the element.
> > >>>>>>> I've attached an example solver. To make it work for P^k with k >
> > >>>>>>> 2 we need to restrict some functions to cell facets. Using FFC,
> > >>>>>>> we do
> > >>>>>>>
> > >>>>>> I see now that we need to have the above option since the
> > >>>>>> everything (e.g. the dof map) is created and compiled inside
> > >>>>>> functionspace.py.
> > >>>>>
> > >>>>> We could implement it in FunctionSpaceBase, as an operator,
> > >>>>> returning a new FunctionSpaceBase, with the restricted element as
> > >>>>> arguemnt.
> > >>>>>
> > >>>>> However my concerns go to a sub space of a restricted mixed space
> > >>>>> (if such exists) see the other email.
> > >>>>>
> > >>> After a second thought I think that doing it in the constructor is
> > >>> more clean. Makes life simpler. Is this also possible i UFL, I mean:
> > >>>
> In FFC I might consider adding a default 'domain=None' to the argument list
> of a FiniteElement since it will make some things easier. Maybe we should
> add this in UFL too?

More, harmony between the languages is nice, therefore I asked. Then we should 
probably support both syntaxes in PyDOLFIN, but the __getitem__ syntax might 
be troublesome to implement.

Johan

> > >> recompiled when the mesh is changed. Can we avoid this? Should one
> > >> then create a finite element and a dof map with which to initialise
> > >> the Pythin FunctionSpace?
> > >
> > >>>>>>> -----------------------------------------------------------------
> > >>>>>>>---- -- -
> > >>>>>>>

---

From: Kristian Oelgaard <[email-masked]>
Date: Wed, 19 Aug 2009 17:25:59 +0200

> be troublesome to implement.

Personally I don't mind adding the 'domain' argument to FiniteElementBase in
UFL, but maybe someone have objections in this regard? Then at least this
syntax will be similar to what you will/can do in PyDOLFIN. The only difference
is then not being able to use __getitem__ in PyDOLFIN.

Kristian

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 19 Aug 2009 22:26:56 +0100

> Are you sure we get a recompilation, or is the module just loaded from cache? 

It's recompiling. It seems to create code for each mesh I use. If I go 
back to a previously used mesh, it's super fast.

Garth

---

From: Johan Hake <[email-masked]>
Date: Thu, 20 Aug 2009 10:49:35 +0200

> back to a previously used mesh, it's super fast.

Strange, I get this after an instant-clean

   >>> from dolfin import *
   >>> m = UnitCube(10,10,10)
   >>> m2 = UnitCube(5,5,5)
   >>> V = FunctionSpace(m,"CG",2)
   Calling FFC just-in-time (JIT) compiler, this may take some time.
   >>> V2 = FunctionSpace(m2,"CG",2)
   >>>

As can be seen I do not get a recompile. This is all handed by ffc jit and 
JITObject. Particular JITObject.signature.

Put some print statements in there to debug maybe?

Johan

> > If a mesh is refined it is the same mesh, and then it would be cool to
> > just reinitialize the FunctionSpace, or the DofMap. Wouldn't this also be
> > a feature in C++?
> >
> > or something like that. The first one when the same mesh is being used,
> > for example after a refinement, and the second one when another mesh is
> > being used. Then we do not have to create a new FunctionSpace.
> >
> > Johan
> >
> >> Garth
> >>
> >>>>>>>>>-- -- -- -

---

From: "Garth N. Wells" <[email-masked]>
Date: Thu, 20 Aug 2009 09:55:54 +0100

> Put some print statements in there to debug maybe?

I didn't test it this way. I ran a demo with one mesh, changed it, and 
then ran the demo again.

Garth

---

From: Johan Hake <[email-masked]>
Date: Wed, 26 Aug 2009 13:21:49 +0200

> create a finite element and a dof map with which to initialise the

Should be fixed in a patch comming soon to ffc

Johan