dolfin team mailing list archive

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

On Thu, Mar 12, 2009 at 10:46 AM, Martin Sandve Alnæs
<martinal@xxxxxxxxx> wrote:
> 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

Note that these suggestions do not remove the feature of making
myfunction.vector() construct a discrete function, but allows me to
ensure that it doesn't happen if I don't want it to by simply not
assigning a function space to myfunction.

Martin