On Mon, Nov 03, 2008 at 06:25:18PM +0100, Martin Sandve Alnæs wrote: > 2008/11/3 Anders Logg <[EMAIL PROTECTED]>: > > On Mon, Nov 03, 2008 at 03:55:31PM +0000, Garth N. Wells wrote: > >> > >> > >> Anders Logg wrote: > >> > On Mon, Nov 03, 2008 at 02:38:36PM +0000, Garth N. Wells wrote: > >> >> > >> >> Anders Logg wrote: > >> >>> On Mon, Nov 03, 2008 at 11:22:26AM +0000, Garth N. Wells wrote: > >> >>>> Anders Logg wrote: > >> >>>>> On Sun, Nov 02, 2008 at 06:29:25PM +0000, Garth N. Wells wrote: > >> >>>>>> Anders Logg wrote: > >> >>>>>>> On Sun, Nov 02, 2008 at 05:52:21PM +0000, Garth N. Wells wrote: > >> >>>>>>>> Do we want to insist that Dirichlet bc functions that do not > >> >>>>>>>> appear > >> >>>>>>>> inside a form are constructed with a FunctionSpace? DirichletBC is > >> >>>>>>>> supplied with a FunctionSpace, so if the bc Function does not > >> >>>>>>>> have a > >> >>>>>>>> FunctionSpace, we could attach one automatically. > >> >>>>>>>> > >> >>>>>>>> Garth > >> >>>>>>>> _______________________________________________ > >> >>>>>>>> DOLFIN-dev mailing list > >> >>>>>>>> [email protected] > >> >>>>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev > >> >>>>>>> I think this is already handled. Look in the Poisson demo. It uses > >> >>>>>>> a > >> >>>>>>> Constant to set the BC and it does not have a FunctionSpace > >> >>>>>>> attached > >> >>>>>>> to it. The DirichletBC class now uses its own FunctionSpace rather > >> >>>>>>> than the one that the Function has (if any). There is a check (in > >> >>>>>>> DirichletBC::check()) that checks that the FunctionSpace for the > >> >>>>>>> Function is the same as the one in the DirichletBC. > >> >>>>>>> > >> >>>>>> It works for Constant, but not for Functions. I was getting an error > >> >>>>>> when Function::interpolate is called. Function::interpolate leads to > >> >>>>>> eval being called, in which case there is a test for the > >> >>>>>> FunctionSpace > >> >>>>>> which fails. Constant provides its own eval and therefore doesn't > >> >>>>>> have a > >> >>>>>> problem. > >> >>>>>> > >> >>>>>> For now, I've added a test in DirichletBC for the FunctionSpace. > >> >>>>>> What we > >> >>>>>> can add is an attach function if there is no FunctionSpace > >> >>>>>> associated. > >> >>>>>> > >> >>>>>> Garth > >> >>>>> In which demo does this show up? Is there a simple way I can comment > >> >>>>> something out to reproduce the error so I understand what goes wrong? > >> >>>>> > >> >>>> Look at /demo/nls/nonlinearpoisson/cpp. > >> >>>> > >> >>>> If you change > >> >>>> > >> >>>> DirichletBoundaryCondition g(V, t); > >> >>>> > >> >>>> to > >> >>>> > >> >>>> DirichletBoundaryCondition g(t); > >> >>>> > >> >>>> it will break down. > >> >>>> > >> >>>> Garth > >> >>> ok I see the problem now. > >> >>> > >> >>> The problem is a user may choose to either overload a scalar eval > >> >>> function or a tensor eval function and we need to decide which one > >> >>> after the callback from ufc::function::evaluate(). If the > >> >>> FunctionSpace is not known, we can't decide which one to pick. > >> >>> > >> >>> If we insist that one should be able to pass a Function without a > >> >>> FunctionSpace to a DirichletBC, then we must remove the scalar eval > >> >>> function. > >> >>> > >> >> Fine with me. I think that it makes things simpler because the eval > >> >> interface remains the same for all user-defined functions. > >> >> > >> >> Garth > >> > > >> > ok. It will also look the same as in Python. > >> > > >> > >> We discussed recently passing an object to eval() which contains some > >> data. It would be useful the object also carried information on the rank > >> and dimension of the function to allow checks and switching between > >> 1D/2D/3D problems. > >> > >> Garth > > > > Yes, this would be nice, but it won't work as long as we don't require > > that a Function always has a FunctionSpace. We could add some new > > classes to handle error checking and data for user-defined Functions: > > > > void eval(Values& values, Data& data) > > { > > values[0] = sin(data.x[0]); > > } > > > > The class Values could check that data is not assigned to any illegal > > indices and it could also check that all values have been assigned > > etc, but if the Function does not know its FunctionSpace, this can't > > be done. > > > > Another complication related to this but also to the thread-safety of > > cell() and facet() is that UFC gets in the middle of the call > > sequence: > > > > assemble() > > |--> Function::interpolate() > > |--> FiniteElement::evaluate_dof() > > |--> ufc::finite_element::evaluate_dof > > |--> ufc::function::evaluate() > > |--> Function::eval() > > > > Since eval() is called from the generated UFC code, any arguments like > > cell and facet passed from the assembler will be lost on the way. > > > > Should we extend the UFC interface to allow sending a void* to > > evaluate_dof which it will propagate to evaluate()? > > That's possible, but not very safe. > > A typesafe alternative is that dolfin::Function doesn't inherit ufc::function, > but a ufc::function subclass is created which has a dolfin::Function > which it calls and a dolfin::Data & which it sends in the call. > Then we avoid ufc complications in dolfin::Function, and one such > wrapper function can be created for each thread. > It doesn't really add any more function calls, since it replaces the > existing ufc::function::evaluate in the call stack you wrote above.
Sounds good. I'll try something like this. -- Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
