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
>>>>>>
>>>>>> 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
>>>
>>> -- 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