← Back to team overview

dolfin team mailing list archive

Re: Expressions without elements

 

On Tue, Oct 20, 2009 at 03:03:11PM +0200, Johan Hake wrote:
> On Tuesday 20 October 2009 14:58:44 Anders Logg wrote:
> > On Tue, Oct 20, 2009 at 02:30:56PM +0200, Johan Hake wrote:
> > > On Tuesday 20 October 2009 13:57:16 Anders Logg wrote:
> > > > Here's an issue I've run into lately.
> > > >
> > > > The current design of the Expression class forces the specification
> > > > of a FunctionSpace or UFL FiniteElement when one creates an Expression:
> > > >
> > > >   v = Expression("sin(x[0])", V=V)  or
> > > >   v = Expression("sin(x[0])", element=element)
> > > >
> > > > This is only necessary in Python, but not in C++ where it's enough to
> > > > set the geometric dimension.
> > >
> > > All you ask for is already here for you, but not in a shiny easy
> > > accessible way.
> > >
> > >   CompiledClass = compile_expressions(["sin(x[0])"],[{}])[0]
> > >   expr = CompiledClass(2)
> > >
> > > This is a cpp.Expression, which you cannot use in a ufl form and it does
> > > not have the nice __call__ method.
> > >
> > > > Would it be possible to add an optional constructor that just takes
> > > > the geometric dimension as an argument?
> > >
> > > This is what the above do.
> > >
> > > > I'm writing some code where I create various Expressions and project
> > > > to different function spaces (for some theoretical studies related to
> > > > adaptivity). Then it shouldn't matter (and it doesn't) which function
> > > > space or element I originally specify in the constructor of my sin(x)
> > > > expression.
> > > >
> > > > If necessary, we can automatically create either a piecewise linear
> > > > Lagrange element based on the incoming geometric dimension. Another
> > > > option would be to use a QuadratureElement.
> > >
> > > I will not make this shine for now. However, the future CompileExpression
> > > could take an argument dim, that if given, will create a cpp.Expression
> > > only class which cannot be used in ufl.forms.
> >
> > ok.
> >
> > > I also suggest that we keep the future dolfin.Expression class as a
> > > combined cpp.Expression/ufl.Function class. If not we could add a new
> > > class called FormExpression which has the dual inheritance, and
> > > Expression which essentially just is cpp.Expression.
> >
> > Agree.
>
> With what?

With your suggestion: the dual inheritance of Expression.

And it would also be good to have it for CompiledExpression.

This contradicts what I just asked for but after having played around
with compile_expressions for a while, I realized that it wasn't very
useful since I was computing norms etc of the expressions anyway and I
can't do that without specifying the element.

--
Anders

Attachment: signature.asc
Description: Digital signature


Follow ups

References