Note that there are multiple variants of x(...) in MeshGeometry, _some_ which do some kind of renumbering (the renumbering is possibly a no-op, but still it seems prone for future bugs).
The concept of vertex coordinates is still valid for any continuous Lagrange parameterization of the coordinates. I guess we can ignore other cases at least initially. What kind of access patterns are needed to read and write the coordinates? 15. jun. 2015 23.09 skrev "Chris Richardson" <[email protected]>: > On 15/06/2015 19:54, Garth N. Wells wrote: > >> On 15 June 2015 at 17:34, Chris Richardson <[email protected]> wrote: >> >>> >>> Dear all, >>> >>> I've been looking at: >>> >>> >>> https://bitbucket.org/fenics-project/fenics-developer-tools/wiki/Parameterized_geometries >>> >>> today. >>> >>> It seems like it might be a good idea to rewrite the interface to >>> MeshGeometry in some way. >>> If the geometry is going to be stored as xxxxxxyyyyyyzzzzzz etc instead >>> of >>> xyzxyzxyzxyz etc, >>> or perhaps in some other unspecified way internally, then it makes sense >>> to >>> start deprecating >>> methods such as MeshGeometry::x(std::size_t n), which rely on a specific >>> internal data ordering - and to do it for this release... any opinions? >>> >>> >> I'm all for deprecating public functions that expose/depend on the >> internal storage of data. >> >> I'm not sure the comments on the wiki mean we want xxxxyyyyzzzz >> storage in MeshGeometry, rather it's on how we feed the generated >> code. The xxxxyyyyzzzz storage might not be good for data locality. >> >> > OK, I suppose I'm just trying to think of some answers to the DOLFIN side > of things, > which Martin left open. > > It might be good to remove MeshGeometry::x(n), maybe. > > But the more important question is how to store and access higher order > geometric coordinates... one obvious option is to use the same ordering as > a VectorFunctionSpace - does that make any sense? > What are the other alternatives? > > Chris > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
