ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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?

> > 2. Command-line interface which ends up calling the compile() command.
> 
> SFC has a similar structure.
> 
> > The compile command checks each object in the list to see if it's an
> > object of type ElementBase (and then adds it to a list of elements), a
> > Form (and then adds it to a list of forms) and otherwise tries to create a
> > Form from it. This is where the extraction of integrals from a tuple comes
> > in:
> >
> >  for object in objects:
> >        if isinstance(object, Form):
> >            forms.append(object)
> >        elif isinstance(object, FiniteElementBase):
> >            elements.append(object)
> >        elif not object is None:
> >            forms.append(Form(object))
> 
> Ok. I think jit should return a list of compiled objects if objects is a list,
> or a single compiled object if objects is a single object, so there's a
> one to one relationship between the two. An element maps to the tuple
> (dofmap, finiteelement) or the other way around.

Sounds good.

> >> It is possible to have a function "as_form(form)" in UFL to
> >> help with this, but it would be nice to not have to call this
> >> all over the place just so you can write the mass matrix
> >> with three letters less ;-P
> >>
> >> But I think (f,v)*ds is more readable than (f,v,ds) and
> >> they're exactly the same length,
> >>
> >>   a = (u,v) + (f,v)*ds
> >>
> >> so we don't need the (f,v,ds) syntax, ok?
> >
> > But wouldn't *dx be required above as well? I'm not really happy with the
> >
> >  (f, v, ds)
> >
> > syntax but it was the only solution I could come up with.
> 
> No, both are implemented now. If you add (u,v) and a Form, you get a Form.

ok, I didn't realize that. Then I'm happy!

> > But I really like being able to write just (grad(v), grad(u)) for Poisson.
> >
> > In striving for the simplest possible notation, this is *the* global optimum
> > (not just a local optimum)... :-)
> 
> I prefer optimizing the notation within the constraints
> given by proper types and error checking. :-P

;-P back.

-- 
Anders

Attachment: signature.asc
Description: Digital signature