From: Wolfgang Bangerth Date: Fri, 8 Jan 2016 17:22:40 +0000 (-0600) Subject: Comment on a couple of things brought up in review. X-Git-Tag: v8.4.0-rc2~106^2 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=cc708b7c275554f68e2312294026a2a45b06efad;p=dealii.git Comment on a couple of things brought up in review. --- diff --git a/examples/step-18/doc/intro.dox b/examples/step-18/doc/intro.dox index 97e973a5b6..29351409b1 100644 --- a/examples/step-18/doc/intro.dox +++ b/examples/step-18/doc/intro.dox @@ -346,12 +346,14 @@ that reference all files for a given timestep. Sadly, the record files have a different format between VisIt and Paraview, so we write out both formats. The code will generate the files solution-TTTT.NNN.vtu, -where TTTT is the -timestep number (starting from 1) and NNN is the process rank -(starting from +where TTTT is the timestep number (starting from 1) and +NNN is the process rank (starting from 0). These files contain the locally owned cells for the timestep and -processor. The files solution-TTTT.visit is the visit record for timestep -TTTT, while solution-TTTT.pvtu is the same for ParaView. Finally, the file +processor. The files solution-TTTT.visit is the visit record +for timestep TTTT, while solution-TTTT.pvtu is +the same for ParaView. (More recent versions of Visit can actually read +.pvtu files as well, but it doesn't hurt to output both +kinds of record files.) Finally, the file solution.pvd is a special record only supported by ParaView that references all time steps. So in ParaView, only solution.pvd needs to be opened, while one needs to select the group of all .visit files in VisIt for the same @@ -406,6 +408,16 @@ DoFTools::extract_locally_relevant_dofs(). Finally, the DataOut class also knows how to deal with such triangulations and will simply skip generating graphical output on cells not locally owned. +Of course, as has been noted numerous times in the discussion in step-17, +keeping the entire triangulation on every process will not scale: large +problems may simply not fit into each process's memory any more, even if +we have sufficiently many processes around to solve them in a reasonable +time. In such cases, the parallel::shared::Triangulation is no longer +a reasonable basis for computations and we will show in step-40 how the +parallel::distributed::Triangulation class can be used to work around +this, namely by letting each process store only a part of the +triangulation. +

Overall structure of the program