ufl team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

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

Martin