Subject: [UFL-dev] [HG UFL] Fixed lhs/rhs bug, turns out it was in the list_tensor handler.

From: [email-masked] (UFL)
Date: Tue, 22 Sep 2009 20:14:18 +0200 (CEST)

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

changeset:   934:799f014b9983
tag:         tip
user:        martinal@martinal-desktop
date:        Tue Sep 22 20:13:30 2009 +0200
files:       ChangeLog ufl/algorithms/formtransformations.py ufl/formoperators.py ufl/tensors.py
description:
Fixed lhs/rhs bug, turns out it was in the list_tensor handler.
This was easy to find once ScalarSomething was removed.

changeset:   933:716b00f86749
user:        martinal@martinal-desktop
date:        Tue Sep 22 19:30:12 2009 +0200
files:       ufl/classes.py ufl/constantvalue.py
description:
Removed ScalarSomething. Now getting proper error message when type conversion fails.

changeset:   932:85fd3f21bdde
user:        "Kristian Oelgaard <[email-masked]>"
date:        Tue Sep 22 19:02:28 2009 +0200
files:       ChangeLog
description:
Added note on ElementRestriction to ChangeLog.

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

---

From: Anders Logg <[email-masked]>
Date: Tue, 22 Sep 2009 20:28:03 +0200

Harish, can you test on your forms so we know it works before the
release?

Martin, do you want to make the release or should I make it?

--
Anders

On Tue, Sep 22, 2009 at 08:14:18PM +0200, UFL wrote:
> _______________________________________________
> UFL-dev mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/ufl-dev

---

From: Harish Narayanan <[email-masked]>
Date: Tue, 22 Sep 2009 20:31:04 +0200

> Harish, can you test on your forms so we know it works before the

I already did, and something's not ok (with LHS/RHS). I'll try to send
the simplest case that reproduces my problem.

Harish

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 22 Sep 2009 20:32:41 +0200

Feel free to do the release. I have a trial lecture to prepare :)

Martin

On Tue, Sep 22, 2009 at 8:28 PM, Anders Logg <[email-masked]> wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkq5FzIACgkQTuwUCDsYZdF4FgCfUDorzKgFA2IZ+cgi6TUv67so
> y3cAn1qqyNvewm4GzJY5HdaSxIFaMKU7
> =YJ7/
> -----END PGP SIGNATURE-----
>

---

From: Anders Logg <[email-masked]>
Date: Tue, 22 Sep 2009 20:43:32 +0200

ok. I'm looking forward to that (the trial lecture). :-)

--
Anders

---

From: Harish Narayanan <[email-masked]>
Date: Tue, 22 Sep 2009 20:47:23 +0200

> the simplest case that reproduces my problem.

The attached form does not compile.

Harish
# Define the symmetric gradient of the velocity
def sgrad(v):
    return 0.5*(grad(v) + grad(v).T)

# Define the Cauchy stress tensor
def sigma(v, q):
    return 2.0*nu*sgrad(v) - q*Identity(v.cell().d)

cell = triangle
vector = VectorElement("Lagrange", cell, 2)
scalar = FiniteElement("Lagrange", cell, 1)

v = TestFunction(vector)
q = TestFunction(scalar)
u = TrialFunction(vector)
p = TrialFunction(scalar)

p0 = Function(scalar)
nu = Function(scalar)

F =  inner(sgrad(v), sigma(u, p0))*dx

a = lhs(F)
L = rhs(F)

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 22 Sep 2009 21:01:43 +0200

I agree that the error is completely incomprehensible,
but in sigma(u, p0) you're adding terms with a trialfunction
only in one of the terms. Can you try with a valid form?

Martin

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 22 Sep 2009 21:06:47 +0200

It doesn't help replacing p0 with p though...

Martin

---

From: Harish Narayanan <[email-masked]>
Date: Tue, 22 Sep 2009 21:16:29 +0200

> only in one of the terms. Can you try with a valid form?

I was overzealous in reducing the size of the form. As you noted in your
next e-mail, changing p0 to p results in the same error.

Harish

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 22 Sep 2009 21:26:17 +0200

Further simplification that still reproduces the problem:

cell = triangle
d = cell.d
I = Identity(d)

vector = VectorElement("Lagrange", cell, 2)
scalar = FiniteElement("Lagrange", cell, 1)
element = vector + scalar

v, q = TestFunctions(element)
u, p = TrialFunctions(element)

F = inner(grad(v), grad(u) - p*I)*dx

#a = lhs(F)
L = rhs(F)

Note that you didn't use a mixed element.

Martin

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 22 Sep 2009 22:00:16 +0200

I fixed _something_...

Now I'm getting:

Visiting Zero: Zero((), (), {})
Zero is not supported (yet).

*** FFC: Zero is not supported (yet).
*** FFC: To get more information about this error, rerun FFC with --debug.

And sfc fails to compile the form for some other reason.

Martin

---

From: Harish Narayanan <[email-masked]>
Date: Tue, 22 Sep 2009 22:28:29 +0200

> And sfc fails to compile the form for some other reason.

I am just writing to note that the original form I was trying to compile
where I noticed this error (it was not a system) is now working.

Harish

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 23 Sep 2009 12:09:15 +0100

> where I noticed this error (it was not a system) is now working.

What's the status of this? Is it critical enough to hold up a release 
(more to the point, a release of all the other FEniCS components which 
is long overdue)?

Garth

---

From: Harish Narayanan <[email-masked]>
Date: Wed, 23 Sep 2009 13:32:27 +0200

> (more to the point, a release of all the other FEniCS components which

I just checked this and the case that Martin mentioned (which has a zero
rhs) still doesn't work.

cell = triangle
d = cell.d
I = Identity(d)

#a = lhs(F)
L = rhs(F)

Harish

---

From: Kristian Oelgaard <[email-masked]>
Date: Wed, 23 Sep 2009 12:41:43 +0200

> I just checked this and the case that Martin mentioned (which has a zero

I wouldn't call this a bug, it's just a missing implementation. We have a ton of
other things that are not implemented/supported yet, so if we have to wait for
all that, the release will never happen.
At least it crashes with a sensible error message.

Kristian

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 23 Sep 2009 12:46:32 +0100

> At least it crashes with a sensible error message.

OK. So unless someone is working on resolving it imminently. I suggest 
that we move forward with a release.

Garth

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 23 Sep 2009 14:10:25 +0200

> that we move forward with a release.

I concur.

Martin

---

From: "Garth N. Wells" <[email-masked]>
Date: Wed, 23 Sep 2009 15:10:03 +0100

>> that we move forward with a release.

OK! Anders, can you make the release of UFL? Then the rest can follow.

Garth

---

From: Anders Logg <[email-masked]>
Date: Wed, 23 Sep 2009 16:13:10 +0200

> OK! Anders, can you make the release of UFL? Then the rest can follow.

Yes, I just want the buildbot to be green first. It's currently
failing because of the update to UFL which results in different
signatures and different code for some of the demos.

I'll check that and then release UFL, UFC, FFC.

--
Anders

---

From: Anders Logg <[email-masked]>
Date: Wed, 23 Sep 2009 20:55:58 +0200

> I'll check that and then release UFL, UFC, FFC.

I've done UFL and UFC. Will release FFC when we've fixed the bug for
the Windows buildbot. It's not very important but it's nice to do it
before the release since we are going to update the references.

-- 
Anders