dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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 <gnw20@xxxxxxxxx>"
> > 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@xxxxxxxxxx
> 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 gnw20@xxxxxxxxx
http://www.eng.cam.ac.uk/~gnw20/