On Thu, Mar 22, 2012 at 08:07:28AM -0000, Kent-Andre Mardal wrote:
> On 22 March 2012 08:37, Anders Logg <email address hidden> wrote:
>
> > On Tue, Mar 20, 2012 at 09:28:22AM -0000, Johan Hake wrote:
> > > On 03/19/2012 02:02 PM, Kristian B. Ølgaard wrote:
> > > > On 19 March 2012 09:34, Johan Hake<email address hidden>
> > > > wrote:
> > > >> 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.
> > > >
> > > > There's definitely room for optimisations w.r.t. speed and memory
> > > > consumption in FFC for hyperelastic forms and the like. Using floats
> > > > instead of Constant, in your form, FFC will produce a reasonable
> > > > result with -O -feliminate_zeros -fprecompute_basis_const, but I'd
> > > > suggest using SFC for this class of problems at the moment.
> > >
> > > Ok.
> > >
> > > > After
> > > > all, SFC was designed with hyperelasticity in mind while the
> > > > quadrature representation and optimisation was developed (and tested
> > > > on) plasticity problems. This is no excuse for not improving the
> > > > performance though, it just won't happen in near future.
> > >
> > > Sure, maybe some code could be shared between the two projects?
> >
> > That would make sense. At least when possible. There are some
> > different strategies used for generating the code.
> >
> >
>
> Unified Form Compiler?

That won't work, we already have "UFC". :-)

--
Anders


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