Strange results in JIT compilation

Works fine with 1.1.x, but not with 1.2.x or trunk.

On 03/11/2013 10:28 AM, Johannes Ring wrote:
> Works fine with 1.1.x, but not with 1.2.x or trunk.

Probably something with signature computation then.

Johan

> ** Changed in: dolfin Status: New => Confirmed
>

Are you sure this is a bug?

In the first example the Expression is generated without setting the
degree. If this is auto chosen to 2 it should make perfectly sense they
give the same results. Change degree to something else and you will have
a different results.

Johan

On 03/11/2013 10:06 AM, Marie Rognes wrote:
> Public bug reported:
>
> There seems to be something seriously wrong with either DOLFIN-FFC jit
> compilation or caching or instant.
>
> To reproduce, for instance consider the following code snippet and do
> the following
>
> (1): Run instant-clean
>
> (2): Run script unmodified.
>
> Output is:
>
> Calling FFC just-in-time (JIT) compiler, this may take some time.
> Calling DOLFIN just-in-time (JIT) compiler, this may take some time.
> Calling FFC just-in-time (JIT) compiler, this may take some time.
> Calling FFC just-in-time (JIT) compiler, this may take some time.
> Solving linear system of size 1089 x 1089 (PETSc Krylov solver).
> 40.4757877531
>
> (3) Uncomment commented lines and run.
>
> Output is:
>
> Solving linear system of size 1089 x 1089 (PETSc Krylov solver).
> 40.4757877531
> Solving linear system of size 1089 x 1089 (PETSc Krylov solver).
> 40.4757877531 (*)
>
> (4) Run instant-clean, comment out lines defining f, g, and 1st print.
> Run.
>
> Output is
> Calling FFC just-in-time (JIT) compiler, this may take some time.
> Calling DOLFIN just-in-time (JIT) compiler, this may take some time.
> Calling FFC just-in-time (JIT) compiler, this may take some time.
> Calling FFC just-in-time (JIT) compiler, this may take some time.
> Solving linear system of size 1089 x 1089 (PETSc Krylov solver).
> 40.490263582 (**)
>
> Problem: The last two floats, tagged by (*) and (**), should be the
> same: they are not.
>
> Code snippet:
>
> --
>
>
> from dolfin import *
> mesh = UnitSquareMesh(16,16)
> V = FunctionSpace(mesh, 'CG', 2)
>
> f = Expression("x[0]*x[0] + 2*x[1]*x[1]")
> g = project(f, V)
> print g.vector().norm("l2")
>
> #f2 = Expression("x[0]*x[0] + 2*x[1]*x[1]", degree=2)
> #g2 = project(f2, V)
> #print g2.vector().norm("l2")
>
>
> --
>
> ** Affects: dolfin
> Importance: Undecided
> Status: New
>

On 03/11/2013 04:07 PM, Johan Hake wrote:
> Are you sure this is a bug?

Pretty sure, yes.

> In the first example the Expression is generated without setting the
> degree. If this is auto chosen to 2 it should make perfectly sense they
> give the same results.

Yes. But the problem is that the Expression with degree=2 gives
different results depending on what has been compiled before it.

> Change degree to something else and you will have
> a different results.

Did you read the problem carefully? Look at (*) and (**). Both of these
correspond to setting degree=2 explicitly. The numbers should therefore
be the same. They are not, which is highly disturbing. (*) is produced
after doing instant-clean, running with auto degree, and running with
degree = 2 (which seems to reuse the auto degree code); while (**) is
produced after doing instant-clean and directly running with degree=2.

--
Marie

> Johan
>
> On 03/11/2013 10:06 AM, Marie Rognes wrote:
>> Public bug reported:
>>
>> There seems to be something seriously wrong with either DOLFIN-FFC jit
>> compilation or caching or instant.
>>
>> To reproduce, for instance consider the following code snippet and do
>> the following
>>
>> (1): Run instant-clean
>>
>> (2): Run script unmodified.
>>
>> Output is:
>>
>> Calling FFC just-in-time (JIT) compiler, this may take some time.
>> Calling DOLFIN just-in-time (JIT) compiler, this may take some time.
>> Calling FFC just-in-time (JIT) compiler, this may take some time.
>> Calling FFC just-in-time (JIT) compiler, this may take some time.
>> Solving linear system of size 1089 x 1089 (PETSc Krylov solver).
>> 40.4757877531
>>
>> (3) Uncomment commented lines and run.
>>
>> Output is:
>>
>> Solving linear system of size 1089 x 1089 (PETSc Krylov solver).
>> 40.4757877531
>> Solving linear system of size 1089 x 1089 (PETSc Krylov solver).
>> 40.4757877531 (*)
>>
>> (4) Run instant-clean, comment out lines defining f, g, and 1st print.
>> Run.
>>
>> Output is
>> Calling FFC just-in-time (JIT) compiler, this may take some time.
>> Calling DOLFIN just-in-time (JIT) compiler, this may take some time.
>> Calling FFC just-in-time (JIT) compiler, this may take some time.
>> Calling FFC just-in-time (JIT) compiler, this may take some time.
>> Solving linear system of size 1089 x 1089 (PETSc Krylov solver).
>> 40.490263582 (**)
>>
>> Problem: The last two floats, tagged by (*) and (**), should be the
>> same: they are not.
>>
>> Code snippet:
>>
>> --
>>
>>
>> from dolfin import *
>> mesh = UnitSquareMesh(16,16)
>> V = FunctionSpace(mesh, 'CG', 2)
>>
>> f = Expression("x[0]*x[0] + 2*x[1]*x[1]")
>> g = project(f, V)
>> print g.vector().norm("l2")
>>
>> #f2 = Expression("x[0]*x[0] + 2*x[1]*x[1]", degree=2)
>> #g2 = project(f2, V)
>> #print g2.vector().norm("l2")
>>
>>
>> --
>>
>> ** Affects: dolfin
>> Importance: Undecided
>> Status: New
>>

On 03/11/2013 04:31 PM, Marie Rognes wrote:
> On 03/11/2013 04:07 PM, Johan Hake wrote:
>> Are you sure this is a bug?
>
> Pretty sure, yes.
>
>> In the first example the Expression is generated without setting the
>> degree. If this is auto chosen to 2 it should make perfectly sense they
>> give the same results.
>
> Yes. But the problem is that the Expression with degree=2 gives
> different results depending on what has been compiled before it.
>
>> Change degree to something else and you will have
>> a different results.
>
> Did you read the problem carefully? Look at (*) and (**). Both of these
> correspond to setting degree=2 explicitly. The numbers should therefore
> be the same. They are not, which is highly disturbing. (*) is produced
> after doing instant-clean, running with auto degree, and running with
> degree = 2 (which seems to reuse the auto degree code); while (**) is
> produced after doing instant-clean and directly running with degree=2.

Ok, I see it now. Pretty disturbing yes.

How can we find out what degree is chosen for the expression when it is
autogenerated? Is it during preprocess? Is it still so that it is the
repr of the preprocessed form that determines if a form will get recompiled?

from dolfin import *

mesh = UnitSquareMesh(16,16)
V = FunctionSpace(mesh, 'CG', 2)
w = TestFunction(V)
f = Expression("x[0]*x[0] + 2*x[1]*x[1]")
L = inner(w, f)*dx
b = assemble(L)

print "Preprocessed:", repr(L.form_data().preprocessed_form)
print "Not preprocessed:", repr(L)

Prints:
Preprocessed: Form([Integral(Product(Argument(FiniteElement('Lagrange',
Domain(Cell('triangle', 2), 'triangle_multiverse', 2, 2), 2, None), -2),
Coefficient(FiniteElement('Lagrange', None, None, None), 0)), 'cell',
'otherwise', None, None)])
Not preprocessed:
Form([Integral(Product(Argument(FiniteElement('Lagrange',
Domain(Cell('triangle', 2), 'triangle_multiverse', 2, 2), 2, None), -2),
Coefficient(FiniteElement('Lagrange', None, None, None), 0)), 'cell',
'everywhere', None, None)])

Where it is clear that the Coefficient of the first form has not got any
degree. Shouldn't it have got one?

Johan

> --
> Marie
>
>
>> Johan
>>
>> On 03/11/2013 10:06 AM, Marie Rognes wrote:
>>> Public bug reported:
>>>
>>> There seems to be something seriously wrong with either DOLFIN-FFC jit
>>> compilation or caching or instant.
>>>
>>> To reproduce, for instance consider the following code snippet and do
>>> the following
>>>
>>> (1): Run instant-clean
>>>
>>> (2): Run script unmodified.
>>>
>>> Output is:
>>>
>>> Calling FFC just-in-time (JIT) compiler, this may take some time.
>>> Calling DOLFIN just-in-time (JIT) compiler, this may take some time.
>>> Calling FFC just-in-time (JIT) compiler, this may take some time.
>>> Calling FFC just-in-time (JIT) compiler, this may take some time.
>>> Solving linear system of size 1089 x 1089 (PETSc Krylov solver).
>>> 40.4757877531
>>>
>>> (3) Uncomment commented lines and run.
>>>
>>> Output is:
>>>
>>> Solving linear system of size 1089 x 1089 (PETSc Krylov solver).
>>> 40.4757877531
>>> Solving linear system of size 1089 x 1089 (PETSc Krylov solver).
>>> 40.4757877531 (*)
>>>
>>> (4) Run instant-clean, commen...

I would look at the instant side. Or in ffc.jitobject. repr of a form is
not used anywhere.

Martin
Den 11. mars 2013 18:20 skrev "Johan Hake" <email address hidden>
følgende:

> On 03/11/2013 04:31 PM, Marie Rognes wrote:
> > On 03/11/2013 04:07 PM, Johan Hake wrote:
> >> Are you sure this is a bug?
> >
> > Pretty sure, yes.
> >
> >> In the first example the Expression is generated without setting the
> >> degree. If this is auto chosen to 2 it should make perfectly sense they
> >> give the same results.
> >
> > Yes. But the problem is that the Expression with degree=2 gives
> > different results depending on what has been compiled before it.
> >
> >> Change degree to something else and you will have
> >> a different results.
> >
> > Did you read the problem carefully? Look at (*) and (**). Both of these
> > correspond to setting degree=2 explicitly. The numbers should therefore
> > be the same. They are not, which is highly disturbing. (*) is produced
> > after doing instant-clean, running with auto degree, and running with
> > degree = 2 (which seems to reuse the auto degree code); while (**) is
> > produced after doing instant-clean and directly running with degree=2.
>
> Ok, I see it now. Pretty disturbing yes.
>
> How can we find out what degree is chosen for the expression when it is
> autogenerated? Is it during preprocess? Is it still so that it is the
> repr of the preprocessed form that determines if a form will get
> recompiled?
>
> from dolfin import *
>
> mesh = UnitSquareMesh(16,16)
> V = FunctionSpace(mesh, 'CG', 2)
> w = TestFunction(V)
> f = Expression("x[0]*x[0] + 2*x[1]*x[1]")
> L = inner(w, f)*dx
> b = assemble(L)
>
> print "Preprocessed:", repr(L.form_data().preprocessed_form)
> print "Not preprocessed:", repr(L)
>
> Prints:
> Preprocessed: Form([Integral(Product(Argument(FiniteElement('Lagrange',
> Domain(Cell('triangle', 2), 'triangle_multiverse', 2, 2), 2, None), -2),
> Coefficient(FiniteElement('Lagrange', None, None, None), 0)), 'cell',
> 'otherwise', None, None)])
> Not preprocessed:
> Form([Integral(Product(Argument(FiniteElement('Lagrange',
> Domain(Cell('triangle', 2), 'triangle_multiverse', 2, 2), 2, None), -2),
> Coefficient(FiniteElement('Lagrange', None, None, None), 0)), 'cell',
> 'everywhere', None, None)])
>
> Where it is clear that the Coefficient of the first form has not got any
> degree. Shouldn't it have got one?
>
> Johan
>
>
> > --
> > Marie
> >
> >
> >> Johan
> >>
> >> On 03/11/2013 10:06 AM, Marie Rognes wrote:
> >>> Public bug reported:
> >>>
> >>> There seems to be something seriously wrong with either DOLFIN-FFC jit
> >>> compilation or caching or instant.
> >>>
> >>> To reproduce, for instance consider the following code snippet and do
> >>> the following
> >>>
> >>> (1): Run instant-clean
> >>>
> >>> (2): Run script unmodified.
> >>>
> >>> Output is:
> >>>
> >>> Calling FFC just-in-time (JIT) compiler, this may take some time.
> >>> Calling DOLFIN just-in-time (JIT) compiler, this may take some time.
> >>> Calling FFC just-in-time (JIT) compiler, this may take some time.
> >>> Calling FFC just-in-time (JIT) compiler, this may take some time.
> >>> Solving linear system of size 1089 x ...

The two forms generates the same signature, but different
tabulate_tensor functions. Something is fishy with form_data.signature.

instant-clean
run script
out-comment region and run instant-clean

from dolfin import *

mesh = UnitSquareMesh(16,16)
V = FunctionSpace(mesh, 'CG', 2)
w = TestFunction(V)
Pv = TrialFunction(V)
a = inner(w, Pv)*dx
A = assemble(a)
u = Function(V)

# Out-comment next region and run instant clean to reproduce bug
f = Expression("x[0]*x[0] + 2*x[1]*x[1]")
L = inner(w, f)*dx
b = assemble(L)
print "Signature", L.form_data().signature
solve(A, u.vector(), b)
print u.vector().norm("l2")
# Out-comment to here.

f2 = Expression("x[0]*x[0] + 2*x[1]*x[1]", degree=2)
L = inner(w, f2)*dx
b = assemble(L)
solve(A, u.vector(), b)
print "Signature", L.form_data().signature
print u.vector().norm("l2")

Happy bug hunting :)

Johan

On 03/11/2013 07:28 PM, Martin Sandve Alnæs wrote:
> I would look at the instant side. Or in ffc.jitobject. repr of a form is
> not used anywhere.
>
> Martin
> Den 11. mars 2013 18:20 skrev "Johan Hake" <email address hidden>
> følgende:
>
>> On 03/11/2013 04:31 PM, Marie Rognes wrote:
>>> On 03/11/2013 04:07 PM, Johan Hake wrote:
>>>> Are you sure this is a bug?
>>>
>>> Pretty sure, yes.
>>>
>>>> In the first example the Expression is generated without setting the
>>>> degree. If this is auto chosen to 2 it should make perfectly sense they
>>>> give the same results.
>>>
>>> Yes. But the problem is that the Expression with degree=2 gives
>>> different results depending on what has been compiled before it.
>>>
>>>> Change degree to something else and you will have
>>>> a different results.
>>>
>>> Did you read the problem carefully? Look at (*) and (**). Both of these
>>> correspond to setting degree=2 explicitly. The numbers should therefore
>>> be the same. They are not, which is highly disturbing. (*) is produced
>>> after doing instant-clean, running with auto degree, and running with
>>> degree = 2 (which seems to reuse the auto degree code); while (**) is
>>> produced after doing instant-clean and directly running with degree=2.
>>
>> Ok, I see it now. Pretty disturbing yes.
>>
>> How can we find out what degree is chosen for the expression when it is
>> autogenerated? Is it during preprocess? Is it still so that it is the
>> repr of the preprocessed form that determines if a form will get
>> recompiled?
>>
>> from dolfin import *
>>
>> mesh = UnitSquareMesh(16,16)
>> V = FunctionSpace(mesh, 'CG', 2)
>> w = TestFunction(V)
>> f = Expression("x[0]*x[0] + 2*x[1]*x[1]")
>> L = inner(w, f)*dx
>> b = assemble(L)
>>
>> print "Preprocessed:", repr(L.form_data().preprocessed_form)
>> print "Not preprocessed:", repr(L)
>>
>> Prints:
>> Preprocessed: Form([Integral(Product(Argument(FiniteElement('Lagrange',
>> Domain(Cell('triangle', 2), 'triangle_multiverse', 2, 2), 2, None), -2),
>> Coefficient(FiniteElement('Lagrange', None, None, None), 0)), 'cell',
>> 'otherwise', None, None)])
>> Not preprocessed:
>> Form([Integral(Product(Argument(FiniteElement('Lagrange',
>> Domain(Cell('triangle', 2), 'triangle_multiverse', 2, 2), 2, None), -2),
>> Coefficient(FiniteElement('Lagrange', None, None, None), 0))...

Here's what I've found out so far:

- The tabulate_tensor functions in your example should be equal, it's
actually the signature that is correct.

- The bug is independent of ffc representation (quadrature, tensor, and
uflacs),

- In uflacs I see some tables for CG2 values are different which they
shouldn't be. Since not all of the table generation is shared between
representations, this narrows it down.

- My strong hunch now is that some place in FFC, related to tabulation of
element values from FIAT, access UFL elements without replacing with the
mapped element. I have checked in a slightly simpler script in uflacs that
cause a failure, which could be related.

Martin

On 11 March 2013 19:59, Johan Hake <email address hidden> wrote:

> The two forms generates the same signature, but different
> tabulate_tensor functions. Something is fishy with form_data.signature.
>
> instant-clean
> run script
> out-comment region and run instant-clean
>
> from dolfin import *
>
> mesh = UnitSquareMesh(16,16)
> V = FunctionSpace(mesh, 'CG', 2)
> w = TestFunction(V)
> Pv = TrialFunction(V)
> a = inner(w, Pv)*dx
> A = assemble(a)
> u = Function(V)
>
> # Out-comment next region and run instant clean to reproduce bug
> f = Expression("x[0]*x[0] + 2*x[1]*x[1]")
> L = inner(w, f)*dx
> b = assemble(L)
> print "Signature", L.form_data().signature
> solve(A, u.vector(), b)
> print u.vector().norm("l2")
> # Out-comment to here.
>
> f2 = Expression("x[0]*x[0] + 2*x[1]*x[1]", degree=2)
> L = inner(w, f2)*dx
> b = assemble(L)
> solve(A, u.vector(), b)
> print "Signature", L.form_data().signature
> print u.vector().norm("l2")
>
>
> Happy bug hunting :)
>
> Johan
>
>
> On 03/11/2013 07:28 PM, Martin Sandve Alnæs wrote:
> > I would look at the instant side. Or in ffc.jitobject. repr of a form is
> > not used anywhere.
> >
> > Martin
> > Den 11. mars 2013 18:20 skrev "Johan Hake" <email address hidden>
> > følgende:
> >
> >> On 03/11/2013 04:31 PM, Marie Rognes wrote:
> >>> On 03/11/2013 04:07 PM, Johan Hake wrote:
> >>>> Are you sure this is a bug?
> >>>
> >>> Pretty sure, yes.
> >>>
> >>>> In the first example the Expression is generated without setting the
> >>>> degree. If this is auto chosen to 2 it should make perfectly sense
> they
> >>>> give the same results.
> >>>
> >>> Yes. But the problem is that the Expression with degree=2 gives
> >>> different results depending on what has been compiled before it.
> >>>
> >>>> Change degree to something else and you will have
> >>>> a different results.
> >>>
> >>> Did you read the problem carefully? Look at (*) and (**). Both of
> these
> >>> correspond to setting degree=2 explicitly. The numbers should therefore
> >>> be the same. They are not, which is highly disturbing. (*) is produced
> >>> after doing instant-clean, running with auto degree, and running with
> >>> degree = 2 (which seems to reuse the auto degree code); while (**) is
> >>> produced after doing instant-clean and directly running with degree=2.
> >>
> >> Ok, I see it now. Pretty disturbing yes.
> >>
> >> How can we find out what degree is chosen for the expression when it is
> >> autogenerated? Is it during preprocess? Is it still so that...

On 03/12/2013 12:28 AM, Martin Sandve Alnæs wrote:
> Here's what I've found out so far:
>
> - The tabulate_tensor functions in your example should be equal, it's
> actually the signature that is correct.
>
> - The bug is independent of ffc representation (quadrature, tensor, and
> uflacs),
>
> - In uflacs I see some tables for CG2 values are different which they
> shouldn't be. Since not all of the table generation is shared between
> representations, this narrows it down.

Ok, but the bug was present in all representations?

> - My strong hunch now is that some place in FFC, related to tabulation of
> element values from FIAT, access UFL elements without replacing with the
> mapped element. I have checked in a slightly simpler script in uflacs that
> cause a failure, which could be related.

Ok, this is so beyond me...

Johan

> Martin
>
>
> On 11 March 2013 19:59, Johan Hake <email address hidden> wrote:
>
>> The two forms generates the same signature, but different
>> tabulate_tensor functions. Something is fishy with form_data.signature.
>>
>> instant-clean
>> run script
>> out-comment region and run instant-clean
>>
>> from dolfin import *
>>
>> mesh = UnitSquareMesh(16,16)
>> V = FunctionSpace(mesh, 'CG', 2)
>> w = TestFunction(V)
>> Pv = TrialFunction(V)
>> a = inner(w, Pv)*dx
>> A = assemble(a)
>> u = Function(V)
>>
>> # Out-comment next region and run instant clean to reproduce bug
>> f = Expression("x[0]*x[0] + 2*x[1]*x[1]")
>> L = inner(w, f)*dx
>> b = assemble(L)
>> print "Signature", L.form_data().signature
>> solve(A, u.vector(), b)
>> print u.vector().norm("l2")
>> # Out-comment to here.
>>
>> f2 = Expression("x[0]*x[0] + 2*x[1]*x[1]", degree=2)
>> L = inner(w, f2)*dx
>> b = assemble(L)
>> solve(A, u.vector(), b)
>> print "Signature", L.form_data().signature
>> print u.vector().norm("l2")
>>
>>
>> Happy bug hunting :)
>>
>> Johan
>>
>>
>> On 03/11/2013 07:28 PM, Martin Sandve Alnæs wrote:
>>> I would look at the instant side. Or in ffc.jitobject. repr of a form is
>>> not used anywhere.
>>>
>>> Martin
>>> Den 11. mars 2013 18:20 skrev "Johan Hake" <email address hidden>
>>> følgende:
>>>
>>>> On 03/11/2013 04:31 PM, Marie Rognes wrote:
>>>>> On 03/11/2013 04:07 PM, Johan Hake wrote:
>>>>>> Are you sure this is a bug?
>>>>>
>>>>> Pretty sure, yes.
>>>>>
>>>>>> In the first example the Expression is generated without setting the
>>>>>> degree. If this is auto chosen to 2 it should make perfectly sense
>> they
>>>>>> give the same results.
>>>>>
>>>>> Yes. But the problem is that the Expression with degree=2 gives
>>>>> different results depending on what has been compiled before it.
>>>>>
>>>>>> Change degree to something else and you will have
>>>>>> a different results.
>>>>>
>>>>> Did you read the problem carefully? Look at (*) and (**). Both of
>> these
>>>>> correspond to setting degree=2 explicitly. The numbers should therefore
>>>>> be the same. They are not, which is highly disturbing. (*) is produced
>>>>> after doing instant-clean, running with auto degree, and running with
>>>>> degree = 2 (which seems to reuse the auto degree code); while (**) is
>>>>> produced after doing instant-clean and directl...

Short version: it was probably my fault and I am on the track.

Martin
Den 12. mars 2013 08:30 skrev "Johan Hake" <email address hidden>
følgende:

> On 03/12/2013 12:28 AM, Martin Sandve Alnæs wrote:
> > Here's what I've found out so far:
> >
> > - The tabulate_tensor functions in your example should be equal, it's
> > actually the signature that is correct.
> >
> > - The bug is independent of ffc representation (quadrature, tensor, and
> > uflacs),
> >
> > - In uflacs I see some tables for CG2 values are different which they
> > shouldn't be. Since not all of the table generation is shared between
> > representations, this narrows it down.
>
> Ok, but the bug was present in all representations?
>
> > - My strong hunch now is that some place in FFC, related to tabulation of
> > element values from FIAT, access UFL elements without replacing with the
> > mapped element. I have checked in a slightly simpler script in uflacs
> that
> > cause a failure, which could be related.
>
> Ok, this is so beyond me...
>
> Johan
>
> > Martin
> >
> >
> > On 11 March 2013 19:59, Johan Hake <email address hidden> wrote:
> >
> >> The two forms generates the same signature, but different
> >> tabulate_tensor functions. Something is fishy with form_data.signature.
> >>
> >> instant-clean
> >> run script
> >> out-comment region and run instant-clean
> >>
> >> from dolfin import *
> >>
> >> mesh = UnitSquareMesh(16,16)
> >> V = FunctionSpace(mesh, 'CG', 2)
> >> w = TestFunction(V)
> >> Pv = TrialFunction(V)
> >> a = inner(w, Pv)*dx
> >> A = assemble(a)
> >> u = Function(V)
> >>
> >> # Out-comment next region and run instant clean to reproduce bug
> >> f = Expression("x[0]*x[0] + 2*x[1]*x[1]")
> >> L = inner(w, f)*dx
> >> b = assemble(L)
> >> print "Signature", L.form_data().signature
> >> solve(A, u.vector(), b)
> >> print u.vector().norm("l2")
> >> # Out-comment to here.
> >>
> >> f2 = Expression("x[0]*x[0] + 2*x[1]*x[1]", degree=2)
> >> L = inner(w, f2)*dx
> >> b = assemble(L)
> >> solve(A, u.vector(), b)
> >> print "Signature", L.form_data().signature
> >> print u.vector().norm("l2")
> >>
> >>
> >> Happy bug hunting :)
> >>
> >> Johan
> >>
> >>
> >> On 03/11/2013 07:28 PM, Martin Sandve Alnæs wrote:
> >>> I would look at the instant side. Or in ffc.jitobject. repr of a form
> is
> >>> not used anywhere.
> >>>
> >>> Martin
> >>> Den 11. mars 2013 18:20 skrev "Johan Hake" <<email address hidden>
> >
> >>> følgende:
> >>>
> >>>> On 03/11/2013 04:31 PM, Marie Rognes wrote:
> >>>>> On 03/11/2013 04:07 PM, Johan Hake wrote:
> >>>>>> Are you sure this is a bug?
> >>>>>
> >>>>> Pretty sure, yes.
> >>>>>
> >>>>>> In the first example the Expression is generated without setting the
> >>>>>> degree. If this is auto chosen to 2 it should make perfectly sense
> >> they
> >>>>>> give the same results.
> >>>>>
> >>>>> Yes. But the problem is that the Expression with degree=2 gives
> >>>>> different results depending on what has been compiled before it.
> >>>>>
> >>>>>> Change degree to something else and you will have
> >>>>>> a different results.
> >>>>>
> >>>>> Did you read the problem carefully? Look at (*) and (**). Both of
> >> these
> >>>>> correspond ...

Found it, just waiting for ffc tests to pass locally. The element mapping was not considered when estimating quadrature degree, so the integral with an Expression without a well defined element (degree=None) got a different degree, even though the final form was the same.

This halfway-defined coefficients stuff in pydolfin is killing me... It creates so many special case situations.