ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Mar 31, 2009 at 06:22:05PM +0200, Martin Sandve Alnæs wrote:
> 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.
> >
> 
> 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 -.

ok. I guess that's a good compromise.

-- 
Anders

Attachment: signature.asc
Description: Digital signature