← Back to team overview

dolfin team mailing list archive

Re: [HG DOLFIN] Rmove some interpolate functions from FunctionSpace.

 

On Thu, Oct 01, 2009 at 11:40:20PM +0200, Anders Logg wrote:
> On Thu, Oct 01, 2009 at 07:20:53PM +0200, DOLFIN wrote:
> > One or more new changesets pushed to the primary dolfin repository.
> > A short summary of the last three changesets is included below.
> >
> > changeset:   7215:54eb1b460f36
> > tag:         tip
> > user:        "Garth N. Wells <gnw20@xxxxxxxxx>"
> > date:        Thu Oct 01 18:20:43 2009 +0100
> > files:       dolfin/function/Function.cpp dolfin/function/FunctionSpace.cpp dolfin/function/FunctionSpace.h
> > description:
> > Rmove some interpolate functions from FunctionSpace.
> >
> > One remains. Should it stay?
>
> The two interpolate() functions that we have now in Function seem to
> be the only two logical interpolate() functions. And they are actually
> the same: a Function interpolating something else which can be either
> a Function or an Expression.
>
> Then we have two other functions which are now named interpolate. One
> is interpolate_vertex_values in Function and one is interpolate in
> FunctionSpace. These are really different since they are about taking
> a Function and computing some values: either vertex values or
> expansion coefficients in another space.
>
> I suggest we rename these and put them both in the Function class:
>
>   /// Compute vertex values for all vertices of the mesh
>   void compute_vertex_values(double* vertex_values) const;

Done.

>   /// Compute expansion coefficients on given function space
>   void compute_expansion_coefficients(GenericVector& coefficients,
>   const FunctionSpace& V);

I started working on this but realized two things:

1. This must be implemented in the FunctionSpace class, since we can
then reuse the implementation for computing expansion coefficients for
Expressions. So the function is rightly named interpolate() and should
be in V.

2. The implementation will rely on the restrict() function doing the
right thing when restricting to an element that may have a different
local function space and possibly come from a different mesh.

So the restrict() implementation is indeed too simple as Garth pointed
out a couple of days ago.

I'll push some minor updates and comments in a short while but I
won't have time to look more into this until later tonight or this
weekend so feel free to have a look.

--
Anders

Attachment: signature.asc
Description: Digital signature


References