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
