← Back to team overview

ffc team mailing list archive

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