dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, Mar 21, 2009 at 09:11:46PM +0100, Johan Hake wrote:
> On Friday 20 March 2009 20:29:16 Anders Logg wrote:
> > On Fri, Mar 20, 2009 at 03:39:03PM +0100, Johan Hake wrote:
> > > Hello!
> > >
> > > Soon it will be time to shift from ffc.Foo in PyDOLFIN to ufl.Foo. This
> > > should(!?) be quite straight forward to do.
> > >
> > > Then the only ffc releated code in PyDOLFIN would be the jit call in
> > > dolfin.jit.py
> > >
> > > Would it be a point to continue the migration of the whole jit
> > > compilation thing to ufc instead of beeing a part of the form compiler?
> > >
> > > The form compiler could provide a python interface that ufc.jit could
> > > use. For example:
> > >
> > >   FC.signature(ufl_form, options = None)
> > >   FC.compile_form(ufl_form, options = None)
> > >
> > > where FC is the form compiler. Based on these two functions ufc will
> > > return a form from the cache or call the FC.compile_form to produce
> > > code,compile the extension module and return the compiled form.
> > >
> > > ufc could have a configuration file naming the prefered form compiler and
> > > jit could of course also take option "form_compiler" too.
> > >
> > > Does this make sense? Are the above functions enough?
> > >
> > > If we do this PyDOLFIN is clean from dependencies to a certain form
> > > compiler.
> >
> > Sounds good to me!
> 
> Ok,
> 
> I suggest that we get the PyDOLFIN interface up and running with ufl stuff 
> when this has stabilized and when this is in place we can migrate to a 
> ufc.jit.

Sounds good. We plan to make a new release of FFC (0.6.2) as soon as
we can with experimental support for UFL forms. This will be followed
by a new release (0.9.0) with cleanups and removed support for .form.

-- 
Anders


> It's also good to here if Martin knows if there will be any problems to 
> integrate sfc with this approach.
> 
> Johan

Attachment: signature.asc
Description: Digital signature