Anders Logg wrote:
> On Sat, Oct 03, 2009 at 11:12:15PM +0200, DOLFIN wrote:
>> One or more new changesets pushed to the primary dolfin repository.
>> A short summary of the last three changesets is included below.
>>
>> changeset:   7244:da48cdfb0ecf
>> tag:         tip
>> user:        "Garth N. Wells <gn...@cam.ac.uk>"
>> date:        Sat Oct 03 13:34:09 2009 +0100
>> files:       dolfin/function/Data.h
>> description:
>> Make Data::update public.
>>
>> The Function design seems to be betting a bit complicated again.
> 
> Let's revise it until it's simple enough. The point about the redesign
> is to make it simple.
> 

I would like to not have the 'call back' to the eval functions in 
Coefficient because they're hard to follow. Should we make

     Coefficient::evaluate

pure virtual for clarity?


>> I just want a function in Coefficient that takes a point and a cell
>> and evaluates the function.We have Coefficient::eval(double*,
>> Data&), but the necessary functions to constract Data were private.
> 
> The point with Data is to keep it simple, in particular to avoid
> having many different versions of eval, one when the cell is
> available, when it's not, when the facet is available etc etc.
> 
> So there are two versions: one with just the point x and another one
> that should cover the rest.
> 

I wasn't very accurate in what I wanted to express. I'm happy with an 
eval function that takes the value(s) and a Data object. The issue is 
that it wasn't possible to construct a suitable Data object to pass to 
an eval function because the necessary Data data/functions were private.

Garth

>> Also, if one calls Coefficient::evaluate(....), the coordinate are
>> updated in the Data object (inside Coefficient::evaluate(.)), but
>> not the cell.
> 
> That's a bug. It should be updated. It should fill out the data with
> all information it has: the cell and the coordinates. I'll fix it.
> More data may already have been filled into Data, like the current
> facet if it's known during assembly (set at the time of calling the
> restrict function).
> 
> --
> Anders
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@fenics.org
> http://www.fenics.org/mailman/listinfo/dolfin-dev

-- 
Dr Garth N Wells
Department of Engineering
University of Cambridge
Trumpington Street
Cambridge CB2 1PZ
United Kingdom

tel.   +44 1223 3 32743
e-mail gn...@cam.ac.uk
http://www.eng.cam.ac.uk/~gnw20/
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@fenics.org
http://www.fenics.org/mailman/listinfo/dolfin-dev

Reply via email to