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 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, 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 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 /bugs.launchpad .net/ffc/ +bug/956979/ +subscriptions /bugs.launchpad .net/bugs/ 956979 /bugs.launchpad .net/ffc/ +bug/956979/ +subscriptions www.eng. cam.ac. uk/~gnw20 /bugs.launchpad .net/bugs/ 956979 /bugs.launchpad .net/ffc/ +bug/956979/ +subscriptions /bugs.launchpad .net/bugs/ 956979 /bugs.launchpad .net/ffc/ +bug/956979/ +subscriptions
>
>> >> 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:/
>> >>
>> >
>> > --
>> > You received this bug notification because you are a member of FFC Core
>> > Team, which is subscribed to FFC.
>> > https:/
>> >
>> > Title:
>> > FFC generate code which cannot be compiled
>> >
>> > To manage notifications about this bug go to:
>> > https:/
>>
>>
>> --
>> Garth N. Wells
>> Department of Engineering, University of Cambridge
>> http://
>>
>> --
>> You received this bug notification because you are a member of FFC Core
>> Team, which is subscribed to FFC.
>> https:/
>>
>> 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:/
>
> --
> You received this bug notification because you are a member of FFC Core
> Team, which is subscribed to FFC.
> https:/
>
> 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:/