ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Dec 09, 2009 at 08:04:48AM -0800, Johan Hake wrote:
> On Wednesday 09 December 2009 01:59:58 Anders Logg wrote:
> > On Tue, Dec 08, 2009 at 11:52:38PM -0800, Johan Hake wrote:
> > > On Tuesday 08 December 2009 17:09:09 Anders Logg wrote:
> > > > We're working on simplifying the FFC code (and parts of UFL). Both
> > > > have grown out of hand and with limited resources (like Martin and
> > > > Johan leaving for other ventures) we need to make the codebase easier
> > > > to maintain.
> > > >
> > > > As part of this, we've made some changes to how UFL and FFC handle the
> > > > preprocessing of forms. In particular, we've removed the caching of so
> > > > called form data in a form. Ideally, this should not lead to any
> > > > problems but there may be regressions such as slow JIT compilation as
> > > > a result of not caching certain data so keep an eye out for this.
> > >
> > > Do you know why Martin did include these in the first place?
> >
> > Yes, we discussed it quite a bit but I believe he was never happy with
> > the solution. We had things like form_data being cached in a form and
> > form_data also storing a modified version of the form so there were
> > things like
> >
> >   self.form.form_data().form
> >
> > being used in the form. I believe the new design is cleaner.
>
> Ok.
>
>   v = TestFunction
>   u = TrialFunction
>
>   M0 = assemble(u*v*dx)
>
>   v = TestFunction
>   u = TrialFunction
>
>   M1 = assemble(u*v*dx)
>
> I think that he wanted to prevent recompilation of M1, as it is basically the
> same code that is generated as for M0. But due to some internal and necessary
> they are treated differently. I think that the form_data thing was a
> workaround for that. Is this correct?

I don't think form_data has anything to do with this.

The above code should not lead to any new code generation as both M0
and M1 should have the same signatures. If not, there's a bug in
jit.py in FFC. The code for M1 should be picked up from disk cache.

--
Anders


> > > How do we retrieve the original UFL/PyDolfin objects now? I thought these
> > > were cached because otherwise they might get lost in some UFL algorithm.
> >
> > The original objects are still stored in form data:
> >
> >   form_data.original_arguments
> >   form_data.original_coefficients
>
> Ok.
>
> > > > Oh, and we also changed the name of Function to Coefficient in UFL so
> > > > .ufl files need to be updated. We also moved from BasisFunction to
> > > > Argument but this should not be visible in the user interface.
> > >
> > > Why?
> >
> > Since it agrees better with the naming elsewhere, including some
> > chapters in the FEniCS book.
> >
> > More precisely:
> >
> > 1. The first arguments in a form like v and u are the form
> > arguments. They can be test and trial functions and when we assemble
> > they are basis functions, but they are not always basis functions.
> > Hence Argument instead of BasisFunction.
> >
> > 2. The last arguments in a form like w_0, w_1, ... are the form
> > coefficients. They can be functions (as in dolfin::Function),
> > expressions or constants, but they are not always functions.
> > Hence Coefficient instead of Function.
>
> Ok.
>
> Johan

Attachment: signature.asc
Description: Digital signature