ffc team mailing list archive
-
ffc team
-
Mailing list archive
-
Message #02125
Re: [HG FFC] Added option 'compiler' to FFC_OPTIONS, default is ffc. The JIT compiler uses this to determine if the standard FFC compiler or the UFL compiler should be used.
On Tue, Feb 24, 2009 at 05:28:07PM +0100, Kristian Oelgaard wrote:
> Quoting Anders Logg <logg@xxxxxxxxx>:
>
> > On Tue, Feb 24, 2009 at 03:37:31PM +0100, Kristian Oelgaard wrote:
> > > Quoting FFC <ffc@xxxxxxxxxx>:
> > >
> > > > One or more new changesets pushed to the primary ffc repository.
> > > > A short summary of the last three changesets is included below.
> > > >
> > > > changeset: 1328:83a16cff359ac9faf01d3af927e8d88a6005663e
> > > > tag: tip
> > > > user: "Kristian Oelgaard <k.b.oelgaard@xxxxxxxxxx>"
> > > > date: Tue Feb 24 15:33:18 2009 +0100
> > > > files: ffc/common/constants.py ffc/jit/jit.py ffc/jit/jitobject.py
> > > > test/verify_tensors/test.py
> > > > description:
> > > > Added option 'compiler' to FFC_OPTIONS, default is ffc. The JIT compiler
> > uses
> > > > this to determine if the standard FFC compiler or the UFL compiler should
> > be
> > > > used.
> > >
> > > I ran all tests in DOLFIN and nothing seems to be broken. I fixed this by
> > > calling jit_object.signature() (to generate jit_object.form_data) BEFORE
> > > checking cache. If this is somehow unsafe, we need to come up with a
> > different
> > > approach. I just think that it will introduce a small overhead?
> > >
> > > Kristian
> >
> > This was the problem I ran into when trying to fix the bug in jit.py
> > before release. I couldn't figure out how to solve it without doing as
> > you say, namely to generate the signature before checking the cache.
> >
> > But this should be avoided. Computing the signature may actually take
> > some time. There are two levels of cache (although I don't know the
> > details of this now that it has moved into Instant): one in-memory
> > cache and one disk cache. The in-memory cache does not require the
> > signature, it just looks at the id() of the form which is faster
> > than computing and comparing signatures.
> >
> > Why is this change needed for compilation of UFL forms?
>
> I just need to tell JIT that it should use uflcompiler.py for *.ufl forms and
> compiler.py for *.form forms.
>
> a = dot(grad(V), grad(U))*dx
> is a *.form form
>
> a = inner(grad(V), grad(U))*dx
> is a *.ufl form
>
> otherwise JIT will just use compiler.py which cannot compile the second form.
I still don't see why the signature change is needed. Isn't a simple
if-case enough to choose between the two compilers?
--
Anders
Attachment:
signature.asc
Description: Digital signature
References