dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Sep 15, 2008 at 04:32:38PM +0100, Garth N. Wells wrote:
> 
> 
> 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.

I think FunctionSpace is a good name.

> 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

Perhaps, but it would require storing an extra vector of values for
user-defined functions unnecessarily.

-- 
Anders

Attachment: signature.asc
Description: Digital signature