From a6a56fc12132dc73e426881b4dffa9e707aaac35 Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Thu, 20 Sep 2012 02:42:11 +0000 Subject: [PATCH] Generate output in GMV format instead of VTK. GMV has long been dead. git-svn-id: https://svn.dealii.org/trunk@26542 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/doc/news/changes.h | 5 ++ deal.II/examples/step-8/doc/results.dox | 66 +++++++++++++------------ deal.II/examples/step-8/step-8.cc | 4 +- 3 files changed, 42 insertions(+), 33 deletions(-) diff --git a/deal.II/doc/news/changes.h b/deal.II/doc/news/changes.h index 3f62209077..91de6a8289 100644 --- a/deal.II/doc/news/changes.h +++ b/deal.II/doc/news/changes.h @@ -53,6 +53,11 @@ DoFHandler, in particular removal of specializations.

Specific improvements

    +
  1. Changed: step-8 now outputs data in VTK format, rather than GMV. +GMV has long been dead. +
    +(Wolfgang Bangerth, 2012/09/19) +
  2. Fixed: One can compile deal.II with MPI support but run programs that aren't intended to use parallel communications and that, in fact, do not call MPI_Init at all. They are nevertheless supposed diff --git a/deal.II/examples/step-8/doc/results.dox b/deal.II/examples/step-8/doc/results.dox index 5052393a21..1af1e9d0cd 100644 --- a/deal.II/examples/step-8/doc/results.dox +++ b/deal.II/examples/step-8/doc/results.dox @@ -1,36 +1,10 @@

    Results

    -There is not much to be said about the results of this program, apart -from that they look nice. All images were made using GMV from the -output files that the program wrote to disk. The first picture shows -the displacement as a vector field, where one vector is shown at each -vertex of the grid: - - -@image html step-8.vectors.png - - -You can clearly see the sources of $x$-displacement around $x=0.5$ and -$x=-0.5$, and of $y$-displacement at the origin. In this example, we have -used the GMV program to produce a vector plot by telling it that the -two solution components, $x$-displacement and $y$-displacement, are in -fact not two independent scalar fields, but the components of a vector -field. Depending on what graphical file format we use, we could as -well have specified this in the program already and then written into -the output file. The step-22 shows how to do this in -the output_results() function. - -The next image shows the final grid after eight steps of refinement: - - -@image html step-8.grid.png - - - -Finally, the $x$-displacement and $y$-displacement are displayed separately: - - +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: @@ -44,8 +18,38 @@ Finally, the $x$-displacement and $y$-displacement are displayed separately:
    +You can clearly see the sources of $x$-displacement around $x=0.5$ and +$x=-0.5$, and of $y$-displacement at the origin. The next image shows the +final grid after eight steps of refinement: + +@image html step-8.grid.png + + +What one frequently would like to do is to show the displacement as a vector +field, i.e., show vectors that for each point show the direction and magnitude +of displacement. Unfortunately, that's a bit more involved. To understand why +this is so, remember that we have just defined our finite element as a +collection of two components (in dim=2 dimensions). Nowhere have +we said that this is not just a pressure and a concentration (two scalar +quantities) but that the two components actually are the parts of a +vector-valued quantity, namely the displacement. Absent this knowledge, the +DataOut class assumes that all individual variables we print are separate +scalars, and Visit then faithfully assumes that this is indeed what it is. In +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 ElasticProblem::output_results. 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 +step-22. The vector field then looks like this (Visit randomly selects a few +hundred vertices from which to draw the vectors; drawing them from each +individual vertex would make the picture unreadable): + +@image html step-8.vectors.png + -It should be noted that intuitively one would have expected the +We note that one may have intuitively expected the solution to be symmetric about the $x$- and $y$-axes since the $x$- and $y$-forces are symmetric with respect to these axes. However, the force considered as a vector is not symmetric and consequently neither is diff --git a/deal.II/examples/step-8/step-8.cc b/deal.II/examples/step-8/step-8.cc index 34beba20e0..4f29f8120f 100644 --- a/deal.II/examples/step-8/step-8.cc +++ b/deal.II/examples/step-8/step-8.cc @@ -937,7 +937,7 @@ namespace Step8 filename += ('0' + cycle); Assert (cycle < 10, ExcInternalError()); - filename += ".gmv"; + filename += ".vtk"; std::ofstream output (filename.c_str()); DataOut data_out; @@ -1024,7 +1024,7 @@ namespace Step8 // that to the other function. data_out.add_data_vector (solution, solution_names); data_out.build_patches (); - data_out.write_gmv (output); + data_out.write_vtk (output); } -- 2.39.5