dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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...

Johan

> Garth
> 
> > --
> > Anders
> > 
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp