<h1>Results</h1>


The output of this program is not really much different from that of
step-21: it solves the same problem, after all. Of more importance are
quantitative metrics such as the accuracy of the solution as well as
the time needed to compute it. These are documented in detail in the
two publications listed at the top of this page and we won't repeat
them here.

That said, no tutorial program is complete without a couple of good
pictures, so here is some output of a run in 3d:

<table align="center" class="tutorial" cellspacing="3" cellpadding="3">
  <tr>
    <td align="center">
        <img src="https://www.dealii.org/images/steps/developer/step-43.3d.velocity.png" alt="">
	<p align="center">
        Velocity vectors of flow through the porous medium with random
        permeability model. Streaming paths of high permeability and resulting
        high velocity are clearly visible.
	</p>
    </td>
    <td align="center">
        <img src="https://www.dealii.org/images/steps/developer/step-43.3d.streamlines.png" alt="">
	<p align="center">
        Streamlines colored by the saturation along the streamline path. Blue
        streamlines indicate low saturations, i.e., the flow along these
	streamlines must be slow or else more fluid would have been
        transported along them. On the other hand, green paths indicate high
        velocities since the fluid front has already reached further into the
        domain.
	</p>
    </td>
  </tr>
  <tr>
    <td align="center">
        <img src="https://www.dealii.org/images/steps/developer/step-43.3d.saturation.png" alt="">
	<p align="center">
        Streamlines with a volume rendering of the saturation, showing how far
        the fluid front has advanced at this time.
	</p>
    </td>
    <td align="center">
        <img src="https://www.dealii.org/images/steps/developer/step-43.3d.mesh.png" alt="">
	<p align="center">
	Surface of the mesh showing the adaptive refinement along the front.
	</p>
    </td>
  </tr>
</table>


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

The primary objection one may have to this program is that it is still too
slow: 3d computations on reasonably fine meshes are simply too expensive to be
done routinely and with reasonably quick turn-around. This is similar to the
situation we were in when we wrote step-31, from which this program has taken
much inspiration. The solution is similar as it was there as well: We need to
parallelize the program in a way similar to how we derived step-32 out of
step-31. In fact, all of the techniques used in step-32 would be transferable
to this program as well, making the program run on dozens or hundreds of
processors immediately.

A different direction is to make the program more relevant to many other
porous media applications. Specifically, one avenue is to go to the primary
user of porous media flow simulators, namely the oil industry. There,
applications in this area are dominated by multiphase flow (i.e., more than
the two phases we have here), and the reactions they may have with each other
(or any other way phases may exchange mass, such as through dissolution in and
bubbling out of gas from the oil phase). Furthermore, the presence of gas
often leads to compressibility effects of the fluid. Jointly, these effects
are typically formulated in the widely-used "black oil model". True reactions
between multiple phases also play a role in oil reservoir modeling when
considering controlled burns of oil in the reservoir to raise pressure and
temperature. These are much more complex problems, though, and left for future
projects.

Finally, from a mathematical perspective, we have derived the
criterion for re-computing the velocity/pressure solution at a given
time step under the assumption that we want to compare the solution we
would get at the current time step with that computed the last time we
actually solved this system. However, in the program, whenever we did
not re-compute the solution, we didn't just use the previously
computed solution but instead extrapolated from the previous two times
we solved the system. Consequently, the criterion was pessimistically
stated: what we should really compare is the solution we would get at
the current time step with the extrapolated one. Re-stating the
theorem in this regard is left as an exercise.

There are also other ways to extend the mathematical foundation of
this program; for example, one may say that it isn't the velocity we
care about, but in fact the saturation. Thus, one may ask whether the
criterion we use here to decide whether $\mathbf u$ needs to be
recomputed is appropriate; one may, for example, suggest that it is
also important to decide whether (and by how much) a wrong velocity
field in fact affects the solution of the saturation equation. This
would then naturally lead to a sensitivity analysis.

From an algorithmic viewpoint, we have here used a criterion for refinement
that is often used in engineering, namely by looking at the gradient of
the solution. However, if you inspect the solution, you will find that
it quickly leads to refinement almost everywhere, even in regions where it
is clearly not necessary: frequently used therefore does not need to imply
that it is a useful criterion to begin with. On the other hand, replacing
this criterion by a different and better one should not be very difficult.
For example, the KellyErrorEstimator class used in many other programs
should certainly be applicable to the current problem as well.
