dolfin team mailing list archive

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

Anders Logg wrote:
> On Sat, Oct 03, 2009 at 10:59:39PM +0100, Garth N. Wells wrote:
> > 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?
>
> Would that help? Then both Expression and Function would need to
> reimplement the evaluate() function (in the same way) and both would
> need to handle the somewhat ugly update of the data object.

I don't mind the update. I find it hard to follow code when the base 
class calls functions which are implemented in the sub-class.

Garth


> > > > 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.
>
> ok, should be fixed now. The Data class may need some more tweaks to
> make it useful and more robust.
>
> --
> Anders
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev