ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

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

I'll use it.

-- 
Anders

Attachment: signature.asc
Description: Digital signature