FFC

Bug #897372
Comment #18

Comment 18 for bug 897372

Revision history for this message

Anders Logg (logg) wrote on 2011-11-30: Re: [Bug 897372] [NEW] FFC is extremely slow compared to SFC for this Fung-type material law

#18

On Wed, Nov 30, 2011 at 03:12:04PM -0000, Kristian B. Ølgaard wrote:
> On 30 November 2011 15:29, Anders Logg <email address hidden> wrote:
> > On Wed, Nov 30, 2011 at 02:16:33PM -0000, Kristian B. Ølgaard wrote:
> >> On 28 November 2011 20:47, Anders E. Johansen <email address hidden> wrote:
> >> > Public bug reported:
> >> >
> >> > FFC uses a considerable amount of time (> 1h) compiling the following
> >> > program. The generated .h-file exceeds 90MB. Running, it uses hours
> >> > assembling a matrix. Using the SFC compiler, compiling is done in no
> >> > more than ten minutes, and then the program finishes in about ten
> >> > seconds.
> >> >
> >> > I have similar problems with FFC and this Fung-type material law in
> >> > other cases, eg computing the second Piola-Kirchhoff stress tensor.
> >> > Then, the SFC compiled code is about 22000 times faster than FFC.
> >> >
> >> > Anders
> >> >
> >> >
> >> > from dolfin import *
> >> >
> >> > mesh = UnitCube(2, 2, 2)
> >> > V = VectorFunctionSpace(mesh, "CG", 1)
> >> > bcl = DirichletBC(V, (0.0, 0.0, 0.0), "near(x[0], 0.0) && on_boundary")
> >> > bcr = DirichletBC(V, (0.1, 0.0, 0.0), "near(x[0], 1.0) && on_boundary")
> >> > bcs = [bcl, bcr]
> >> >
> >> > v = TestFunction(V)
> >> > u = Function(V)
> >> > du = TrialFunction(V)
> >> >
> >> > K = Constant(0.876)
> >> > C = Constant(10.0)
> >> > bff = Constant(18.48)
> >> > bxx = Constant(3.58)
> >> > bfx = Constant(2.8)
> >> >
> >> > I = Identity(3)
> >> > F = I + grad(u)
> >> >
> >> > a = Expression(("x[0]*DOLFIN_PI/8"))
> >> > R = as_matrix([[cos(a), 0, -sin(a)], [0, 1, 0], [sin(a), 0, cos(a)]])
> >> >
> >> > F = variable(R.T*F*R)
> >> > E = 0.5*(F.T*F - I)
> >> > J = det(F)
> >> >
> >> > f=0; s=1; n=2
> >> > W = (bff*E[f,f]**2
> >> > + bxx*(E[n,n]**2 + E[s,s]**2 + E[n,s]**2)
> >> > + bfx*(E[f,n]**2 + E[n,f]**2 + E[f,s]**2 + E[s,f]**2))
> >> > psi = 0.5*K*(exp(W) - 1) + C*(J*ln(J) - J + 1)
> >> >
> >> > P = diff(psi, F)
> >> > P = R*P*R.T
> >> >
> >> > L = inner(P, grad(v))*dx
> >> > a = derivative(L, u, du)
> >> > solve(L==0, u, bcs, J=a)
> >> > plot(u, mode="displacement", interactive=True)
> >> >
> >> > ** Affects: ffc
> >> > Importance: Undecided
> >> > Status: New
> >> >
> >> >
> >> > Title:
> >> > FFC is extremely slow compared to SFC for this Fung-type material law
> >> >
> >> > Status in FEniCS Form Compiler:
> >> > New
> >> >
> >> > Bug description:
> >> > FFC uses a considerable amount of time (> 1h) compiling the following
> >> > program. The generated .h-file exceeds 90MB. Running, it uses hours
> >> > assembling a matrix. Using the SFC compiler, compiling is done in no
> >> > more than ten minutes, and then the program finishes in about ten
> >> > seconds.
> >> >
> >> > I have similar problems with FFC and this Fung-type material law in
> >> > other cases, eg computing the second Piola-Kirchhoff stress tensor.
> >> > Then, the SFC compiled code is about 22000 times faster than FFC.
> >> >
> >> > Anders
> >> >
> >> >
> >> > from dolfin import *
> >> >
> >> > mesh = UnitCube(2, 2, 2)
> >> > V = VectorFunctionSpace(mesh, "CG", 1)
> >> > bcl = DirichletBC(V, (0.0, 0.0, 0.0), "near(x[0], 0.0) && on_boundary")
> >> > bcr = DirichletBC(V, (0.1, 0.0, 0.0), "near(x[0], 1.0) && on_boundary")
> >> > bcs = [bcl, bcr]
> >> >
> >> > v = TestFunction(V)
> >> > u = Function(V)
> >> > du = TrialFunction(V)
> >> >
> >> > K = Constant(0.876)
> >> > C = Constant(10.0)
> >> > bff = Constant(18.48)
> >> > bxx = Constant(3.58)
> >> > bfx = Constant(2.8)
> >> >
> >> > I = Identity(3)
> >> > F = I + grad(u)
> >> >
> >> > a = Expression(("x[0]*DOLFIN_PI/8"))
> >> > R = as_matrix([[cos(a), 0, -sin(a)], [0, 1, 0], [sin(a), 0, cos(a)]])
> >> >
> >> > F = variable(R.T*F*R)
> >> > E = 0.5*(F.T*F - I)
> >> > J = det(F)
> >> >
> >> > f=0; s=1; n=2
> >> > W = (bff*E[f,f]**2
> >> > + bxx*(E[n,n]**2 + E[s,s]**2 + E[n,s]**2)
> >> > + bfx*(E[f,n]**2 + E[n,f]**2 + E[f,s]**2 + E[s,f]**2))
> >> > psi = 0.5*K*(exp(W) - 1) + C*(J*ln(J) - J + 1)
> >> >
> >> > P = diff(psi, F)
> >> > P = R*P*R.T
> >> >
> >> > L = inner(P, grad(v))*dx
> >> > a = derivative(L, u, du)
> >> > solve(L==0, u, bcs, J=a)
> >> > plot(u, mode="displacement", interactive=True)
> >> >
> >> > To manage notifications about this bug go to:
> >> > https://bugs.launchpad.net/ffc/+bug/897372/+subscriptions
> >>
> >> I tested the above solver on my system with:
> >>
> >> parameters["form_compiler"]["cpp_optimize"] = True
> >>
> >> For SFC
> >> parameters["form_compiler"]["name"] = "sfc"
> >> The total time to reach the plot command was
> >> 1. run 4m38s
> >> 2. run 1.8s
> >> For the given problem, SFC will use 4 integration points per cell.
> >>
> >>
> >> For FFC (running instant-clean first) without adding any additional
> >> options I didn't bother to wait for the solver to complete, the
> >> solution step took too long.
> >> This is because FFC uses 97336 integration points per cell for the
> >> given problem,
> >> this is roughly a factor 24000 more than SFC and also explains why the
> >> generated code is so big.
> >>
> >> To ensure a fair comparison, adding the ffc_options dict:
> >>
> >> ffc_options = {"quadrature_degree": 2}
> >>
> >> to the solve function will result in 4 integration points being used
> >> for FFC too.
> >>
> >> The total time to reach the plot command was:
> >> 1. run 3m55s
> >> 2. run 3.2s
> >>
> >> and if FFC optimisation is switched on:
> >>
> >> ffc_options = {"quadrature_degree": 2, \
> >> "optimize": True, \
> >> "eliminate_zeros": True, \
> >> "precompute_basis_const": True}
> >>
> >> The total time to reach the plot command was:
> >> 1. run 9m37s
> >> 2. run 1.8s (identical to SFC)
> >>
> >> Can you perhaps confirm these trends? If so, I'll mark the bug as
> >> invalid.
> >
> > Should we add a warning when too many quadrature points per cell are
> > use? And a recommendation to set quadrature_degree to something
> > smaller?
> >
> > I'd say anything avove 10,000 is seriously too much... And probably a
> > warning is in order if it exceeds 100.
>
> A warning is definitely in place. Users who compile forms from
> PyDOLFIN don't see anything suspicious.
> I even forgot that this could be the culprit.
> >From the command line it is a little better, since the
> qudrature_degree and number of operations is printed, but still a
> warning is in place.
> 100 is fine by me.

ok. Can you add it or should I?

--
Anders

> >
> >
> > Title:
> > FFC is extremely slow compared to SFC for this Fung-type material law
> >
> > Status in FEniCS Form Compiler:
> > New
> >
> > Bug description:
> > FFC uses a considerable amount of time (> 1h) compiling the following
> > program. The generated .h-file exceeds 90MB. Running, it uses hours
> > assembling a matrix. Using the SFC compiler, compiling is done in no
> > more than ten minutes, and then the program finishes in about ten
> > seconds.
> >
> > I have similar problems with FFC and this Fung-type material law in
> > other cases, eg computing the second Piola-Kirchhoff stress tensor.
> > Then, the SFC compiled code is about 22000 times faster than FFC.
> >
> > Anders
> >
> >
> > from dolfin import *
> >
> > mesh = UnitCube(2, 2, 2)
> > V = VectorFunctionSpace(mesh, "CG", 1)
> > bcl = DirichletBC(V, (0.0, 0.0, 0.0), "near(x[0], 0.0) && on_boundary")
> > bcr = DirichletBC(V, (0.1, 0.0, 0.0), "near(x[0], 1.0) && on_boundary")
> > bcs = [bcl, bcr]
> >
> > v = TestFunction(V)
> > u = Function(V)
> > du = TrialFunction(V)
> >
> > K = Constant(0.876)
> > C = Constant(10.0)
> > bff = Constant(18.48)
> > bxx = Constant(3.58)
> > bfx = Constant(2.8)
> >
> > I = Identity(3)
> > F = I + grad(u)
> >
> > a = Expression(("x[0]*DOLFIN_PI/8"))
> > R = as_matrix([[cos(a), 0, -sin(a)], [0, 1, 0], [sin(a), 0, cos(a)]])
> >
> > F = variable(R.T*F*R)
> > E = 0.5*(F.T*F - I)
> > J = det(F)
> >
> > f=0; s=1; n=2
> > W = (bff*E[f,f]**2
> > + bxx*(E[n,n]**2 + E[s,s]**2 + E[n,s]**2)
> > + bfx*(E[f,n]**2 + E[n,f]**2 + E[f,s]**2 + E[s,f]**2))
> > psi = 0.5*K*(exp(W) - 1) + C*(J*ln(J) - J + 1)
> >
> > P = diff(psi, F)
> > P = R*P*R.T
> >
> > L = inner(P, grad(v))*dx
> > a = derivative(L, u, du)
> > solve(L==0, u, bcs, J=a)
> > plot(u, mode="displacement", interactive=True)
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/ffc/+bug/897372/+subscriptions
>

On Wed, Nov 30, 2011 at 03:12:04PM -0000, Kristian B. Ølgaard wrote:
> On 30 November 2011 15:29, Anders Logg <logg@simula.no> wrote:
> > On Wed, Nov 30, 2011 at 02:16:33PM -0000, Kristian B. Ølgaard wrote:
> >> On 28 November 2011 20:47, Anders E. Johansen <897372@bugs.launchpad.net> wrote:
> >> > Public bug reported:
> >> >
> >> > FFC uses a considerable amount of time (> 1h) compiling the following
> >> > program. The generated .h-file exceeds 90MB. Running, it uses hours
> >> > assembling a matrix. Using the SFC compiler, compiling is done in no
> >> > more than ten minutes, and then the program finishes in about ten
> >> > seconds.
> >> >
> >> > I have similar problems with FFC and this Fung-type material law in
> >> > other cases, eg computing the second Piola-Kirchhoff stress tensor.
> >> > Then, the SFC compiled code is about 22000 times faster than FFC.
> >> >
> >> > Anders
> >> >
> >> >
> >> > from dolfin import *
> >> >
> >> > mesh = UnitCube(2, 2, 2)
> >> > V = VectorFunctionSpace(mesh, "CG", 1)
> >> > bcl = DirichletBC(V, (0.0, 0.0, 0.0), "near(x[0], 0.0) && on_boundary")
> >> > bcr = DirichletBC(V, (0.1, 0.0, 0.0), "near(x[0], 1.0) && on_boundary")
> >> > bcs = [bcl, bcr]
> >> >
> >> > v  = TestFunction(V)
> >> > u  = Function(V)
> >> > du = TrialFunction(V)
> >> >
> >> > K   = Constant(0.876)
> >> > C   = Constant(10.0)
> >> > bff = Constant(18.48)
> >> > bxx = Constant(3.58)
> >> > bfx = Constant(2.8)
> >> >
> >> > I = Identity(3)
> >> > F = I + grad(u)
> >> >
> >> > a = Expression(("x[0]*DOLFIN_PI/8"))
> >> > R = as_matrix([[cos(a), 0, -sin(a)], [0, 1, 0], [sin(a), 0, cos(a)]])
> >> >
> >> > F = variable(R.T*F*R)
> >> > E = 0.5*(F.T*F - I)
> >> > J = det(F)
> >> >
> >> > f=0; s=1; n=2
> >> > W = (bff*E[f,f]**2
> >> >     + bxx*(E[n,n]**2 + E[s,s]**2 + E[n,s]**2)
> >> >     + bfx*(E[f,n]**2 + E[n,f]**2 + E[f,s]**2 + E[s,f]**2))
> >> > psi = 0.5*K*(exp(W) - 1) + C*(J*ln(J) - J + 1)
> >> >
> >> > P = diff(psi, F)
> >> > P = R*P*R.T
> >> >
> >> > L = inner(P, grad(v))*dx
> >> > a = derivative(L, u, du)
> >> > solve(L==0, u, bcs, J=a)
> >> > plot(u, mode="displacement", interactive=True)
> >> >
> >> > ** Affects: ffc
> >> >     Importance: Undecided
> >> >         Status: New
> >> >
> >> >
> >> > Title:
> >> >  FFC is extremely slow compared to SFC for this Fung-type material law
> >> >
> >> > Status in FEniCS Form Compiler:
> >> >  New
> >> >
> >> > Bug description:
> >> >  FFC uses a considerable amount of time (> 1h) compiling the following
> >> >  program. The generated .h-file exceeds 90MB. Running, it uses hours
> >> >  assembling a matrix. Using the SFC compiler, compiling is done in no
> >> >  more than ten minutes, and then the program finishes in about ten
> >> >  seconds.
> >> >
> >> >  I have similar problems with FFC and this Fung-type material law in
> >> >  other cases, eg computing the second Piola-Kirchhoff stress tensor.
> >> >  Then, the SFC compiled code is about 22000 times faster than FFC.
> >> >
> >> >  Anders
> >> >
> >> >
> >> >  from dolfin import *
> >> >
> >> >  mesh = UnitCube(2, 2, 2)
> >> >  V = VectorFunctionSpace(mesh, "CG", 1)
> >> >  bcl = DirichletBC(V, (0.0, 0.0, 0.0), "near(x[0], 0.0) && on_boundary")
> >> >  bcr = DirichletBC(V, (0.1, 0.0, 0.0), "near(x[0], 1.0) && on_boundary")
> >> >  bcs = [bcl, bcr]
> >> >
> >> >  v  = TestFunction(V)
> >> >  u  = Function(V)
> >> >  du = TrialFunction(V)
> >> >
> >> >  K   = Constant(0.876)
> >> >  C   = Constant(10.0)
> >> >  bff = Constant(18.48)
> >> >  bxx = Constant(3.58)
> >> >  bfx = Constant(2.8)
> >> >
> >> >  I = Identity(3)
> >> >  F = I + grad(u)
> >> >
> >> >  a = Expression(("x[0]*DOLFIN_PI/8"))
> >> >  R = as_matrix([[cos(a), 0, -sin(a)], [0, 1, 0], [sin(a), 0, cos(a)]])
> >> >
> >> >  F = variable(R.T*F*R)
> >> >  E = 0.5*(F.T*F - I)
> >> >  J = det(F)
> >> >
> >> >  f=0; s=1; n=2
> >> >  W = (bff*E[f,f]**2
> >> >       + bxx*(E[n,n]**2 + E[s,s]**2 + E[n,s]**2)
> >> >       + bfx*(E[f,n]**2 + E[n,f]**2 + E[f,s]**2 + E[s,f]**2))
> >> >  psi = 0.5*K*(exp(W) - 1) + C*(J*ln(J) - J + 1)
> >> >
> >> >  P = diff(psi, F)
> >> >  P = R*P*R.T
> >> >
> >> >  L = inner(P, grad(v))*dx
> >> >  a = derivative(L, u, du)
> >> >  solve(L==0, u, bcs, J=a)
> >> >  plot(u, mode="displacement", interactive=True)
> >> >
> >> > To manage notifications about this bug go to:
> >> > https://bugs.launchpad.net/ffc/+bug/897372/+subscriptions
> >>
> >> I tested the above solver on my system with:
> >>
> >> parameters["form_compiler"]["cpp_optimize"] = True
> >>
> >> For SFC
> >> parameters["form_compiler"]["name"] = "sfc"
> >> The total time to reach the plot command was
> >> 1. run 4m38s
> >> 2. run       1.8s
> >> For the given problem, SFC will use 4 integration points per cell.
> >>
> >>
> >> For FFC (running instant-clean first) without adding any additional
> >> options I didn't bother to wait for the solver to complete, the
> >> solution step took too long.
> >> This is because FFC uses 97336 integration points per cell for the
> >> given problem,
> >> this is roughly a factor 24000 more than SFC and also explains why the
> >> generated code is so big.
> >>
> >> To ensure a fair comparison, adding the ffc_options dict:
> >>
> >> ffc_options = {"quadrature_degree": 2}
> >>
> >> to the solve function will result in 4 integration points being used
> >> for FFC too.
> >>
> >> The total time to reach the plot command was:
> >> 1. run 3m55s
> >> 2. run       3.2s
> >>
> >> and if FFC optimisation is switched on:
> >>
> >> ffc_options = {"quadrature_degree": 2, \
> >>                "optimize": True, \
> >>                "eliminate_zeros": True, \
> >>                "precompute_basis_const": True}
> >>
> >> The total time to reach the plot command was:
> >> 1. run 9m37s
> >> 2. run       1.8s (identical to SFC)
> >>
> >> Can you perhaps confirm these trends? If so, I'll mark the bug as
> >> invalid.
> >
> > Should we add a warning when too many quadrature points per cell are
> > use? And a recommendation to set quadrature_degree to something
> > smaller?
> >
> > I'd say anything avove 10,000 is seriously too much... And probably a
> > warning is in order if it exceeds 100.
>
> A warning is definitely in place. Users who compile forms from
> PyDOLFIN don't see anything suspicious.
> I even forgot that this could be the culprit.
> >From the command line it is a little better, since the
> qudrature_degree and number of operations is printed, but  still a
> warning is in place.
> 100 is fine by me.

ok. Can you add it or should I?

--
Anders

> >
> >
> > Title:
> >  FFC is extremely slow compared to SFC for this Fung-type material law
> >
> > Status in FEniCS Form Compiler:
> >  New
> >
> > Bug description:
> >  FFC uses a considerable amount of time (> 1h) compiling the following
> >  program. The generated .h-file exceeds 90MB. Running, it uses hours
> >  assembling a matrix. Using the SFC compiler, compiling is done in no
> >  more than ten minutes, and then the program finishes in about ten
> >  seconds.
> >
> >  I have similar problems with FFC and this Fung-type material law in
> >  other cases, eg computing the second Piola-Kirchhoff stress tensor.
> >  Then, the SFC compiled code is about 22000 times faster than FFC.
> >
> >  Anders
> >
> >
> >  from dolfin import *
> >
> >  mesh = UnitCube(2, 2, 2)
> >  V = VectorFunctionSpace(mesh, "CG", 1)
> >  bcl = DirichletBC(V, (0.0, 0.0, 0.0), "near(x[0], 0.0) && on_boundary")
> >  bcr = DirichletBC(V, (0.1, 0.0, 0.0), "near(x[0], 1.0) && on_boundary")
> >  bcs = [bcl, bcr]
> >
> >  v  = TestFunction(V)
> >  u  = Function(V)
> >  du = TrialFunction(V)
> >
> >  K   = Constant(0.876)
> >  C   = Constant(10.0)
> >  bff = Constant(18.48)
> >  bxx = Constant(3.58)
> >  bfx = Constant(2.8)
> >
> >  I = Identity(3)
> >  F = I + grad(u)
> >
> >  a = Expression(("x[0]*DOLFIN_PI/8"))
> >  R = as_matrix([[cos(a), 0, -sin(a)], [0, 1, 0], [sin(a), 0, cos(a)]])
> >
> >  F = variable(R.T*F*R)
> >  E = 0.5*(F.T*F - I)
> >  J = det(F)
> >
> >  f=0; s=1; n=2
> >  W = (bff*E[f,f]**2
> >       + bxx*(E[n,n]**2 + E[s,s]**2 + E[n,s]**2)
> >       + bfx*(E[f,n]**2 + E[n,f]**2 + E[f,s]**2 + E[s,f]**2))
> >  psi = 0.5*K*(exp(W) - 1) + C*(J*ln(J) - J + 1)
> >
> >  P = diff(psi, F)
> >  P = R*P*R.T
> >
> >  L = inner(P, grad(v))*dx
> >  a = derivative(L, u, du)
> >  solve(L==0, u, bcs, J=a)
> >  plot(u, mode="displacement", interactive=True)
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/ffc/+bug/897372/+subscriptions
>