Subject: [FFC-dev] [Bug 426512] Re: Problems parsing form file with diff and derivative

From: Garth Wells <[email-masked]>
Date: Wed, 09 Sep 2009 05:56:32 -0000

Are you using optimisation ('-O' flag)?

-- 
Problems parsing form file with diff and derivative
https://bugs.launchpad.net/bugs/426512
You received this bug notification because you are subscribed to FFC.

Status in FEniCS Form Compiler: New

Bug description:
FFC has problems parsing the following form file. As I have pointed out in the code, I need to use the following:

from ufl.algorithms import expand_derivatives, strip_variables
L = strip_variables(expand_derivatives(L_temp))
a = strip_variables(expand_derivatives(a_temp))

to get it to compile via FFC. This is not needed for SFC, and while SFC takes a few seconds (without these lines), FFC takes 6m 25s)

Also, FFC doesn't like fractional exponents which is pointed out in bug #423398.

# Finite strain elasticity

# Function space
vector = VectorElement("Lagrange", "tetrahedron", 1)

# Functions
v  = TestFunction(vector)   # Test function
du = TrialFunction(vector)  # Incremental displacement
B  = Function(vector)       # Body force
u  = Function(vector)       # Displacement at previous iteration

# Kinematics
I = Identity(3)
F = I + grad(u).T
C = F.T*F
J = sqrt(det(C))
Fbar = J**(-1./3.)*F  # Does not like fractional exponents
Cbar = J**(-2./3.)*C  # Does not like fractional exponents

E = (J*C - I)/2       # Want to try Cbar here, but using J*C instead
E = variable(E)

# Material law
mu    = Constant("tetrahedron")
lmbda = Constant("tetrahedron")

psi = lmbda/2*(tr(E)**2) + mu*tr(E*E)
S = diff(psi, E)
P = F*S

# Balance of momentum in the reference configuration
L_temp = inner(P, grad(v).T)*dx - inner(B, v)*dx
a_temp = derivative(L_temp, u, du)

# FIXME: Shouldn't need to do the following
from ufl.algorithms import expand_derivatives, strip_variables
L = strip_variables(expand_derivatives(L_temp))
a = strip_variables(expand_derivatives(a_temp))

---

From: Garth Wells <[email-masked]>
Date: Wed, 09 Sep 2009 06:14:46 -0000

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

** Changed in: ffc
     Assignee: (unassigned) => oelgaard (k-b-oelgaard)

Status in FEniCS Form Compiler: Confirmed

Bug description:

# Function space

# Functions

# Kinematics
I = Identity(3)
F = I + grad(u).T
C = F.T*F
J = sqrt(det(C))

# Material law

---

From: Garth Wells <[email-masked]>
Date: Wed, 09 Sep 2009 06:21:07 -0000

Hyperelasticity is an important test problem for FFC, so I'm changing
the importance to 'High'.

** Changed in: ffc
   Importance: Undecided => High

Bug description:

# Function space

# Functions

# Kinematics
I = Identity(3)
F = I + grad(u).T
C = F.T*F
J = sqrt(det(C))

# Material law

---

From: oelgaard <[email-masked]>
Date: Thu, 10 Sep 2009 10:06:45 -0000

The problems with:

is because FFC only handled integer exponents, a fix is on the way for
this.

Bug description:

# Function space

# Functions

# Kinematics
I = Identity(3)
F = I + grad(u).T
C = F.T*F
J = sqrt(det(C))

# Material law

---

From: oelgaard <[email-masked]>
Date: Thu, 10 Sep 2009 12:04:21 -0000

I have fixed the issues with variable and exponents != IntValue, so the
above form should compile with FFC now.

I can confirm that it takes 2m46s (166s) to compile the form on my
machine and the bottlenecks are:

expand_indices, time = 114.66s
visit integrand, time =    36.59s

expand_indices is a UFL algorithm, so to make things faster we will have to generate code without calling this.
The time spent in visit integrand might be reduced if we don't call expand_indices on the integrand.

This bug should be fixed and I'm going to close it unless anyone has
objections. We can create an appropriate blueprint to take care of the
compile time issue.

Bug description:

# Function space

# Functions

# Kinematics
I = Identity(3)
F = I + grad(u).T
C = F.T*F
J = sqrt(det(C))

# Material law

---

From: logg <[email-masked]>
Date: Thu, 10 Sep 2009 12:28:49 -0000

> objections. We can create an appropriate blueprint to take care of the

We should not call expand_indices. It's something I added to fix the
lhs/rhs bug. We just need to decipher Martin's instructions to find
out what the correct fix is... :-)

--
Anders

Bug description:

# Function space

# Functions

# Kinematics
I = Identity(3)
F = I + grad(u).T
C = F.T*F
J = sqrt(det(C))

# Material law

---

From: oelgaard <[email-masked]>
Date: Thu, 10 Sep 2009 12:53:07 -0000

As I understood Martin's objection it was only concerned with calling expand_indices inside UFL because other UFL algorithms might not work very well with and expression which is expanded.
I use expand_indices just before generating the code, to get rid of the free_indices 'i' and 'j' etc. to make things easier when dealing with things like derivatives and components.

Bug description:

# Function space

# Functions

# Kinematics
I = Identity(3)
F = I + grad(u).T
C = F.T*F
J = sqrt(det(C))

# Material law

---

From: Garth Wells <[email-masked]>
Date: Thu, 10 Sep 2009 14:37:56 -0000

> objections. We can create an appropriate blueprint to take care of the

Is there an explanation why SFC only takes a few seconds?

Garth

Bug description:

# Function space

# Functions

# Kinematics
I = Identity(3)
F = I + grad(u).T
C = F.T*F
J = sqrt(det(C))

# Material law

---

From: oelgaard <[email-masked]>
Date: Thu, 10 Sep 2009 14:57:45 -0000

> Is there an explanation why SFC only takes a few seconds?

I don't think sfc (or I should say newsfc) uses expand_indices, it just operates
directly on the free indices in the expression. I think the first
implementations of sfc used expand_indices (according to grep) but Martin must
have figured out a better way to generate code without this call.
I tried to compile using sfc just to measure the difference, but I ran into
trouble with ginac/swiginac.

Kristian

> to get it to compile via FFC. This is not needed for SFC, and while SFC takes
> a few seconds (without these lines), FFC takes 6m 25s)
>
> _______________________________________________
> FFC-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/ffc-dev
>

Bug description:

# Function space

# Functions

# Kinematics
I = Identity(3)
F = I + grad(u).T
C = F.T*F
J = sqrt(det(C))

# Material law

---

From: oelgaard <[email-masked]>
Date: Fri, 11 Sep 2009 12:39:39 -0000

Quoting Harish Narayanan <[email-masked]>:

> I noticed one more thing since this fix to get it compiling with FFC.
>
> The .h file that is generated with and without this
> strip_variables(expand_derivatives()) hack is different. Furthermore, in
> my test cases, the version with the hack results in code that converges
> quadratically whereas the version without does not converge. I have
> attached the test case I am considering.
>
> ** Attachment added: "test.tbz2"
>    http://launchpadlibrarian.net/31646352/test.tbz2

Sure it converges, if I increase the maximum number of iterations in the Newton
solver... :)

First of all, variable names are not guaranteed to be the same on consecutive
runs so the output might differ if you compare using e.g., kdiff3 or meld. The
convergence problems, however, clearly indicates that something is wrong.

I use the same code to handle the Variable object in the quadrature transformer
as is used in the strip_variables function. The reason for the different
results is that expand_indices is called in quadrature transformer BEFORE
handling variables. In your hack strip_variables is called first and surely, if
I change
strip_variables(expand_derivatives())
to
strip_variables(expand_indices(expand_derivatives()))
the convergence problems appears again. So we can conclude that expand_indices
is indeed evil as Martin pointed out.

I'll disable the handling of Variables in the transformer and instead call
strip_variables before expand_indices, then your form should work without any
hacks such that we can close this bug.

I'll add a blueprint about removing the expand_indices call, which should also
speed up compilation. However, this will not be very high on my todo list.

Kristian

> You received this bug notification because you are a bug assignee.
>

Bug description:

# Function space

# Functions

# Kinematics
I = Identity(3)
F = I + grad(u).T
C = F.T*F
J = sqrt(det(C))

# Material law

---

From: oelgaard <[email-masked]>
Date: Tue, 15 Sep 2009 10:20:27 -0000

** Changed in: ffc
       Status: Confirmed => Fix Released

Status in FEniCS Form Compiler: Fix Released

Bug description:

# Function space

# Functions

# Kinematics
I = Identity(3)
F = I + grad(u).T
C = F.T*F
J = sqrt(det(C))

# Material law

---

From: logg <[email-masked]>
Date: Tue, 15 Sep 2009 14:41:58 -0000

** Changed in: ffc
       Status: Fix Released => Fix Committed

Status in FEniCS Form Compiler: Fix Committed

Bug description:

# Function space

# Functions

# Kinematics
I = Identity(3)
F = I + grad(u).T
C = F.T*F
J = sqrt(det(C))

# Material law

---

From: logg <[email-masked]>
Date: Thu, 24 Sep 2009 19:49:26 -0000

** Changed in: ffc
       Status: Fix Committed => Fix Released

Bug description:

# Function space

# Functions

# Kinematics
I = Identity(3)
F = I + grad(u).T
C = F.T*F
J = sqrt(det(C))

# Material law