Comment 22 for bug 956979
Revision history for this message
| Johan Hake (johan-hake) wrote Re: [Bug 956979] Re: FFC generate code which cannot be compiled | #22 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0f7b58d
(Get the code!)
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/
> 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:/
>>>>>>
>>>>>
>>>>> -- 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:/
>>>
>>
>> --
>> 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:/
>