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 be done, as it works pretty nice in SFC, where FFC 
chokes.

Johan

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