On Thu, Mar 12, 2009 at 10:32 AM, Anders Logg <logg@xxxxxxxxx> wrote:
On Thu, Mar 12, 2009 at 10:25:36AM +0100, Martin Sandve Alnæs wrote:
I have serious problems with the idea of letting user-defined
functions change nature to discrete functions as a side effect
of other operations, effectively hiding the user-defined implementation
of eval.
(I know this concept wasn't introduced in this discussion, but it's related).
You mean by calling u.vector()? Yes, I agree it's problematic.
But I don't know how to handle it otherwise. Consider the following example:
u = Function(V)
solve(A, u.vector(), b)
First u is a user-defined function since it doesn't have a
vector. Then it becomes discrete when we ask for the vector.
The problem I think is that there is no way for us to check whether a
user has overloaded eval() without trying to call it.
If we didn't require that user-defined functions had a function space
for various operations, this wouldn't be as large a problem.
Then you could do
class MyFunction(Function)
{
MyFunction(V): Function(V) {}
MyFunction(): Function() {}
void eval(...) { ... }
}
MyFunction f;
f.vector(); // error, no function space!
MyFunction f(V);
f.vector(); // ok, should interpolate and make f discrete
This is already possible, but function spaces get attached unneccesarily:
1) It's not necessary to attach function spaces to functions for
assembly, since a user-defined function is evaluated through
ufc::finite_element::evaluate_dofs for each cell anyway.
This would remove the need for the side-effect in
MyFunction f;
MyForm a;
a.f = f; // attaches function space to f
2) It's not necessary to require f to have a function space to interpolate
it into another discrete function, as in:
MyFunction f(V);
Function g(V);
f.interpolate(g.vector(), V)
could just be:
MyFunction f;
Function g(V);
f.interpolate(g.vector(), V);
or even shorter:
MyFunction f;
Function g(V);
f.interpolate_into(g); // I'm often confused about the direction of
"interpolate"
