coordinateChange.hh File Reference
Go to the source code of this file.
Classes | |
| class | concepts::EdgeCoordinateChange< pdim > |
| Coordinate changes for edge elements. More... | |
| class | concepts::EdgeCoordinateChange< 2 > |
| class | concepts::EdgeCoordinateChange< 3 > |
| Coordinate changes for edge elements in a parent hexahedron. More... | |
| struct | concepts::EdgeCoordinateChange< 2 >::EdgeHash |
| Hash function. More... | |
| class | concepts::QuadCoordinateChange< pdim > |
| Coordinate changes for quadrilateral elements. More... | |
| class | concepts::QuadCoordinateChange< 3 > |
| Coordinate changes for quadrilateral face elements in a parent hexahedron. More... | |
| struct | concepts::QuadCoordinateChange< 3 >::QuadHash |
| Hash function. More... | |
Namespaces | |
| concepts | |
| Basic namespace for Concepts-2. | |
Detailed Description
The purpose of the following templates is to transform a given topological orientation of a particular quadrilateral or edge Connector in a hexahedron Connector to the functor represented in the input parameters of the invertOrientation/inverse-members of the geometric Map2d/Map1d types (if pdim == 3, pdim for dimension of the parent connector) so as to reorient them according to one of the following orientations:
geometric orientation: aligned with coordinate axes of the parent connector (generally the (most convenient) one to compute with) Concepts orientation: aligned with the "standard" orientation defined in the topological types concepts::Hexahedron etc.
Analogously for edge Connectors in quadrilateral parents. Hence in fact, the following types not only implement an isomorphism for different orientation groups used in the topology and geometry types (in the sense that a given topological orientation is mapped to the required transformation for the geometry to realign it according to some convention) but also these isomorphisms vary for every single boundary element of some parent connector. The problem here is that Concepts uses differing groups for boundary entities at different position. This is a costly maintenance problem which should be solved at some point.
Definition in file coordinateChange.hh.