diff --git a/base_classes/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml new file mode 100644 index 0000000000..80de81f407 --- /dev/null +++ b/base_classes/NXcoordinate_system.nxdl.xml @@ -0,0 +1,159 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the third axis which spans the coordinate system. + This axis is frequently referred to as the z-axis in real space and + the k-axis in reciprocal space. + + + + + + + + This specificies the relation to another coordinate system by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe this coordinate system + with respect to another coordinate system. + + + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml deleted file mode 100644 index 38a448a0e1..0000000000 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ /dev/null @@ -1,135 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - - - - - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - - - If all ellipsoids in the set have the same half-axes. - - - - - - - - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index ea8faee3e4..0000000000 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,243 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry description of geometric primitives via a face and edge list. - - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. - - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. - - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. - - - - Dimensionality. - - - - - - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - - - - - - - - Number of edges. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish vertices explicitly. - - - - - - - - Integer used to distinguish edges explicitly. - - - - - - - - Integer used to distinguish faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - The edges are stored as a pairs of vertex identifier values. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. - - - - - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. - - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 96c2d7123c..0000000000 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,239 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). - - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. - - - - - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. - - - - - - - - - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - - - - - - - - - - - - - - Total area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - - - - - - Disentangled representations of the mesh of specific hexahedra. - - - - - - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index ca4a569845..0000000000 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms in Euclidean space. - - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: - - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. - - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. - - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. - - An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. - - - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of an edge within - a specific coordinate system. - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - - - - - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - - - - - - Disentangled representations of the mesh of specific parallelograms. - - - - diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml deleted file mode 100644 index e5c351839c..0000000000 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 1. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points in Euclidean space. - - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish points for explicit indexing. - - - - - - - - The array of point coordinates. - - - - - - - - - The optional array of time for each vertex. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index e90dd652f4..0000000000 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ /dev/null @@ -1,225 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are related are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - - - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polygons for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - - - - - - - - - - - - - - The accumulated length of the polygon edge. - - - - - - - - Array of interior angles. There are many values per polygon as number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index e3a6e99fe4..0000000000 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,194 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a polyhedra in Euclidean space. - - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. - - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. - - - - - Length of each edge of each tetrahedron. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - - - - - - Disentangled representations of the mesh of specific polyhedron. - - - - - - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - - diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml deleted file mode 100644 index e50192cf85..0000000000 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - - - Computational geometry description of a set of spheres in Euclidean space. - - Each sphere can have a different radius. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - - - - In the case that all spheres have the same radius. - - - - - In the case that spheres have different radius use this - instead of the radius field. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index b3e27b0f93..0000000000 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra in Euclidean space. - - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most - frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. - - - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - - - - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - - - - - - Disentangled representations of the mesh of specific tetrahedra. - - - - - - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - - diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 3640f8ff30..0000000000 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,132 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles in Euclidean space. - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish triangles for explicit indexing. - - - - - - - - - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - -