← Back to team overview

ufl team mailing list archive

Re: [HG UFL] Implemented better version of tuple syntax:

 



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.

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.

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.

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


I actually prefer inner(v, v)*dx because what's going on is unambiguous. It also seems that it's also simpler in implementation. I don't see that typing 'inner' burdens the user excessively.

Garth

Martin
_______________________________________________
UFL-dev mailing list
UFL-dev@xxxxxxxxxx
http://fenics.org/mailman/listinfo/ufl-dev




Follow ups

References