Subject: [FFC-dev] ffc compile problem

From: Patrick Riesen <[email-masked]>
Date: Tue, 24 Feb 2009 10:41:28 +0100

hi

i'm under way of implementing a powerlaw stokes with newton iteration in 
a mixed formulation (2d triangles).
compiling my forms with ffc runs into the following:

a)
using normal tensor representation the compile fails in 
monomialintegration.py when computing the terms with:

ValueError: dimensions too large.

b)
using quadrature representation the compile takes very long (>20min) and 
cpu and memory are heavy and increasing, so i aborted.

i don't understand the error from (a), what does it mean?
if (a) fails, does it necessarily mean that my forms have an error and 
(b) will fail as well, or should i try running (b) to the end?

thanks for your help

patrick

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 24 Feb 2009 11:23:55 +0100

> ValueError: dimensions too large.

For very complex forms, this is not unusual for tensor representation.

> cpu and memory are heavy and increasing, so i aborted.

What stage of the compilation process does the compiler reach?
Compile times up to 1 hour has been reported for some forms so you could try to
let it finish.
Alternatively, see if you can simplify your form somehow.
We're currently working on a transition to UFL which will hopefully speed up the
compile process although this is still at an early stage.

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

---

From: Patrick Riesen <[email-masked]>
Date: Tue, 24 Feb 2009 12:01:21 +0100

hi kristian

> Compile times up to 1 hour has been reported for some forms so you could try to

i let it run now with -d1 & quadrature and it aborts in compiler phase 2 
when computing the cell tensor. i attached the last part of the 
std:output before if stopped.

> Alternatively, see if you can simplify your form somehow.

what's a good way to do so?

can i do something like this:
if i have an operator yielding actually a constant as

def V(v):
     return dot(grad(v),grad(v))*dot(grad(v),grad(v))

can i use

vv=Constant("triangle")

for this term and implement the above term in another form file as

M=dot(grad(v),grad(v))*dot(grad(v),grad(v))*dx ?

or does it help when i define the (other) possible terms in the way of 
V(v) in the same form file so that the bilinear & linear forms are reduced?

thanks for the help,
patrick

Compiler phase 2: Computing form representation
-----------------------------------------------

  Computing cell tensor
  ---------------------

    Number of terms to consider: 2
    Number of terms to compute: 2
    Computing quadrature representation for term 0...
    Total degree is 4, using 3 quadrature point(s) in each dimension
    Primary multi index: rank = 1 dims = [15] indices = [[0], [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]]
    Secondary multi index: rank = 1 dims = [12] indices = [[0], [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]]
    Auxiliary_0 multi index: rank = 1 dims = [2] indices = [[0], [1]]
    Auxiliary_G multi index: rank = 0 dims = [] indices = [[]]
    QuadratureElement indices: []
    done
    Computing quadrature representation for term 1...
    Total degree is 6, using 4 quadrature point(s) in each dimension
    Primary multi index: rank = 1 dims = [15] indices = [[0], [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]]
Traceback (most recent call last):
  File "/home/priesen/num/fenics_py/bin/ffc", line 218, in <module>
    sys.exit(main(sys.argv[1:]))
  File "/home/priesen/num/fenics_py/bin/ffc", line 107, in main
    execfile(script, {})
  File "NonNewtonianStokes.py", line 56, in <module>
    compile([a, L, M, element], "NonNewtonianStokes", {'language': 'dolfin', 'blas': False, 'form_postfix': True, 'precision': '15', 'cpp optimize': False, 'split_implementation': False, 'quadrature_points': False, 'output_dir': '.', 'representation': 'quadrature', 'cache_dir': None, 'optimize': False})
  File "/home/priesen/num/fenics_py/lib/python2.5/site-packages/ffc/compiler/compiler.py", line 68, in compile
    (form_data, form_representation) = __compile_forms(forms, prefix, options)
  File "/home/priesen/num/fenics_py/lib/python2.5/site-packages/ffc/compiler/compiler.py", line 99, in __compile_forms
    form_representation = compute_form_representation(form_data, options)
  File "/home/priesen/num/fenics_py/lib/python2.5/site-packages/ffc/compiler/compiler.py", line 200, in compute_form_representation
    form_representation = Representation(form_data, int(options["quadrature_points"]))
  File "/home/priesen/num/fenics_py/lib/python2.5/site-packages/ffc/compiler/representation/quadrature/quadraturerepresentation.py", line 49, in __init__
    self.cell_tensor = self.__compute_cell_tensor(form)
  File "/home/priesen/num/fenics_py/lib/python2.5/site-packages/ffc/compiler/representation/quadrature/quadraturerepresentation.py", line 72, in __compute_cell_tensor
    tensors = self.__compute_tensors(monomials, factorization, Integral.CELL, None, None)
  File "/home/priesen/num/fenics_py/lib/python2.5/site-packages/ffc/compiler/representation/quadrature/quadraturerepresentation.py", line 174, in __compute_tensors
    tensors[i] = ElementTensor(m, facet0, facet1, self.num_user_specified_quad_points)
  File "/home/priesen/num/fenics_py/lib/python2.5/site-packages/ffc/compiler/representation/quadrature/elementtensor.py", line 67, in __init__
    debug("Secondary multi index: " + str(self.a), 1)
  File "/home/priesen/num/fenics_py/lib/python2.5/site-packages/ffc/compiler/representation/tensor/multiindex.py", line 48, in __repr__
    return "rank = %d dims = %s indices = %s" % (self.rank, str(self.dims), str(self.indices))
MemoryError

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 24 Feb 2009 12:13:48 +0100

> std:output before if stopped.

I see that it runs out of memory when computing the representation. Currently,
the quadrature representation at this stage is very similar to the tensor
representation, this is one of the things that will change with the new UFL
implementation so hopefully this problem will be solved in the future.

>      return dot(grad(v),grad(v))*dot(grad(v),grad(v))

If you use 'V' (and similar functions) in many places of your form I'm not
surprised that it runs out of memory. It's not an 'error' on your account it's
just due to the way things work currently which means that premultiplying terms
with derivatives of functions makes the compile time blow up or in some cases
even prevent compilation as it did in your case.

> M=dot(grad(v),grad(v))*dot(grad(v),grad(v))*dx ?

That would be an excellent idea.
 
> V(v) in the same form file so that the bilinear & linear forms are reduced?

I'm not sure I understand this.

Kristian

---

From: Patrick Riesen <[email-masked]>
Date: Tue, 24 Feb 2009 12:58:23 +0100

> even prevent compilation as it did in your case.

aha, so it is better to write out full things in the forms for a,L, that 
would mean i shouldn't use further terms à la V(v).

due to the powerlaw behavior if have dot-products which have the form as 
(here v=test,u=trial,u0=func)

dot(|grad(u0)|*|grad(u0)| * grad(u), grad(v))

where |grad(u0)| is dot(grad(u0),grad(u0))

so using

M=dot(grad(u0),grad(u0))*dot(grad(u0),grad(u0))*dx

in another form-file should may work?

patrick

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 24 Feb 2009 13:34:19 +0100

> would mean i shouldn't use further terms à la V(v).

Defining functions using

def some_function(v)

in the form file is part of what makes the language so flexible. So in some
cases it is a good idea. The problem in your case is that multiplying the terms
with derivatives of functions rapidly increases the form complexity.

> in another form-file should may work?

Yes, it should work, and the compilation and runtime performance of your code
will benefit from it. The downside of course is that the user will have to
handle the additional forms etc.

Kristian

---

From: Patrick Riesen <[email-masked]>
Date: Tue, 24 Feb 2009 13:43:29 +0100

> handle the additional forms etc.

ok, i will pursue this approach. and do the the newton solving and 
computing of the terms in the increments accordingly. let's see how far 
i get before stumbling.

thanks for your help, kristian,

regards,
patrick