| Thread Previous • Date Previous • Date Next • Thread Next |
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@xxxxxxxxxxxxxwrote:------------------------------------------------------------ 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_areadiameter 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.
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. 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
| Thread Previous • Date Previous • Date Next • Thread Next |
