← Back to team overview

dolfin team mailing list archive

Re: [Branch ~dolfin-core/dolfin/main] Rev 5346: Re-working of Function interfaces for removal of Data object.

 

On Wednesday December 1 2010 23:04:46 Anders Logg wrote:
> 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.

Convinced!

I you wrote MyExpression, I read Expression :P

Now I am wondering how this should be done for the complex compiled 
expressions in Python. For now we have relied on the user attaching data to a 
constructed compiled expression. We probably need to still do that for a mesh. 
It get messy to pass such things through the constructor.

Johan

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



Follow ups

References