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 <[email protected]> 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
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
