dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Feb 16, 2009 at 04:36:58PM +0000, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > On Mon, Feb 16, 2009 at 01:48:52PM +0100, Johan Hake wrote:
> >> On Monday 16 February 2009 13:15:11 Anders Logg wrote:
> >>> On Mon, Feb 16, 2009 at 12:39:15PM +0100, Johan Hake wrote:
> >>>> On Monday 16 February 2009 12:06:09 Anders Logg wrote:
> >>>>> On Mon, Feb 16, 2009 at 11:52:54AM +0100, Johan Hake wrote:
> >>>>>> On Monday 16 February 2009 11:31:36 Anders Logg wrote:
> >>>>>>> On Mon, Feb 16, 2009 at 10:12:21AM +0000, Garth N. Wells wrote:
> >>>>>>>> Anders Logg wrote:
> >>>>>>>>> On Mon, Feb 16, 2009 at 10:36:52AM +0100, Johan Hake wrote:
> >>>>>>>>>> On Sunday 15 February 2009 21:23:44 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:   5701:d3661203791d9c7707695c59adbbd3a2e20a220c
> >>>>>>>>>>> tag:         tip
> >>>>>>>>>>> user:        Anders Logg <logg@xxxxxxxxx>
> >>>>>>>>>>> date:        Sun Feb 15 21:23:36 2009 +0100
> >>>>>>>>>>> files:       dolfin/function/Function.cpp
> >>>>>>>>>>> description:
> >>>>>>>>>>> Move code from Function copy constructor to assignment
> >>>>>>>>>>> operator and call assignment operator from copy constructor
> >>>>>>>>>> I liked Garth solution better.
> >>>>>>>>>>
> >>>>>>>>>>  1) A copy constructor that, just copies the Function if it
> >>>>>>>>>> has a FunctionSpace.
> >>>>>>>>>>  2) The assignment operator works only for discrete Functions.
> >>>>>>>>>>
> >>>>>>>>>> We could add an interpolate() (or something) function that
> >>>>>>>>>>
> >>>>>>>>>>   v.interpolate(*_vector, *_function_space);
> >>>>>>>>> We already have exactly such a function.
> >>>>>> Do we?
> >>>>> Yes:
> >>>>>
> >>>>>   /// Interpolate function to given function space
> >>>>>   void interpolate(GenericVector& coefficients, const FunctionSpace& V)
> >>>>> const;
> >>>> Can you use this to initialize your own vector if you e.g. is a
> >>>> user-defined Function? I think we have ahd this discussion before, and
> >>>> Martin added such a function, but removed it because it was not general
> >>>> enough, or am I wrong?
> >>> Yes, it should work, both for interpolation of user-defined and
> >>> discrete functions.
> >> So if I want to "discretize" MyFunc I do:
> >>
> >>   MyFunc f(V);
> >>   ...
> >>   f.interpolate(f.vector(),f.function_space());
> > 
> > Yes, that should work.
> > 
> >>>>>>>>>> Then the user can explicitly create a discrete function of its
> >>>>>>>>>> user-defined Function. Now the user gets this as an implicitly
> >>>>>>>>>> result of a function copy, which make litle sense to me.
> >>>>>>>>>>
> >>>>>>>>>> But that's just me :)
> >>>>>>>>> I like it. Other opinions?
> >>>>>>>> It is neat, but I would prefer any interpolation to be more
> >>>>>>>> explicit so that it's clear what's going on. A copy should be a
> >>>>>>>> straight copy.
> >>>>>>>>
> >>>>>>>> Garth
> >>>>>>> ok. I've changed it back. See if it looks ok.
> >>>>>> Now a user cannot copy a Function that is not a discrete function,
> >>>>>> which was the case before we started all this.
> >>>>> Wasn't that the point? It's not possible to copy the eval() operator.
> >>>>>
> >>>>> Well it is but then it would be necessary to keep a pointer to the
> >>>>> given Function and propagate the eval call to that Function's eval.
> >>>>> That seems a bit overkill.
> >>>>>
> >>>>>> Also sometimes a copy is something different than an assignment, so
> >>>>>> it is not always meaningfull to use *this = other; in the copy
> >>>>>> constructor.
> >>>>> I've found it's almost always the case that one can implement the
> >>>>> copy constructor by
> >>>>>
> >>>>>   *this = other;
> >>>>>
> >>>>> We use this in a bunch of other places, including the Mesh class.
> >>>>>
> >>>>> In which cases will it break?
> >>>> I am thinking very simple here, it deals with defining a sane and
> >>>> complete C++ interface to Function. Should we be able to copy a
> >>>> user-defined Function or not?
> >>> I think we should (by interpolation) but if there's otherwise
> >>> consensus we should not interpolate then it should not be possible to
> >>> assign user-defined functions since we can't or won't deal with
> >>> copying of eval().
> >> You guys decide this one. I stay with the python interface ;)
> > 
> > I suggest we keep it as it is now and then add back the interpolation
> > if we should find a need for it.
> >
> 
> Is this back to how it was now? If this is sorted out, when can think 
> about making a release. Any other issues that need to be dealt with?
> 
> Garth

I don't think it was ever changed after I changed it. Here's the
current version:

  // Check for function space and vector
  if (!v.has_function_space())
    error("Cannot copy Functions which do not have a FunctionSpace.");
  if (!v.has_vector())
    error("Cannot copy Functions which do not have a Vector (user-defined Functions).");

  // Copy function space
  _function_space = v._function_space;
  
  // Initialize vector and copy values
  init();
  *_vector = *v._vector;

  return *this;

So, only discrete functions can be assigned/copied and no
interpolation is used.

I don't know of any other things that need to be fixed before a
release as long as the buildbot is all green (currently building).

-- 
Anders

Attachment: signature.asc
Description: Digital signature