← Back to team overview

dolfin team mailing list archive

Re: PyDOLFIN Function

 



Anders Logg wrote:
On Mon, Sep 15, 2008 at 03:47:59PM +0100, Garth N. Wells wrote:

Anders Logg wrote:
On Mon, Sep 15, 2008 at 03:12:58PM +0100, Garth N. Wells wrote:
Anders Logg wrote:
On Mon, Sep 15, 2008 at 03:06:55PM +0200, Johan Hake wrote:
On Monday 15 September 2008 14:29:08 Garth N. Wells wrote:
Could a Python expert take a look at site-packges/dolfin/function.py?
The code directly following the comment

  # Special case, Function(element, mesh, x), need to create simple form
to get arguments

need to be updated but I don't understand it well.
The first special case is for initializing a Function with a given Vector, by constructing a dofmap from the handed element.

As constructing a Function from a vector is removed from the cpp interface, and we have not, (or have we?) figured out how to wrap a shared_ptr in swig, we should probably just remove the first case for now.

Johan
The question is how we want to create discrete Functions in Python.
Previously, this was done by

  u = Function(element, mesh, Vector())

but now the third argument is not needed anymore. If we remove it,
we get

  u = Function(element, mesh)

but that doesn't work since that is the way to initialize a
user-defined function (something overloading eval()).

We could put in a flag and make "discrete" the default. Then all
user-defined functions need to set the flag to "user".

Suggestions? This is a good time to worry about how we want to design
the Function interface.

Sounds ok to me. This is basically what Vector() was doing, and a flag would be more descriptive.

Garth
Maybe we could first try to think seriously about reducing the number
of different constructors in Function. There are 14 now! See below.

I guess we need the following two basic constructors (empty and copy):

  /// Create empty function (read data from file)
  Function();

  /// Copy constructor
  Function(const Function& f);

Then we have one for reading from file, which seems ok:

  /// Create function from data file
  explicit Function(const std::string filename);

And then the following set of constructors for constants:

  /// Create constant scalar function from given value
  Function(Mesh& mesh, real value);

This one is useful.

  /// Create constant vector function from given size and value
  Function(Mesh& mesh, uint size, real value);

We could get rid of this one and use the below constructor.

  /// Create constant vector function from given size and values
  Function(Mesh& mesh, const Array<real>& values);

This one is useful.

  /// Create constant tensor function from given shape and values
  Function(Mesh& mesh, const Array<uint>& shape, const Array<real>& values);

This is the most generic of the constant functions, so I guess we need it.

And then there's this constructor which is needed for w.split(u, p):

  /// Create discrete function from sub function
  explicit Function(SubFunction sub_function);

But then there's the following mess of constructors:

Some of these constructors are necessary to support the PyDOLFIN interface. Can we get around this somehow to avoid duplication?

  /// Create function from given ufc::function
  Function(Mesh& mesh, const ufc::function& function, uint size);
/// Create discrete function for argument function i of form
  Function(Mesh& mesh, Form& form, uint i = 1);
/// Create discrete function for argument function i of form
  Function(Mesh& mesh, DofMap& dof_map, const ufc::form& form, uint i = 1);

  /// Create discrete function for argument function i of form (data may be shared)
  Function(std::tr1::shared_ptr<Mesh> mesh,
           std::tr1::shared_ptr<GenericVector> x,
           std::tr1::shared_ptr<DofMap> dof_map, const ufc::form& form, uint i = 1);

  /// Create discrete function based on signatures
  Function(std::tr1::shared_ptr<Mesh> mesh,
           const std::string finite_element_signature,
           const std::string dof_map_signature);

  /// Create user-defined function (evaluation operator must be overloaded)
  explicit Function(Mesh& mesh);

We need this one.

Garth

If we just consider discrete functions for a while, the question is
how these may be most conveniently (and naturally) defined in C++ and
Python.

In C++, one only has a dolfin::Form, for example PoissonBilinearForm,
and then it's simple to create a discrete Function by

  Function u(mesh, form);

This will extract the element and dof map for the second argument of
the form (the trial function) which is normally what is needed.

In Python, one does not have a dolfin::Form, but instead one has a
FiniteElement, and then the simplest thing to do is

  u = Function(element, mesh)

The element is the first argument for practical reasons (see
function.py) but maybe it shouldn't. I'd like to change this so that
the mesh is always first. All Functions require a Mesh and then it's
natural to put this first.

So then we would have

  C++:    Function u(mesh, form);
  Python: u = Function(mesh, element)

On the other hand, we've been discussing adding a FunctionSpace class,
and then it might be natural to just have

  C++:    Function u(V);
  Python: u = Function(V)

This would create a discrete Function. Constant Functions and
user-defined Functions may be created without reference to a
FunctionSpace. This would solve the problem of overloading
constructors. It would be very clear that whenever a FunctionSpace is
involved, it is a discrete Function.


Agree. It's not appropriate to initialise a discrete function with a form. It seems that using a FunctionSpace will simplify the interface and provide uniformity across the C++ and Python interfaces, so let's get FunctionSpace (or something similar with another name) in place and then remove some the Function constructors.

Function spaces are not only associated with DiscreteFunctions. We usually interpolate user defined function in the finite element space, so perhaps there is some scope to unify discrete and user defined functions?

Garth



------------------------------------------------------------------------

_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev



Follow ups

References