ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.

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

-- 
Anders


> I am not deep into this but I suggested this function because I imagine that 
> the form compilers defines their own signatures, based on for example some 
> formcompiler specific options or state of some configuration file of the form 
> compiler or what not.
> 
> > > To match the above functions, we could have
> > >
> > >  def jit_form(form, options=None)
> > >  def jit_forms(forms, options=None)
> > >  def jit_element(element, options=None)
> > >  def jit_elements(elements, options=None)
> 
> I think a common jit function is enough. 
> 
> Johan

Attachment: signature.asc
Description: Digital signature