← Back to team overview

dolfin team mailing list archive

Re: Another suggestion for the Function class

 

On Tue, Dec 02, 2008 at 12:00:34PM +0100, Martin Sandve Alnæs wrote:
> 2008/12/2 Anders Logg <logg@xxxxxxxxx>:
> > Would it be difficult to add the possibility of sending in a SymPy or
> > Swiginac expression to the Function constructor? As I understand, both
> > can generate C++ code so it seems we could reuse what we already have
> > for cppexpr.
> 
> Trivial. Except that the symbols used must be named like
> x = swiginac.symbol("x[0]") etc from the user side, we can
> just call "swiginac_expression.printc()" to get a scalar string.
> Eventually "swiginac_expression.evalm().evalf().printc()"
> to be on the safe side.

Can't we just define

  x = swiginac.symbol("x[0]")

in the __init__ file for DOLFIN so x would be available directly, just
like dx, ds, grad, etc.

> > Then, one could do things like
> >
> > f = Function(V, sin(x))
> >
> > which would be close to optimal.
> 
> You're forgetting namespace clashes here...
> In real code there will have to be detailed imports from different
> modules or explicit namespace handling to separate
> sympy.sin, numpy.sin, ufl.sin and math.sin.

Ah, this can be problematic.

> > The best of course would be if one
> > did not need to first define f and then use it, but instead could
> > write it directly in the form:
> >
> > L = v*sin(x)*dx
> 
> We can do that easily if we add terminal symbols x,y,z or x[0], x[1],
> ... to UFL.
> 
> from ufl import *
> polygon = triangle
> element = FiniteElement("CG", polygon, 1)
> v = TestFunction(element)
> x = SpatialCoordinate(polygon)
> f = sin(x[0])
> a = f*v*dx
> 
> Generated quadrature code can handle this directly, while tensor
> representation would require some function extraction magic.

Sounds good.

-- 
Anders

Attachment: signature.asc
Description: Digital signature


Follow ups

References