From 9750dadc3eb5b35b5f6138c24fe6ad6b5d1eb644 Mon Sep 17 00:00:00 2001 From: Ralf Hartmann Date: Thu, 2 Feb 2006 12:03:23 +0000 Subject: [PATCH] Fix docu. git-svn-id: https://svn.dealii.org/trunk@12224 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/base/include/base/geometry_info.h | 52 +++++++++++------------ 1 file changed, 25 insertions(+), 27 deletions(-) diff --git a/deal.II/base/include/base/geometry_info.h b/deal.II/base/include/base/geometry_info.h index 9d390439b9..ee54ef4152 100644 --- a/deal.II/base/include/base/geometry_info.h +++ b/deal.II/base/include/base/geometry_info.h @@ -143,7 +143,7 @@ struct GeometryInfo<0> * * The ordering of vertices and faces (lines) in 2d is defined by * - * N1) vertices are numbered in lexicographically + * N1) vertices are numbered in lexicographic ordering * * N2) faces (lines in 2d): first the two faces with normals in x- * and then y-direction. For each two faces: first the face with @@ -299,19 +299,18 @@ struct GeometryInfo<0> * *--->---* *--->---* * @endverbatim * - * The fact that edges (just as vertices and faces) are entities - * that are stored in their own right rather than constructed from - * cells each time they are needed, means that adjacent cells - * actually have pointers to edges that are thus shared between - * them. This implies that the convention that sets of parallel - * edges have parallel directions is not only a local - * condition. Before a list of cells is passed to an object of this - * class for creation of a triangulation, you therefore have to make - * sure that cells are oriented in a compatible fashion, so that - * edge directions are globally according to above - * convention. However, the GridReordering class can do this - * for you, by reorienting cells and edges of an arbitrary list of - * input cells that need not be already sorted. + * The fact that edges (just as vertices and faces) are entities that + * are stored in their own right rather than constructed from cells + * each time they are needed, means that adjacent cells actually have + * pointers to edges that are thus shared between them. This implies + * that the convention that sets of parallel edges have parallel + * directions is not only a local condition. Before a list of cells is + * passed to an object of the Triangulation class for creation of a + * triangulation, you therefore have to make sure that cells are + * oriented in a compatible fashion, so that edge directions are + * globally according to above convention. However, the GridReordering + * class can do this for you, by reorienting cells and edges of an + * arbitrary list of input cells that need not be already sorted. * *

Faces

* @@ -475,19 +474,18 @@ struct GeometryInfo<0> * and the face_to_cell_vertices functions of GeometryInfo<3> do, * when invoked with a face_orientation=false argument. * - * The information which child cell is at which position of which - * face is most often used when computing jump terms across faces - * with hanging nodes, using objects of type - * FESubfaceValues. Sitting on one cell, you would look at face and - * figure out which child of the neighbor is sitting on a given - * subface between the present and the neighboring cell. To avoid - * having to query the standard orientation of the faces of the two - * cells every time in such cases, you should use a function call - * like - * cell->neighbor_child_on_subface(face_no,subface_no), - * which returns the correct result both in 2d (where face - * orientations are immaterial) and 3d (where it is necessary to use - * the face orientation as additional argument to + * The information which child cell is at which position of which face + * is most often used when computing jump terms across faces with + * hanging nodes, using objects of type FESubfaceValues. Sitting on + * one cell, you would look at a face and figure out which child of + * the neighbor is sitting on a given subface between the present and + * the neighboring cell. To avoid having to query the standard + * orientation of the faces of the two cells every time in such cases, + * you should use a function call like + * cell->neighbor_child_on_subface(face_no,subface_no), which + * returns the correct result both in 2d (where face orientations are + * immaterial) and 3d (where it is necessary to use the face + * orientation as additional argument to * GeometryInfo<3>::child_cell_on_face). * *

Coordinate systems

-- 2.39.5