On Tue, Oct 20, 2009 at 03:19:22PM +0200, Johan Hake wrote:
> On Tuesday 20 October 2009 15:14:23 Anders Logg wrote:
> > 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.
>
> Not a cpp.Expression only class then? Just to be sure...This is what I thought I wanted but it turned out it wasn't useful (for me). There might be other uses for it though. -- Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev
