ufl team mailing list archive

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

On Wed, Apr 1, 2009 at 9:28 AM, Johan Hake <hake@xxxxxxxxx> wrote:
> On Wednesday 01 April 2009 09:01:29 Martin Sandve Alnæs wrote:
>> 2009/4/1 Johan Hake <hake@xxxxxxxxx>:
>> > On Wednesday 01 April 2009 01:19:14 Anders Logg wrote:
>> >> On Tue, Mar 31, 2009 at 11:38:08PM +0200, Johan Hake wrote:
>> >> > 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?
>> >>
>> >> Does the jit function need to know what type of objects it gets? If it
>> >> knows whether an object is a form or element, then it appropriate to
>> >> call either compile_form or compile_element. If not, then I agree it's
>> >> better to let the form compiler resolve the type of object.
>> >
>> > I vote for this. The interface between ufc.jit and the formcompiler will
>> > then be minimal, and that is good.
>> >
>> > I added the type check suggestion as a sanity check for what the
>> > formcompiler returns. But I do not think it is nescessary.
>>
>> If we are supposed to handle a list of objects that can be a mixture of
>> elements and forms, it doesn't make any sense to split the implementations.
>> Since we have a single "jit" command, the types of the input must be
>> inspected anyway, so I don't really see what the splitting simplifies.
>
> Agree.
>
> While at it, when we compile a list of objects these will go into the same
> extension module, right? If so, how will ufc.jit know the name of the classes
> it will instantiate from the module? Will this be formcompiler specific?

This + options handling is basically what jit does now, and it is
formcompiler specific. See my other email.

> Maybe open a new thread?
>
> Johan

Martin