From a9e1dde6eb78ac8d35ac348647b10fcb11e5c22d Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Wed, 16 Sep 2009 12:09:29 +0000 Subject: [PATCH] Minor edit. git-svn-id: https://svn.dealii.org/trunk@19461 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/examples/step-35/doc/intro.dox | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/deal.II/examples/step-35/doc/intro.dox b/deal.II/examples/step-35/doc/intro.dox index 58c209f946..9b3aaf6b26 100644 --- a/deal.II/examples/step-35/doc/intro.dox +++ b/deal.II/examples/step-35/doc/intro.dox @@ -138,14 +138,14 @@ projection methods that we have just described: Our implementation of the projection methods follows verbatim the description given above. We must note, however, that as opposed to most other problems that have several solution components, we do not use -vector-valued finite elements. Instead, we use separate finite elements for each component of the velocity +vector-valued finite elements. Instead, we use separate finite elements the components of the velocity and the pressure, respectively, and use different DoFHandler's for those as well. The main reason for doing this is that, as we see from the description of the scheme, the dim components of the velocity and the pressure are decoupled. As a consequence, the equations for all the velocity components -look all the same, have the same system matrix, and can be solved in parallel. Obviously, this approach +look all the same, have the same system matrix, and can be solved in %parallel. Obviously, this approach has also its disadvantages. For instance, we need to keep several DoFHandlers and iterators synchronized when assembling matrices and right hand sides; obtaining quantities that are inherent to -vector-valued functions (i.e. divergences) becomes a little awkward, and others. +vector-valued functions (e.g. divergences) becomes a little awkward, and others.

The Testcase

-- 2.39.5