Johan Hake wrote: > On Tuesday 04 November 2008 13:15:51 Anders Logg wrote: >> On Mon, Nov 03, 2008 at 10:38:40PM +0100, Anders Logg wrote: >>> 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. >> This is now implemented. Take a look in Function::interpolate(), > > Should it be called FunctionData instead? >
Yes, that is a more descriptive name. Garth > As Data is implemented now it cannot be changed after creation, i.e., you > cannot set _facet or _cell. Would it be benefitial to cache the Data object > and the dofs, which both are created for each call of interpolate? > > Johan > _______________________________________________ > 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
