ufl team mailing list archive

[logg@xxxxxxxxx]

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

2. Command-line interface which ends up calling the compile() command.

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

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

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

--
Anders