dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Dec 01, 2010 at 04:57:08PM -0800, Johan Hake wrote:
> On Wednesday December 1 2010 15:22:54 Garth N. Wells wrote:
> > On 01/12/10 23:07, Anders Logg wrote:
> > > On Wed, Dec 01, 2010 at 03:01:13PM -0800, Johan Hake wrote:
> > >> On Wednesday December 1 2010 14:52:32 Garth N. Wells wrote:
> > >>> On 01/12/10 22:25, Johan Hake wrote:
> > >>>> On Wednesday December 1 2010 14:06:59 Anders Logg wrote:
> > >>>>> On Wed, Dec 01, 2010 at 01:51:01PM -0800, Johan Hake wrote:
> > >>>>>> On Wednesday December 1 2010 11:19:28 noreply@xxxxxxxxxxxxx wrote:
> > >>>>>>> ------------------------------------------------------------
> > >>>>>>> revno: 5346
> > >>>>>>> committer: Garth N. Wells<gnw20@xxxxxxxxx>
> > >>>>>>> branch nick: dolfin-all
> > >>>>>>> timestamp: Wed 2010-12-01 19:15:42 +0000
> > >>>>>>>
> > >>>>>>> message:
> > >>>>>>>     Re-working of Function interfaces for removal of Data object.
> > >>>>>>>
> > >>>>>>>     Nearly all test running, but logic needs to be checked. Problem
> > >>>>>>>     remains
> > >>>>>>>
> > >>>>>>> with demos that use facet info.
> > >>>>>>>
> > >>>>>>>     Also need to sort out determning whether or nor a ufc::cell
> > >>>>>>>     belongs to a
> > >>>>>>>
> > >>>>>>> given mesh. modified:
> > >>>>>> There is a whole bunch of functionality that is lost with not having
> > >>>>>> access to a dolfin::Cell. Should this be added to ufc::cell?
> > >>>>>
> > >>>>> I assume we will keep all existing functionality in place, in
> > >>>>> particular the functions defined in SpecialFunctions.h.
> > >>>>
> > >>>> My point is that in the data argument you could access a dolfin::Cell.
> > >>>> This you cannot do now. I think this is a no go if we cannot find a
> > >>>> substitute for the lost functionality.
> > >>>
> > >>> We haven't lost much, since nearly everything that was in
> > >>> SpecialFunctions.h is now in UFL/FFC. What remains (e.g. FacetArea)
> > >>> could probably go in UFC eventually.
> > >>
> > >> FacetArea as in special function FacetArea?
> > >>
> > >> There are all kinds of functionalities in dolfin::Cell:
> > >>    volume, diameter, normal, facet_area
> >
> > diameter and normal are available through UFL (and so too could be
> > volume and facet area, if not already).
>
> My point is that it might be usefull to have these guys available within the
> Expression::eval if a user want to define complex Expressions interacting with
> user provided data.
>
> > >> which are neat functions to have within a more complex Expression.
> > >>
> > >>> What we can do is create a dolfin::Cell from a ufc::cell (since we can
> > >>> access the cell index from the ufc::cell object) if we know that the
> > >>> ufc::cell comes from the mesh at hand.
> > >>
> > >> How would a user access a dolfin::Cell from within eval?
> > >
> > > By storing a reference to the Mesh:
> > >    class MyExpression : public Expression
> > >    {
> > >
> > >    public:
> > >      MyExpression(const Mesh&  mesh) : mesh(mesh) {}
> > >
> > >      ...
> > >
> > >      void eval(...)
> > >      {
> > >
> > >        Cell cell(mesh, cell_index);
> > >        ...
> > >
> > >      }
> > >
> > >    private:
> > >      const Mesh&  mesh;
> > >
> > >    };
> >
> > Exactly. We might also be able to provide a simple interface that
> > supplies the cell (by doing the above in the background).
>
> Yes, because we made quite an effor to make Expression mesh independent ;)
>
> > All we need is the cell index, and in some cases the local facet index
> > too, to access everything that we could previously.
>
> and the information of the mesh...

Expression would still be Mesh independent, unless the user explicitly
makes it Mesh dependent by the above construction.

--
Anders