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