ufl team mailing list archive

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

On Tue, Mar 31, 2009 at 1:41 PM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
>
>
> 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

I agree completely, and this is an unsafe feature.
I just tried to make the implementation slightly safer.

The "form" doesn't have the right type, potentially leading to
additional typechecking code many places.
(I certainly won't bother with this).

Error checking is not as good, making a proper form
instantaneously triggers some checks.
Also consider 2*(u,v) -> (u,v,u,v).

I won't use this feature and I won't spend more time on it.

Martin