From: Wolfgang Bangerth Date: Sat, 3 Aug 2019 20:36:30 +0000 (-0600) Subject: Use VTU format in step-5. X-Git-Tag: v9.2.0-rc1~1322^2~1 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=16f7a287b4d02bb53a309e27d61e5b285feff258;p=dealii.git Use VTU format in step-5. --- diff --git a/examples/step-5/doc/results.dox b/examples/step-5/doc/results.dox index 79dc502440..fdea08db7a 100644 --- a/examples/step-5/doc/results.dox +++ b/examples/step-5/doc/results.dox @@ -39,34 +39,32 @@ Cycle 5: In each cycle, the number of cells quadruples and the number of CG iterations roughly doubles. -Also, in each cycle, the program writes one output graphic file in EPS +Also, in each cycle, the program writes one output graphic file in VTU format. They are depicted in the following: - -
- + - +
- + - +
- + - +
@@ -76,6 +74,14 @@ format. They are depicted in the following: Due to the variable coefficient (the curvature there is reduced by the same factor by which the coefficient is increased), the top region of the solution is flattened. The gradient of the solution is -discontinuous there, although this is not very clearly visible in the -pictures above. We will look at this in more detail in the next -example. +discontinuous along the interface, although this is not very clearly +visible in the pictures above. We will look at this in more detail in +the next example. + +The pictures also show that the solution computed by this program is +actually pretty wrong on a very coarse mesh (its magnitude is +wrong). That's because no numerical method guarantees that the solution +on a coarse mesh is particularly accurate -- but we know that the +solution converges to the exact solution, and indeed you can +see how the solutions from one mesh to the next seem to not change +very much any more at the end. diff --git a/examples/step-5/step-5.cc b/examples/step-5/step-5.cc index 2cb79b3c33..24d6b9a6af 100644 --- a/examples/step-5/step-5.cc +++ b/examples/step-5/step-5.cc @@ -279,9 +279,15 @@ void Step5::solve() // @sect4{Step5::output_results and setting output flags} -// Writing output to a file is mostly the same as for the previous example, -// but here we will show how to modify some output options and how to -// construct a different filename for each refinement cycle. +// Writing output to a file is mostly the same as for the previous tutorial. +// The only difference is that we now need to construct a different filename +// for each refinement cycle. +// +// The function writes the output in VTU format, a variation of the VTK format +// that requires less disk space because it compresses the data. Of course, +// there are many other formats supported by the DataOut class if you +// desire to use a program for visualization that doesn't understand +// VTK or VTU. template void Step5::output_results(const unsigned int cycle) const { @@ -292,54 +298,8 @@ void Step5::output_results(const unsigned int cycle) const data_out.build_patches(); - // For this example, we would like to write the output directly to a file in - // Encapsulated Postscript (EPS) format. The library supports this, but - // things may be a bit more difficult sometimes, since EPS is a printing - // format, unlike most other supported formats which serve as input for - // graphical tools. Therefore, you can't scale or rotate the image after it - // has been written to disk, and you have to decide about the viewpoint or - // the scaling in advance. - // - // The defaults in the library are usually quite reasonable, and regarding - // viewpoint and scaling they coincide with the defaults of - // Gnuplot. However, since this is a tutorial, we will demonstrate how to - // change them. For this, we first have to generate an object describing the - // flags for EPS output (similar flag classes exist for all supported output - // formats): - DataOutBase::EpsFlags eps_flags; - // They are initialized with the default values, so we only have to change - // those that we don't like. For example, we would like to scale the z-axis - // differently (stretch each data point in z-direction by a factor of four): - eps_flags.z_scaling = 4.; - // Then we would also like to alter the viewpoint from which we look at the - // solution surface. The default is at an angle of 60 degrees down from the - // vertical axis, and 30 degrees rotated against it in mathematical positive - // sense. We raise our viewpoint a bit and look more along the y-axis: - eps_flags.azimut_angle = 40.; - eps_flags.turn_angle = 10.; - // That shall suffice. There are more flags, for example whether to draw the - // mesh lines, which data vectors to use for colorization of the interior of - // the cells, and so on. You may want to take a look at the documentation of - // the EpsFlags structure to get an overview of what is possible. - // - // The only thing still to be done, is to tell the output object to use - // these flags: - data_out.set_flags(eps_flags); - // The above way to modify flags requires recompilation each time we would - // like to use different flags. This is inconvenient, and we will see more - // advanced ways in step-19 where the output flags are determined at run - // time using an input file (step-19 doesn't show many other things; you - // should feel free to read over it even if you haven't done step-6 to - // step-18 yet). - - // Finally, we need the filename to which the results are to be written. We - // would like to have it of the form solution-N.eps, where N is - // the number of the refinement cycle. Thus, we have to convert an integer - // to a part of a string; this is most easily done using the C++ function - // std::to_string. With the so-constructed filename, we can - // then open an output stream and write the data to that file: - std::ofstream output("solution-" + std::to_string(cycle) + ".eps"); - data_out.write_eps(output); + std::ofstream output("solution-" + std::to_string(cycle) + ".vtu"); + data_out.write_vtu(output); }