ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.

> > > > >>   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.

ok, then I understand. Should it be named something like compute_signature?

-- 
Anders

Attachment: signature.asc
Description: Digital signature