ufl team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

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)

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

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

> 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