Anders Logg wrote: > 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. >
Agree. Garth > > > ------------------------------------------------------------------------ > > _______________________________________________ > DOLFIN-dev mailing list > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
