On Mon, Feb 08, 2010 at 12:33:46PM -0000, Kristian B. Ølgaard wrote:
>
> On 8 February 2010 13:10, Anders Logg <email address hidden> wrote:
> > On Mon, Feb 08, 2010 at 11:20:33AM -0000, Kristian B. Ølgaard wrote:
> >>
> >> On 7 February 2010 20:38, Anders Logg <email address hidden> wrote:
> >> > On Sun, Feb 07, 2010 at 01:03:53PM -0000, Garth Wells wrote:
> >> >> ** Changed in: ffc
> >> >>     Milestone: 0.7.1 => 0.9.1
> >> >
> >> > Would it be possible to move the quadrature optimizations to stage 3?
> >> > Or are they an integral part of the code generation in stage 4?
> >>
> >> The current optimisations take place after the code has been generated.
> >> So it is not possible to move it, but maybe some other optimisations can
> >> be implemented although I don't see how this should work right now.
> >>
> >> Kristian
> >
> > ok. I thought you operated on some abstract code or intermediate
> > representation. Isn't it very costly to operate on the generated code?
> > Then you have to parse it (?) to know what it means.
>
> Parts of the optimisation like reducing the range of the loops by eliminating zeros in the basis values is done when tabulating the values, this can be done on the intermediate representation (stage 3) but I don't see any real gain in code readability or performance in doing this.
> The other optimisations work on the generated expression which is necessary to identify all terms that can be optimised, it is rather costly both in memory and time, which is why I'll be looking into another approach.

ok, I just imagine it would be more efficient to manipulate/optimize
the expression if it were stored as some kind of symbolic AST instead
of as a string. Then it would fit naturally into stage 3.

> > It's not very high priority to do this right now. But just have a look
> > at the comment in quadratureoptimization.py.
>
> Done.

Looks good.

--
Anders


> Kristian
>
> > I'll close this bug now.
> >
> >
> >
> >> >
> >> >
> >> > Status in FEniCS Form Compiler: Confirmed
> >> >
> >> > Bug description:
> >> > When compiling a form one will always get the output:
> >> >
> >> > Compiler stage 3: Optimizing form representation
> >> > ------------------------------------------------
> >> >  Optimization of tensor contraction representation currently broken (to be fixed).
> >> >
> >> > even if the quadrature representation is being used, which is the default.
> >> >
> >> > This output should only become active if:
> >> > ffc -O -r tensor foo.ufl
> >> > was invoked on the command line.
> >> >
> >> > In all other cases there should only be 4 stages.
> >> >
> >> >
> >> >
> >>
> >
> >
> > Status in FEniCS Form Compiler: Fix Committed
> >
> > Bug description:
> > When compiling a form one will always get the output:
> >
> > Compiler stage 3: Optimizing form representation
> > ------------------------------------------------
> >  Optimization of tensor contraction representation currently broken (to be fixed).
> >
> > even if the quadrature representation is being used, which is the default.
> >
> > This output should only become active if:
> > ffc -O -r tensor foo.ufl
> > was invoked on the command line.
> >
> > In all other cases there should only be 4 stages.
> >
> >
> >
>