ffc team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Wednesday 09 December 2009 08:13:20 Anders Logg wrote:
> 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.

Ok, I see that this is not the case for Arguments (BasisFunctions), but it is 
for Coefficients (Functions):

   f = Function(V)
   u = TestFunction(V)

   m0 = assemble(v*f*dx)

   f = Function(V)

   m1 = assemble(v*f*dx)
 
will now trigger a recompilation.

Just take a repr on the two 'f' and see.

Johan

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