From d536d724ec810c1081ac9bf81b28228f5f206498 Mon Sep 17 00:00:00 2001 From: David Wells Date: Sun, 4 Feb 2018 16:08:05 -0500 Subject: [PATCH] Improve some minor things in step-49. --- examples/step-49/doc/intro.dox | 18 +++++++++--------- examples/step-49/step-49.cc | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/examples/step-49/doc/intro.dox b/examples/step-49/doc/intro.dox index c570b4c1d8..0c6a3c8bc8 100644 --- a/examples/step-49/doc/intro.dox +++ b/examples/step-49/doc/intro.dox @@ -1,5 +1,5 @@ This program was contributed by Timo Heister. Parts of the results section -were contributed by Yuhan Zhou and Wolfgang Bangerth. +were contributed by Yuhan Zhou, Wolfgang Bangerth, and David Wells.

Introduction

@@ -45,7 +45,7 @@ GridGenerator, as already discussed in step-1. There are many different helper functions available, including GridGenerator::hyper_cube(), GridGenerator::hyper_shell(), GridGenerator::hyper_ball(), -GridGenerator::hyper_cube_with_cylindrical_hole(), ... +and GridGenerator::hyper_cube_with_cylindrical_hole().

Constructing your own mesh programmatically

@@ -73,8 +73,8 @@ href="http://geuz.org/gmsh/" target="_top">gmsh, lagrit and cubit. See the documentation of GridIn for more information. The problem is that deal.II -needs meshes that only consist of quads and hexas -- tetrahedral meshes won't -work (this means tools like tetgen can not be used directly). +needs meshes that only consist of quadrilaterals and hexahedra -- tetrahedral +meshes won't work (this means tools like tetgen can not be used directly). We will describe a possible workflow using Gmsh. Gmsh is the smallest and most quickly set up open source tool we are aware of. It can generate @@ -82,18 +82,18 @@ unstructured 2d quad meshes, but in 3d it can only extrude 2d meshes to get hexahedral meshes. 3D meshing of unstructured geometry into hexahedra is not supported at the time of writing this tutorial (early 2013). -In gmsh, a mesh is described in a text based .geo file, that can +In Gmsh, a mesh is described in a text based .geo file, that can contain computations, loops, variables, etc. It is very flexible. The mesh is generated from a surface representation, which is build from a list of line loops, which is build from a list of lines, which are in turn built from points. The .geo script can be written and edited by hand or it -can be generated automatically by creating objects graphically inside gmsh. In +can be generated automatically by creating objects graphically inside Gmsh. In many cases it is best to combine both approaches. The file can be easily reloaded by pressing "reload" under the "Geometry" tab. This tutorial contains an example .geo file, that describes a box with two objects cut out in the interior. This is how -untitled.geo looks like in gmsh (displaying the boundary +untitled.geo looks like in Gmsh (displaying the boundary indicators as well as the mesh discussed further down below): @@ -112,7 +112,7 @@ in deal.II. Without these physical entities, nothing will be imported into deal.II. deal.II's GridIn class can read the .msh format written by -gmsh and that contains a mesh created for the geometry described by the +Gmsh and that contains a mesh created for the geometry described by the .geo file. You generate the .msh from the .geo by running the commands @@ -254,7 +254,7 @@ GridGenerator::extrude_triangulation(). See the grid_4() function in this tutorial for an example. Note that for this particular case, the given result could also be achieved using the 3d version of GridGenerator::hyper_cube_with_cylindrical_hole(). The main usage is a 2d -mesh, generated for example with gmsh, that is read in from a +mesh, generated for example with Gmsh, that is read in from a .msh file as described above. This is the output from grid_4(): diff --git a/examples/step-49/step-49.cc b/examples/step-49/step-49.cc index 4e55e9116c..46e18df35e 100644 --- a/examples/step-49/step-49.cc +++ b/examples/step-49/step-49.cc @@ -168,7 +168,7 @@ void grid_2 () // more than once. It works here because we select the vertices we want to use // based on their geometric location, and a vertex moved once will fail this // test in the future. A more general approach to this problem would have been -// to keep a std::set of of those vertex indices that we have already moved +// to keep a std::set of those vertex indices that we have already moved // (which we can obtain using cell-@>vertex_index(i) and only // move those vertices whose index isn't in the set yet. void grid_3 () -- 2.39.5