| Thread Previous • Date Previous • Date Next • Thread Next |
Johan Hake wrote:
On Thursday 02 July 2009 23:22:35 Garth N. Wells wrote:Anders Logg wrote:On Thu, Jul 02, 2009 at 01:42:41PM +0200, Johan Hake wrote:On Thursday 02 July 2009 13:24:28 Garth N. Wells wrote:Johan Hake wrote:On Thursday 02 July 2009 13:07:47 Garth N. Wells wrote:Marie Rognes wrote:Garth N. Wells wrote:Marie Rognes wrote:The following code gives r = 0.0. It is not supposed to be. The problem seems to be that f's vector is still all zeros at the call to interpolate. Could this be easily fixed?This example should have led to an error message since f is not a discrete function. I'll take a look.Ok, thanks! However, (a) Why is f not a discrete function? (It is defined on a finite element space?)On second thought, it may be a discrete function. I think that this is defined in the Python interface and not the C++ interface, so I'll take a look.A user defined function is not a discrete function untill you either call interpolate() or vector, also in python. The problem with the later is that you then create a vector which is initialized to 0. I think this has been discussed before, but should we populate the vector using f.interpolate() when vector is called on a userdefined function?Or perhaps Function::vector() should throw an error if the vector has not already been allocated.I vote for this. The error message can include information about the user might want to call interpolate? JohanSounds good.Unfortunately this won't work because we often do Function u(V); solve(A, u.vector(), b);I see.
The best short-term solution is a clear comment above Function::vector() in Function.h that calling this function will create a new and empty vector, thereby and that it is the users responsibility to deal with this situation
The real problem is a deeper design issue. For example, say a user creates an object
MyFunction my_function(V);
and provides an eval function, and then calls vector(). Now,
if the user calls eval(....) on my_function the eval function will be
entered. However, if the user does
Function& function = my_function;
(or just passes my_function to a function which expects a Function
object) and then calls eval, the entries in the dof vector (which are
zero) will be used to evaluate the function rather than the eval
function. The behaviour of the object is inconsistent due to the
call-back function eval(..) inside Function. The root of the problem is
the old one of aFfunction object that can change state between
user-defined and discrete.
I don't see a simple solution. We could add a switch to indicate that a Function is user-defined, in which case a vector can never be created and a Function cannot change state,
Function f(V, Function::user); Function pi_f0 = f; // Interpolate f in V Function pi_f1(W); pi_f1.interpolate(f); // Interpolate f (defined on V) in W GenericVector& x = f.vect(); // Throw an errorOr, we add a new class like 'UserFunction' which is derived from (Generic)Function and cannot create a vector, and let Function create a vector upon construction. Now that we have interpolation, the need for allowing Functions to change state is diminished.
Garth
It would have worked in python though, as u would have been a discrete Function when created. However this is now implemented as a call to vector() in the constructor of DiscreteFunction, so that would also need some attention.JohanGarthJust to check: this only occurs (in Python) when a user defines a Function using a C++ expression or overloads eval(), right? ------------------------------------------------------------------------ _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@xxxxxxxxxx http://www.fenics.org/mailman/listinfo/dolfin-dev_______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@xxxxxxxxxx http://www.fenics.org/mailman/listinfo/dolfin-dev
| Thread Previous • Date Previous • Date Next • Thread Next |
