ufl team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Wednesday 01 April 2009 10:31:32 Martin Sandve Alnæs wrote:
> On Wed, Apr 1, 2009 at 9:34 AM, Johan Hake <hake@xxxxxxxxx> wrote:
> > 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
>
> The flaw in this statement is that the signature of jit is not
>   def jit(input)
> but
>   def jit(input, options)

I intended this to be the signature of ufc.jit.

> and options are formcompiler specific ways to change the behaviour of jit.

Yes and I thought these could just be sent to the formcompiler, and the 
compiler could do what ever it would like to do with them.

> Another argument against this is that it makes ufc depend on ufl, we
> don't want that.

Not necessary, it could just send the input to 
   
  form_compiler.compute_signature()

and then to 

  form_compiler.generate_code()

the generated code will then be used to build the extension module. However 
the classes will not easily be instantiated from ufc, without any more 
information. I think this is a show stopper. Also if ufc will not depend on 
UFL we cannot check the input to see what we should extract and again the 
point is lost.

So then we are almost back to what we have today. The formcompiler define its 
own jit, which returns instantiated form(s), (element(s), dofmap(s)), 
depending on the input?

Johan

> > 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?
>
> Yes.
>
> Martin