ufl team mailing list archive

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

On Tue, Mar 31, 2009 at 5:02 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> On Tue, Mar 31, 2009 at 02:34:19PM +0200, Martin Sandve Alnæs wrote:
>> 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).
>
> But that's correct, right? Doing (u, v) + (u, v) also gives
> (u, v, u, v) which will be interpreted as
>
>  inner(u, v)*dx + inner(u, v)*dx = 2*inner(u, v)*dx

True.

>> I won't use this feature and I won't spend more time on it.
>
> I'll use it.
>
> --
> Anders

Can we at least drop the "a = (u,v)" version?
The forms look more consistent if we require *dx.
The implementation becomes simpler and we don't need
typechecks all over the place. Subtraction works since *
has higher precedence than -.

Martin