dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Mar 12, 2009 at 10:46:14AM +0100, Martin Sandve Alnæs 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"

Yes, it's a bit confusing but it can be deduced from the constness or
no-constness of the functions.

The above example could be

  MyFunction f;
  Function g(V);
  g.interpolate(f); // g interpolates f

> Any other places this affects?

I think it's worth trying.

-- 
Anders

Attachment: signature.asc
Description: Digital signature