ufl team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Wednesday 01 April 2009 09:10:40 Martin Sandve Alnæs wrote:
> 2009/3/31 Johan Hake <hake@xxxxxxxxx>:
> > On Tuesday 31 March 2009 23:06:15 Anders Logg wrote:
> >> On Tue, Mar 31, 2009 at 10:09:26PM +0200, Johan Hake wrote:
> >> > On Tuesday 31 March 2009 21:24:21 Martin Sandve Alnæs wrote:
> >> > > 2009/3/31 Anders Logg <logg@xxxxxxxxx>:
> >> > > > On Tue, Mar 31, 2009 at 08:39:42PM +0200, Johan Hake wrote:
> >> > > >> On Tuesday 31 March 2009 17:13:13 Martin Sandve Alnæs wrote:
> >> > > >> > On Tue, Mar 31, 2009 at 3:55 PM, Anders Logg <logg@xxxxxxxxx>
> >
> > wrote:
> >> > > >> > > On Tue, Mar 31, 2009 at 01:06:36PM +0200, Martin Sandve Alnæs
> >
> > wrote:
> >> > > >> > >> On Mon, Mar 30, 2009 at 7:48 PM,  <logg@xxxxxxxxx> wrote:
> >> > > >> > >> >> I'm ok with the "forms / (a,L,M)" feature, and that
> >> > > >> > >> >> pretty much solves the interpretation problem for (u,v)
> >> > > >> > >> >> in that context. We should also have an optional list
> >> > > >> > >> >> "elements" like "forms". I like
> >> > > >> > >> >>   forms = [a, L]
> >> > > >> > >> >> better, quotes are unnecessary.
> >> > > >> > >> >
> >> > > >> > >> > ok!
> >> > > >> > >> >
> >> > > >> > >> >> In the context of PyDOLFIN, PyDOLFIN can itself check for
> >> > > >> > >> >> tuple or Form, so we don't need to check it everywhere.
> >> > > >> > >> >
> >> > > >> > >> > I don't think DOLFIN should need to check for this.
> >> > > >> > >> > Wouldn't it be better to let the form compiler handle it?
> >> > > >> > >> >
> >> > > >> > >> > Which interfaces does SFC have? FFC has two interfaces:
> >> > > >> > >> >
> >> > > >> > >> > 1. The compile() command in FFC (takes a single object or
> >> > > >> > >> > list of objects)
> >> > > >> > >>
> >> > > >> > >> compile is a builtin function in Python, so this should be
> >> > > >> > >> renamed.
> >> > > >> > >
> >> > > >> > > Good point. I've been told this before (by Rob). Do you have
> >> > > >> > > a good suggestion for a better name?
> >> > > >> >
> >> > > >> > I have
> >> > > >> > def generate_code(input, options=None):
> >> > > >> > def jit(input, options=None):
> >> > > >>
> >> > > >> Will this be different if we let ufc take care of the jit
> >> > > >> compilation?
> >> > > >>
> >> > > >> I think,
> >> > > >>
> >> > > >>   def generate_code(input, options=None):
> >> > > >
> >> > > > I think it should be made more explicit:
> >> > > >
> >> > > >  def compile_form(form, options=None)
> >> > > >  def compile_forms(forms, options=None)
> >> > > >  def compile_element(element, options=None)
> >> > > >  def compile_elements(elements, options=None)
> >> > >
> >> > > Why? It's convenient to share code between these.
> >> >
> >> > Agree.
> >>
> >> Yes, but that's an implementation issue. It's perfeclty fine to
> >> implement compile form by
> >>
> >>   return compile_forms([form], options)
> >>
> >> or even
> >>
> >>   return _compile_objects([form], options)
> >>
> >> Having separate functions simplifies error checking on input.
> >
> > You meen that ufc provides a jit function. This function check what is
> > provided and call the proper function, you mentioned above, which is
> > provided by the formcompiler?
> >
> > Couldn't we just send the ufl input to generate_code(). Then we compile
> > the extension module and based on the ufl input we try to instantiate the
> > form(s) or finite element(s) and dofmap(s) and return these to the user.
> > Based on the input we type check the instantiated objects and that is
> > enough?
> >
> >> > > >>   def signature(input, options=None):
> >> > > >>
> >> > > >> make sense then.
> >> > > >
> >> > > > This looks like a function that just computes a signature.
> >> > >
> >> > > Because that's what it is? SFC has a similar function. I suggest
> >> > > compute_signature.
> >> >
> >> > Sounds good.
> >>
> >> Aren't we talking about the call to the JIT compiler? What is
> >> signature supposed to do?
> >
> > The jit function will be implemented in ufc. ufc needs to be able to
> > compute a signature to check whether the form(s) or element(s) allready
> > are compiled. This, as I have argued above but still not sure is right,
> > is formcompiler specific.
>
> I'm not sure why we need to move jit to ufc. Why is that?
>
> It seems to me that large parts of newsfc.jit is concerned with
> handling sfc specific options. If ufc.jit is supposed to be a complete
> replacement, it would need many options to cater for the
> same functionality. I don't feel like standardizing the form compiler
> options, and I don't feel like removing functionality. I just don't
> see the point of this.

I see your point. It was a suggestion I thought was resonable wrt to code 
sharing, and the nice logic (I think ;) ):

   You send ufl statements to ufc, and get compiled ufc objects back

In an other email I also raised a problem wrt to instantiate the right objects 
from ufc, when it has compiled the module. The names of the different classes 
are probably also formcompiler specific?

Johan