From: Wolfgang Bangerth Date: Fri, 7 Feb 2020 20:46:53 +0000 (-0700) Subject: Convert step-14 from using eps/gnuplot to svg/vtu. X-Git-Tag: v9.2.0-rc1~531^2 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7ff97013210f3c276e1bbc54b9a3aca331cba0ab;p=dealii.git Convert step-14 from using eps/gnuplot to svg/vtu. The figures as currently used are actually quite ugly. We can do substantially better. While there, also clean up the function that creates output a bit. --- diff --git a/examples/step-14/doc/results.dox b/examples/step-14/doc/results.dox index 5d40975785..de1e756840 100644 --- a/examples/step-14/doc/results.dox +++ b/examples/step-14/doc/results.dox @@ -47,41 +47,46 @@ Refinement cycle: 8 @endcode -First let's look what the program actually computed. On the fifth -grid, primal and dual numerical solutions look like this: +First let's look what the program actually computed. On the seventh +grid, primal and dual numerical solutions look like this (using a +color scheme intended to evoke the snow-capped mountains of +Colorado that the original author of this program now calls +home):
- + - +
-Obviously, the region at the bottom left is so unimportant for the +Apparently, the region at the bottom left is so unimportant for the point value evaluation at the top right that the grid is left entirely -unrefined there, even though the solution has singularities there! Due +unrefined there, even though the solution has singularities at the inner +corner of that cell! Due to the symmetry in right hand side and domain, the solution should actually look like at the top right in all four corners, but the mesh refinement criterion involving the dual solution chose to refine them -differently. +differently -- because we said that we really only care about a single +function value somewhere at the top right. -Looking at the grids that are produced in the course of subsequent -refinement, here are some of them: +Here are some of the meshes that are produced in refinement cycles 0, +2, 4 (top row), and 5, 7, and 8 (bottom row): - - - + + + - - - + + +
@@ -89,14 +94,14 @@ Note the subtle interplay between resolving the corner singularities, and resolving around the point of evaluation. It will be rather difficult to generate such a mesh by hand, as this would involve to judge quantitatively how much which of the four corner singularities -shall be resolved, and to set the weight compared to the vicinity of +should be resolved, and to set the weight compared to the vicinity of the evaluation point. The program prints the point value and the estimated error in this quantity. From extrapolating it, we can guess that the exact value is -somewhat like 0.0334473, plus or minus 0.0000001 (note that we get +somewhere close to 0.0334473, plus or minus 0.0000001 (note that we get almost 6 valid digits from only 22,000 (primal) degrees of freedom. This number cannot be obtained from the value of the functional alone, but I have used the assumption that the error @@ -227,7 +232,11 @@ evaluation shows this: + +
- + + +
This time, the grids in refinement cycles 0, 5, 6, 7, 8, and 9 look @@ -235,20 +244,21 @@ like this: - - - + + + - - - + + +
Note the asymmetry of the grids compared with those we obtained for -the point evaluation, which is due to the directionality of the -x-derivative for which we tailored the refinement criterion. +the point evaluation. This is due to the fact that the domain and the primal +solution may be symmetric about the diagonal, but the $x$-derivative is +not, and the latter enters the refinement criterion. @@ -285,32 +295,34 @@ computed value of $J(u_h)$. If instead of the Exercise_2_3 data set, we choose -CurvedRidges in the main function, we can redo the +CurvedRidges in the main function, and choose $(0.5,0.5)$ +as the evaluation point, then we can redo the computations of the previous example program, to compare whether the results obtained with the help of the dual weighted error estimator are better than those we had previously. -First, the meshes after 9 and 10 adaptive refinement cycles, -respectively, look like this: +First, the meshes after 9 adaptive refinement cycles obtained with +the point evaluation and derivative evaluation refinement +criteria, respectively, look like this: - - + +
-The features of the solution can still be seen slightly, but since the -solution is smooth, the roughness of the dual solution entirely -dominates the mesh refinement criterion, and leads to strongly -concentrated meshes. The solution after the seventh refinement step is -like so: +The features of the solution can still be seen in the mesh, but since the +solution is smooth, the singularities of the dual solution entirely +dominate the mesh refinement criterion, and lead to strongly +concentrated meshes. The solution after the seventh refinement step looks +like the following: - +
diff --git a/examples/step-14/step-14.cc b/examples/step-14/step-14.cc index 2813ba7893..d687448edd 100644 --- a/examples/step-14/step-14.cc +++ b/examples/step-14/step-14.cc @@ -325,8 +325,8 @@ namespace Step14 const Vector & /*solution*/) const { std::ofstream out(output_name_base + "-" + - std::to_string(this->refinement_cycle) + ".eps"); - GridOut().write_eps(dof_handler.get_triangulation(), out); + std::to_string(this->refinement_cycle) + ".svg"); + GridOut().write_svg(dof_handler.get_triangulation(), out); } } // namespace Evaluation @@ -750,8 +750,8 @@ namespace Step14 data_out.build_patches(); std::ofstream out("solution-" + std::to_string(this->refinement_cycle) + - ".gnuplot"); - data_out.write(out, DataOutBase::gnuplot); + ".vtu"); + data_out.write(out, DataOutBase::vtu); } @@ -2100,8 +2100,8 @@ namespace Step14 data_out.build_patches(); std::ofstream out("solution-" + std::to_string(this->refinement_cycle) + - ".gnuplot"); - data_out.write(out, DataOutBase::gnuplot); + ".vtu"); + data_out.write(out, DataOutBase::vtu); }