dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, Oct 03, 2009 at 11:20:41PM +0100, Garth N. Wells wrote:
>
>
> 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

It's even worse: the Coefficient base class calls
ufc::finite_element::evaluate_dof, which in turn calls evaluate in the
ufc::function base class, which is implemented by the Coefficient
(soon GenericFunction) subclass, which calls eval implemented in a
subclass of Coefficient...

--
Anders


>
> >>>> 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.
> >
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature