@endcode
As can be seen, we set
-$d=0.3$, which amounts to a focus of the transducer lens
-at $x=0.5$, $y=0.3$. The coarse mesh is refined 5 times,
-resulting in 160x160 cells, and the output is written in gmv
+$d=0.3$, which amounts to a focus of the transducer lens
+at $x=0.5$, $y=0.3$. The coarse mesh is refined 5 times,
+resulting in 160x160 cells, and the output is written in gmv
format. The parameter reader understands many more parameters
pertaining in particular to the generation of output, see the
explanation in step-19, but we need none of these
parameters here and therefore stick with their default values.
-Here's the console output of the program in debug mode:
+Here's the console output of the program in debug mode:
-@code
+@code
examples/step-29> make run
============================ Running step-29
DEAL::Generating grid... done (1.11607s)
DEAL::Generating output... done (4.52428s)
@endcode
-(Of course, execution times will differ if you run the program
-locally.) The fact that most of the time is spent on assembling
+(Of course, execution times will differ if you run the program
+locally.) The fact that most of the time is spent on assembling
the system matrix and generating output is due to the many assertion
that need to be checked in debug mode. In optimized mode these parts
of the program run much faster whereas solving the linear system is
-hardly sped up at all:
+hardly sped up at all:
@code
============================ Running step-29
DEAL::Generating output... done (0.880055s)
@endcode
-The graphical output of the program looks as follows:
+The graphical output of the program looks as follows:
<table align="center" border="1" cellspacing="3" cellpadding="3">
</tr>
</table>
-The first two pictures show the real and imaginary parts of
-$u$, whereas the last shows the intensity $|u|$. One can clearly
-see that the intensity is focussed around the focal point of the
-lens (0.5, 0.3), and that the focus
-is rather sharp in $x$-direction but more blurred in $y$-direction, which is a
+The first two pictures show the real and imaginary parts of
+$u$, whereas the last shows the intensity $|u|$. One can clearly
+see that the intensity is focussed around the focal point of the
+lens (0.5, 0.3), and that the focus
+is rather sharp in $x$-direction but more blurred in $y$-direction, which is a
consequence of the geometry of the focusing lens, its finite aperture,
-and the wave nature of the problem.
+and the wave nature of the problem.
Because colorful graphics are always fun, and to stress the focusing
effects some more, here is another set of images highlighting how well
@endcode
Each time we refine the mesh once, so the number of cells and degrees
-of freedom roughly quadruples from each step to the next. As can be seen,
+of freedom roughly quadruples from each step to the next. As can be seen,
generating the grid, setting up degrees of freedom, assembling the
linear system, and generating output scale pretty closely to linear,
whereas solving the linear system is an operation that requires 8
<code>UltrasoundProblem</code> object), but scales very badly and
takes extraordinate patience before it finishes solving the linear
system on a mesh with appreciable resolution, even though all the
-other parts of the program scale very nicely.
+other parts of the program scale very nicely.
+
+
+
+<a name="extensions"></a>
+<h3>Possibilities for extensions</h3>
+
+An obvious possible extension for this program is to run it in 3d
+— after all, the world around us is three-dimensional, and
+ultrasound beams propagate in three-dimensional media. You can try
+this by simply changing the template parameter of the principal class
+in <code>main()</code> and running it. This won't get you very far,
+though: certainly not if you do 5 global refinement steps as set in
+the parameter file. You'll simply run out of memory as both the mesh
+(with its $(2^5)^3 \cdot 5^3=2^{15}\cdot 125 \approx 4\cdot 10^6$ cells)
+and in particular the sparse direct solver take too much memory. You
+can solve with 3 global refinement steps, however, if you have a bit
+of time: in early 2011, the direct solve takes about half an
+hour. What you'll notice, however, is that the solution is completely
+wrong: the mesh size is simply not small enough to resolve the
+solution's waves accurately, and you can see this in plots of the
+solution. Consequently, this is one of the cases where adaptivity is
+indispensible if you don't just want to throw a bigger (presumably
+%parallel) machine at the problem.
projects / dealii.git / commitdiff