diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml new file mode 100644 index 0000000000..124b20ebbc --- /dev/null +++ b/base_classes/NXcg_alpha_complex.nxdl.xml @@ -0,0 +1,101 @@ + + + + + + + Computational geometry of alpha complexes (alpha shapes or alpha wrappings) about primitives. + + For details see: + + * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, + * https://dx.doi.org/10.1145/174462.156635 for 3D, + * https://dl.acm.org/doi/10.5555/871114 for weighted, and + * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation of alpha shapes, and + * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D alpha wrappings + + in CGAL, the Computational Geometry Algorithms Library respectively. + As a starting point, we follow the conventions of the CGAL library. + + In general, an alpha complex is a not necessarily connected or not necessarily pure complex, + i.e. singular faces may exist. The number of cells, faces, and edges depends on how a specific + alpha complex is filtered for lower-dimensional simplices. The fields is_regularized and + regularization can be used to provide details about regularization procedures. + + + + Type of alpha complex following the terminology used by CGAL for now. + + Alpha_shape means meshes created using one of the alpha_shape algorithm. + Alpha_wrapping means meshes created using the alpha_wrapping algorithm. + + + + + + + + + + Human-readable description about regularization procedures. + + + + + Was the alpha complex regularized, i.e. have singular faces been removed, or not. + + + + + The alpha parameter, i.e. the squared radius of the alpha-sphere + that is used when computing the alpha complex. + + + + + The offset distance parameter used when computing alpha_wrappings. + + + + + + Point cloud serving as input for the computation of the alpha complex. + + + + + Triangle soup serving as input for the computation of the alpha complex. + + + + + Triangle mesh representing the output of the computation, i.e. the alpha complex. + + + + + Tetrahedra representing an interior volume of the alpha complex (if such exists). + + + diff --git a/base_classes/NXcg_cylinder.nxdl.xml b/base_classes/NXcg_cylinder.nxdl.xml new file mode 100644 index 0000000000..2459121170 --- /dev/null +++ b/base_classes/NXcg_cylinder.nxdl.xml @@ -0,0 +1,133 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the space in which the members are assumed embedded. + + + + + The cardinality of the set, i.e. the number of members. + + + + + Computational geometry description of a set of cylinders or (truncated) cones. + + The radius can either be defined in the radii field or by filling the upper_cap_radii + and lower_cap_radii fields respectively. The latter field case can + thus be used to represent (truncated) cones. + + It is possible to define only one of the cap_radii fields + to represent half-open cylinder. + + + + A direction vector which is parallel to the cylinder/cone axis + and whose magnitude is the height of the cylinder/cone. + + The upper_cap is assumed to represent the end while the + lower_cap is assumed to represent the start of the + respective cylinder instances when inspecting along the + direction vector. + + + + + + + + + Radius of the cylinder if all have the same radius. + + + + + Radii of the cylinder. + + + + + + + + Radii of the upper circular cap. + + This field, combined with lower_cap_radius can be used to describe + (eventually truncated) circular cones. + + + + + + + + Radii of the upper circular cap. + + This field, combined with upper_cap_radius can be used to describe + (eventually truncated) circular cones. + + + + + + + + + Lateral surface area of each cylinder. + + + + + + + + Area of the upper cap of each cylinder. + + + + + + + + Area of the lower cap of each cylinder. + + + + + + + + Sum of upper and lower cap area and lateral surface area of each cylinder. + + + + + + diff --git a/base_classes/NXcg_ellipsoid.nxdl.xml b/base_classes/NXcg_ellipsoid.nxdl.xml new file mode 100644 index 0000000000..c34a4897e7 --- /dev/null +++ b/base_classes/NXcg_ellipsoid.nxdl.xml @@ -0,0 +1,81 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the space in which the members are assumed embedded. + + + + + The cardinality of the set, i.e. the number of members. + + + + + Computational geometry description of a set of ellipsoids. + + + + Length of the semi-axes (e.g. semi-major and semi-minor + respectively for an ellipse). + + Use if all ellipsoids in the set have the same half-axes. + + + + + + + + Length of the semi-axes if ellipsoids have individually different lengths. + + + + + + + + + + In the case that all ellipsoids are spheres. + + + + + In the case that all ellipsoids are spheres whose radii differ. + For a mixture of spheres use semi_axes_values. + + + + + + + diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 0000000000..5fcfde6822 --- /dev/null +++ b/base_classes/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,227 @@ + + + + + + + + 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. + + + + + Computational geometry of primitives via a face-and-edge-list data structure. + + Primitives must neither be degenerated nor self-intersect but can have different + properties. A face-and-edge-list-based description of primitives is + frequently used for triangles and polyhedra to store them on disk for + visualization purposes (see OFF, PLY, VTK, or STL file formats). + + Although this description is storage efficient, it is not well-suited for + topological analyses. In this case using a half-edge data structure is + an alternative. + + Having an own base class for the data structure how primitives are stored is + useful to embrace both users with small or detailed specification demands. + + Indices can be used as identifier and thus names for individual instances. + + + + + Number of vertices for each face. + + Each entry represents the total number of vertices for that face, + irrespectively whether vertices are shared among faces or not. + + + + + + + + Number of edges for each face. + + Each entry represents the total number of edges for that face, + irrespectively whether edges are shared across faces or not. + + + + + + + + Number of faces of the primitives. + + + + + Integer offset whereby the identifier of the first member + of the vertices differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive for further details. + + + + + Integer offset whereby the identifier of the first member + of the edges differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive for further details. + + + + + Integer offset whereby the identifier of the first member + of the faces differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive for further details. + + + + + Integer identifier to distinguish all vertices explicitly. + + + + + + + + Integer used to distinguish all edges explicitly. + + + + + + + + Integer used to distinguish all faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to a unique set as this may + result in more efficient storage. Alternatively, storing vertex positions naively + should be indicated with setting vertices_are_unique to False. + Naively means that each vertex is stored even though many vertices may + share the same positions. + + + + + + + + + The edges are stored as pairs of vertex identifier. + + + + + + + + + The faces are stored as a concatenated array of vertex identifier tuples. + + 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: :math:`[\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 more + than once. + + + + + If true, indicates that no edge is stored more than once. + + Users are encouraged to consider using a half_edge_data_structure instead. + + + + + If true, indicates that no face is stored more than once. + + + + + 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_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml similarity index 59% rename from contributed_definitions/NXcg_grid.nxdl.xml rename to base_classes/NXcg_grid.nxdl.xml index f3cbc28539..07abb1001a 100644 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ b/base_classes/NXcg_grid.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,36 +33,36 @@ - The cardinality or total number of cells/grid points. + The cardinality or total number of cells aka grid points. - Number of boundaries of the bounding box or primitive to the grid. + Number of boundaries of the bounding box or primitive housing the grid. - Computational geometry description of a Wigner-Seitz cell grid in Euclidean space. + Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. - Frequently convenient three-dimensional grids with cubic cells are used. - Exemplar applications are spectral-solver based crystal plasticity - and stencil methods like phase-field or cellular automata. + Three-dimensional grids with cubic cells are if not the most frequently used + example of such grids. Numerical methods and models that use grids are used + in many cases in the natural sciences and engineering disciplines. Examples are + discretizations in space and time used for phase-field, cellular automata, or Monte Carlo + modeling. - - - - - - - - - + + + Location of the origin of the grid. + + Use the depends_on field that is inherited from the :ref:`NXcg_primitive` + class to specify the coordinate system in which the origin location is defined. + - + The symmetry of the lattice defining the shape of the unit cell. @@ -78,49 +78,23 @@ - + Number of unit cells along each of the d unit vectors. - The total number of cells, or grid points has to be the cardinality. + + The total number of cells or grid points has to be the cardinality. If the grid has an irregular number of grid positions in each direction, as it could be for instance the case of a grid where all grid points outside some masking primitive are removed, this extent field should - not be used. Instead use the coordinate field. + not be used. Instead, use the coordinate field. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cells. 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 cells for explicit indexing. - - - - - - + Position of each cell in Euclidean space. @@ -139,26 +113,27 @@ should constraints on the grid be place here or not--> - + - A tight bounding box or sphere or bounding primitive about the grid. + A tight bounding box about the grid. - - + - How many distinct boundaries are distinguished? + Number of boundaries distinguished + Most grids discretize a cubic or cuboidal region. In this case six sides can be distinguished, each making an own boundary. - + - Name of domain boundaries of the simulation box/ROI e.g. left, right, - front, back, bottom, top. + Name of domain boundaries of the simulation box/ROI + e.g. left, right, front, back, bottom, top. - @@ -178,4 +153,25 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele + + + Details about the computational geometry method and implementation + used for discretizing internal surfaces as e.g. obtained with marching methods, + like marching squares or marching cubes. + + Documenting which specific version was used helps with understanding how + robust the results are with respect to the topology of the triangulation. + Reference to the specific implementation of marching cubes used. + + See for example the following papers for details about how to identify a + DOI which specifies the implementation used: + + * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ + * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ + + The value placed here should ideally be an identifier of a program. + If not possible, an identifier for a paper, technical report, or free-text + description can be used instead. + + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml new file mode 100644 index 0000000000..91eb74bc44 --- /dev/null +++ b/base_classes/NXcg_half_edge_data_structure.nxdl.xml @@ -0,0 +1,195 @@ + + + + + + + + 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 faces. + + + + + The number of half-edges. + + + + + Computational geometry description of a half-edge data structure. + + Such a data structure can be used to efficiently circulate around faces + and iterate over vertices of a planar graph. The data structure is also + known as a doubly connected edge list. + + Indices can be used as identifier and thus names for individual instances. + + + + Dimensionality of the primitives described. + + + + + + Number of vertices for each face. + + Each entry represents the total number of vertices for that face, + irrespectively whether vertices are shared among faces or not. + + + + + + + + Number of edges for each face. + + Each entry represents the total number of edges for that face, + irrespectively whether edges are shared across faces or not. + + + + + + + + Integer offset whereby the identifier of the first member + of the vertices differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive` for further details. + + + + + Integer offset whereby the identifier of the first member + of the edges differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive` for further details. + + + + + Integer offset whereby the identifier of the first member + of the faces differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive` for further details. + + + + + + The position of the vertices. + + + + + + + + + Identifier of the incident half-edge. + + + + + + + + Identifier of the (starting)/associated half-edge of the face. + + + + + + + + The identifier of the vertex from which this half-edge is outwards pointing. + + + + + + + + Identifier of the associated oppositely pointing half-edge. + + + + + + + + If the half-edge is a boundary half-edge the + incident face identifier is NULL, i.e. 0. + + + + + + + + Identifier of the next half-edge. + + + + + + + + Identifier of the previous half-edge. + + + + + + + + Users are referred to the literature for the background of L. Weinberg's + work about topological characterization of planar graphs: + + * `L. Weinberg 1966a, <https://dx.doi.org/10.1109/TCT.1964.1082216>`_ + * `L. Weinberg, 1966b, <https://dx.doi.org/10.1137/0114062>`_ + * `E. A. Lazar et al. <https://doi.org/10.1103/PhysRevLett.109.095505>`_ + + and how this work can e.g. be applied in space-filling tessellations + of microstructural objects like crystals/grains. + + + diff --git a/base_classes/NXcg_hexahedron.nxdl.xml b/base_classes/NXcg_hexahedron.nxdl.xml new file mode 100644 index 0000000000..2684550116 --- /dev/null +++ b/base_classes/NXcg_hexahedron.nxdl.xml @@ -0,0 +1,191 @@ + + + + + + + + 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. + + 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 an approach whereby + different specific views can be implemented using the same base class: + + * In the simplest case experimentalists may use this base class to describe + the dimensions or size of a specimen. In this case the alignment with axes + is not relevant as eventually only the volume of the specimen is of interest. + * In many cases, take for example an experiment where a specimen was cut out + from a specifically deformed piece of material, the orientation of the + specimen's edges with the experiment coordinate system is of high relevance. + Examples include knowledge about the specimen edge, whether it is + parallel to the rolling, the transverse, or the normal direction. + * While the above-mentioned use cases are sufficient to pinpoint the sample + within a known laboratory/experiment coordinate system, these descriptions + are not detailed enough to specify e.g. a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of hexahedra is offered to serve additional 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. + + As a specialization of the :ref:`NXcg_primitive` base class hexahedra + are assumed non-degenerated, closed, and built of polygons that are + not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the special cases cuboid, cube, box, axis-aligned bounding box (AABB), + and optimal bounding box (OBB). + + An axis-aligned bounding box is a common data object in computational science + and simulation codes to represent a cuboid whose edges are aligned with the + base vectors of a coordinate system. As a part of binary trees, these data + objects are important for making 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 + tightly fitting box about an arbitrary object. In general, such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist to compute optimal or near optimal bounding boxes for sets of points. + + + + + Qualifier for the shape of each hexahedron. + + + + + + + + + Qualifier that is useful in cases when one edge is longer than all other + edges of the hexahedra. Often the term length is associated with the + assumption that one edge is parallel to an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the extent of an object in the horizontal + direction assuming a specific coordinate system. + + For the sake of explicitness quantities like length, width, and height + should not be reported without specifying also the assumed reference frame. + + + + + + + + Qualifier often used to describe the extent of an object in the vertical + direction assuming a specific coordinate system. + + + + + + + + Volume of each hexahedron. + + + + + + + + Total (surface) 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 coordinate system. + + + + + + + + + + + + Combined storage of all primitives of all hexahedra. + + + + + Individual storage of each hexahedron. + + + + + Individual storage of each hexahedron as a graph. + + + diff --git a/base_classes/NXcg_parallelogram.nxdl.xml b/base_classes/NXcg_parallelogram.nxdl.xml new file mode 100644 index 0000000000..f54790ce5f --- /dev/null +++ b/base_classes/NXcg_parallelogram.nxdl.xml @@ -0,0 +1,101 @@ + + + + + + + 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. + + This class can also be used to describe rectangles or squares, irrespective + whether these are axis-aligned or not. The class represents different + access and description levels to embrace applied scientists and computational + geometry experts with their different views: + + * The simplest case is the communication of dimensions aka the size of a + region of interest in the 2D plane. In this case, communicating the + alignment with axes is maybe not as relevant as it is to report the area + of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally, in CAD models it should be possible to specify the polygons + which the parallelograms represent with exact numerical details. + + Parallelograms are important geometrical primitives as their usage for + describing many scanning experiments shows where typically parallelogram-shaped + ROIs are scanned across the surface of a sample. + + The term parallelogram will be used throughout this base class thus including + the important special cases rectangle, square, 2D box, axis-aligned bounding box + (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D + counterparts. See :ref:`NXcg_hexahedron` for the generalization in 3D. + + An axis-aligned bounding box is a common data object in computational science + and simulation codes to represent a rectangle whose edges are aligned with the + axes of a coordinate system. As a part of binary trees AABBs are important data + objects for executing 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, i.e. + most tightly 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 an optimal bounding box to a point set in 2D. + + + + + To specify which parallelogram is a rectangle. + + + + + + + + Only to be used if is_rectangle is present. In this case, this field + describes whether parallelograms are rectangles whose primary edges + are parallel to the axes of the coordinate system. + + + + + + + + + Combined storage of all parallelograms. + + + + + Individual storage of each parallelogram. + + + diff --git a/base_classes/NXcg_point.nxdl.xml b/base_classes/NXcg_point.nxdl.xml new file mode 100644 index 0000000000..169abbe893 --- /dev/null +++ b/base_classes/NXcg_point.nxdl.xml @@ -0,0 +1,87 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points. + + Points may have an associated time value. Users are advised though to store + time data of point sets rather as instances of time events, where for each + point in time there is an :ref:`NXcg_point` 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 (real time or + simulated physical time). Thereby, the storage of redundant timestamp + information per point is considered as obsolete. + + + + Coordinates of the points. + + + + + + + + + (Elapsed) time for each point. + + If the field time is needed contextualize the time_offset relative to which + time values are defined. Alternative store timestamp. + + + + + + + + ISO8601 with local time zone offset for each point. + + + + + + + + ISO8601 with local time zone offset that serves as the reference + for values in the field time. + + + diff --git a/base_classes/NXcg_polygon.nxdl.xml b/base_classes/NXcg_polygon.nxdl.xml new file mode 100644 index 0000000000..d20f4aed81 --- /dev/null +++ b/base_classes/NXcg_polygon.nxdl.xml @@ -0,0 +1,126 @@ + + + + + + + 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 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 :ref:`NXcg_polyhedron` base class if they wish to describe closed + polyhedra. Even more general complexes can be thought of. An example are the + so-called piecewise-linear complexes used in the TetGen library. + + As these complexes can have holes though, polyhedra without holes are one + subclass of such complexes, users should rather design their own base class + e.g. NXcg_polytope to describe such even more complex primitives instead + of abusing this base class for such purposes. + + + + The total number of vertices in the set. + + + + + + Combined storage of all primitives of all polygons. + + + + + Individual storage of the mesh of each polygon. + + + + + Individual storage of each polygon as a graph. + + + + + + For each polygon its accumulated length along its edges. + + + + + + + + Interior angles for each polygon. There are as many values per polygon + as there are 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 + + + + + + diff --git a/base_classes/NXcg_polyhedron.nxdl.xml b/base_classes/NXcg_polyhedron.nxdl.xml new file mode 100644 index 0000000000..5e72d6070f --- /dev/null +++ b/base_classes/NXcg_polyhedron.nxdl.xml @@ -0,0 +1,104 @@ + + + + + + + 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 set of polyhedra in Euclidean space. + + Polyhedra or so-called cells (especially in the convex of tessellations) are + constructed from polygon meshes. Polyhedra may make contact to allow a usage + of this base class for a description of tessellations. + + For the description of more complicated manifolds and especially for polyhedra + with holes, users are advised to check if their particular needs are described + by creating customized instances of an :ref:`NXcg_polygon`. + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. + + + + + + + + Area of each of faces. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counted for each polyhedron. + + + + + Length of each edge. + + + + + + + + + Combined storage of all primitives of all polyhedra. + + + + + Individual storage of each polyhedron. + + + + + Individual storage of each polygon as a graph. + + + diff --git a/base_classes/NXcg_polyline.nxdl.xml b/base_classes/NXcg_polyline.nxdl.xml new file mode 100644 index 0000000000..f5e247c756 --- /dev/null +++ b/base_classes/NXcg_polyline.nxdl.xml @@ -0,0 +1,140 @@ + + + + + + + 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 polylines. + + + + + + The number of vertices, supporting the polylines. + + + + + The total number of vertices traversed when visiting every polyline. + + + + + Computational geometry description of a set of polylines. + + Each polyline is built from a sequence of vertices (points with identifiers). + Each polyline must have a start and an end point. + The sequence describes the traversal along the polyline when + walking from the first to the last vertex. + + + + Reference to an instance of :ref:`NXcg_point` which defines the + location of the vertices that are referred to in this + NXcg_polyline instance. + + + + + The total number of vertices that have different positions. + + + + + The total number of vertices, irrespective of their eventual uniqueness. + + + + + The total number of vertices of each polyline, irrespectively + whether vertices are shared by vertices or not. + + + + + + + + + Positions of the vertices which support the members of the polyline set. + + Users are encouraged to reduce the vertices to unique positions and vertices + as this often supports with storing geometry data more efficiently. + 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 stores each vertex of a triangle mesh + even though many vertices are shared between triangles and thus + storing multiple copies of their positions is redundant. + + + + + + + + + If true indicates that the vertices are all placed at different + positions and have different identifiers, i.e. no points overlap + or are counted several times. + + + + + Sequence of identifier for vertices how they build each polyline. + + A trivial example is a set with two polylines with three vertices each. + If the polylines meet at a vertex (assume for example that the second vertex + is shared and marking the junction between the two polylines), it is possible + that there are only five unique positions. This suggests to store five + unique vertices. + + A non-trivial example is a set with several polylines. Assume that each + has a different number of vertices. The array stores the identifier of + the vertices in the sequence how the polylines are visited: + + The first entry is the identifier of the first vertex of the first polyline, + followed by the second vertex of the first polyline, until the last vertex + of the first polyline. + Thereafter, the first vertex of the second polyline, and so on and so forth. + Using the (cumulated) counts in number_of_vertices (:math:`n^v_i`), + the vertices of the N-th polyline can be accessed on the array + index interval :math:`[\sum_{i=0}^{i=N-1} n^v_i, \sum_{i=0}^{i=N} n^v_i]`. + + + + + + diff --git a/base_classes/NXcg_primitive.nxdl.xml b/base_classes/NXcg_primitive.nxdl.xml new file mode 100644 index 0000000000..eb5b01f402 --- /dev/null +++ b/base_classes/NXcg_primitive.nxdl.xml @@ -0,0 +1,247 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the embedding space. + + + + + The cardinality of the set, i.e. the number of members. + + + + + Computational geometry description of a set of primitives in Euclidean space. + + Primitives must neither be degenerated nor self-intersect. + Individual primitives can differ in their properties (e.g. size, shape, rotation). + + + + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives + are defined. + + + + + The dimensionality of the primitive set with value up to d. + + + + + + + + + + + The cardinality of the primitive set. Value should be equal to c. + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + Indices can be used as identifiers and thus names of instances. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[index\_offset, index\_offset + c - 1]`. + + Therefore, implicit identifier are completely defined by the value of + index_offset and cardinality. For example if identifier run from + -2 to 3 the value for index_offset is -2. + + For explicit indexing the field identifier has to be used. + Fortran-/Matlab- and C-/Python-style indexing have specific implicit + identifier conventions where index_offset is 1 and 0 respectively. + + + + + Identifier of each member for explicit indexing. + + + + + + + + The center of each primitive + + + + + + + + + True if the center is a center of mass. + + + + + + + + Shape of each primitive + + + + + + + + + Length of each primitive + + Often the term is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + + + + + + + + Width of each primitive + + Often the term is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + + + + + + + + Height of each primitive + + Often the term is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + + + + + + + + True if primitive is closed such that it has properties like area or volume. + + + + + + + + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + Volume is an N-D concept for values of dimensionality larger than 1, + Area is an alias for the two-dimensional case. + + + + + + + + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + + + + + + + + Direction unit vector which points along the + longest principal axis of each primitive. + + Use the depends_on attribute to specify in which coordinate system + these direction unit vectors are defined. + + + + + + + + + Do the primitives define a mesh. + + + + + Do the primitives define a triangle mesh or not. + + + + + Do the primitives discretize the surface of an object or not. + + + + + Do the primitives define a geodesic mesh or not. + + A geodesic surface mesh is a triangulated surface mesh with metadata which + can be used as an approximation to describe the surface of a sphere. + Triangulation of spheres are commonly used in Materials Science + for quantifying texture of materials, i.e. the relative rotation of + crystals to sample directions. + + For additional details or an introduction into the topic of geodesic meshes + see (from which specifically the section on subdivision schemes is relevant). + + * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ + + Earth scientists have specific demands and different views about what should + be included in such a base class, given that nested geodesic meshes are a key + component of climate modelling software. For now we propose to use this + base class as a container for organizing data related to geodesic meshes. + + Specifically an instance of this base class should detail the rule set how + e.g. a geodesic (surface) mesh was instantiated as there are many + possibilities to do so. + + + + + Possibility to store details such as when primitives form a (specific) type + of mesh such as geodesic meshes. + + + + + + diff --git a/contributed_definitions/NXcg_roi_set.nxdl.xml b/base_classes/NXcg_roi.nxdl.xml similarity index 50% rename from contributed_definitions/NXcg_roi_set.nxdl.xml rename to base_classes/NXcg_roi.nxdl.xml index ab2b677754..329c767c4a 100644 --- a/contributed_definitions/NXcg_roi_set.nxdl.xml +++ b/base_classes/NXcg_roi.nxdl.xml @@ -2,9 +2,9 @@ - - + + - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. + Use :ref:`NXcg_primitive` and :ref:`NXcoordinate_system` classes to + define explicitly the reference frame in which the primitives are + defined. - Base class to hold geometric primitives. + Base class for a region-of-interest (ROI) bound by geometric primitives. + + So-called region-of-interest(s) (ROIs) are typically used to describe a + region in space (and time) where an observation is made or for which + a computer simulation is performed with given boundary conditions. - - - - - + + + + + + diff --git a/base_classes/NXcg_tetrahedron.nxdl.xml b/base_classes/NXcg_tetrahedron.nxdl.xml new file mode 100644 index 0000000000..95bf4e02dc --- /dev/null +++ b/base_classes/NXcg_tetrahedron.nxdl.xml @@ -0,0 +1,76 @@ + + + + + + + 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. + + Among hexahedral elements, tetrahedral elements are one of the most + frequently used geometric primitive for meshing and describing volumetric + objects in continuum-field simulations. + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Combined storage of all primitives of all tetrahedra. + + + + + Individual storage of each tetrahedron. + + + + + Individual storage of each tetrahedron as a graph. + + + diff --git a/base_classes/NXcg_triangle.nxdl.xml b/base_classes/NXcg_triangle.nxdl.xml new file mode 100644 index 0000000000..d6c91451b9 --- /dev/null +++ b/base_classes/NXcg_triangle.nxdl.xml @@ -0,0 +1,92 @@ + + + + + + + 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. + + + + Number of unique vertices in the triangle set. + + + + + Combined storage of all primitives of all triangles. + + This description resembles the typical representation of primitives + in file formats such as OFF, PLY, VTK, or STL. + + + + + Individual storage of each triangle. + Users are advised that using such individual storage of primitives + may be less storage efficient than creating a combined storage. + + + + + Length of the edges of each triangle. + + For each triangle values are reported via traversing + the vertices in the sequence as these are defined. + + + + + + + + + Interior angles of each triangle. + + For each triangle values are reported for the angle opposite + to the respective edges in the sequence how vertices are defined. + + + + + + + diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal.nxdl.xml similarity index 68% rename from contributed_definitions/NXcg_unit_normal_set.nxdl.xml rename to base_classes/NXcg_unit_normal.nxdl.xml index 68f9c847e2..5eaacd9e75 100644 --- a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml +++ b/base_classes/NXcg_unit_normal.nxdl.xml @@ -2,9 +2,9 @@ - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -42,12 +44,14 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Computational geometry description of a set of (oriented) unit normal vectors. + + Store normal vector information as properties of primitives. + Use only only as a child of an instance of :ref:`NXcg_primitive` + so that this instance acts as the parent to define a context. - - - + - Direction of each normal + Direction of each normal - a unit normal. @@ -56,12 +60,13 @@ rather make this a set of vectors, irrespective whether these are unit or not--> - Qualifier how which specifically oriented normal to its primitive each - normal represents. + An indicator which details the orientation of each normal vector + in relation to its primitive, assuming the object is viewed + from a position outside the object. * 0 - undefined - * 1 - outer - * 2 - inner + * 1 - outer unit normal vector + * 2 - inner unit normal vector diff --git a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml index 4f13739236..b740203e4f 100644 --- a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml @@ -230,7 +230,7 @@ mapping_dictionary_value(NX_UINT): - + @@ -238,7 +238,7 @@ mapping_dictionary_value(NX_UINT): - + @@ -246,7 +246,7 @@ mapping_dictionary_value(NX_UINT): - + diff --git a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml index 4a24598fe1..14db557bd6 100644 --- a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml @@ -104,7 +104,7 @@ - + @@ -112,7 +112,7 @@ - + @@ -120,7 +120,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml index ab98e2e98b..340c30e093 100644 --- a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml @@ -129,7 +129,7 @@ - + @@ -137,7 +137,7 @@ - + @@ -145,7 +145,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml index f832bf02b7..7fd4937625 100644 --- a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml @@ -118,7 +118,7 @@ unless it is explicitly specified differently--> - + @@ -126,7 +126,7 @@ unless it is explicitly specified differently--> - + @@ -134,7 +134,7 @@ unless it is explicitly specified differently--> - + diff --git a/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml index 1293fb98d6..cdaa32bb64 100644 --- a/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml @@ -107,19 +107,19 @@ unless it is explicitly specified differently--> - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml index d886dc0da8..81c175e434 100644 --- a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml @@ -123,7 +123,7 @@ unless it is explicitly specified differently--> - + @@ -131,7 +131,7 @@ unless it is explicitly specified differently--> - + @@ -139,7 +139,7 @@ unless it is explicitly specified differently--> - + diff --git a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml index 5f30cc0f2f..8427d9bb1a 100644 --- a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml @@ -117,7 +117,7 @@ unless it is explicitly specified differently--> - + @@ -125,7 +125,7 @@ unless it is explicitly specified differently--> - + @@ -133,7 +133,7 @@ unless it is explicitly specified differently--> - + diff --git a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml index ca0798c3a8..e963465431 100644 --- a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml @@ -107,7 +107,7 @@ unless it is explicitly specified differently--> - + @@ -115,7 +115,7 @@ unless it is explicitly specified differently--> - + @@ -123,7 +123,7 @@ unless it is explicitly specified differently--> - + diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml index aae16541ee..ea636969ae 100644 --- a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -444,7 +444,7 @@ if weighting_model == isotopic_decomposition needs isotopic_decomposition_rule-- For explicit indexing the identifier array has to be defined. - + A tight axis-aligned bounding box about the grid. @@ -766,7 +766,7 @@ for XDMF in ParaView ?--> The threshold or iso-contour value. - + Details about the specific marching cubes algorithm which was taken to compute the iso-surface. @@ -782,7 +782,7 @@ for XDMF in ParaView ?--> - + The resulting triangle soup computed via marching cubes. @@ -868,7 +868,7 @@ for XDMF in ParaView ?--> - + Direction of each normal. @@ -892,9 +892,9 @@ for XDMF in ParaView ?--> - - + Direction of each normal. @@ -1084,7 +1084,7 @@ details about specific features--> - + An oriented bounding box (OBB) to each object. @@ -1188,7 +1188,7 @@ details about specific features--> - + - + @@ -1276,7 +1276,7 @@ face_identifier_offset(NX_UINT):--> - + - + @@ -1388,7 +1388,7 @@ isotope_vector(NX_UINT):--> - + - + @@ -1475,7 +1475,7 @@ isotope_vector(NX_UINT):--> - + - + @@ -1568,7 +1568,7 @@ face_identifier_offset(NX_UINT):--> - + The triangle surface mesh representing the interface model. Exported at some iteration before the next DCOM step. @@ -1606,8 +1606,8 @@ face_identifier_offset(NX_UINT):--> - - + + @@ -1633,7 +1633,7 @@ face_identifier_offset(NX_UINT):--> - + @@ -1687,7 +1687,7 @@ face_identifier_offset(NX_UINT):--> - + The triangle surface mesh representing the interface model. Exported at some iteration after the next DCOM step. @@ -1724,8 +1724,8 @@ face_identifier_offset(NX_UINT):--> - - + + @@ -1751,7 +1751,7 @@ face_identifier_offset(NX_UINT):--> - + @@ -1807,7 +1807,7 @@ face_identifier_offset(NX_UINT):--> - + The ROIs are defined as cylinders for the computations. To visualize these though we discretize them into regular n-gons. diff --git a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml index dbb0bb4e44..5c5220f2a8 100644 --- a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml @@ -302,7 +302,7 @@ for eventually performed preprocessing--> - + The set of triangles in the coordinate system paraprobe which discretizes the exterior surface of the alpha complex. @@ -365,7 +365,7 @@ for eventually performed preprocessing--> - + The set of tetrahedra which represent the interior volume of the complex if that is a closed 2-manifold. diff --git a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml index 4d8eb2476e..c6081efe77 100644 --- a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml @@ -481,7 +481,7 @@ unless it is explicitly specified differently--> - + diff --git a/contributed_definitions/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/NXcg_alpha_complex.nxdl.xml deleted file mode 100644 index 1b3e3446e6..0000000000 --- a/contributed_definitions/NXcg_alpha_complex.nxdl.xml +++ /dev/null @@ -1,151 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the alpha shape, for now 2 or 3. - - - - - - The number of edges. - - - - - The number of faces. - - - - - The number of cells. - - - - - Computational geometry description of alpha shapes or wrappings to primitives. - - For details see: - - * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, - * https://dx.doi.org/10.1145/174462.156635 for 3D, - * https://dl.acm.org/doi/10.5555/871114 for weighted, and - * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap - - in CGAL, the Computational Geometry Algorithms Library. - As a starting point, we follow the conventions of the CGAL library. - - - - - - - - - - Specify which general type of alpha shape is computed. - Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. - Alpha_wrapping means meshes created using alpha wrapping procedures. - - - - - - - - - - Specifically when computed with the CGAL, the mode specifies if singular - faces are removed (regularized) of the alpha complex. - - - - - - - - - - The alpha, (radius of the alpha-sphere) parameter to be used for alpha - shapes and alpha wrappings. - - - - - The offset distance parameter to be used in addition to alpha - in the case of alpha_wrapping. - - - - - - Point cloud for which the alpha shape or wrapping should be computed. - - - - - - Triangle soup for which the alpha wrapping should be computed. - - - - - A meshed representation of the resulting shape. - - - - - - diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml deleted file mode 100644 index e5e5e88601..0000000000 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ /dev/null @@ -1,165 +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 cylinders or cones. - - - - - Computational geometry description of a set of cylinders in Euclidean space. - - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. - - - - - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. 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 members for explicit indexing. - - - - - - - - The geometric center of each member. - - - - - - - - - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. - - - - - - - - - - - - - - - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - - - - - - - - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Interior volume of each cylinder - - - - - - - - Lateral surface area - - - - - - - - Area of the upper and the lower cap of each cylinder respectively. - - - - - - - - - Cap and lateral surface area for each cylinder. - - - - - - - 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_geodesic_mesh.nxdl.xml b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml deleted file mode 100644 index 1b69e9bc4f..0000000000 --- a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computational geometry description of a geodesic mesh. - - People from geodesic/surveyors will likely have specific demands and - different views about what should be included in such a base class, given - that nested geodesic meshes are a key component of climate modelling tools. - For now we propose to use this base class as a container to organize metadata - and data related to geodesic meshes. - - Specifically an instance of this base class should detail the rule set how - how the geodesic (surface) mesh was instantiated as there are many - possibilities. A geodesic surface mesh is in this sense a triangulated - surface mesh with metadata. For additional details as an introduction - into the topic see e.g.: - - * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ - - Here, especially the section on subdivision schemes is relevant. - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml deleted file mode 100644 index 81c66fb2bf..0000000000 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ /dev/null @@ -1,174 +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 faces. - - - - - The number of half-edges. - - - - - Computational geeometry description of a half-edge data structure. - - Such a data structure can be used to efficiently circulate around faces - and iterate over vertices of a planar graph. - - - - - - - - In this half-edge data structure vertex identifiers start at 1. - Vertices are identified with consecutive integers up to number_of_vertices. - This field can be used to document which constant integer has to be - added to another set of vertex_identifier to assure that these other - identifiers also start at 1. - - - - - In this half-edge data structure face identifiers start at 1. - Faces are identified with consecutive integers up to number_of_faces. - This field can be used to document which constant integer has to be - added to another set of face_identifier to assure that these other - identifiers also start at 1. - - The face identifier zero is reserved for the NULL face ! - - - - - In this half-edge data structure half-edge identifiers start at 1. - Half-edges are identified with consecutive integers up to number_of_half_edges. - This field can be used to document which constant integer has to be - added to another set of half_edge_identifier to assure that these other - identifiers also start at 1. - - - - - - The position of the vertices. - - - - - - - - - Identifier of the incident half-edge. - - - - - - - - Identifier of the (starting)/associated half-edge of the face. - - - - - - - - The identifier of the vertex from which this half-edge is outwards pointing. - - - - - - - - Identifier of the associated oppositely pointing half-edge. - - - - - - - - If the half-edge is a boundary half-edge the - incident face identifier is NULL, i.e. 0. - - - - - - - - Identifier of the next half-edge. - - - - - - - - Identifier of the previous half-edge. - - - - - - - - Users are referred to the literature for the background of L. Weinberg's - work about topological characterization of planar graphs: - - * `L. Weinberg 1966a, <https://dx.doi.org/10.1109/TCT.1964.1082216>`_ - * `L. Weinberg, 1966b, <https://dx.doi.org/10.1137/0114062>`_ - * `E. A. Lazar et al. <https://doi.org/10.1103/PhysRevLett.109.095505>`_ - - and how this work can e.g. be applied in space-filling tessellations - of microstructural objects like crystals/grains. - - - - 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_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml deleted file mode 100644 index b1f8e92738..0000000000 --- a/contributed_definitions/NXcg_marching_cubes.nxdl.xml +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computational geometry description of the marching cubes algorithm. - - Documenting which specific version was used can help to understand how robust - the results are with respect to the topology of the triangulation. - - - - Reference/link to and/or details of the grid on which a specific - marching cubes algorithm implementation is operating. - - - - - Reference to the specific implementation of marching cubes used. - - See for example the following papers for details about how to identify a - DOI which specifies the implementation used: - - * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ - * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ - - The value placed here should be a DOI. If there are no specific DOI or - details write not_further_specified, or give at least a free-text - description. - - - - - Commercial or otherwise given name to the program which was used. - - - - Program version plus build number, commit hash, or description of - an ever persistent resource where the source code of the program - and build instructions can be found so that the program can be - configured in such a manner that the result file is ideally - recreatable yielding the same results. - - - - - 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_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml deleted file mode 100644 index b64c3467d6..0000000000 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ /dev/null @@ -1,183 +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 polylines. - - - - - - The number of vertices, supporting the polylines. - - - - - The total number of vertices traversed when visiting every polyline. - - - - - Computational geometry description of a set of polylines in Euclidean space. - - Each polyline is built from a sequence of vertices (points with identifiers). - Each polyline must have a start and an end point. - The sequence describes the positive traversal along the polyline when walking - from the start vertex to the end/last vertex. - - - - - - - The total number of vertices, irrespective of their eventual uniqueness, - i.e. the total number of vertices that have to be visited when walking - along each polyline. - - - - - Array which specifies of how many vertices each polyline is built. - The number of vertices represent the total number of vertices for - each polyline, irrespectively whether vertices are shared or not. - See the docstring for polylines for further details about how - a set with different polyline members should be stored. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and polyline data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - polylines. 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 polylines for explicit indexing. - - - - - - - - - Positions of the vertices which support the members of the polyline set. - - 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. - - - - - - - - - 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. - - - - - Sequence of vertex identifiers which describe each polyline. - - A trivial example is a set with two polylines with three vertices each. - If the polylines meet in a junction, say the second vertex is shared - and marking the junction between the two polylines, it is possible that - there are only five unique positions suggesting five unique vertices. - - A non-trivial example is a set with several polylines, each of which with - eventually different number of vertices. The array stores the vertex - identifiers in the order how the polylines are visited: - - The first entry is the identifier of the start vertex of the first polyline, - followed by the second vertex of the first polyline, until the last vertex - of the polyline. Thereafter, the start vertex of the second polyline, and - so on and so forth. Using the (cumulated) counts in number_of_vertices, - the vertices of the n-th polyline can be accessed on the following - array index interval: - :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - - - - - - - - - The length of each polyline. - - - - - - - - If true specifies that a polyline is closed, i.e. - its end point is connected to the start point. - - - - - - - - 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. - - - diff --git a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml deleted file mode 100644 index 51ec02bfd1..0000000000 --- a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computational geometry description of a mesh of triangles. - - The mesh may be self-intersecting and have holes but the - triangles must not be degenerated. - - - - - - A graph-based approach to describe the mesh when it is also desired - to perform topological processing or analyses on the mesh. - - - diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index aa3dd46be3..6654812eca 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -386,7 +386,7 @@ in every case data are Kikuchi diffraction pattern and their metadata--> - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 75a010f88c..b62e2f5dca 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -276,7 +276,7 @@ preparation_date(NX_DATE_TIME): - + - - - + + + A boundary to the volume element. - Either an instance of NXcg_hexahedron_set or of NXcg_ellipsoid_set. + Either an instance of NXcg_hexahedron or of NXcg_ellipsoid. +https://docs.lammps.org/Howto_triclinic.html NXcg_hexahedron because can be a parallelepiped--> How many distinct boundaries are distinguished. Value required equal to n_b. @@ -380,8 +380,8 @@ snapshots--> - - + + to locate zero-dimensional/point-(like) features which are discretized/represented by points. - + Assumptions, parameters, and details how positional uncertainty @@ -205,8 +205,8 @@ but here NXms_feature_set instances--> to locate one-dimensional/line-like features which are discretized by polylines. - - + + Assumptions, parameters, and details how positional uncertainty @@ -220,8 +220,8 @@ but here NXms_feature_set instances--> to locate two-dimensional/interface features which are discretized by triangulated surface meshes. - - + + Assumptions, parameters, and details how positional uncertainty @@ -235,8 +235,8 @@ but here NXms_feature_set instances--> to locate three-dimensional/volumetric features which are discretized by triangulated surface meshes of polyhedra. - - + + Assumptions, parameters, and details how positional uncertainty diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 0e957612e5..a05e0fdab3 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -311,14 +311,14 @@ preparation_date(NX_DATE_TIME): - + The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, - NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs + NXcg_polyhedron, or NXcg_point. This geometry group needs to contain details about the boundary conditions. @@ -330,7 +330,7 @@ for is a matter of interpretation (fundamentally this is an assumption) and can - + A tight bounding box or sphere or bounding primitive about the grid. diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index 25e5ae820a..d036d84574 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -78,8 +78,8 @@ - - - + + + diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst index 6190f0a30d..323d356494 100644 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -5,96 +5,12 @@ Geometry & Microstructure ========================= .. index:: - IntroductionCgms - PhysicsCgms - CgmsAppDef CgmsBC - IcmeMsModels - - -.. _IntroductionCgms: - -Introduction -############ - -The computational-geometry/microstructure-modeling-based part of the proposal -has the following aims: - -First, we would like to contribute to efforts on standardizing a controlled -vocabulary, definitions for these terms, and relations between the terms, for -computational-geometry-based descriptions of the structure of materials and -atomic configurations used when characterizing materials in experiments -and computer simulations. - -As far as NeXus is concerned, this proposed set of simple geometric primitives -and shapes offer a complementary alternative to the current set of base classes in -NeXus for constructive solid geometry such as :ref:`NXcsg`, :ref:`NXoff_geometry`, -or :ref:`NXquadric` to name but a few. - -Second, we would like to explore with this proposal how we can harmonize terms -frequently used by materials scientists in the field of condensed-matter physics -with definitions and terms offer by the NOMAD MetaInfo description. - -Third, the proposal should yield a substantiated set of arguments and suggestions -how descriptors for the structure and atomic architecture of materials can be -harmonized. With this we especially would like to reach out and intensify the -cooperation between the materials-science-related consortia of the German -National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, -NFDI4Chem, NFDI4Cat, MaRDi, and DAPHNE. - -.. The proposal reaches out to our colleagues in the materials engineering-based -.. consortia to document that there is value in discussing about controlled vocabulary. - -.. _PhysicsCgms: - -Physics background -################## -Microstructural features or crystal defects are spatial arrangements of atoms. -Given their specific atomic arrangement and composition, such features have -specific constraints on the degrees of freedom how atoms can arrange. This causes -these defects to have specific properties. -Provided well-defined coarse-graining procedures are used and regions-of-interest -and/or regions-of-applicability are defined, microstructural features are often -characterized and modelled to have associated thermodynamic descriptors. - -Another motivation for the proposal was the observation that frequently the design -of file formats for simulation software in the computational materials science especially -those tools at the interface between condensed-matter physics and materials engineering -are frequently reimplementing the wheel (at least partly) when it comes to decide how to store -e.g. atom and feature positions or shape of regions-of-interest, grids, crystals, -grains, precipitates, and dislocations. - -Maybe this is a historical burden given the large set of technical terms and jargon -in place, which then motivated pragmatic solutions that resulted in many research groups -have developed similar formats using similar descriptions. - -We see this work on base classes and application definitions not primarily an -effort to improve and extend NeXus for now. Rather this part of the proposal -is an effort to support activities in materials science to work towards -common terminology and using controlled vocabularies more frequently. -These are the foundation for more sophisticated thoughts about practically -useful ontologies. - -Defining crystal defects is a question of how to coarse-grain a given spatiotemporal -set of atoms, each having a nuclide type and position/trajectory. Different mathematical/geometrical -methods exists to coarse-grain and thus determine how a point, a line, a surface, or -a volumetric defect can be described and be spatiotemporally constrained through -a geometrical model with defined geometric primitives and associated (materials) -properties at a coarser-scale. - -The key motivation to such coarse-graining is to reduce the complexity of the -description. On the one hand to support visualization and scientific analyses - not only -of crystal defect arrangements. On the other hand it is the hope that using descriptors -at a coarser level, i.e. nanometre, micrometre, and larger, it is still possible -to find sufficiently accurate and precise descriptors that avoid one having to account -for the dynamics of each atom to predict or understand the properties of defects -and their dynamics. - -Nevertheless, experience has shown that computational-geometry-based descriptions -when combined with hierarchical clustering/labeling methods, applied on set of -atoms and features turn out to yield useful descriptors. Examples include point, -line, surface defects, such as vacancies, solute cluster, dislocations, -disconnections, interfaces to name but a few. + +.. literalinclude:: cube_example.txt + :tab-width: 4 + :linenos: + :language: text .. _CgmsBC: @@ -105,43 +21,40 @@ The following base classes are defined to incentivize the use of NeXus for using computational-geometry-based descriptions. In what follows, base classes for frequently used shapes and geometric primitives are proposed: - :ref:`NXcg_sphere_set`: - A description for a set of possibly dissimilar spheres. + :ref:`NXcg_primitive`: + Base class from which most other NXcg classes that define specific primitives inherit. - :ref:`NXcg_ellipsoid_set`: + :ref:`NXcg_ellipsoid`: A description for a set of possibly dissimilar oriented ellipsoids. - :ref:`NXcg_cylinder_set`: + :ref:`NXcg_cylinder`: A description for a set of possibly dissimilar oriented cylinders. - :ref:`NXcg_point_set`: + :ref:`NXcg_point`: A collection of points with labels. - :ref:`NXcg_polyline_set`: + :ref:`NXcg_polyline`: A collection of lines and linear segments. - :ref:`NXcg_triangle_set`: + :ref:`NXcg_triangle`: A collection of triangles. - :ref:`NXcg_parallelogram_set`: + :ref:`NXcg_parallelogram`: A collection of possibly dissimilar parallelograms. - :ref:`NXcg_triangulated_surface_mesh`: - A mesh of triangles. - - :ref:`NXcg_polygon_set`: + :ref:`NXcg_polygon`: A collection of polygons. - :ref:`NXcg_polyhedron_set`: + :ref:`NXcg_polyhedron`: A collection of polyhedra. - :ref:`NXcg_roi_set`: + :ref:`NXcg_roi`: A container to host a number of different types of primitives. - :ref:`NXcg_tetrahedron_set`: + :ref:`NXcg_tetrahedron`: A collection of tetrahedra. - :ref:`NXcg_hexahedron_set`: + :ref:`NXcg_hexahedron`: A collection of hexahedra with capabilities to represent also simpler (bounding) boxes for e.g. binary trees. @@ -157,14 +70,10 @@ These base classes describe data structures used for more complex geometries: topological analyses and traversal of the graph of how polygons and polyhedra are connected. - :ref:`NXcg_unit_normal_set`: + :ref:`NXcg_unit_normal`: As an additional structuring element especially for meshes, well-documented normal information is crucial for distance computations. - :ref:`NXcg_geodesic_mesh`: - Geodesic meshes are useful for all applications when meshing the surface - of a sphere. - :ref:`NXcg_alpha_complex`: Alpha shapes and alpha wrappings, specifically the special case of the convex hull, are frequently used geometrical models for describing @@ -179,11 +88,6 @@ of material (area or volume) which can be useful not only for stencil-based meth :ref:`NXisocontour`: A description for isocontour descriptions. - :ref:`NXcg_marching_cubes`: - An approach to store metadata of a specific implementation of - the Marching Cubes algorithm, whose sensitivity to specific topological - configurations is known to result in different triangle collections. - :ref:`NXdelocalization`: An approach to document procedures whereby a scalar field is smoothed in a controlled manner. @@ -194,91 +98,3 @@ of material (area or volume) which can be useful not only for stencil-based meth :ref:`NXclustering`: A description for clustering of objects (such as atoms or features). - :ref:`NXorientation_set`: - A set of parameters to describe the relative orientation of members of a set of features/objects. - - :ref:`NXslip_system_set`: - Metadata for a set of slip systems in a given crystal structure. - - :ref:`NXms_feature_set`: - Generic base class to describe any nested set of features - of a microstructure at the continuum-, micron-, nano-scale, or - to represent a topology of molecules and atoms. - - :ref:`NXms_snapshot`: - A container to describe the state of microstructural features - at a given point in time. - - :ref:`NXms_snapshot_set`: - The corresponding class to hold a set of :ref:`NXms_snapshot` objects. - - :ref:`NXchemical_composition`: - (Chemical) composition of a sample or a set of things. - -Finally, the following base classes allow data processing software to document its input -parameters and to summarize its performance statistics: - - :ref:`NXprogram`: - A named and version of a program of library/component. - - :ref:`NXcs_filter_boolean_mask`: - A boolean mask. - - :ref:`NXcs_prng`: - Metadata of a pseudo-random number generator (PRNG) algorithm. - - :ref:`NXcs_profiling`: - A structuring group holding a set of :ref:`NXcs_profiling_event` instances. - - :ref:`NXcs_profiling_event`: - Profiling/benchmark data to an event of - tracking an algorithm/computational step. - - :ref:`NXcs_computer`: - Metadata of a computer. - - :ref:`NXcs_cpu`: - Metadata of a central processing unit. - - :ref:`NXcs_gpu`: - Metadata of a graphical processing unit / accelerator. - - :ref:`NXcs_mm_sys`: - Metadata of the (main) memory (sub-)system. - - :ref:`NXcs_io_sys`: - Metadata of the input/output system. - - :ref:`NXcs_io_obj`: - Metadata of a component storing data of an :ref:`NXcs_io_sys` instance. - -.. _IcmeMsModels: - -Application definitions for ICME models -####################################### - -It is important to embrace the large research community of materials engineers -as they are frequent users of electron microscopy and atom probe microscopy. -In this community frequently ICME (Integrated Computational Materials Engineering) -microstructure models are used. These models are derived from a design strategy -and workflow whereby physics-based modelling of microstructure evolution, typically -at the mesoscopic scale, is used to understand the relations between -the microstructure and technological relevant descriptors for the properties -of materials. - -The following application definitions are proposed to support discussion on -how materials engineering-specific data models connect to or can be mapped on -concepts which are equally modellable with NeXus: - - :ref:`NXms`: - An application definition for arbitrary spatiotemporally resolved simulations. - - :ref:`NXms_score_config`: - A specific example of how :ref:`NXapm_paraprobe_config_ranger` can be - specialized for documenting the configuration of a computer simulation - with the static recrystallization cellular automata model SCORE. - - :ref:`NXms_score_results`: - A specific example of how :ref:`NXms` can be specialized for documenting - results of computer simulations with the static recrystallization - cellular automata model SCORE. diff --git a/manual/source/classes/contributed_definitions/cube_example.txt b/manual/source/classes/contributed_definitions/cube_example.txt new file mode 100644 index 0000000000..2f669d767f --- /dev/null +++ b/manual/source/classes/contributed_definitions/cube_example.txt @@ -0,0 +1,12 @@ +/entry1:NXentry + /reference_frame:NXcoordinate_system + /x = [1, 0, 0] + /y = [0, 1, 0] + /z = [0, 0, 1] + /unit_cube:NXcg_hexahedron + /is_axis_aligned = True + /hexahedron1:NXcg_face_list_data_structure + /@depends_on = "/entry1/reference_frame" + /number_of_vertices = 8 + /vertices = [[0, 0, 0], [1, 0, 0], [1, 1, 0], [0, 1, 0], + [0., 0, 1], [1, 0, 1], [1, 1, 1], [0, 1, 1]]