<h1>Results</h1>

Running the program produces graphics of two grids (grid-1.svg and grid-2.svg).
You can open these with most every web browser -- in the simplest case,
just open the current directory in your file system explorer and click
on the file. If you like working on the command line, you call your
web browser with the file: `firefox grid-1.svg`, `google-chrome grid-1.svg`,
or whatever the name of your browser is. If you do this, the two meshes
should look like this:

<table width="60%" align="center">
  <tr>
    <td align="center">
      <img src="https://www.dealii.org/images/steps/developer/step-1.grid-1-r9.2.png" alt="">
    </td>
    <td align="center">
      <img src="https://www.dealii.org/images/steps/developer/step-1.grid-2-r9.2.png" alt="">
    </td>
  </tr>
</table>

The left one, well, is not very exciting. The right one is &mdash; at least
&mdash; unconventional. The pictures color-code the "refinement level" of each
cell: How many times did a coarse mesh cell have to be subdivided to obtain
the given cell. In the left image, this is boring since the mesh was
refined globally a number of times, i.e., <i>every</i> cell was
refined the same number of times.

(While the second mesh is entirely artificial and made-up, and
certainly not very practical in applications, to everyone's surprise it
has found its way into the literature: see @cite Mu05. Apparently it is
good for some things at least.)


<h3> Possibilities for extensions </h3>

<h4> Different adaptive refinement strategies </h4>

This program obviously does not have a whole lot of functionality, but
in particular the <code>second_grid</code> function has a bunch of
places where you can play with it. For example, you could modify the
criterion by which we decide which cells to refine. An example would
be to change the condition to this:
@code
      for (auto &cell: triangulation.active_cell_iterators())
        if (cell->center()[1] > 0)
          cell->set_refine_flag ();
@endcode
This would refine all cells for which the $y$-coordinate of the cell's
center is greater than zero (the <code>TriaAccessor::center</code>
function that we call by dereferencing the <code>cell</code> iterator
returns a Point<2> object; subscripting <code>[0]</code> would give
the $x$-coordinate, subscripting <code>[1]</code> the
$y$-coordinate). By looking at the functions that TriaAccessor
provides, you can also use more complicated criteria for refinement.

In general, what you can do with operations of the form
`cell->something()` is a bit difficult to find in the documentation
because `cell` is not a pointer but an iterator. The functions you can
call on a cell can be found in the documentation of the classes
`TriaAccessor` (which has functions that can also be called on faces
of cells or, more generally, all sorts of geometric objects that
appear in a triangulation), and `CellAccessor` (which adds a few
functions that are specific to *cells*).

A more thorough description of the whole iterator concept can be found
in the @ref Iterators documentation module.


<h4> Different geometries </h4>

Another possibility would be to generate meshes of entirely different
geometries altogether. While for complex geometries there is no way around
using meshes obtained from mesh generators, there is a good number of
geometries for which deal.II can create meshes using the functions in the
GridGenerator namespace. Many of these geometries (such as the one used in this
example program) contain cells with curved faces: put another way, we expect the
new vertices placed on the boundary to lie along a circle. deal.II handles complex
geometries with the Manifold class (and classes inheriting from it); in particular,
the functions in GridGenerator corresponding to non-Cartesian grids (such as
GridGenerator::hyper_shell or GridGenerator::truncated_cone) attach a Manifold
object to the part of the triangulation that should be curved (SphericalManifold
and CylindricalManifold, respectively) and use another manifold on the parts that
should be flat (FlatManifold). See the documentation
of Manifold or the @ref manifold "manifold module" for descriptions of the design
philosophy and interfaces of these classes. Take a look at what they provide and
see how they could be used in a program like this.

We also discuss a variety of other ways to create and manipulate meshes (and
describe the process of attaching Manifolds) in step-49.


<h4> Comments about programming and debugging </h4>

We close with a comment about modifying or writing programs with deal.II in
general. When you start working with tutorial programs or your own
applications, you will find that mistakes happen: your program will contain
code that either aborts the program right away or bugs that simply lead to
wrong results. In either case, you will find it extremely helpful to know how
to work with a debugger: you may get by for a while by just putting debug
output into your program, compiling it, and running it, but ultimately finding
bugs with a debugger is much faster, much more convenient, and more reliable
because you don't have to recompile the program all the time and because you
can inspect the values of variables and how they change.

Rather than postponing learning how to use a debugger till you really can't
see any other way to find a bug, here's the one piece of
advice we will provide in this program: learn how to use a debugger as soon as
possible. It will be time well invested.
(@dealiiVideoLectureSeeAlso{25}) The deal.II Frequently Asked
Questions (FAQ) page linked to from the top-level <a
href="http://www.dealii.org/">deal.II webpage</a> also provides a good number
of hints on debugging deal.II programs.


<h4> More about graphical output </h4>

It is often useful to include meshes into your theses or publications.
For this, it may not be very useful to color-code the cells by
refinement level, and to print the cell number onto each cell. But
it doesn't have to be that way -- the GridOut class allows setting flags
for each possible output format (see the classes in the GridOutFlags
namespace) that control how exactly a mesh is plotted. You can of
course also choose other output file formats such as VTK or VTU; this
is particularly useful for 3d meshes where a 2d format such as SVG
is not particular useful because it fixes a particular viewpoint onto
the 3d object. As a consequence, you might want to explore other
options in the GridOut class.
