dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Saturday 28 November 2009 00:55:01 Anders Logg wrote:
> On Sat, Nov 28, 2009 at 12:47:40AM -0800, Johan Hake wrote:
> > On Friday 27 November 2009 23:59:52 Johan Hake wrote:
> > > Hello!
> > >
> > > I have not pushed anything, but Expressions should be up to shape now,
> > > and I am working on simplifying the logic in other places of
> > > expression.py
> > >
> > > I do not like the implementation of the dim method. It is used to read
> > > a user defined value dimension and then discarded. I suggest that we
> > > add a value_shape attribute to the dolfin.Expression class. If not set
> > > by the user it is by default (), i.e., a scalar Expression.
> > >
> > >   class MyExpression(Expression):
> > >       value_shape = (2,)
> > >       def eval(self, values, x):
> > >          values[0] = 1
> > >          values[1] = 1
> > >
> > > The dim name is also only making sense for Vector Expressions, where I
> > >  think a value_shape attribute makes sense for all occasions. A
> > > value_shape for scalar Expression will still be the default.
> > >
> > > After creation and instantiation we then have an object that have both
> > > a shape method (from ufl.Function) and a value_shape attribute from the
> > > subclassing definition.
> > >
> > > What you think.
> >
> > Hmm, more trouble I think. How should we be able to specify the degree,
> > and or element when we have derived python Expression? Should we add more
> > attributes?
> 
> I think it works to do
> 
>   f = MyExpression(element=FiniteElement("Lagrange", triangle, 3))
> 
> Or is that broken?

Yes of course, that should work. It was awful late last night. Will push my 
changes later today.

Johan

> --
> Anders
> 
> > One way is to adapt the CompiledExpression solution, and to make
> > dolfin.Expression a pure and nice subclass of ufl.Function and
> > cpp.Expression. a user defined python Expression would then look like:
> >
> >    class MyExpression(Expression):
> >        def __init__(self):
> >            Expression.__init__(self, element, degree, value_shape)
> >        def eval(self, values, x):
> >            values[0] = 1
> >            values[1] = 1
> >
> > Where element, degree, and value_shapes are all optional. All the logic
> > of what element, should be used is concealed in
> > dolfin.Expression.__init__
> >
> > With this solution we split all the logic that goes into a compiled
> > Expression from what goes into a user defined Python Expression. One of
> > the main problems with the present design is that they are too
> > intermingled.
> >
> > Johan
> >
> > > Johan
> > >
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~dolfin
> > > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe : https://launchpad.net/~dolfin
> > > More help   : https://help.launchpad.net/ListHelp
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp
>