dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Thursday December 2 2010 09:43:13 Garth N. Wells wrote:
> On 02/12/10 17:03, Johan Hake wrote:
> > 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.
> 
> I'm sceptical now about passing the local facet index. If we assemble by
> looping over cells, and then over facets (which we already do in some
> cases), we need to call 'restrict' for each facet, and this will lead to
> quite some redundant operations. Despite a facet index being passed, the
> Expression is evaluated at all dofs, even though some are away from the
> facet.

How did we do this previously when iterating just over let say the exterior 
facets? Here we pass the Cell, and notion of the local (global) facet.

> What we need to resolve quickly is how to identify whether or not a
> ufc::cell belongs to a particular Mesh. One approach would be to create
> a singleton class that hands out integers. Every time an integer index
> is handed out, the index can be incremented. We could have that the Mesh
> constructors always request an index that can be used to identify the
> mesh. A ufc::cell could store the mesh identifying integer.
> 
> Another possibility is to use Boost UUID:
> 
>    http://www.boost.org/doc/libs/1_45_0/libs/uuid/index.html
> 
> A ufc::cell could optionally store a Mesh UUID as a string.

UUID looks light weighted and good. Would it make sense to let a ufc::mesh 
have an UUID (or equivalent, not happy to have ufc depend on boost...), and 
then ufc::cell have a pointer to the mesh?

Johan

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