// next cycle with mesh refinement, we want to output the results from this
// cycle.
//
-// In the present program, we will not write the solution (except for in the
-// last step, see the next function), but only the meshes that we generated,
-// as a two-dimensional Encapsulated Postscript (EPS) file.
+// We have already seen in step-1 how this can be achieved for the
+// mesh itself. The only thing we have to change is the generation of
+// the file name, since it should contain the number of the present
+// refinement cycle provided to this function as an argument. To this
+// end, we simply append the number of the refinement cycle as a
+// string to the file name.
//
-// We have already seen in step-1 how this can be achieved. The only thing we
-// have to change is the generation of the file name, since it should contain
-// the number of the present refinement cycle provided to this function as an
-// argument. To this end, we simply append the number of the refinement cycle
-// as a string to the file name.
+// We also output the solution in the same way as we did before, with
+// a similarly constructed file name.
template <int dim>
void Step6<dim>::output_results (const unsigned int cycle) const
{
- std::ofstream output ("grid-" + std::to_string(cycle) + ".eps");
-
- GridOut grid_out;
- grid_out.write_eps (triangulation, output);
+ {
+ GridOut grid_out;
+ std::ofstream output ("grid-" + std::to_string(cycle) + ".eps");
+ grid_out.write_eps (triangulation, output);
+ }
+
+ {
+ DataOut<dim> data_out;
+ data_out.attach_dof_handler (dof_handler);
+ data_out.add_data_vector (solution, "solution");
+ data_out.build_patches ();
+
+ std::ofstream output ("solution-" + std::to_string(cycle) + ".vtk");
+ data_out.write_vtk (output);
+ }
}
solve ();
output_results (cycle);
}
-
- // After we have finished computing the solution on the finest mesh, and
- // writing all the grids to disk, we want to also write the actual solution
- // on this final mesh to a file. As already done in one of the previous
- // examples, we use the EPS format for output, and to obtain a reasonable
- // view on the solution, we rescale the z-axis by a factor of four.
- DataOutBase::EpsFlags eps_flags;
- eps_flags.z_scaling = 4;
-
- DataOut<dim> data_out;
- data_out.set_flags (eps_flags);
-
- data_out.attach_dof_handler (dof_handler);
- data_out.add_data_vector (solution, "solution");
- data_out.build_patches ();
-
- std::ofstream output ("final-solution.eps");
- data_out.write_eps (output);
}
There is not much to be said about the results of this program, other than
that they look nice. All images were made using Visit from the
output files that the program wrote to disk. The first two pictures show
-the $x$- and $y$-displacements as a scalar components:
+the $x$- and $y$-displacements as scalar components:
<TABLE WIDTH="100%">
<tr>
other words, once we have written the data as scalars, there is nothing in
Visit that allows us to paste these two scalar fields back together as a
vector field. Where we would have to attack this problem is at the root,
-namely in <code>ElasticProblem::output_results</code>. We won't do so here but
+namely in <code>ElasticProblem::output_results()</code>. We won't do so here but
instead refer the reader to the step-22 program where we show how to do this
for a more general situation. That said, we couldn't help generating the data
anyway that would show how this would look if implemented as discussed in
// valued. The <code>DataOut</code> class takes care of this automatically,
// but we have to give each component of the solution vector a different
// name.
+ //
+ // To do this, the DataOut::add_vector() function wants a vector of
+ // strings. Since the number of components is the same as the number
+ // of dimensions we are working in, we use the <code>switch</code>
+ // statement below.
+ //
+ // We note that some graphics programs have restriction on what
+ // characters are allowed in the names of variables. deal.II therefore
+ // supports only the minimal subset of these characters that is supported
+ // by all programs. Basically, these are letters, numbers, underscores,
+ // and some other characters, but in particular no whitespace and
+ // minus/hyphen. The library will throw an exception otherwise, at least
+ // if in debug mode.
+ //
+ // After listing the 1d, 2d, and 3d case, it is good style to let the
+ // program die if we run upon a case which we did not consider. Remember
+ // that the <code>Assert</code> macro generates an exception if the
+ // condition in the first parameter is not satisfied. Of course, the
+ // condition <code>false</code> can never be satisfied, so the program
+ // will always abort whenever it gets to the default statement:
template <int dim>
void ElasticProblem<dim>::output_results (const unsigned int cycle) const
{
- std::string filename = "solution-";
- filename += ('0' + cycle);
- Assert (cycle < 10, ExcInternalError());
-
- filename += ".vtk";
- std::ofstream output (filename.c_str());
-
DataOut<dim> data_out;
data_out.attach_dof_handler (dof_handler);
-
-
- // As said above, we need a different name for each component of the
- // solution function. To pass one name for each component, a vector of
- // strings is used. Since the number of components is the same as the
- // number of dimensions we are working in, the following
- // <code>switch</code> statement is used.
- //
- // We note that some graphics programs have restriction as to what
- // characters are allowed in the names of variables. The library therefore
- // supports only the minimal subset of these characters that is supported
- // by all programs. Basically, these are letters, numbers, underscores,
- // and some other characters, but in particular no whitespace and
- // minus/hyphen. The library will throw an exception otherwise, at least
- // if in debug mode.
- //
- // After listing the 1d, 2d, and 3d case, it is good style to let the
- // program die if we run upon a case which we did not consider. Remember
- // that the <code>Assert</code> macro generates an exception if the
- // condition in the first parameter is not satisfied. Of course, the
- // condition <code>false</code> can never be satisfied, so the program
- // will always abort whenever it gets to the default statement:
std::vector<std::string> solution_names;
switch (dim)
{
Assert (false, ExcNotImplemented());
}
- // After setting up the names for the different components of the solution
- // vector, we can add the solution vector to the list of data vectors
- // scheduled for output. Note that the following function takes a vector
- // of strings as second argument, whereas the one which we have used in
- // all previous examples accepted a string there. In fact, the latter
- // function is only a shortcut for the function which we call here: it
- // puts the single string that is passed to it into a vector of strings
- // with only one element and forwards that to the other function.
+ // After setting up the names for the different components of the
+ // solution vector, we can add the solution vector to the list of
+ // data vectors scheduled for output. Note that the following
+ // function takes a vector of strings as second argument, whereas
+ // the one which we have used in all previous examples accepted a
+ // string there. (In fact, the function we had used before would
+ // convert the single string into a vector with only one element
+ // and forwards that to the other function.)
data_out.add_data_vector (solution, solution_names);
data_out.build_patches ();
+
+ std::ofstream output ("solution-" + std::to_string(cycle) + ".vtk");
data_out.write_vtk (output);
}
The results of this program are not particularly spectacular. They
consist of the console output, some grid files, and the solution on
-the finest grid. First for the console output:
+each of these grids. First for the console output:
@code
Cycle 0:
Number of active cells: 256
The structure of the grid will be understandable by looking at the
-solution itself:
+final solution itself:
<img src="https://www.dealii.org/images/steps/developer/step-9.solution.png" alt="">
-
-
+(This image was generated using an earlier version of the program that
+still generated gmv instead of VTK output, and so is visualized
+using gmv.)
Note that the solution is created by that part that is transported
along the wiggly advection field from the left and lower boundaries
to the top right, and the part that is created by the source in the
// Writing output to disk is done in the same way as in the previous
- // examples...
+ // examples. Indeed, the function is identical to the one in step-6.
template <int dim>
void AdvectionProblem<dim>::output_results (const unsigned int cycle) const
{
- std::string filename = "grid-";
- filename += ('0' + cycle);
- Assert (cycle < 10, ExcInternalError());
+ {
+ GridOut grid_out;
+ std::ofstream output ("grid-" + std::to_string(cycle) + ".eps");
+ grid_out.write_eps (triangulation, output);
+ }
- filename += ".eps";
- std::ofstream output (filename.c_str());
+ {
+ DataOut<dim> data_out;
+ data_out.attach_dof_handler (dof_handler);
+ data_out.add_data_vector (solution, "solution");
+ data_out.build_patches ();
- GridOut grid_out;
- grid_out.write_eps (triangulation, output);
+ std::ofstream output ("solution-" + std::to_string(cycle) + ".vtk");
+ data_out.write_vtk (output);
+ }
}
solve ();
output_results (cycle);
}
-
- DataOut<dim> data_out;
- data_out.attach_dof_handler (dof_handler);
- data_out.add_data_vector (solution, "solution");
- data_out.build_patches ();
-
- std::ofstream output ("final-solution.vtk");
- data_out.write_vtk (output);
}
projects / dealii.git / commitdiff