dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Nov 13, 2009 at 08:18:38AM +0000, Garth N. Wells wrote:
>
>
> Anders Logg wrote:
> > On Fri, Nov 13, 2009 at 07:28:07AM +0100, Johan Hake wrote:
> >> On Thursday 12 November 2009 21:15:51 Anders Logg wrote:
> >>> I have received some complaints on the new Expression class. It works
> >>> reasonably well from C++ but is still confusing from Python:
> >>>
> >>> 1. Why does a function space need to be specified in the constructor?
> >>>
> >>>   f = Expression("sin(x[0])", V=V)
> >>>
> >>> Does this mean f is a function on V? (No, it doesn't.)
> >>>
> >>> 2. The keyword argument V=foo is confusing:
> >>>
> >>>   f = Expression(("sin(x[0])", "cos(x[1])"), V=V)
> >>>   g = Expression("1 - x[0]", V=Q)
> >>>
> >>> The reason for the function space argument V is that we need to know
> >>> how to approximate an expression when it appears in a form. For
> >>> example, when we do
> >>>
> >>>   L = dot(v, grad(f))*dx
> >>>
> >>> we need to interpolate f (locally) into a finite element space so we
> >>> can compute the gradient.
> >>>
> >>> Sometimes we also need to know the mesh on which the expression is defined:
> >>>
> >>>   M = f*dx
> >>>
> >>> This integral can't be computed unless we know the mesh which is why
> >>> one needs to do
> >>>
> >>>   assemble(M, mesh=mesh)
> >>>
> >>> My suggestion for fixing these issues is the following:
> >>>
> >>> 1. We require a mesh argument when constructing an expression.
> >>>
> >>>   f = Expression("sin(x[0])", mesh)
> >>>
> >>> 2. We allow an optional argument for specifying the finite element.
> >>>
> >>>   f = Expression("sin(x[0])", mesh, element)
> >>>
>
> We could also have
>
>      f = Expression("sin(x[0])", mesh, k)
>
> where k is the order of the continuous Lagrange basis since that's the
> most commonly used.
>
> >>> 3. When the element is not specified, we choose a simple default
> >>> element which is piecewise linear approximation. We can derive the
> >>> geometric dimension from the mesh and we can derive the value shape
> >>> from the expression (scalar, vector or tensor).
> >>>
>
> This is bad. If a user increases the polynomial order of the test/trial
> functions and f remains P1, the convergence rate will not be optimal.
>
> A better solution would be to define it on a QuadratureElement by
> default. This, I think, is the behaviour that most people would expect.
> This would take care of higher-order cases.

Yes, I've thought about this. That would perhaps be the best solution.
Does a quadrature element have a fixed degree or can the form compiler
adjust it later to match the degree of for example the basis functions
in the form?

If one should happen to differentiate a coefficient in a form, we just
need to give an informative error message and advise that one needs to
specify a finite element for the approximation of the coefficient.

> >>> This will remove the need for the V argument and the confusion about
> >>> whether an expression is defined on some function space (which it is
> >>> not).
>
> But it is when it's used in a form since it's interpolated in the given
> space.

The important point is that we only need to be able to interpolate it
locally to any given cell in the mesh, so we just need a mesh and a
cell. The dofmap is never used so it's different from a full function
space.

> >>> It also removes the need for an additional mesh=mesh argument
> >>> when assembling functionals and computing norms.
> >>>
> >>> This change will make the Constant and Expression constructors very
> >>> similar in that they require a value and a mesh (and some optional
> >>> stuff). Therefore it would be good to change the order of the
> >>> arguments in Constant so they are the same as in Expression:
> >>>
> >>>  f = Constant(0, mesh)
> >>>  f = Expression("0", mesh)
> >>>
>
> Yes.

Good.

> >>> And we should change Constant rather than Expression since Expression
> >>> might have an optional element argument:
> >>>
> >>>  f = Expression("0", mesh, element)
> >>>
> >>> Does this sound good?
> >> Yes, I think so. I suppose you mean
> >>
> >>   f = CompiledExpression("0", mesh)
> >>
> >> Just referring to the Blueprint about the simplification of the Expression
> >> class in PyDOLFIN.
> >
> > I'm not so sure anymore. Calling it Expression looks simpler.
>
> Agree.

Good.

--
Anders


> Garth
>
> What
> > were the reasons for splitting it into Expression and
> > CompiledExpression? Is it the problem with the non-standard
> > constructor when implementing subclasses?
> >
> > It's just that the most common use of expressions in simple demos will
> > be stuff like
> >
> >   f = Expression("sin(x([0])", mesh)
> >
> > so one could argue that this should be as simple as possible (and just
> > be named Expression).
> >
> >> Should an Expression in PyDOLFIN  then always have a mesh? This will make an
> >> Expression in PyDOLFIN and DOLFIN different, which is fine with me.
> >
> > Yes, to avoid needing to pass the mesh to assemble() and norm() in
> > some cases and to automatically get the geometric dimension.
> >
> >> If others agree, can you add it to the Blueprint, mentioned above, and I can
> >> do the change some time next week, or after a release (?).
> >
> > Let's hear some more comments first.
> >
>
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature