FFC generates code which cannot be compiled

The attached PyDOLFIN script triggers the insanely large .h file.

Is it possible to do some optimization, like grouped finiteelement method to reduce the complexity of the tabulate tensor function. Because essentially it boils down to the expansion of coefficient operations, right?

One should also be able to split up that one line of 44M characters into some 1000 intermediate lines. I definitely think the compiler likes that more than one line.

This is really a duplication of bug 897372, which compared FFc and SFC, as SFC compiles the attached form just fine. The generated code is much smaller. Talking with Martin, I get the impression that FFC does not use the information UFL provides about the internal structure of the different sub expressions. I got the impression that FFC lump the whole expression into a large string. Subdividing this string is probably suboptimal compared to using the information already stored in UFL.

On 16 March 2012 15:49, Johan Hake <email address hidden> wrote:
> This is really a duplication of bug 897372, which compared FFc and SFC,
> as SFC compiles the attached form just fine. The generated code is much
> smaller. Talking with Martin, I get the impression that FFC does not use
> the information UFL provides about the internal structure of the
> different sub expressions. I got the impression that FFC lump the whole
> expression into a large string.

... for arguments to MathFunctions that is, according to earlier
comments from Kristian.

Material models for biological tissue often have rather complex
arguments to e.g. exp.

But Johan, did you try _with_ ffc optimization? I believe that may
improve the size of the generated code.

Martin

> Subdividing this string is probably
> suboptimal compared to using the information already stored in UFL.
>
> --
> You received this bug notification because you are subscribed to FFC.
> https://bugs.launchpad.net/bugs/956979
>
> Title:
>  FFC generate code which cannot be compiled
>
> Status in FEniCS Form Compiler:
>  New
>
> Bug description:
>  I have a viscoelastic biomechanics form which generate an .h file
>  which is 45M large, with a single line length of 44M characters long.
>  This wont compile with gcc. No optimization enabled at all.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions

On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs wrote:
> On 16 March 2012 15:49, Johan Hake <email address hidden> wrote:
> > This is really a duplication of bug 897372, which compared FFc and SFC,
> > as SFC compiles the attached form just fine. The generated code is much
> > smaller. Talking with Martin, I get the impression that FFC does not use
> > the information UFL provides about the internal structure of the
> > different sub expressions. I got the impression that FFC lump the whole
> > expression into a large string.
>
> ... for arguments to MathFunctions that is, according to earlier
> comments from Kristian.
>
> Material models for biological tissue often have rather complex
> arguments to e.g. exp.
>
> But Johan, did you try _with_ ffc optimization? I believe that may
> improve the size of the generated code.

I thought the issue was the number of quadrature points used by FFC
trying to integrate the expression exactly. Does it not help to reduce
the quadrature order?

--
Anders

> Martin
>
>
> > Subdividing this string is probably
> > suboptimal compared to using the information already stored in UFL.
> >
> >
> > Title:
> >  FFC generate code which cannot be compiled
> >
> > Status in FEniCS Form Compiler:
> >  New
> >
> > Bug description:
> >  I have a viscoelastic biomechanics form which generate an .h file
> >  which is 45M large, with a single line length of 44M characters long.
> >  This wont compile with gcc. No optimization enabled at all.
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
>

On 16 March 2012 15:17, Anders Logg <email address hidden> wrote:
> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs wrote:
>> On 16 March 2012 15:49, Johan Hake <email address hidden> wrote:
>> > This is really a duplication of bug 897372, which compared FFc and SFC,
>> > as SFC compiles the attached form just fine. The generated code is much
>> > smaller. Talking with Martin, I get the impression that FFC does not use
>> > the information UFL provides about the internal structure of the
>> > different sub expressions. I got the impression that FFC lump the whole
>> > expression into a large string.
>>
>> ... for arguments to MathFunctions that is, according to earlier
>> comments from Kristian.
>>
>> Material models for biological tissue often have rather complex
>> arguments to e.g. exp.
>>

Which explode when linearised.

>> But Johan, did you try _with_ ffc optimization? I believe that may
>> improve the size of the generated code.
>
> I thought the issue was the number of quadrature points used by FFC
> trying to integrate the expression exactly. Does it not help to reduce
> the quadrature order?
>

This doesn't impact on the generation time, just the runtime.

The linearisation of complicated functions (fractions, etc) can really blow up.

Garth

> --
> Anders
>
>
>> Martin
>>
>>
>> > Subdividing this string is probably
>> > suboptimal compared to using the information already stored in UFL.
>> >
>> >
>> > Title:
>> >  FFC generate code which cannot be compiled
>> >
>> > Status in FEniCS Form Compiler:
>> >  New
>> >
>> > Bug description:
>> >  I have a viscoelastic biomechanics form which generate an .h file
>> >  which is 45M large, with a single line length of 44M characters long.
>> >  This wont compile with gcc. No optimization enabled at all.
>> >
>> > To manage notifications about this bug go to:
>> > https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
>>
>
> --
> You received this bug notification because you are a member of FFC Core
> Team, which is subscribed to FFC.
> https://bugs.launchpad.net/bugs/956979
>
> Title:
>  FFC generate code which cannot be compiled
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions

--
Garth N. Wells
Department of Engineering, University of Cambridge
http://www.eng.cam.ac.uk/~gnw20

On Mar 16, 2012 4:25 PM, "Anders Logg" <email address hidden> wrote:
>
> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs wrote:
> > On 16 March 2012 15:49, Johan Hake <email address hidden> wrote:
> > > This is really a duplication of bug 897372, which compared FFc and
SFC,
> > > as SFC compiles the attached form just fine. The generated code is
much
> > > smaller. Talking with Martin, I get the impression that FFC does not
use
> > > the information UFL provides about the internal structure of the
> > > different sub expressions. I got the impression that FFC lump the
whole
> > > expression into a large string.
> >
> > ... for arguments to MathFunctions that is, according to earlier
> > comments from Kristian.
> >
> > Material models for biological tissue often have rather complex
> > arguments to e.g. exp.
> >
> > But Johan, did you try _with_ ffc optimization? I believe that may
> > improve the size of the generated code.

No, that was turned of to improve performance of FFC, which was fixed by my
previous commit. Will test with optimization on.

> I thought the issue was the number of quadrature points used by FFC
> trying to integrate the expression exactly. Does it not help to reduce
> the quadrature order?

It definitely helped but here I am using quadrature order 2.

Johan

> --
> Anders
>
>
> > Martin
> >
> >
> > > Subdividing this string is probably
> > > suboptimal compared to using the information already stored in UFL.
> > >
> > >
> > > Title:
> > > FFC generate code which cannot be compiled
> > >
> > > Status in FEniCS Form Compiler:
> > > New
> > >
> > > Bug description:
> > > I have a viscoelastic biomechanics form which generate an .h file
> > > which is 45M large, with a single line length of 44M characters long.
> > > This wont compile with gcc. No optimization enabled at all.
> > >
> > > To manage notifications about this bug go to:
> > > https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
> >
>
> --
> You received this bug notification because you are a member of FFC Core
> Team, which is subscribed to FFC.
> https://bugs.launchpad.net/bugs/956979
>
> Title:
> FFC generate code which cannot be compiled
>
> Status in FEniCS Form Compiler:
> New
>
> Bug description:
> I have a viscoelastic biomechanics form which generate an .h file
> which is 45M large, with a single line length of 44M characters long.
> This wont compile with gcc. No optimization enabled at all.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions

On Mar 16, 2012 4:35 PM, "Garth Wells" <email address hidden> wrote:
>
> On 16 March 2012 15:17, Anders Logg <email address hidden> wrote:
> > On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs wrote:
> >> On 16 March 2012 15:49, Johan Hake <email address hidden> wrote:
> >> > This is really a duplication of bug 897372, which compared FFc and
SFC,
> >> > as SFC compiles the attached form just fine. The generated code is
much
> >> > smaller. Talking with Martin, I get the impression that FFC does not
use
> >> > the information UFL provides about the internal structure of the
> >> > different sub expressions. I got the impression that FFC lump the
whole
> >> > expression into a large string.
> >>
> >> ... for arguments to MathFunctions that is, according to earlier
> >> comments from Kristian.
> >>
> >> Material models for biological tissue often have rather complex
> >> arguments to e.g. exp.
> >>
>
> Which explode when linearised.

Sure, but not that bad. SFC managed just fine. FFC optimization might help.

FYI both SFC and FFC still use heck of alot memory. This might be rooted in
the repr are which grow quite large during a compile. Not sure how to
profile memory use in python...

Johan

> >> But Johan, did you try _with_ ffc optimization? I believe that may
> >> improve the size of the generated code.
> >
> > I thought the issue was the number of quadrature points used by FFC
> > trying to integrate the expression exactly. Does it not help to reduce
> > the quadrature order?
> >
>
> This doesn't impact on the generation time, just the runtime.
>
> The linearisation of complicated functions (fractions, etc) can really
> blow up.
>
> Garth
>
> > --
> > Anders
> >
> >
> >> Martin
> >>
> >>
> >> > Subdividing this string is probably
> >> > suboptimal compared to using the information already stored in UFL.
> >> >
> >> >
> >> > Title:
> >> > FFC generate code which cannot be compiled
> >> >
> >> > Status in FEniCS Form Compiler:
> >> > New
> >> >
> >> > Bug description:
> >> > I have a viscoelastic biomechanics form which generate an .h file
> >> > which is 45M large, with a single line length of 44M characters
long.
> >> > This wont compile with gcc. No optimization enabled at all.
> >> >
> >> > To manage notifications about this bug go to:
> >> > https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
> >>
> >
> > --
> > You received this bug notification because you are a member of FFC Core
> > Team, which is subscribed to FFC.
> > https://bugs.launchpad.net/bugs/956979
> >
> > Title:
> > FFC generate code which cannot be compiled
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
>
>
> --
> Garth N. Wells
> Department of Engineering, University of Cambridge
> http://www.eng.cam.ac.uk/~gnw20
>
> --
> You received this bug notification because you are a member of FFC Core
> Team, which is subscribed to FFC.
> https://bugs.launchpad.net/bugs/956979
>
> Title:
> FFC generate code which cannot be compiled
>
> Status in FEniCS Form Compiler:
> New
>
> Bug description:
> I have a viscoelastic biomechanics form which generate an .h file
> which is 45M large,...

On 16 March 2012 15:49, Johan Hake <email address hidden> wrote:
> This is really a duplication of bug 897372, which compared FFc and SFC,
> as SFC compiles the attached form just fine. The generated code is much
> smaller. Talking with Martin, I get the impression that FFC does not use
> the information UFL provides about the internal structure of the
> different sub expressions. I got the impression that FFC lump the whole
> expression into a large string. Subdividing this string is probably
> suboptimal compared to using the information already stored in UFL.

FFC quadrature without any optimisation will simply take the UFL
representation as is and generate code accordingly.
Any of the optimisations will result in the line being split up in
multiple lines. See the FEniCS book chapter for details.
Notice that hyperelastic models are usually very heavy on memory when
using the simply_expressions option, so if it takes very long, check
the memory consumption.

> --
> You received this bug notification because you are a member of FFC Core
> Team, which is subscribed to FFC.
> https://bugs.launchpad.net/bugs/956979
>
> Title:
>  FFC generate code which cannot be compiled
>
> Status in FEniCS Form Compiler:
>  New
>
> Bug description:
>  I have a viscoelastic biomechanics form which generate an .h file
>  which is 45M large, with a single line length of 44M characters long.
>  This wont compile with gcc. No optimization enabled at all.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions

On 16 March 2012 16:48, Johan Hake <email address hidden> wrote:
> On Mar 16, 2012 4:25 PM, "Anders Logg" <email address hidden> wrote:
>>
>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs wrote:
>> > On 16 March 2012 15:49, Johan Hake <email address hidden> wrote:
>> > > This is really a duplication of bug 897372, which compared FFc and
> SFC,
>> > > as SFC compiles the attached form just fine. The generated code is
> much
>> > > smaller. Talking with Martin, I get the impression that FFC does not
> use
>> > > the information UFL provides about the internal structure of the
>> > > different sub expressions. I got the impression that FFC lump the
> whole
>> > > expression into a large string.
>> >
>> > ... for arguments to MathFunctions that is, according to earlier
>> > comments from Kristian.
>> >
>> > Material models for biological tissue often have rather complex
>> > arguments to e.g. exp.
>> >
>> > But Johan, did you try _with_ ffc optimization? I believe that may
>> > improve the size of the generated code.
>
> No, that was turned of to improve performance of FFC, which was fixed by my
> previous commit. Will test with optimization on.

The fix you added is in a function which is pre-UFL.
It was part of a set of functions that could optimise code passed as a string.
It is currently only used to compute the number of operations in
non-optimised code, kudos for the fix though.

>> I thought the issue was the number of quadrature points used by FFC
>> trying to integrate the expression exactly. Does it not help to reduce
>> the quadrature order?
>
> It definitely helped but here I am using quadrature order 2.

Switching on optimisations will reduce the size of the code, as terms
and tables will be reused.
Reducing the quadrature order from ridiculous to 2 will also help as
tables will be smaller, but to a less extent (and you already did
that).

> Johan
>
>> --
>> Anders
>>
>>
>> > Martin
>> >
>> >
>> > > Subdividing this string is probably
>> > > suboptimal compared to using the information already stored in UFL.
>> > >
>> > >
>> > > Title:
>> > >  FFC generate code which cannot be compiled
>> > >
>> > > Status in FEniCS Form Compiler:
>> > >  New
>> > >
>> > > Bug description:
>> > >  I have a viscoelastic biomechanics form which generate an .h file
>> > >  which is 45M large, with a single line length of 44M characters long.
>> > >  This wont compile with gcc. No optimization enabled at all.
>> > >
>> > > To manage notifications about this bug go to:
>> > > https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
>> >
>>
>> --
>> You received this bug notification because you are a member of FFC Core
>> Team, which is subscribed to FFC.
>> https://bugs.launchpad.net/bugs/956979
>>
>> Title:
>>  FFC generate code which cannot be compiled
>>
>> Status in FEniCS Form Compiler:
>>  New
>>
>> Bug description:
>>  I have a viscoelastic biomechanics form which generate an .h file
>>  which is 45M large, with a single line length of 44M characters long.
>>  This wont compile with gcc. No optimization enabled at all.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/ffc/+bug/956979/+subscripti...

On 16 March 2012 16:56, Johan Hake <email address hidden> wrote:
> On Mar 16, 2012 4:35 PM, "Garth Wells" <email address hidden> wrote:
>>
>> On 16 March 2012 15:17, Anders Logg <email address hidden> wrote:
>> > On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs wrote:
>> >> On 16 March 2012 15:49, Johan Hake <email address hidden> wrote:
>> >> > This is really a duplication of bug 897372, which compared FFc and
> SFC,
>> >> > as SFC compiles the attached form just fine. The generated code is
> much
>> >> > smaller. Talking with Martin, I get the impression that FFC does not
> use
>> >> > the information UFL provides about the internal structure of the
>> >> > different sub expressions. I got the impression that FFC lump the
> whole
>> >> > expression into a large string.
>> >>
>> >> ... for arguments to MathFunctions that is, according to earlier
>> >> comments from Kristian.
>> >>
>> >> Material models for biological tissue often have rather complex
>> >> arguments to e.g. exp.
>> >>
>>
>> Which explode when linearised.
>
> Sure, but not that bad. SFC managed just fine. FFC optimization might
> help.
>
> FYI both SFC and FFC still use heck of alot memory. This might be rooted in
> the repr are which grow quite large during a compile. Not sure how to
> profile memory use in python...

For speed, objects are cached in FFC (and I believe also in SFC the
last time I checked) so as the expression become more and more complex
the memory usage will increase. The simplify_expression optimisation
strategy for FFC is particular poor in this regard as it relies on
first expanding the expression before trying to optimise it which
results in a lot of temporary expressions (objects) being created.

> Johan
>
>> >> But Johan, did you try _with_ ffc optimization? I believe that may
>> >> improve the size of the generated code.
>> >
>> > I thought the issue was the number of quadrature points used by FFC
>> > trying to integrate the expression exactly. Does it not help to reduce
>> > the quadrature order?
>> >
>>
>> This doesn't impact on the generation time, just the runtime.
>>
>> The linearisation of complicated functions (fractions, etc) can really
>> blow up.
>>
>> Garth
>>
>> > --
>> > Anders
>> >
>> >
>> >> Martin
>> >>
>> >>
>> >> > Subdividing this string is probably
>> >> > suboptimal compared to using the information already stored in UFL.
>> >> >
>> >> >
>> >> > Title:
>> >> >  FFC generate code which cannot be compiled
>> >> >
>> >> > Status in FEniCS Form Compiler:
>> >> >  New
>> >> >
>> >> > Bug description:
>> >> >  I have a viscoelastic biomechanics form which generate an .h file
>> >> >  which is 45M large, with a single line length of 44M characters
> long.
>> >> >  This wont compile with gcc. No optimization enabled at all.
>> >> >
>> >> > To manage notifications about this bug go to:
>> >> > https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
>> >>
>> >
>> > --
>> > You received this bug notification because you are a member of FFC Core
>> > Team, which is subscribed to FFC.
>> > https://bugs.launchpad.net/bugs/956979
>> >
>> > Title:
>> >  FFC generate code which cannot be compiled
>> >
>> > To manage notifi...

On 03/18/2012 11:41 PM, Kristian B. Ølgaard wrote:
> On 16 March 2012 15:49, Johan Hake<email address hidden>
> wrote:
>> This is really a duplication of bug 897372, which compared FFc and
>> SFC, as SFC compiles the attached form just fine. The generated
>> code is much smaller. Talking with Martin, I get the impression
>> that FFC does not use the information UFL provides about the
>> internal structure of the different sub expressions. I got the
>> impression that FFC lump the whole expression into a large string.
>> Subdividing this string is probably suboptimal compared to using
>> the information already stored in UFL.
>
> FFC quadrature without any optimisation will simply take the UFL
> representation as is and generate code accordingly. Any of the
> optimisations will result in the line being split up in multiple
> lines. See the FEniCS book chapter for details. Notice that
> hyperelastic models are usually very heavy on memory when using the
> simply_expressions option, so if it takes very long, check the memory
> consumption.

Yes, but if I am not simplifying it it generates lines which have 40M
characters in it, which eventually wont compile.

>> -- You received this bug notification because you are a member of
>> FFC Core Team, which is subscribed to FFC.
>> https://bugs.launchpad.net/bugs/956979
>>
>> Title: FFC generate code which cannot be compiled
>>
>> Status in FEniCS Form Compiler: New
>>
>> Bug description: I have a viscoelastic biomechanics form which
>> generate an .h file which is 45M large, with a single line length
>> of 44M characters long. This wont compile with gcc. No optimization
>> enabled at all.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
>

On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
> On 16 March 2012 16:48, Johan Hake<email address hidden>
> wrote:
>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden> wrote:
>>>
>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs
>>> wrote:
>>>> On 16 March 2012 15:49, Johan Hake<email address hidden>
>>>> wrote:
>>>>> This is really a duplication of bug 897372, which compared
>>>>> FFc and
>> SFC,
>>>>> as SFC compiles the attached form just fine. The generated
>>>>> code is
>> much
>>>>> smaller. Talking with Martin, I get the impression that FFC
>>>>> does not
>> use
>>>>> the information UFL provides about the internal structure of
>>>>> the different sub expressions. I got the impression that FFC
>>>>> lump the
>> whole
>>>>> expression into a large string.
>>>>
>>>> ... for arguments to MathFunctions that is, according to
>>>> earlier comments from Kristian.
>>>>
>>>> Material models for biological tissue often have rather
>>>> complex arguments to e.g. exp.
>>>>
>>>> But Johan, did you try _with_ ffc optimization? I believe that
>>>> may improve the size of the generated code.
>>
>> No, that was turned of to improve performance of FFC, which was
>> fixed by my previous commit. Will test with optimization on.
>
> The fix you added is in a function which is pre-UFL. It was part of a
> set of functions that could optimise code passed as a string. It is
> currently only used to compute the number of operations in
> non-optimised code, kudos for the fix though.

Ok, good to know :)

It was however a show stopper for the attached form. Now FFC manage to
generate the code, at least when no optimization (simplification) is
done to the expression. But as said before the code wont compile because
of that one darn long line.

>>> I thought the issue was the number of quadrature points used by
>>> FFC trying to integrate the expression exactly. Does it not help
>>> to reduce the quadrature order?
>>
>> It definitely helped but here I am using quadrature order 2.
>
> Switching on optimisations will reduce the size of the code, as
> terms and tables will be reused. Reducing the quadrature order from
> ridiculous to 2 will also help as tables will be smaller, but to a
> less extent (and you already did that).

Yes, and I guess your optimziation algorithm works on the already
assembles string, which is very long. I think operating on such a big
string forces FFC to its knees.

SFC does not have this problem at all, as it make the simplification
(optimization) based on the UFL expression. SFC never contracts the
whole expression.

Johan

>>>> Martin
>>>>
>>>>
>>>>> Subdividing this string is probably suboptimal compared to
>>>>> using the information already stored in UFL.
>>>>>
>>>>>
>>>>> Title: FFC generate code which cannot be compiled
>>>>>
>>>>> Status in FEniCS Form Compiler: New
>>>>>
>>>>> Bug description: I have a viscoelastic biomechanics form
>>>>> which generate an .h file which is 45M large, with a single
>>>>> line length of 44M characters long. This wont compile with
>>>>> gcc. No optimization enabled at all.
>>>>>
>>>>> To manage notifications about this bug go to:
>>>>> https://bugs.launchpad....

On 03/18/2012 11:56 PM, Kristian B. Ølgaard wrote:
> On 16 March 2012 16:56, Johan Hake<email address hidden>
> wrote:
>> On Mar 16, 2012 4:35 PM, "Garth Wells"<email address hidden>
>> wrote:
>>>
>>> On 16 March 2012 15:17, Anders Logg<email address hidden> wrote:
>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs
>>>> wrote:
>>>>> On 16 March 2012 15:49, Johan Hake<email address hidden>
>>>>> wrote:
>>>>>> This is really a duplication of bug 897372, which compared
>>>>>> FFc and
>> SFC,
>>>>>> as SFC compiles the attached form just fine. The generated
>>>>>> code is
>> much
>>>>>> smaller. Talking with Martin, I get the impression that FFC
>>>>>> does not
>> use
>>>>>> the information UFL provides about the internal structure
>>>>>> of the different sub expressions. I got the impression that
>>>>>> FFC lump the
>> whole
>>>>>> expression into a large string.
>>>>>
>>>>> ... for arguments to MathFunctions that is, according to
>>>>> earlier comments from Kristian.
>>>>>
>>>>> Material models for biological tissue often have rather
>>>>> complex arguments to e.g. exp.
>>>>>
>>>
>>> Which explode when linearised.
>>
>> Sure, but not that bad. SFC managed just fine. FFC optimization
>> might help.
>>
>> FYI both SFC and FFC still use heck of alot memory. This might be
>> rooted in the repr are which grow quite large during a compile. Not
>> sure how to profile memory use in python...
>
> For speed, objects are cached in FFC (and I believe also in SFC the
> last time I checked) so as the expression become more and more
> complex the memory usage will increase. The simplify_expression
> optimisation strategy for FFC is particular poor in this regard as it
> relies on first expanding the expression before trying to optimise it
> which results in a lot of temporary expressions (objects) being
> created.

What algorithm are you talking about that stores all these temporary
objects. I have at least found out that the memory explosion happens within:

   ffc:extract_monomial_integrand

within the call to

   ufl:purge_list_tensors

Which indicates that UFL is actually the leaker her. This also makes
sense as SFC show the same huge memory usage.

Will file a speate bug to UFL for this.

Johan

>> Johan
>>
>>>>> But Johan, did you try _with_ ffc optimization? I believe
>>>>> that may improve the size of the generated code.
>>>>
>>>> I thought the issue was the number of quadrature points used by
>>>> FFC trying to integrate the expression exactly. Does it not
>>>> help to reduce the quadrature order?
>>>>
>>>
>>> This doesn't impact on the generation time, just the runtime.
>>>
>>> The linearisation of complicated functions (fractions, etc) can
>>> really blow up.
>>>
>>> Garth
>>>
>>>> -- Anders
>>>>
>>>>
>>>>> Martin
>>>>>
>>>>>
>>>>>> Subdividing this string is probably suboptimal compared to
>>>>>> using the information already stored in UFL.
>>>>>>
>>>>>>
>>>>>> Title: FFC generate code which cannot be compiled
>>>>>>
>>>>>> Status in FEniCS Form Compiler: New
>>>>>>
>>>>>> Bug description: I have a viscoelastic biomechanics form
>>>>>> which generate an .h file which is 45M large, with a single
>>>>>> line length of 44M...

On 19 March 2012 07:47, Johan Hake <email address hidden> wrote:
> On 03/18/2012 11:56 PM, Kristian B. Ølgaard wrote:
>> On 16 March 2012 16:56, Johan Hake<email address hidden>
>> wrote:
>>> On Mar 16, 2012 4:35 PM, "Garth Wells"<email address hidden>
>>> wrote:
>>>>
>>>> On 16 March 2012 15:17, Anders Logg<email address hidden>  wrote:
>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs
>>>>> wrote:
>>>>>> On 16 March 2012 15:49, Johan Hake<email address hidden>
>>>>>> wrote:
>>>>>>> This is really a duplication of bug 897372, which compared
>>>>>>> FFc and
>>> SFC,
>>>>>>> as SFC compiles the attached form just fine. The generated
>>>>>>> code is
>>> much
>>>>>>> smaller. Talking with Martin, I get the impression that FFC
>>>>>>> does not
>>> use
>>>>>>> the information UFL provides about the internal structure
>>>>>>> of the different sub expressions. I got the impression that
>>>>>>> FFC lump the
>>> whole
>>>>>>> expression into a large string.
>>>>>>
>>>>>> ... for arguments to MathFunctions that is, according to
>>>>>> earlier comments from Kristian.
>>>>>>
>>>>>> Material models for biological tissue often have rather
>>>>>> complex arguments to e.g. exp.
>>>>>>
>>>>
>>>> Which explode when linearised.
>>>
>>> Sure, but not that bad. SFC managed just fine. FFC optimization
>>> might help.
>>>
>>> FYI both SFC and FFC still use heck of alot memory. This might be
>>> rooted in the repr are which grow quite large during a compile. Not
>>> sure how to profile memory use in python...
>>
>> For speed, objects are cached in FFC (and I believe also in SFC the
>> last time I checked) so as the expression become more and more
>> complex the memory usage will increase. The simplify_expression
>> optimisation strategy for FFC is particular poor in this regard as it
>> relies on first expanding the expression before trying to optimise it
>> which results in a lot of temporary expressions (objects) being
>> created.
>
> What algorithm are you talking about that stores all these temporary
> objects. I have at least found out that the memory explosion happens within:
>
>   ffc:extract_monomial_integrand
>
> within the call to
>
>   ufl:purge_list_tensors
>
> Which indicates that UFL is actually the leaker her. This also makes
> sense as SFC show the same huge memory usage.

Not quite, because SFC never calls that function...

> Will file a speate bug to UFL for this.

Please do, I can take a look at the UFL side.

Martin

On 19 March 2012 07:35, Johan Hake <email address hidden> wrote:
> On 03/18/2012 11:41 PM, Kristian B. Ølgaard wrote:
>> On 16 March 2012 15:49, Johan Hake<email address hidden>
>> wrote:
>>> This is really a duplication of bug 897372, which compared FFc and
>>> SFC, as SFC compiles the attached form just fine. The generated
>>> code is much smaller. Talking with Martin, I get the impression
>>> that FFC does not use the information UFL provides about the
>>> internal structure of the different sub expressions. I got the
>>> impression that FFC lump the whole expression into a large string.
>>> Subdividing this string is probably suboptimal compared to using
>>> the information already stored in UFL.
>>
>> FFC quadrature without any optimisation will simply take the UFL
>> representation as is and generate code accordingly. Any of the
>> optimisations will result in the line being split up in multiple
>> lines. See the FEniCS book chapter for details. Notice that
>> hyperelastic models are usually very heavy on memory when using the
>> simply_expressions option, so if it takes very long, check the memory
>> consumption.
>
> Yes, but if I am not simplifying it it generates lines which have 40M
> characters in it, which eventually wont compile.

Yes I know. I expect the best option for your case to be:

-feliminate_zeros -fprecompute_basis_const

which will result in code similar to what SFC will produce, but with
loops over the A_ij indices (SFC unrolls the loops).
Also remember to set the quadrature_degree manually as discussed previously.

>>> -- You received this bug notification because you are a member of
>>> FFC Core Team, which is subscribed to FFC.
>>> https://bugs.launchpad.net/bugs/956979
>>>
>>> Title: FFC generate code which cannot be compiled
>>>
>>> Status in FEniCS Form Compiler: New
>>>
>>> Bug description: I have a viscoelastic biomechanics form which
>>> generate an .h file which is 45M large, with a single line length
>>> of 44M characters long. This wont compile with gcc. No optimization
>>> enabled at all.
>>>
>>> To manage notifications about this bug go to:
>>> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
>>
>
> --
> You received this bug notification because you are a member of FFC Core
> Team, which is subscribed to FFC.
> https://bugs.launchpad.net/bugs/956979
>
> Title:
>  FFC generate code which cannot be compiled
>
> Status in FEniCS Form Compiler:
>  New
>
> Bug description:
>  I have a viscoelastic biomechanics form which generate an .h file
>  which is 45M large, with a single line length of 44M characters long.
>  This wont compile with gcc. No optimization enabled at all.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions

On 03/19/2012 09:09 AM, Martin Sandve Alnæs wrote:
> On 19 March 2012 07:47, Johan Hake<email address hidden> wrote:
>> On 03/18/2012 11:56 PM, Kristian B. Ølgaard wrote:
>>> On 16 March 2012 16:56, Johan Hake<email address hidden>
>>> wrote:
>>>> On Mar 16, 2012 4:35 PM, "Garth Wells"<email address hidden>
>>>> wrote:
>>>>>
>>>>> On 16 March 2012 15:17, Anders Logg<email address hidden> wrote:
>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs
>>>>>> wrote:
>>>>>>> On 16 March 2012 15:49, Johan Hake<email address hidden>
>>>>>>> wrote:
>>>>>>>> This is really a duplication of bug 897372, which compared
>>>>>>>> FFc and
>>>> SFC,
>>>>>>>> as SFC compiles the attached form just fine. The generated
>>>>>>>> code is
>>>> much
>>>>>>>> smaller. Talking with Martin, I get the impression that FFC
>>>>>>>> does not
>>>> use
>>>>>>>> the information UFL provides about the internal structure
>>>>>>>> of the different sub expressions. I got the impression that
>>>>>>>> FFC lump the
>>>> whole
>>>>>>>> expression into a large string.
>>>>>>>
>>>>>>> ... for arguments to MathFunctions that is, according to
>>>>>>> earlier comments from Kristian.
>>>>>>>
>>>>>>> Material models for biological tissue often have rather
>>>>>>> complex arguments to e.g. exp.
>>>>>>>
>>>>>
>>>>> Which explode when linearised.
>>>>
>>>> Sure, but not that bad. SFC managed just fine. FFC optimization
>>>> might help.
>>>>
>>>> FYI both SFC and FFC still use heck of alot memory. This might be
>>>> rooted in the repr are which grow quite large during a compile. Not
>>>> sure how to profile memory use in python...
>>>
>>> For speed, objects are cached in FFC (and I believe also in SFC the
>>> last time I checked) so as the expression become more and more
>>> complex the memory usage will increase. The simplify_expression
>>> optimisation strategy for FFC is particular poor in this regard as it
>>> relies on first expanding the expression before trying to optimise it
>>> which results in a lot of temporary expressions (objects) being
>>> created.
>>
>> What algorithm are you talking about that stores all these temporary
>> objects. I have at least found out that the memory explosion happens within:
>>
>> ffc:extract_monomial_integrand
>>
>> within the call to
>>
>> ufl:purge_list_tensors
>>
>> Which indicates that UFL is actually the leaker her. This also makes
>> sense as SFC show the same huge memory usage.
>
> Not quite, because SFC never calls that function...

The culprit isn't that function but rather the one that
purge_list_tensors calls

   expand_indices

which is reported in the filed UFL bug.

Johan

>> Will file a speate bug to UFL for this.
>
> Please do, I can take a look at the UFL side.
>
> Martin
>

On 19 March 2012 07:40, Johan Hake <email address hidden> wrote:
> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
>> On 16 March 2012 16:48, Johan Hake<email address hidden>
>> wrote:
>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden>  wrote:
>>>>
>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs
>>>> wrote:
>>>>> On 16 March 2012 15:49, Johan Hake<email address hidden>
>>>>> wrote:
>>>>>> This is really a duplication of bug 897372, which compared
>>>>>> FFc and
>>> SFC,
>>>>>> as SFC compiles the attached form just fine. The generated
>>>>>> code is
>>> much
>>>>>> smaller. Talking with Martin, I get the impression that FFC
>>>>>> does not
>>> use
>>>>>> the information UFL provides about the internal structure of
>>>>>> the different sub expressions. I got the impression that FFC
>>>>>> lump the
>>> whole
>>>>>> expression into a large string.
>>>>>
>>>>> ... for arguments to MathFunctions that is, according to
>>>>> earlier comments from Kristian.
>>>>>
>>>>> Material models for biological tissue often have rather
>>>>> complex arguments to e.g. exp.
>>>>>
>>>>> But Johan, did you try _with_ ffc optimization? I believe that
>>>>> may improve the size of the generated code.
>>>
>>> No, that was turned of to improve performance of FFC, which was
>>> fixed by my previous commit. Will test with optimization on.
>>
>> The fix you added is in a function which is pre-UFL. It was part of a
>> set of functions that could optimise code passed as a string. It is
>> currently only used to compute the number of operations in
>> non-optimised code, kudos for the fix though.
>
> Ok, good to know :)
>
> It was however a show stopper for the attached form. Now FFC manage to
> generate the code, at least when no optimization (simplification) is
> done to the expression. But as said before the code wont compile because
> of that one darn long line.
>
>>>> I thought the issue was the number of quadrature points used by
>>>> FFC trying to integrate the expression exactly. Does it not help
>>>> to reduce the quadrature order?
>>>
>>> It definitely helped but here I am using quadrature order 2.
>>
>> Switching on optimisations will reduce the size of the code, as
>> terms and tables will be reused. Reducing the quadrature order from
>> ridiculous to 2 will also help as tables will be smaller, but to a
>> less extent (and you already did that).
>
> Yes, and I guess your optimziation algorithm works on the already
> assembles string, which is very long. I think operating on such a big
> string forces FFC to its knees.
>
> SFC does not have this problem at all, as it make the simplification
> (optimization) based on the UFL expression. SFC never contracts the
> whole expression.

No, FFC translates UFL to an intermediate representation of the
expression using symbols (objects defined in
ffc/quadrature/fraction.py ffc/quadrature/product.py etc.).
This expression can then be optimised in various ways.

> Johan
>
>>>>> Martin
>>>>>
>>>>>
>>>>>> Subdividing this string is probably suboptimal compared to
>>>>>> using the information already stored in UFL.
>>>>>>
>>>>>>
>>>>>> Title: FFC generate code which cannot be compiled
>...

On 19 March 2012 07:47, Johan Hake <email address hidden> wrote:
> On 03/18/2012 11:56 PM, Kristian B. Ølgaard wrote:
>> On 16 March 2012 16:56, Johan Hake<email address hidden>
>> wrote:
>>> On Mar 16, 2012 4:35 PM, "Garth Wells"<email address hidden>
>>> wrote:
>>>>
>>>> On 16 March 2012 15:17, Anders Logg<email address hidden>  wrote:
>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs
>>>>> wrote:
>>>>>> On 16 March 2012 15:49, Johan Hake<email address hidden>
>>>>>> wrote:
>>>>>>> This is really a duplication of bug 897372, which compared
>>>>>>> FFc and
>>> SFC,
>>>>>>> as SFC compiles the attached form just fine. The generated
>>>>>>> code is
>>> much
>>>>>>> smaller. Talking with Martin, I get the impression that FFC
>>>>>>> does not
>>> use
>>>>>>> the information UFL provides about the internal structure
>>>>>>> of the different sub expressions. I got the impression that
>>>>>>> FFC lump the
>>> whole
>>>>>>> expression into a large string.
>>>>>>
>>>>>> ... for arguments to MathFunctions that is, according to
>>>>>> earlier comments from Kristian.
>>>>>>
>>>>>> Material models for biological tissue often have rather
>>>>>> complex arguments to e.g. exp.
>>>>>>
>>>>
>>>> Which explode when linearised.
>>>
>>> Sure, but not that bad. SFC managed just fine. FFC optimization
>>> might help.
>>>
>>> FYI both SFC and FFC still use heck of alot memory. This might be
>>> rooted in the repr are which grow quite large during a compile. Not
>>> sure how to profile memory use in python...
>>
>> For speed, objects are cached in FFC (and I believe also in SFC the
>> last time I checked) so as the expression become more and more
>> complex the memory usage will increase. The simplify_expression
>> optimisation strategy for FFC is particular poor in this regard as it
>> relies on first expanding the expression before trying to optimise it
>> which results in a lot of temporary expressions (objects) being
>> created.
>
> What algorithm are you talking about that stores all these temporary
> objects. I have at least found out that the memory explosion happens within:

No one algorithm in particular, but calls to the function
create_product, create_sum etc. in ffc/quadrature/symbolics.py will
result in objects being cached.
The .expand() function of the expression objects calls create_* a lot,
and the .expand() function is necessary for the -fsimplify_expression
optimisation to work.

>   ffc:extract_monomial_integrand
>
> within the call to
>
>   ufl:purge_list_tensors
>
> Which indicates that UFL is actually the leaker her. This also makes
> sense as SFC show the same huge memory usage.
>
> Will file a speate bug to UFL for this.
>
> Johan
>
>>> Johan
>>>
>>>>>> But Johan, did you try _with_ ffc optimization? I believe
>>>>>> that may improve the size of the generated code.
>>>>>
>>>>> I thought the issue was the number of quadrature points used by
>>>>> FFC trying to integrate the expression exactly. Does it not
>>>>> help to reduce the quadrature order?
>>>>>
>>>>
>>>> This doesn't impact on the generation time, just the runtime.
>>>>
>>>> The linearisation of complicated functions (fractions, etc) can
>>>> really b...

On 19 March 2012 07:47, Johan Hake <email address hidden> wrote:
> On 03/18/2012 11:56 PM, Kristian B. Ølgaard wrote:
>> On 16 March 2012 16:56, Johan Hake<email address hidden>
>> wrote:
>>> On Mar 16, 2012 4:35 PM, "Garth Wells"<email address hidden>
>>> wrote:
>>>>
>>>> On 16 March 2012 15:17, Anders Logg<email address hidden>  wrote:
>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs
>>>>> wrote:
>>>>>> On 16 March 2012 15:49, Johan Hake<email address hidden>
>>>>>> wrote:
>>>>>>> This is really a duplication of bug 897372, which compared
>>>>>>> FFc and
>>> SFC,
>>>>>>> as SFC compiles the attached form just fine. The generated
>>>>>>> code is
>>> much
>>>>>>> smaller. Talking with Martin, I get the impression that FFC
>>>>>>> does not
>>> use
>>>>>>> the information UFL provides about the internal structure
>>>>>>> of the different sub expressions. I got the impression that
>>>>>>> FFC lump the
>>> whole
>>>>>>> expression into a large string.
>>>>>>
>>>>>> ... for arguments to MathFunctions that is, according to
>>>>>> earlier comments from Kristian.
>>>>>>
>>>>>> Material models for biological tissue often have rather
>>>>>> complex arguments to e.g. exp.
>>>>>>
>>>>
>>>> Which explode when linearised.
>>>
>>> Sure, but not that bad. SFC managed just fine. FFC optimization
>>> might help.
>>>
>>> FYI both SFC and FFC still use heck of alot memory. This might be
>>> rooted in the repr are which grow quite large during a compile. Not
>>> sure how to profile memory use in python...
>>
>> For speed, objects are cached in FFC (and I believe also in SFC the
>> last time I checked) so as the expression become more and more
>> complex the memory usage will increase. The simplify_expression
>> optimisation strategy for FFC is particular poor in this regard as it
>> relies on first expanding the expression before trying to optimise it
>> which results in a lot of temporary expressions (objects) being
>> created.
>
> What algorithm are you talking about that stores all these temporary
> objects. I have at least found out that the memory explosion happens within:
>
>   ffc:extract_monomial_integrand
>
> within the call to
>
>   ufl:purge_list_tensors
>
> Which indicates that UFL is actually the leaker her. This also makes
> sense as SFC show the same huge memory usage.

BTW, did you find a memory profiler for Python?

> Will file a speate bug to UFL for this.
>
> Johan
>
>>> Johan
>>>
>>>>>> But Johan, did you try _with_ ffc optimization? I believe
>>>>>> that may improve the size of the generated code.
>>>>>
>>>>> I thought the issue was the number of quadrature points used by
>>>>> FFC trying to integrate the expression exactly. Does it not
>>>>> help to reduce the quadrature order?
>>>>>
>>>>
>>>> This doesn't impact on the generation time, just the runtime.
>>>>
>>>> The linearisation of complicated functions (fractions, etc) can
>>>> really blow up.
>>>>
>>>> Garth
>>>>
>>>>> -- Anders
>>>>>
>>>>>
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>>> Subdividing this string is probably suboptimal compared to
>>>>>>> using the information already stored in UFL.
>>>>>>>
>>>>>>>
>>>>>>> Title: FFC generate code which cannot be comp...

On 03/19/2012 09:13 AM, Kristian B. Ølgaard wrote:
> On 19 March 2012 07:35, Johan Hake<email address hidden> wrote:
>> On 03/18/2012 11:41 PM, Kristian B. Ølgaard wrote:
>>> On 16 March 2012 15:49, Johan Hake<email address hidden>
>>> wrote:
>>>> This is really a duplication of bug 897372, which compared FFc and
>>>> SFC, as SFC compiles the attached form just fine. The generated
>>>> code is much smaller. Talking with Martin, I get the impression
>>>> that FFC does not use the information UFL provides about the
>>>> internal structure of the different sub expressions. I got the
>>>> impression that FFC lump the whole expression into a large string.
>>>> Subdividing this string is probably suboptimal compared to using
>>>> the information already stored in UFL.
>>>
>>> FFC quadrature without any optimisation will simply take the UFL
>>> representation as is and generate code accordingly. Any of the
>>> optimisations will result in the line being split up in multiple
>>> lines. See the FEniCS book chapter for details. Notice that
>>> hyperelastic models are usually very heavy on memory when using the
>>> simply_expressions option, so if it takes very long, check the memory
>>> consumption.
>>
>> Yes, but if I am not simplifying it it generates lines which have 40M
>> characters in it, which eventually wont compile.
>
> Yes I know. I expect the best option for your case to be:
>
> -feliminate_zeros -fprecompute_basis_const
>
> which will result in code similar to what SFC will produce, but with
> loops over the A_ij indices (SFC unrolls the loops).
> Also remember to set the quadrature_degree manually as discussed previously.

These are already set to true. The quadrature degree is also set to 2.
How have you implemented the simplification? Is that after you have
expanded the expression to a single string? I suspect Python has problem
with that as that string is pretty big. Martin mention that SFC does the
simplification before the expansion of the expression, based on the
information UFL provides.

Johan

>>>> -- You received this bug notification because you are a member of
>>>> FFC Core Team, which is subscribed to FFC.
>>>> https://bugs.launchpad.net/bugs/956979
>>>>
>>>> Title: FFC generate code which cannot be compiled
>>>>
>>>> Status in FEniCS Form Compiler: New
>>>>
>>>> Bug description: I have a viscoelastic biomechanics form which
>>>> generate an .h file which is 45M large, with a single line length
>>>> of 44M characters long. This wont compile with gcc. No optimization
>>>> enabled at all.
>>>>
>>>> To manage notifications about this bug go to:
>>>> https://bugs.launchpad.net/ffc/+bug/956979/+subscriptions
>>>
>>
>> --
>> You received this bug notification because you are a member of FFC Core
>> Team, which is subscribed to FFC.
>> https://bugs.launchpad.net/bugs/956979
>>
>> Title:
>> FFC generate code which cannot be compiled
>>
>> Status in FEniCS Form Compiler:
>> New
>>
>> Bug description:
>> I have a viscoelastic biomechanics form which generate an .h file
>> which is 45M large, with a single line length of 44M characters long.
>> This wont compile with gcc. No optimization enabled at all.
>>
>> To...

On 03/19/2012 09:20 AM, Kristian B. Ølgaard wrote:
> On 19 March 2012 07:40, Johan Hake<email address hidden> wrote:
>> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
>>> On 16 March 2012 16:48, Johan Hake<email address hidden>
>>> wrote:
>>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden> wrote:
>>>>>
>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs
>>>>> wrote:
>>>>>> On 16 March 2012 15:49, Johan Hake<email address hidden>
>>>>>> wrote:
>>>>>>> This is really a duplication of bug 897372, which compared
>>>>>>> FFc and
>>>> SFC,
>>>>>>> as SFC compiles the attached form just fine. The generated
>>>>>>> code is
>>>> much
>>>>>>> smaller. Talking with Martin, I get the impression that FFC
>>>>>>> does not
>>>> use
>>>>>>> the information UFL provides about the internal structure of
>>>>>>> the different sub expressions. I got the impression that FFC
>>>>>>> lump the
>>>> whole
>>>>>>> expression into a large string.
>>>>>>
>>>>>> ... for arguments to MathFunctions that is, according to
>>>>>> earlier comments from Kristian.
>>>>>>
>>>>>> Material models for biological tissue often have rather
>>>>>> complex arguments to e.g. exp.
>>>>>>
>>>>>> But Johan, did you try _with_ ffc optimization? I believe that
>>>>>> may improve the size of the generated code.
>>>>
>>>> No, that was turned of to improve performance of FFC, which was
>>>> fixed by my previous commit. Will test with optimization on.
>>>
>>> The fix you added is in a function which is pre-UFL. It was part of a
>>> set of functions that could optimise code passed as a string. It is
>>> currently only used to compute the number of operations in
>>> non-optimised code, kudos for the fix though.
>>
>> Ok, good to know :)
>>
>> It was however a show stopper for the attached form. Now FFC manage to
>> generate the code, at least when no optimization (simplification) is
>> done to the expression. But as said before the code wont compile because
>> of that one darn long line.
>>
>>>>> I thought the issue was the number of quadrature points used by
>>>>> FFC trying to integrate the expression exactly. Does it not help
>>>>> to reduce the quadrature order?
>>>>
>>>> It definitely helped but here I am using quadrature order 2.
>>>
>>> Switching on optimisations will reduce the size of the code, as
>>> terms and tables will be reused. Reducing the quadrature order from
>>> ridiculous to 2 will also help as tables will be smaller, but to a
>>> less extent (and you already did that).
>>
>> Yes, and I guess your optimziation algorithm works on the already
>> assembles string, which is very long. I think operating on such a big
>> string forces FFC to its knees.
>>
>> SFC does not have this problem at all, as it make the simplification
>> (optimization) based on the UFL expression. SFC never contracts the
>> whole expression.
>
> No, FFC translates UFL to an intermediate representation of the
> expression using symbols (objects defined in
> ffc/quadrature/fraction.py ffc/quadrature/product.py etc.).
> This expression can then be optimised in various ways.

Ok, I based that assumption on something Martin said. But I guess there
are optimizations to b...

On 03/19/2012 09:29 AM, Kristian B. Ølgaard wrote:
> On 19 March 2012 07:47, Johan Hake<email address hidden> wrote:
>> On 03/18/2012 11:56 PM, Kristian B. Ølgaard wrote:
>>> On 16 March 2012 16:56, Johan Hake<email address hidden>
>>> wrote:
>>>> On Mar 16, 2012 4:35 PM, "Garth Wells"<email address hidden>
>>>> wrote:
>>>>>
>>>>> On 16 March 2012 15:17, Anders Logg<email address hidden> wrote:
>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs
>>>>>> wrote:
>>>>>>> On 16 March 2012 15:49, Johan Hake<email address hidden>
>>>>>>> wrote:
>>>>>>>> This is really a duplication of bug 897372, which compared
>>>>>>>> FFc and
>>>> SFC,
>>>>>>>> as SFC compiles the attached form just fine. The generated
>>>>>>>> code is
>>>> much
>>>>>>>> smaller. Talking with Martin, I get the impression that FFC
>>>>>>>> does not
>>>> use
>>>>>>>> the information UFL provides about the internal structure
>>>>>>>> of the different sub expressions. I got the impression that
>>>>>>>> FFC lump the
>>>> whole
>>>>>>>> expression into a large string.
>>>>>>>
>>>>>>> ... for arguments to MathFunctions that is, according to
>>>>>>> earlier comments from Kristian.
>>>>>>>
>>>>>>> Material models for biological tissue often have rather
>>>>>>> complex arguments to e.g. exp.
>>>>>>>
>>>>>
>>>>> Which explode when linearised.
>>>>
>>>> Sure, but not that bad. SFC managed just fine. FFC optimization
>>>> might help.
>>>>
>>>> FYI both SFC and FFC still use heck of alot memory. This might be
>>>> rooted in the repr are which grow quite large during a compile. Not
>>>> sure how to profile memory use in python...
>>>
>>> For speed, objects are cached in FFC (and I believe also in SFC the
>>> last time I checked) so as the expression become more and more
>>> complex the memory usage will increase. The simplify_expression
>>> optimisation strategy for FFC is particular poor in this regard as it
>>> relies on first expanding the expression before trying to optimise it
>>> which results in a lot of temporary expressions (objects) being
>>> created.
>>
>> What algorithm are you talking about that stores all these temporary
>> objects. I have at least found out that the memory explosion happens within:
>>
>> ffc:extract_monomial_integrand
>>
>> within the call to
>>
>> ufl:purge_list_tensors
>>
>> Which indicates that UFL is actually the leaker her. This also makes
>> sense as SFC show the same huge memory usage.
>
> BTW, did you find a memory profiler for Python?

Plenty, but none which I have been able to use. They were mostly home
brewed libraries... :(

Johan

>
>> Will file a speate bug to UFL for this.
>>
>> Johan
>>
>>>> Johan
>>>>
>>>>>>> But Johan, did you try _with_ ffc optimization? I believe
>>>>>>> that may improve the size of the generated code.
>>>>>>
>>>>>> I thought the issue was the number of quadrature points used by
>>>>>> FFC trying to integrate the expression exactly. Does it not
>>>>>> help to reduce the quadrature order?
>>>>>>
>>>>>
>>>>> This doesn't impact on the generation time, just the runtime.
>>>>>
>>>>> The linearisation of complicated functions (fractions, etc) can
>>>>> really blow up.
>>>>>
>>>>> Garth
>>>>>...

On 19 March 2012 09:34, Johan Hake <email address hidden> wrote:
> On 03/19/2012 09:20 AM, Kristian B. Ølgaard wrote:
>> On 19 March 2012 07:40, Johan Hake<email address hidden>  wrote:
>>> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
>>>> On 16 March 2012 16:48, Johan Hake<email address hidden>
>>>> wrote:
>>>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden>    wrote:
>>>>>>
>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs
>>>>>> wrote:
>>>>>>> On 16 March 2012 15:49, Johan Hake<email address hidden>
>>>>>>> wrote:
>>>>>>>> This is really a duplication of bug 897372, which compared
>>>>>>>> FFc and
>>>>> SFC,
>>>>>>>> as SFC compiles the attached form just fine. The generated
>>>>>>>> code is
>>>>> much
>>>>>>>> smaller. Talking with Martin, I get the impression that FFC
>>>>>>>> does not
>>>>> use
>>>>>>>> the information UFL provides about the internal structure of
>>>>>>>> the different sub expressions. I got the impression that FFC
>>>>>>>> lump the
>>>>> whole
>>>>>>>> expression into a large string.
>>>>>>>
>>>>>>> ... for arguments to MathFunctions that is, according to
>>>>>>> earlier comments from Kristian.
>>>>>>>
>>>>>>> Material models for biological tissue often have rather
>>>>>>> complex arguments to e.g. exp.
>>>>>>>
>>>>>>> But Johan, did you try _with_ ffc optimization? I believe that
>>>>>>> may improve the size of the generated code.
>>>>>
>>>>> No, that was turned of to improve performance of FFC, which was
>>>>> fixed by my previous commit. Will test with optimization on.
>>>>
>>>> The fix you added is in a function which is pre-UFL. It was part of a
>>>> set of functions that could optimise code passed as a string. It is
>>>> currently only used to compute the number of operations in
>>>> non-optimised code, kudos for the fix though.
>>>
>>> Ok, good to know :)
>>>
>>> It was however a show stopper for the attached form. Now FFC manage to
>>> generate the code, at least when no optimization (simplification) is
>>> done to the expression. But as said before the code wont compile because
>>> of that one darn long line.
>>>
>>>>>> I thought the issue was the number of quadrature points used by
>>>>>> FFC trying to integrate the expression exactly. Does it not help
>>>>>> to reduce the quadrature order?
>>>>>
>>>>> It definitely helped but here I am using quadrature order 2.
>>>>
>>>> Switching on optimisations will reduce the size of the code, as
>>>> terms and tables will be reused. Reducing the quadrature order from
>>>> ridiculous to 2 will also help as tables will be smaller, but to a
>>>> less extent (and you already did that).
>>>
>>> Yes, and I guess your optimziation algorithm works on the already
>>> assembles string, which is very long. I think operating on such a big
>>> string forces FFC to its knees.
>>>
>>> SFC does not have this problem at all, as it make the simplification
>>> (optimization) based on the UFL expression. SFC never contracts the
>>> whole expression.
>>
>> No, FFC translates UFL to an intermediate representation of the
>> expression using symbols (objects defined in
>> ffc/quadrature/fraction.py ffc/quadrature/product.py etc.).
>> This ex...

On 03/19/2012 02:02 PM, Kristian B. Ølgaard wrote:
> On 19 March 2012 09:34, Johan Hake<email address hidden>
> wrote:
>> On 03/19/2012 09:20 AM, Kristian B. Ølgaard wrote:
>>> On 19 March 2012 07:40, Johan Hake<email address hidden>
>>> wrote:
>>>> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
>>>>> On 16 March 2012 16:48, Johan
>>>>> Hake<email address hidden> wrote:
>>>>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve
>>>>>>> Alnæs wrote:
>>>>>>>> On 16 March 2012 15:49, Johan
>>>>>>>> Hake<email address hidden> wrote:
>>>>>>>>> This is really a duplication of bug 897372, which
>>>>>>>>> compared FFc and
>>>>>> SFC,
>>>>>>>>> as SFC compiles the attached form just fine. The
>>>>>>>>> generated code is
>>>>>> much
>>>>>>>>> smaller. Talking with Martin, I get the impression
>>>>>>>>> that FFC does not
>>>>>> use
>>>>>>>>> the information UFL provides about the internal
>>>>>>>>> structure of the different sub expressions. I got the
>>>>>>>>> impression that FFC lump the
>>>>>> whole
>>>>>>>>> expression into a large string.
>>>>>>>>
>>>>>>>> ... for arguments to MathFunctions that is, according
>>>>>>>> to earlier comments from Kristian.
>>>>>>>>
>>>>>>>> Material models for biological tissue often have
>>>>>>>> rather complex arguments to e.g. exp.
>>>>>>>>
>>>>>>>> But Johan, did you try _with_ ffc optimization? I
>>>>>>>> believe that may improve the size of the generated
>>>>>>>> code.
>>>>>>
>>>>>> No, that was turned of to improve performance of FFC, which
>>>>>> was fixed by my previous commit. Will test with
>>>>>> optimization on.
>>>>>
>>>>> The fix you added is in a function which is pre-UFL. It was
>>>>> part of a set of functions that could optimise code passed as
>>>>> a string. It is currently only used to compute the number of
>>>>> operations in non-optimised code, kudos for the fix though.
>>>>
>>>> Ok, good to know :)
>>>>
>>>> It was however a show stopper for the attached form. Now FFC
>>>> manage to generate the code, at least when no optimization
>>>> (simplification) is done to the expression. But as said before
>>>> the code wont compile because of that one darn long line.
>>>>
>>>>>>> I thought the issue was the number of quadrature points
>>>>>>> used by FFC trying to integrate the expression exactly.
>>>>>>> Does it not help to reduce the quadrature order?
>>>>>>
>>>>>> It definitely helped but here I am using quadrature order
>>>>>> 2.
>>>>>
>>>>> Switching on optimisations will reduce the size of the code,
>>>>> as terms and tables will be reused. Reducing the quadrature
>>>>> order from ridiculous to 2 will also help as tables will be
>>>>> smaller, but to a less extent (and you already did that).
>>>>
>>>> Yes, and I guess your optimziation algorithm works on the
>>>> already assembles string, which is very long. I think operating
>>>> on such a big string forces FFC to its knees.
>>>>
>>>> SFC does not have this problem at all, as it make the
>>>> simplification (optimization) based on the UFL expression. SFC
>>>> never contracts the whole expression.
>>>
>>> No, FFC translates UFL to an in...

On Tue, Mar 20, 2012 at 09:28:22AM -0000, Johan Hake wrote:
> On 03/19/2012 02:02 PM, Kristian B. Ølgaard wrote:
> > On 19 March 2012 09:34, Johan Hake<email address hidden>
> > wrote:
> >> On 03/19/2012 09:20 AM, Kristian B. Ølgaard wrote:
> >>> On 19 March 2012 07:40, Johan Hake<email address hidden>
> >>> wrote:
> >>>> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
> >>>>> On 16 March 2012 16:48, Johan
> >>>>> Hake<email address hidden> wrote:
> >>>>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve
> >>>>>>> Alnæs wrote:
> >>>>>>>> On 16 March 2012 15:49, Johan
> >>>>>>>> Hake<email address hidden> wrote:
> >>>>>>>>> This is really a duplication of bug 897372, which
> >>>>>>>>> compared FFc and
> >>>>>> SFC,
> >>>>>>>>> as SFC compiles the attached form just fine. The
> >>>>>>>>> generated code is
> >>>>>> much
> >>>>>>>>> smaller. Talking with Martin, I get the impression
> >>>>>>>>> that FFC does not
> >>>>>> use
> >>>>>>>>> the information UFL provides about the internal
> >>>>>>>>> structure of the different sub expressions. I got the
> >>>>>>>>> impression that FFC lump the
> >>>>>> whole
> >>>>>>>>> expression into a large string.
> >>>>>>>>
> >>>>>>>> ... for arguments to MathFunctions that is, according
> >>>>>>>> to earlier comments from Kristian.
> >>>>>>>>
> >>>>>>>> Material models for biological tissue often have
> >>>>>>>> rather complex arguments to e.g. exp.
> >>>>>>>>
> >>>>>>>> But Johan, did you try _with_ ffc optimization? I
> >>>>>>>> believe that may improve the size of the generated
> >>>>>>>> code.
> >>>>>>
> >>>>>> No, that was turned of to improve performance of FFC, which
> >>>>>> was fixed by my previous commit. Will test with
> >>>>>> optimization on.
> >>>>>
> >>>>> The fix you added is in a function which is pre-UFL. It was
> >>>>> part of a set of functions that could optimise code passed as
> >>>>> a string. It is currently only used to compute the number of
> >>>>> operations in non-optimised code, kudos for the fix though.
> >>>>
> >>>> Ok, good to know :)
> >>>>
> >>>> It was however a show stopper for the attached form. Now FFC
> >>>> manage to generate the code, at least when no optimization
> >>>> (simplification) is done to the expression. But as said before
> >>>> the code wont compile because of that one darn long line.
> >>>>
> >>>>>>> I thought the issue was the number of quadrature points
> >>>>>>> used by FFC trying to integrate the expression exactly.
> >>>>>>> Does it not help to reduce the quadrature order?
> >>>>>>
> >>>>>> It definitely helped but here I am using quadrature order
> >>>>>> 2.
> >>>>>
> >>>>> Switching on optimisations will reduce the size of the code,
> >>>>> as terms and tables will be reused. Reducing the quadrature
> >>>>> order from ridiculous to 2 will also help as tables will be
> >>>>> smaller, but to a less extent (and you already did that).
> >>>>
> >>>> Yes, and I guess your optimziation algorithm works on the
> >>>> already assembles string, which is very long. I think operating
> >>>> on such a big string forces FFC to its knees.
> >>>>
> >...

On 03/22/2012 08:37 AM, Anders Logg wrote:
> On Tue, Mar 20, 2012 at 09:28:22AM -0000, Johan Hake wrote:
>> On 03/19/2012 02:02 PM, Kristian B. Ølgaard wrote:
>>> On 19 March 2012 09:34, Johan Hake<email address hidden>
>>> wrote:
>>>> On 03/19/2012 09:20 AM, Kristian B. Ølgaard wrote:
>>>>> On 19 March 2012 07:40, Johan Hake<email address hidden>
>>>>> wrote:
>>>>>> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
>>>>>>> On 16 March 2012 16:48, Johan
>>>>>>> Hake<email address hidden> wrote:
>>>>>>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve
>>>>>>>>> Alnæs wrote:
>>>>>>>>>> On 16 March 2012 15:49, Johan
>>>>>>>>>> Hake<email address hidden> wrote:
>>>>>>>>>>> This is really a duplication of bug 897372, which
>>>>>>>>>>> compared FFc and
>>>>>>>> SFC,
>>>>>>>>>>> as SFC compiles the attached form just fine. The
>>>>>>>>>>> generated code is
>>>>>>>> much
>>>>>>>>>>> smaller. Talking with Martin, I get the impression
>>>>>>>>>>> that FFC does not
>>>>>>>> use
>>>>>>>>>>> the information UFL provides about the internal
>>>>>>>>>>> structure of the different sub expressions. I got the
>>>>>>>>>>> impression that FFC lump the
>>>>>>>> whole
>>>>>>>>>>> expression into a large string.
>>>>>>>>>>
>>>>>>>>>> ... for arguments to MathFunctions that is, according
>>>>>>>>>> to earlier comments from Kristian.
>>>>>>>>>>
>>>>>>>>>> Material models for biological tissue often have
>>>>>>>>>> rather complex arguments to e.g. exp.
>>>>>>>>>>
>>>>>>>>>> But Johan, did you try _with_ ffc optimization? I
>>>>>>>>>> believe that may improve the size of the generated
>>>>>>>>>> code.
>>>>>>>>
>>>>>>>> No, that was turned of to improve performance of FFC, which
>>>>>>>> was fixed by my previous commit. Will test with
>>>>>>>> optimization on.
>>>>>>>
>>>>>>> The fix you added is in a function which is pre-UFL. It was
>>>>>>> part of a set of functions that could optimise code passed as
>>>>>>> a string. It is currently only used to compute the number of
>>>>>>> operations in non-optimised code, kudos for the fix though.
>>>>>>
>>>>>> Ok, good to know :)
>>>>>>
>>>>>> It was however a show stopper for the attached form. Now FFC
>>>>>> manage to generate the code, at least when no optimization
>>>>>> (simplification) is done to the expression. But as said before
>>>>>> the code wont compile because of that one darn long line.
>>>>>>
>>>>>>>>> I thought the issue was the number of quadrature points
>>>>>>>>> used by FFC trying to integrate the expression exactly.
>>>>>>>>> Does it not help to reduce the quadrature order?
>>>>>>>>
>>>>>>>> It definitely helped but here I am using quadrature order
>>>>>>>> 2.
>>>>>>>
>>>>>>> Switching on optimisations will reduce the size of the code,
>>>>>>> as terms and tables will be reused. Reducing the quadrature
>>>>>>> order from ridiculous to 2 will also help as tables will be
>>>>>>> smaller, but to a less extent (and you already did that).
>>>>>>
>>>>>> Yes, and I guess your optimziation algorithm works on the
>>>>>> already assembles string, which is very long. I think operating
>>>>>> on such ...

On 22 March 2012 08:37, Anders Logg <email address hidden> wrote:

> On Tue, Mar 20, 2012 at 09:28:22AM -0000, Johan Hake wrote:
> > On 03/19/2012 02:02 PM, Kristian B. Ølgaard wrote:
> > > On 19 March 2012 09:34, Johan Hake<email address hidden>
> > > wrote:
> > >> On 03/19/2012 09:20 AM, Kristian B. Ølgaard wrote:
> > >>> On 19 March 2012 07:40, Johan Hake<email address hidden>
> > >>> wrote:
> > >>>> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
> > >>>>> On 16 March 2012 16:48, Johan
> > >>>>> Hake<email address hidden> wrote:
> > >>>>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden>
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve
> > >>>>>>> Alnæs wrote:
> > >>>>>>>> On 16 March 2012 15:49, Johan
> > >>>>>>>> Hake<email address hidden> wrote:
> > >>>>>>>>> This is really a duplication of bug 897372, which
> > >>>>>>>>> compared FFc and
> > >>>>>> SFC,
> > >>>>>>>>> as SFC compiles the attached form just fine. The
> > >>>>>>>>> generated code is
> > >>>>>> much
> > >>>>>>>>> smaller. Talking with Martin, I get the impression
> > >>>>>>>>> that FFC does not
> > >>>>>> use
> > >>>>>>>>> the information UFL provides about the internal
> > >>>>>>>>> structure of the different sub expressions. I got the
> > >>>>>>>>> impression that FFC lump the
> > >>>>>> whole
> > >>>>>>>>> expression into a large string.
> > >>>>>>>>
> > >>>>>>>> ... for arguments to MathFunctions that is, according
> > >>>>>>>> to earlier comments from Kristian.
> > >>>>>>>>
> > >>>>>>>> Material models for biological tissue often have
> > >>>>>>>> rather complex arguments to e.g. exp.
> > >>>>>>>>
> > >>>>>>>> But Johan, did you try _with_ ffc optimization? I
> > >>>>>>>> believe that may improve the size of the generated
> > >>>>>>>> code.
> > >>>>>>
> > >>>>>> No, that was turned of to improve performance of FFC, which
> > >>>>>> was fixed by my previous commit. Will test with
> > >>>>>> optimization on.
> > >>>>>
> > >>>>> The fix you added is in a function which is pre-UFL. It was
> > >>>>> part of a set of functions that could optimise code passed as
> > >>>>> a string. It is currently only used to compute the number of
> > >>>>> operations in non-optimised code, kudos for the fix though.
> > >>>>
> > >>>> Ok, good to know :)
> > >>>>
> > >>>> It was however a show stopper for the attached form. Now FFC
> > >>>> manage to generate the code, at least when no optimization
> > >>>> (simplification) is done to the expression. But as said before
> > >>>> the code wont compile because of that one darn long line.
> > >>>>
> > >>>>>>> I thought the issue was the number of quadrature points
> > >>>>>>> used by FFC trying to integrate the expression exactly.
> > >>>>>>> Does it not help to reduce the quadrature order?
> > >>>>>>
> > >>>>>> It definitely helped but here I am using quadrature order
> > >>>>>> 2.
> > >>>>>
> > >>>>> Switching on optimisations will reduce the size of the code,
> > >>>>> as terms and tables will be reused. Reducing the quadrature
> > >>>>> order from ridiculous to 2 will also help as tables will be
> > >>>>> smaller, but to a less extent (and you already did that).
> > >>>...

On Thu, Mar 22, 2012 at 08:07:28AM -0000, Kent-Andre Mardal wrote:
> On 22 March 2012 08:37, Anders Logg <email address hidden> wrote:
>
> > On Tue, Mar 20, 2012 at 09:28:22AM -0000, Johan Hake wrote:
> > > On 03/19/2012 02:02 PM, Kristian B. Ølgaard wrote:
> > > > On 19 March 2012 09:34, Johan Hake<email address hidden>
> > > > wrote:
> > > >> On 03/19/2012 09:20 AM, Kristian B. Ølgaard wrote:
> > > >>> On 19 March 2012 07:40, Johan Hake<email address hidden>
> > > >>> wrote:
> > > >>>> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
> > > >>>>> On 16 March 2012 16:48, Johan
> > > >>>>> Hake<email address hidden> wrote:
> > > >>>>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden>
> > > >>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve
> > > >>>>>>> Alnæs wrote:
> > > >>>>>>>> On 16 March 2012 15:49, Johan
> > > >>>>>>>> Hake<email address hidden> wrote:
> > > >>>>>>>>> This is really a duplication of bug 897372, which
> > > >>>>>>>>> compared FFc and
> > > >>>>>> SFC,
> > > >>>>>>>>> as SFC compiles the attached form just fine. The
> > > >>>>>>>>> generated code is
> > > >>>>>> much
> > > >>>>>>>>> smaller. Talking with Martin, I get the impression
> > > >>>>>>>>> that FFC does not
> > > >>>>>> use
> > > >>>>>>>>> the information UFL provides about the internal
> > > >>>>>>>>> structure of the different sub expressions. I got the
> > > >>>>>>>>> impression that FFC lump the
> > > >>>>>> whole
> > > >>>>>>>>> expression into a large string.
> > > >>>>>>>>
> > > >>>>>>>> ... for arguments to MathFunctions that is, according
> > > >>>>>>>> to earlier comments from Kristian.
> > > >>>>>>>>
> > > >>>>>>>> Material models for biological tissue often have
> > > >>>>>>>> rather complex arguments to e.g. exp.
> > > >>>>>>>>
> > > >>>>>>>> But Johan, did you try _with_ ffc optimization? I
> > > >>>>>>>> believe that may improve the size of the generated
> > > >>>>>>>> code.
> > > >>>>>>
> > > >>>>>> No, that was turned of to improve performance of FFC, which
> > > >>>>>> was fixed by my previous commit. Will test with
> > > >>>>>> optimization on.
> > > >>>>>
> > > >>>>> The fix you added is in a function which is pre-UFL. It was
> > > >>>>> part of a set of functions that could optimise code passed as
> > > >>>>> a string. It is currently only used to compute the number of
> > > >>>>> operations in non-optimised code, kudos for the fix though.
> > > >>>>
> > > >>>> Ok, good to know :)
> > > >>>>
> > > >>>> It was however a show stopper for the attached form. Now FFC
> > > >>>> manage to generate the code, at least when no optimization
> > > >>>> (simplification) is done to the expression. But as said before
> > > >>>> the code wont compile because of that one darn long line.
> > > >>>>
> > > >>>>>>> I thought the issue was the number of quadrature points
> > > >>>>>>> used by FFC trying to integrate the expression exactly.
> > > >>>>>>> Does it not help to reduce the quadrature order?
> > > >>>>>>
> > > >>>>>> It definitely helped but here I am using quadrature order
> > > >>>>>> 2.
> > > >>>>>
> > > >>>>> Switching on optimisations will reduce the size of the code,
> > > >>>>> a...

On 22 March 2012 08:52, Johan Hake <email address hidden> wrote:
> On 03/22/2012 08:37 AM, Anders Logg wrote:
>> On Tue, Mar 20, 2012 at 09:28:22AM -0000, Johan Hake wrote:
>>> On 03/19/2012 02:02 PM, Kristian B. Ølgaard wrote:
>>>> On 19 March 2012 09:34, Johan Hake<email address hidden>
>>>> wrote:
>>>>> On 03/19/2012 09:20 AM, Kristian B. Ølgaard wrote:
>>>>>> On 19 March 2012 07:40, Johan Hake<email address hidden>
>>>>>> wrote:
>>>>>>> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
>>>>>>>> On 16 March 2012 16:48, Johan
>>>>>>>> Hake<email address hidden>  wrote:
>>>>>>>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve
>>>>>>>>>> Alnæs wrote:
>>>>>>>>>>> On 16 March 2012 15:49, Johan
>>>>>>>>>>> Hake<email address hidden>  wrote:
>>>>>>>>>>>> This is really a duplication of bug 897372, which
>>>>>>>>>>>> compared FFc and
>>>>>>>>> SFC,
>>>>>>>>>>>> as SFC compiles the attached form just fine. The
>>>>>>>>>>>> generated code is
>>>>>>>>> much
>>>>>>>>>>>> smaller. Talking with Martin, I get the impression
>>>>>>>>>>>> that FFC does not
>>>>>>>>> use
>>>>>>>>>>>> the information UFL provides about the internal
>>>>>>>>>>>> structure of the different sub expressions. I got the
>>>>>>>>>>>> impression that FFC lump the
>>>>>>>>> whole
>>>>>>>>>>>> expression into a large string.
>>>>>>>>>>>
>>>>>>>>>>> ... for arguments to MathFunctions that is, according
>>>>>>>>>>> to earlier comments from Kristian.
>>>>>>>>>>>
>>>>>>>>>>> Material models for biological tissue often have
>>>>>>>>>>> rather complex arguments to e.g. exp.
>>>>>>>>>>>
>>>>>>>>>>> But Johan, did you try _with_ ffc optimization? I
>>>>>>>>>>> believe that may improve the size of the generated
>>>>>>>>>>> code.
>>>>>>>>>
>>>>>>>>> No, that was turned of to improve performance of FFC, which
>>>>>>>>> was fixed by my previous commit. Will test with
>>>>>>>>> optimization on.
>>>>>>>>
>>>>>>>> The fix you added is in a function which is pre-UFL. It was
>>>>>>>> part of a set of functions that could optimise code passed as
>>>>>>>> a string. It is currently only used to compute the number of
>>>>>>>> operations in non-optimised code, kudos for the fix though.
>>>>>>>
>>>>>>> Ok, good to know :)
>>>>>>>
>>>>>>> It was however a show stopper for the attached form. Now FFC
>>>>>>> manage to generate the code, at least when no optimization
>>>>>>> (simplification) is done to the expression. But as said before
>>>>>>> the code wont compile because of that one darn long line.
>>>>>>>
>>>>>>>>>> I thought the issue was the number of quadrature points
>>>>>>>>>> used by FFC trying to integrate the expression exactly.
>>>>>>>>>> Does it not help to reduce the quadrature order?
>>>>>>>>>
>>>>>>>>> It definitely helped but here I am using quadrature order
>>>>>>>>> 2.
>>>>>>>>
>>>>>>>> Switching on optimisations will reduce the size of the code,
>>>>>>>> as terms and tables will be reused. Reducing the quadrature
>>>>>>>> order from ridiculous to 2 will also help as tables will be
>>>>>>>> smaller, but to a less extent (and you already did that).
>>>>>>>
>>>>>>> Y...

2012/3/22 Kristian B. Ølgaard <email address hidden>:
> On 22 March 2012 08:52, Johan Hake <email address hidden> wrote:
>> On 03/22/2012 08:37 AM, Anders Logg wrote:
>>> On Tue, Mar 20, 2012 at 09:28:22AM -0000, Johan Hake wrote:
>>>> On 03/19/2012 02:02 PM, Kristian B. Ølgaard wrote:
>>>>> On 19 March 2012 09:34, Johan Hake<email address hidden>
>>>>> wrote:
>>>>>> On 03/19/2012 09:20 AM, Kristian B. Ølgaard wrote:
>>>>>>> On 19 March 2012 07:40, Johan Hake<email address hidden>
>>>>>>> wrote:
>>>>>>>> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
>>>>>>>>> On 16 March 2012 16:48, Johan
>>>>>>>>> Hake<email address hidden>  wrote:
>>>>>>>>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve
>>>>>>>>>>> Alnæs wrote:
>>>>>>>>>>>> On 16 March 2012 15:49, Johan
>>>>>>>>>>>> Hake<email address hidden>  wrote:
>>>>>>>>>>>>> This is really a duplication of bug 897372, which
>>>>>>>>>>>>> compared FFc and
>>>>>>>>>> SFC,
>>>>>>>>>>>>> as SFC compiles the attached form just fine. The
>>>>>>>>>>>>> generated code is
>>>>>>>>>> much
>>>>>>>>>>>>> smaller. Talking with Martin, I get the impression
>>>>>>>>>>>>> that FFC does not
>>>>>>>>>> use
>>>>>>>>>>>>> the information UFL provides about the internal
>>>>>>>>>>>>> structure of the different sub expressions. I got the
>>>>>>>>>>>>> impression that FFC lump the
>>>>>>>>>> whole
>>>>>>>>>>>>> expression into a large string.
>>>>>>>>>>>>
>>>>>>>>>>>> ... for arguments to MathFunctions that is, according
>>>>>>>>>>>> to earlier comments from Kristian.
>>>>>>>>>>>>
>>>>>>>>>>>> Material models for biological tissue often have
>>>>>>>>>>>> rather complex arguments to e.g. exp.
>>>>>>>>>>>>
>>>>>>>>>>>> But Johan, did you try _with_ ffc optimization? I
>>>>>>>>>>>> believe that may improve the size of the generated
>>>>>>>>>>>> code.
>>>>>>>>>>
>>>>>>>>>> No, that was turned of to improve performance of FFC, which
>>>>>>>>>> was fixed by my previous commit. Will test with
>>>>>>>>>> optimization on.
>>>>>>>>>
>>>>>>>>> The fix you added is in a function which is pre-UFL. It was
>>>>>>>>> part of a set of functions that could optimise code passed as
>>>>>>>>> a string. It is currently only used to compute the number of
>>>>>>>>> operations in non-optimised code, kudos for the fix though.
>>>>>>>>
>>>>>>>> Ok, good to know :)
>>>>>>>>
>>>>>>>> It was however a show stopper for the attached form. Now FFC
>>>>>>>> manage to generate the code, at least when no optimization
>>>>>>>> (simplification) is done to the expression. But as said before
>>>>>>>> the code wont compile because of that one darn long line.
>>>>>>>>
>>>>>>>>>>> I thought the issue was the number of quadrature points
>>>>>>>>>>> used by FFC trying to integrate the expression exactly.
>>>>>>>>>>> Does it not help to reduce the quadrature order?
>>>>>>>>>>
>>>>>>>>>> It definitely helped but here I am using quadrature order
>>>>>>>>>> 2.
>>>>>>>>>
>>>>>>>>> Switching on optimisations will reduce the size of the code,
>>>>>>>>> as terms and tables will be reused. Reducing the quadrature
>>>>>>>>> order from rid...

On 03/22/2012 11:23 AM, Kristian B. Ølgaard wrote:
> On 22 March 2012 08:52, Johan Hake<email address hidden> wrote:
>> On 03/22/2012 08:37 AM, Anders Logg wrote:
>>> On Tue, Mar 20, 2012 at 09:28:22AM -0000, Johan Hake wrote:
>>>> On 03/19/2012 02:02 PM, Kristian B. Ølgaard wrote:
>>>>> On 19 March 2012 09:34, Johan Hake<email address hidden>
>>>>> wrote:
>>>>>> On 03/19/2012 09:20 AM, Kristian B. Ølgaard wrote:
>>>>>>> On 19 March 2012 07:40, Johan Hake<email address hidden>
>>>>>>> wrote:
>>>>>>>> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
>>>>>>>>> On 16 March 2012 16:48, Johan
>>>>>>>>> Hake<email address hidden> wrote:
>>>>>>>>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve
>>>>>>>>>>> Alnæs wrote:
>>>>>>>>>>>> On 16 March 2012 15:49, Johan
>>>>>>>>>>>> Hake<email address hidden> wrote:
>>>>>>>>>>>>> This is really a duplication of bug 897372, which
>>>>>>>>>>>>> compared FFc and
>>>>>>>>>> SFC,
>>>>>>>>>>>>> as SFC compiles the attached form just fine. The
>>>>>>>>>>>>> generated code is
>>>>>>>>>> much
>>>>>>>>>>>>> smaller. Talking with Martin, I get the impression
>>>>>>>>>>>>> that FFC does not
>>>>>>>>>> use
>>>>>>>>>>>>> the information UFL provides about the internal
>>>>>>>>>>>>> structure of the different sub expressions. I got the
>>>>>>>>>>>>> impression that FFC lump the
>>>>>>>>>> whole
>>>>>>>>>>>>> expression into a large string.
>>>>>>>>>>>>
>>>>>>>>>>>> ... for arguments to MathFunctions that is, according
>>>>>>>>>>>> to earlier comments from Kristian.
>>>>>>>>>>>>
>>>>>>>>>>>> Material models for biological tissue often have
>>>>>>>>>>>> rather complex arguments to e.g. exp.
>>>>>>>>>>>>
>>>>>>>>>>>> But Johan, did you try _with_ ffc optimization? I
>>>>>>>>>>>> believe that may improve the size of the generated
>>>>>>>>>>>> code.
>>>>>>>>>>
>>>>>>>>>> No, that was turned of to improve performance of FFC, which
>>>>>>>>>> was fixed by my previous commit. Will test with
>>>>>>>>>> optimization on.
>>>>>>>>>
>>>>>>>>> The fix you added is in a function which is pre-UFL. It was
>>>>>>>>> part of a set of functions that could optimise code passed as
>>>>>>>>> a string. It is currently only used to compute the number of
>>>>>>>>> operations in non-optimised code, kudos for the fix though.
>>>>>>>>
>>>>>>>> Ok, good to know :)
>>>>>>>>
>>>>>>>> It was however a show stopper for the attached form. Now FFC
>>>>>>>> manage to generate the code, at least when no optimization
>>>>>>>> (simplification) is done to the expression. But as said before
>>>>>>>> the code wont compile because of that one darn long line.
>>>>>>>>
>>>>>>>>>>> I thought the issue was the number of quadrature points
>>>>>>>>>>> used by FFC trying to integrate the expression exactly.
>>>>>>>>>>> Does it not help to reduce the quadrature order?
>>>>>>>>>>
>>>>>>>>>> It definitely helped but here I am using quadrature order
>>>>>>>>>> 2.
>>>>>>>>>
>>>>>>>>> Switching on optimisations will reduce the size of the code,
>>>>>>>>> as terms and tables will be reused. Reducing the quadrature
>>>>>>>>> order from ridicul...

On Thu, Mar 22, 2012 at 10:23:40AM -0000, Kristian B. Ølgaard wrote:
> On 22 March 2012 08:52, Johan Hake <email address hidden> wrote:
> > On 03/22/2012 08:37 AM, Anders Logg wrote:
> >> On Tue, Mar 20, 2012 at 09:28:22AM -0000, Johan Hake wrote:
> >>> On 03/19/2012 02:02 PM, Kristian B. Ølgaard wrote:
> >>>> On 19 March 2012 09:34, Johan Hake<email address hidden>
> >>>> wrote:
> >>>>> On 03/19/2012 09:20 AM, Kristian B. Ølgaard wrote:
> >>>>>> On 19 March 2012 07:40, Johan Hake<email address hidden>
> >>>>>> wrote:
> >>>>>>> On 03/18/2012 11:51 PM, Kristian B. Ølgaard wrote:
> >>>>>>>> On 16 March 2012 16:48, Johan
> >>>>>>>> Hake<email address hidden>  wrote:
> >>>>>>>>> On Mar 16, 2012 4:25 PM, "Anders Logg"<email address hidden>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve
> >>>>>>>>>> Alnæs wrote:
> >>>>>>>>>>> On 16 March 2012 15:49, Johan
> >>>>>>>>>>> Hake<email address hidden>  wrote:
> >>>>>>>>>>>> This is really a duplication of bug 897372, which
> >>>>>>>>>>>> compared FFc and
> >>>>>>>>> SFC,
> >>>>>>>>>>>> as SFC compiles the attached form just fine. The
> >>>>>>>>>>>> generated code is
> >>>>>>>>> much
> >>>>>>>>>>>> smaller. Talking with Martin, I get the impression
> >>>>>>>>>>>> that FFC does not
> >>>>>>>>> use
> >>>>>>>>>>>> the information UFL provides about the internal
> >>>>>>>>>>>> structure of the different sub expressions. I got the
> >>>>>>>>>>>> impression that FFC lump the
> >>>>>>>>> whole
> >>>>>>>>>>>> expression into a large string.
> >>>>>>>>>>>
> >>>>>>>>>>> ... for arguments to MathFunctions that is, according
> >>>>>>>>>>> to earlier comments from Kristian.
> >>>>>>>>>>>
> >>>>>>>>>>> Material models for biological tissue often have
> >>>>>>>>>>> rather complex arguments to e.g. exp.
> >>>>>>>>>>>
> >>>>>>>>>>> But Johan, did you try _with_ ffc optimization? I
> >>>>>>>>>>> believe that may improve the size of the generated
> >>>>>>>>>>> code.
> >>>>>>>>>
> >>>>>>>>> No, that was turned of to improve performance of FFC, which
> >>>>>>>>> was fixed by my previous commit. Will test with
> >>>>>>>>> optimization on.
> >>>>>>>>
> >>>>>>>> The fix you added is in a function which is pre-UFL. It was
> >>>>>>>> part of a set of functions that could optimise code passed as
> >>>>>>>> a string. It is currently only used to compute the number of
> >>>>>>>> operations in non-optimised code, kudos for the fix though.
> >>>>>>>
> >>>>>>> Ok, good to know :)
> >>>>>>>
> >>>>>>> It was however a show stopper for the attached form. Now FFC
> >>>>>>> manage to generate the code, at least when no optimization
> >>>>>>> (simplification) is done to the expression. But as said before
> >>>>>>> the code wont compile because of that one darn long line.
> >>>>>>>
> >>>>>>>>>> I thought the issue was the number of quadrature points
> >>>>>>>>>> used by FFC trying to integrate the expression exactly.
> >>>>>>>>>> Does it not help to reduce the quadrature order?
> >>>>>>>>>
> >>>>>>>>> It definitely helped but here I am using quadrature order
> >>>>>>>>> 2.
> >>>>>>>>
> >>>>>>>> Switching on optimisations will reduce the size of the code,
> >>>>>>>> as ter...