From 2e2bd96533b35f3269a0c18844f0506fcfdd3ad2 Mon Sep 17 00:00:00 2001 From: David Wells Date: Mon, 19 Apr 2021 15:31:29 -0400 Subject: [PATCH] Remove references to the old-style numbering. --- doc/doxygen/headers/reordering.h | 86 ++++++-------------------------- 1 file changed, 15 insertions(+), 71 deletions(-) diff --git a/doc/doxygen/headers/reordering.h b/doc/doxygen/headers/reordering.h index 84d280cfa7..79ac4b585f 100644 --- a/doc/doxygen/headers/reordering.h +++ b/doc/doxygen/headers/reordering.h @@ -19,62 +19,6 @@ * @brief A module describing how deal.II consistently orients Triangulation * objects. * - * This class reorders the vertices of cells such that they meet the standard - * requirements of the Triangulation class when creating grids, i.e. all lines - * have a unique orientation with respect to all neighboring cells. This class - * is mainly used when reading in grids from files and converting them to - * deal.II triangulations. - * - * @note In contrast to the rest of the deal.II library, by default this class - * uses the old deal.II numbering scheme, which was used up to deal.II version - * 5.2 (but the main function of this class takes a flag that specifies - * whether it should do an implicit conversion from the new to the old format - * before doing its work, and then back again after reordering). In this old - * format, the vertex and face ordering in 2d is assumed to be - * @verbatim - * 2 - * 3--->---2 - * | | - * 3^ ^1 - * | | - * 0--->---1 - * 0 - * @endverbatim - * the vertices in 3d: - * @verbatim - * 7-------6 7-------6 - * /| | / /| - * / | | / / | - * / | | / / | - * 3 | | 3-------2 | - * | 4-------5 | | 5 - * | / / | | / - * | / / | | / - * |/ / | |/ - * 0-------1 0-------1 - * @endverbatim - * and the faces in 3d: - * @verbatim - * *-------* *-------* - * /| | / /| - * / | 1 | / 4 / | - * / | | / / | - * * | | *-------* | - * | 5 *-------* | | 3 * - * | / / | | / - * | / 2 / | 0 | / - * |/ / | |/ - * *-------* *-------* - * @endverbatim - * After calling the GridReordering::reorder_cells() function the CellData is - * still in this old numbering scheme. Hence, for creating a Triangulation - * based on the resulting CellData the - * Triangulation::create_triangulation_compatibility() (and not the - * Triangulation::create_triangulation()) function must be used. For a - * typical use of the reorder_cells() function see the implementation of the - * GridIn read_*() functions. - * - * *

Statement of problems

* * Triangulations in deal.II have a special structure, in that there are not @@ -90,7 +34,7 @@ * For example, in two dimensions, a quad consists of four lines which have a * direction, which is by definition as follows: * @verbatim - * 3-->--2 + * 2-->--3 * | | * ^ ^ * | | @@ -104,10 +48,10 @@ * | | | * 0---1---2 * @endverbatim - * may be characterised by the vertex numbers (0 1 4 3) and (1 2 - * 5 4), since the middle line would get the direction 1->4 when - * viewed from both cells. The numbering (0 1 4 3) and (5 4 1 - * 2) would not be allowed, since the left quad would give the common + * may be characterised by the vertex numbers (0 1 3 4) and (1 2 + * 4 5), since the middle line would get the direction 1->4 when + * viewed from both cells. The numbering (0 1 3 4) and (5 4 2 + * 1) would not be allowed, since the left quad would give the common * line the direction 1->4, while the right one would want to use * 4->1, leading to an ambiguity. * @@ -204,8 +148,8 @@ * ^ ^ \ | * 0->-1------2 * @endverbatim - * (This could for example be done by using the indices (0 1 4 3), - * (3 4 7 6), (6 7 10 9) for the three cells). Now, you will + * (This could for example be done by using the indices (0 1 3 4), + * (3 4 6 7), (6 7 9 10) for the three cells). Now, you will * not find a way of giving indices for the right cells, without introducing * either ambiguity for one line or other, or without violating that within * each cells, there must be one vertex from which both lines are directed @@ -213,7 +157,7 @@ * * The solution in this case is to renumber one of the three left cells, e.g. * by reverting the sense of the line between vertices 7 and 10 by numbering - * the top left cell by (9 6 7 10): + * the top left cell by (9 6 10 7): * @verbatim * 9->-10-----11 * v v / | @@ -255,7 +199,7 @@ * @endverbatim * We have here only indicated the numbers of the vertices that are relevant. * Assume that the user had given the cells 0 and 1 by the vertex indices - * 0 1 2 3 and 6 7 4 5. Then, if we follow this orientation, + * 0 1 3 2 and 6 7 5 4. Then, if we follow this orientation, * the grid after creating the lines for these two cells would look like this: * @verbatim * 3-->--2-----o-----o ... o-----7--<--6 @@ -297,9 +241,9 @@ * structure, where node N has as many children as there are possible * orientations of node N+1 (in two space dimensions, there are four * orientations in which each cell can be constructed from its four vertices; - * for example, if the vertex indices are (0 1 2 3), then the four - * possibilities would be (0 1 2 3), (1 2 3 0), (2 3 0 - * 1), and (3 0 1 2)). When adding one cell after the other, we + * for example, if the vertex indices are (0 1 3 2), then the four + * possibilities would be (0 1 3 2), (1 3 2 0), (3 2 0 + * 1), and (2 0 1 3)). When adding one cell after the other, we * traverse this tree in a depth-first (pre-order) fashion. When we encounter * that one path from the root (cell 0) to a leaf (the last cell) is not * allowed (i.e. that the orientations of the cells which are encoded in the @@ -366,7 +310,7 @@ * | | \| * 0------1---------2 * @endverbatim - * First a cell is chosen ( (0,1,4,3) in this case). A single side of the cell + * First a cell is chosen ( (0,1,3,4) in this case). A single side of the cell * is oriented arbitrarily (3->4). This choice of orientation is then * propagated through the mesh, across sides and elements. (0->1), (6->7) and * (9->10). The involves edge-hopping and face hopping, giving a path through @@ -535,8 +479,8 @@ * 0-----1-----2-----3 * @endverbatim * Note that there is a hole in the middle. Assume now that the user described - * the first cell 0 by the vertex numbers 2 3 7 6, and cell 5 by - * 15 14 10 11, and assume that cells 1, 2, 3, and 4 are numbered + * the first cell 0 by the vertex numbers 2 3 6 7, and cell 5 by + * 15 14 11 10, and assume that cells 1, 2, 3, and 4 are numbered * such that 5 can be added in initial rotation. All other cells are numbered * in the usual way, i.e. starting at the bottom left and counting * counterclockwise. Given this description of cells, the algorithm will start -- 2.39.5