<h1>Results</h1>


The output of the program looks as follows (the number of iterations
may vary by one or two, depending on your computer, since this is
often dependent on the round-off accuracy of floating point
operations, which differs between processors):
@code
Solving problem in 2 space dimensions.
   Number of active cells: 256
   Total number of cells: 341
   Number of degrees of freedom: 289
   26 CG iterations needed to obtain convergence.
Solving problem in 3 space dimensions.
   Number of active cells: 4096
   Total number of cells: 4681
   Number of degrees of freedom: 4913
   30 CG iterations needed to obtain convergence.
@endcode
It is obvious that in three spatial dimensions the number of cells and
therefore also the number of degrees of freedom is
much higher. What cannot be seen here, is that besides this higher
number of rows and columns in the matrix, there are also significantly
more entries per row of the matrix in three space
dimensions. Together, this leads to a much higher numerical effort for
solving the system of equation, which you can feel in the run time of the two
solution steps when you actually run the program.



The program produces two files: <code>solution-2d.vtk</code> and
<code>solution-3d.vtk</code>, which can be viewed using the programs
Visit or Paraview (in case you do not have these programs, you can easily
change the 
output format in the program to something which you can view more
easily). Visualizing solutions is a bit of an art, but it can also be fun, so
you should play around with your favorite visualization tool to get familiar
with its functionality. Here's what I have come up with for the 2d solution:

<p align="center">
  <img src="http://www.dealii.org/images/steps/developer/step-4.solution-2d.png" alt="">
</p>

(@dealiiVideoLectureSeeAlso{11,32})
The picture shows the solution of the problem under consideration as
a 3D plot. As can be seen, the solution is almost flat in the interior
of the domain and has a higher curvature near the boundary. This, of
course, is due to the fact that for Laplace's equation the curvature
of the solution is equal to the right hand side and that was chosen as
a quartic polynomial which is nearly zero in the interior and is only
rising sharply when approaching the boundaries of the domain; the
maximal values of the right hand side function are at the corners of
the domain, where also the solution is moving most rapidly.
It is also nice to see that the solution follows the desired quadratic
boundary values along the boundaries of the domain.

On the other hand, even though the picture does not show the mesh lines
explicitly, you can see them as little kinks in the solution. This clearly
indicates that the solution hasn't been computed to very high accuracy and
that to get a better solution, we may have to compute on a finer mesh.

In three spatial dimensions, visualization is a bit more difficult. The left
picture shows the solution and the mesh it was computed on on the surface of
the domain. This is nice, but it has the drawback that it completely hides
what is happening on the inside. The picture on the right is an attempt at
visualizing the interior as well, by showing surfaces where the solution has
constant values (as indicated by the legend at the top left). Isosurface
pictures look best if one makes the individual surfaces slightly transparent
so that it is possible to see through them and see what's behind.

<TABLE WIDTH="60%" ALIGN="center">
  <tr>
    <td ALIGN="center">
      <img src="http://www.dealii.org/images/steps/developer/step-4.solution-3d.png" alt="">
    </td>

    <td ALIGN="center">
      <img src="http://www.dealii.org/images/steps/developer/step-4.contours-3d.png" alt="">
    </td>
  </tr>
</table>

@note
A final remark on visualization: The idea of visualization is to give insight,
which is not the same as displaying information. In particular, it is easy to
overload a picture with information, but while it shows more information it
makes it also more difficult to glean insight. As an example, the program I
used to generate these pictures, Visit, by default puts tick marks on every
axis, puts a big fat label "X Axis" on the $x$ axis and similar for the other
axes, shows the file name from which the data was taken in the top left and
the name of the user doing so and the time and date on the bottom right. None
of this is important 
here: the axes are equally easy to make out because the tripod at the bottom
left is still visible, and we know from the program that the domain is
$[-1,1]^3$, so there is no need for tick marks. As a consequence, I have
switched off all the extraneous stuff in the picture: The art of visualization
is to reduce the picture to those parts that are important to see what one
wants to see, but no more.



<a name="extensions"></a>
<h3>Possibilities for extensions</h3>


Essentially the possibilities for playing around with the program are the same
as for the previous one, except that they will now also apply to the 3d
case. For inspiration read up on <a href="step_3.html#extensions"
target="body">possible extensions in the documentation of step 3</a>.

