The conditions on the interface between the two domains has been
discussed above already.
-For simplicity, we choose the material parameters to be $\eta=\lambda=\mu=1$.
+For simplicity, we choose the material parameters to be
+$\eta=\lambda=\mu=1$. In the results section below, we will also show
+a 3d simulation that can be obtained from the same program. The
+boundary conditions and geometry are defined nearly analogously to the
+2d situation above.
<h4>Linear solvers</h4>
works, even if not with optimal complexity. We will, however, comment
on possible other solvers in the <a href="#Results">results</a> section.
+
<h4>Mesh refinement</h4>
One of the trickier aspects of this program is how to estimate the
This clearly wouldn't happen if we had a refinement indicator that actually
understood something about the problem and simply ignore the interface between
-subdomains when integrating jump terms.
+subdomains when integrating jump terms.
On the other hand, this program is
about showing how to represent problems where we have different physics in
different subdomains, not about the peculiarities of the KellyErrorEstimator,
<a name="Results"></a>
<h1>Results</h1>
+<h3>2d results</h3>
+
+
When running the program, you should get output like the following:
@code
Refinement cycle 0
@image html step-46.velocity-magnitude.png
<p align="center">
- Magnitude of the fluid velocity
+ Magnitude of the fluid velocity.
</p>
</td>
that bends it to the left, as confirmed by the plot of the displacement
vectors.
+
+<h3>3d results</h3>
+
+By changing the dimension of the <code>FluidStructureProblem</code>
+class in <code>main()</code> to 3, we can also run the same problem
+3d. You'd get output along the following lines:
+@code
+Refinement cycle 0
+ Number of active cells: 64
+ Number of degrees of freedom: 1951
+ Assembling...
+ Solving...
+Refinement cycle 1
+ Number of active cells: 288
+ Number of degrees of freedom: 8670
+ Assembling...
+ Solving...
+Refinement cycle 2
+ Number of active cells: 1632
+ Number of degrees of freedom: 45615
+ Assembling...
+ Solving...
+Refinement cycle 3
+ Number of active cells: 8184
+ Number of degrees of freedom: 230015
+ Assembling...
+ Solving...
+@endcode
+You'll notice that the big bottleneck is the solver:
+SparseDirectUmfpack needs approximately 8 hours to solve the last
+iteration of this problem
+on a 2010 workstation (the second to last iteration took only 6
+minutes). Clearly a better solver is needed here, a topic
+discussed below.
+
+The results can also be visualized and yield some good pictures:
+
+<TABLE WIDTH="60%" ALIGN="center">
+ <tr valign="top">
+ <td valign="top" align="center">
+ @image html step-46.3d.velocity.png
+
+ <p align="center">
+ Vectors of the fluid velocity and magnitude of the
+ displacement of the solid part.
+ </p>
+ </td>
+
+ <td valign="top" align="center">
+ @image html step-46.3d.streamlines.png
+
+ <p align="center">
+ Streamlines of the velocity, with the mesh superimposed.
+ </p>
+ </td>
+ </tr>
+ <tr valign="top">
+ <td valign="top" align="center" colspan="2">
+ @image html step-46.3d.displacement.png
+
+ <p align="center">
+ Solid displacement.
+ </p>
+ </td>
+ </tr>
+</table>
+
+In addition to the lack of a good solver, the mesh is a bit
+unbalanced: mesh refinement heavily favors the fluid subdomain (in 2d,
+it was the other way around, prompting us to weigh the fluid error
+indicators higher). Clearly, some tweaking of the relative importance
+of error indicators in the two subdomains is important if one wanted
+to go on doing more 3d computations.
+
+
<a name="extensions"></a>
<h3>Possibilities for extensions</h3>