From 92f7a61a1e805840abd3d72d4668c504fa7180dd Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Thu, 21 Apr 2011 14:06:05 +0000 Subject: [PATCH] Discuss 3d results. git-svn-id: https://svn.dealii.org/trunk@23618 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/examples/step-46/doc/intro.dox | 9 ++- deal.II/examples/step-46/doc/results.dox | 80 +++++++++++++++++++++++- 2 files changed, 86 insertions(+), 3 deletions(-) diff --git a/deal.II/examples/step-46/doc/intro.dox b/deal.II/examples/step-46/doc/intro.dox index 7d7fec1019..d971fc7fcf 100644 --- a/deal.II/examples/step-46/doc/intro.dox +++ b/deal.II/examples/step-46/doc/intro.dox @@ -437,7 +437,11 @@ flow, yielding the implicit no-stress condition $(2\eta 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.

Linear solvers

@@ -449,6 +453,7 @@ good solver: we'll just use the SparseDirectUMFPACK class which always works, even if not with optimal complexity. We will, however, comment on possible other solvers in the results section. +

Mesh refinement

One of the trickier aspects of this program is how to estimate the @@ -514,7 +519,7 @@ is focused on the interface. 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, diff --git a/deal.II/examples/step-46/doc/results.dox b/deal.II/examples/step-46/doc/results.dox index d37bf00fe3..d1b88ee483 100644 --- a/deal.II/examples/step-46/doc/results.dox +++ b/deal.II/examples/step-46/doc/results.dox @@ -1,6 +1,9 @@

Results

+

2d results

+ + When running the program, you should get output like the following: @code Refinement cycle 0 @@ -43,7 +46,7 @@ The results are easily visualized: @image html step-46.velocity-magnitude.png

- Magnitude of the fluid velocity + Magnitude of the fluid velocity.

@@ -90,6 +93,81 @@ and pulls up on the right side. Both forces yield a net torque on the solid that bends it to the left, as confirmed by the plot of the displacement vectors. + +

3d results

+ +By changing the dimension of the FluidStructureProblem +class in main() 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: + + + + + + + + + + +
+ @image html step-46.3d.velocity.png + +

+ Vectors of the fluid velocity and magnitude of the + displacement of the solid part. +

+ 		+ @image html step-46.3d.streamlines.png + +

+ Streamlines of the velocity, with the mesh superimposed. +

+
+ @image html step-46.3d.displacement.png + +

+ Solid displacement. +

+
+ +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. + +

Possibilities for extensions

-- 2.39.5