On Wed, Dec 09, 2009 at 08:25:24AM -0800, Johan Hake wrote: > 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.
Should be fixed now. I've added a call to preprocess before computing the form signature. Does it work now? -- Anders
signature.asc
Description: Digital signature
_______________________________________________ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
