[Dune] vote: what should the codim<3> iterator do in the curvilinear case

[Carsten Gräser]

Hi,

Am 15.01.2015 um 13:33 schrieb Aleksejs Fomins:
> Dear Dune,
> 
> I just realized a slightly puzzling thing:
> 
> In curvilinear geometry, an element has a set of interpolatory
> vertices. For a tetrahedron, there are always 4 corners, plus a bunch
> of internal vertices based on interpolation order of the element.
> 
> Currently, I have implemented it in the grid such that all
> interpolatory vertices are codim<3> entities. This means that
> currently, if one iterates over codim<3> entities, the interpolatory
> vertices will also participate.
then you are violating the dune concept of a grid which essentially
implies that codim<griddim> entities are vertices. The fact that
you need more points to represent you geometries is an implementation
detail and should not change the definition of the interface. I'd also
expect the gridcheck to fail for this.

However,since the user might need this information, you can make it
availabe via an extension of the grid interface (i.e. 3 below).
Note that we decided that such extensions should be done via the
grid itself and not via views, entities, ... In fact the interface
classes for these objects would even hide such extensions.

Best,
Carsten

> 
> Having said that, I personally think it does not make sense. If
> somebody wishes to implement a nodal-based FEM code, they probably
> only care about the corners. I do not see a reason why should a user
> ever care about the non-corner interpolatory vertices, unless he
> directly accesses the Geometry class.
> 
> My proposal:
> 1) All vertices are codim<3> entities
> 2) standard codim<3> iterator will only iterate over corners
> 3) an additional InterpolatoryIterator will be provided which will be
> able to iterate over all codim<3> entities
> 4) DataHandle communication interface will only explicitly be allowed
> to communicate over corners.
> 
> What do people think about this approach
> 
> Best,
> Aleksejs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20150115/9d3af41a/attachment.sig>