dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

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());

> > > > > > >> 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 ;)

Johan

> > I thought yes, and no one came with any argument why not. Remember that
> > this came from the discussion of returning a user-defined Function by
> > value from an other function.
> >
> > we are talking about
> >
> >   MyFunc f(V);
> >   MyFunc g(f);
> >
> > not
> >
> >   MyFunc f(V);
> >   Function g(f);
>
> What is the difference? Both will be possible but only the first will
> make sense.
>
> > So the logic is that a user-defined Function should stay the same if it
> > is copied and the assignment operator can only be used for discrete
> > functions.
> >
> > If we want to be able to copy a user-defined function without
> > initializing the _vector, then the assignment operator needs to be
> > different from the copy constructor.
>
> I still don't understand why they should be different.