From 145d98e66fddb5874992e18fc9c0efdd041e1211 Mon Sep 17 00:00:00 2001 From: bangerth Date: Tue, 26 Oct 2010 20:11:50 +0000 Subject: [PATCH] Typo fix. git-svn-id: https://svn.dealii.org/trunk@22510 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/examples/step-40/doc/results.dox | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/deal.II/examples/step-40/doc/results.dox b/deal.II/examples/step-40/doc/results.dox index 56bb1e36f6..d9608411c7 100644 --- a/deal.II/examples/step-40/doc/results.dox +++ b/deal.II/examples/step-40/doc/results.dox @@ -70,7 +70,7 @@ the size of local problems is too small. For more discussions of these results we refer to the @ref distributed_paper "Distributed Computing paper". So how large are the largest problems one can solve? At the time of writing -this problem, the +this problem, the limiting factor is that the program uses the BoomerAMG algebraic multigrid method from the hypre package as @@ -110,7 +110,7 @@ would produce graphical output on the order of several 10 gigabyte. Currently, no program is able to visualize this amount of data in any reasonable way unless it also runs on at least several hundred processors. There are, however, approaches where visualization -program directly communicate with solvers on each processor with each +programs directly communicate with solvers on each processor with each visualization process rendering the part of the scene computed by the solver on this processor. Implementing such an interface would allow to quickly visualize things that are otherwise not amenable to -- 2.39.5