dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Nov 13, 2009 at 09:46:21AM +0000, Garth N. Wells wrote:
>
>
> Anders Logg wrote:
> > 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?
> >
>
> Kristian?
>
> > 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.
> >
>
> I think you mean element rather than cell?

I actually meant cell. But the restriction operator (extracting the
information we need to integrate over the cell) requires an element
(which implements evaluate_dof).

--
Anders


> Garth
>
> >>>>> 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.
> >
> >> 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
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature