From: Sean Ingimarson Date: Thu, 17 Feb 2022 21:31:13 +0000 (-0500) Subject: indent fixes X-Git-Tag: v9.4.0-rc1~469^2 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=refs%2Fpull%2F13407%2Fhead;p=dealii.git indent fixes --- diff --git a/examples/step-17/doc/intro.dox b/examples/step-17/doc/intro.dox index 0d09aac4dc..361567bc79 100644 --- a/examples/step-17/doc/intro.dox +++ b/examples/step-17/doc/intro.dox @@ -3,14 +3,14 @@

Overview

-This program does not introduce any new mathematical ideas; in fact, all it does -is to do the same computations that step-8 already does, but it does so in a -different manner. Instead of using deal.II's linear algebra classes, we build +This program does not introduce any new mathematical ideas; in fact, all it does +is to do the same computations that step-8 already does, but it does so in a +different manner. Instead of using deal.II's linear algebra classes, we build everything on top of classes deal.II provides that wrap around the linear algebra implementation of the PETSc library. And -since PETSc allows the distribution of matrices and vectors across several -computers within an MPI network, the resulting code will even be capable of -solving the problem in %parallel. If you don't know what PETSc is, then this +since PETSc allows the distribution of matrices and vectors across several +computers within an MPI network, the resulting code will even be capable of +solving the problem in %parallel. If you don't know what PETSc is, then this would be a good time to take a quick glimpse at their homepage. As a prerequisite of this program, you need to have PETSc installed, and if @@ -142,14 +142,14 @@ example, in the program we will use function calls that take a number from each processor, add them all up, and return the sum to all processors. Internally, this is implemented using individual messages, but to the user this is transparent. We call such operations collectives -because all processors participate in them. Collectives allow us -to write programs where not every copy of the executable is doing -something completely different (this would be incredibly difficult to -program) but where all copies are doing the same thing (though on -different data) for themselves, running through the same blocks of code; -then they communicate data through collectives and then go back to doing -something for themselves again running through the same blocks of data. -This is the key piece to being able to write programs, and it is the +because all processors participate in them. Collectives allow us +to write programs where not every copy of the executable is doing +something completely different (this would be incredibly difficult to +program) but where all copies are doing the same thing (though on +different data) for themselves, running through the same blocks of code; +then they communicate data through collectives and then go back to doing +something for themselves again running through the same blocks of data. +This is the key piece to being able to write programs, and it is the key component to making sure that programs can run on any number of processors, since we do not have to write different code for each of the participating processors. diff --git a/examples/step-40/doc/intro.dox b/examples/step-40/doc/intro.dox index 8f54095cd8..c26d797eb2 100644 --- a/examples/step-40/doc/intro.dox +++ b/examples/step-40/doc/intro.dox @@ -52,13 +52,13 @@ entire problem these thousands of computers are solving on every last processor is clearly not going to scale: it is going to take forever, and maybe more importantly no single machine will have enough memory to store a mesh that has a billion cells (at least not at the time of -writing this). In reality, programs like step-17 and step-18 can therefore -not be run on more than maybe 100 or 200 processors, and even then storing -the Triangulation and DoFHandler objects consumes the vast majority of +writing this). In reality, programs like step-17 and step-18 can therefore +not be run on more than maybe 100 or 200 processors, and even then storing +the Triangulation and DoFHandler objects consumes the vast majority of memory on each machine. -Consequently, we need to approach the problem differently: to scale to -very large problems, each processor can only store its own little piece +Consequently, we need to approach the problem differently: to scale to +very large problems, each processor can only store its own little piece of the Triangulation and DoFHandler objects. deal.II implements such a scheme in the parallel::distributed namespace and the classes therein. It builds on an external library,