dolfin team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

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"


Any other places this affects?

Martin