| Thread Previous • Date Previous • Date Next • Thread Next |
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 constructorI 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. Garthok. 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
------------------------------------------------------------------------ _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@xxxxxxxxxx http://www.fenics.org/mailman/listinfo/dolfin-dev
| Thread Previous • Date Previous • Date Next • Thread Next |
