From: Timo Heister Date: Fri, 12 Aug 2016 16:04:14 +0000 (-0400) Subject: update documentation X-Git-Tag: v8.5.0-rc1~773^2~3 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f06ea71ad85631674a27e99622d01ba6cf8a4133;p=dealii.git update documentation --- diff --git a/examples/step-22/doc/intro.dox b/examples/step-22/doc/intro.dox index 5b7fb78496..0271a23b0f 100644 --- a/examples/step-22/doc/intro.dox +++ b/examples/step-22/doc/intro.dox @@ -767,7 +767,8 @@ comparison of their results. Apart from this, many other algorithms have been tested and improved during the creation of this program. For example, in building the sparsity pattern, we originally used a BlockCompressedSparsityPattern object that added one -element at a time; however, its data structures are poorly adapted for the +element at a time (this no longer exists in deal.II); however, its data +structures are poorly adapted for the large numbers of nonzero entries per row created by our discretization in 3d, leading to a quadratic behavior. Replacing the internal algorithms in deal.II to set many elements at a time, and using a diff --git a/examples/step-27/doc/intro.dox b/examples/step-27/doc/intro.dox index 5172b791d4..cc1fa99ef8 100644 --- a/examples/step-27/doc/intro.dox +++ b/examples/step-27/doc/intro.dox @@ -645,36 +645,17 @@ memory for all computations. A solution to the problem has already been discussed in step-11 and step-18. It used an intermediate object of type -CompressedSparsityPattern. This class uses a different memory storage scheme +DynamicSparsityPattern. This class uses a different memory storage scheme that is optimized to creating a sparsity pattern when maximal numbers of entries per row are not accurately available, but is unsuitable for use as the sparsity pattern actually underlying a sparse matrix. After building the intermediate object, it is therefore copied into a true SparsityPattern object, something that can be done very efficient and without having to over-allocate memory. Typical code doing this is shown in the documentation of -the CompressedSparsityPattern class. This solution is slower than directly +the DynamicSparsityPattern class. This solution is slower than directly building a SparsityPattern object, but only uses as much memory as is really necessary. -As it now turns out, the storage format used in the -CompressedSparsityPattern class is not very good for matrices with -truly large numbers of entries per row — where truly large -numbers mean in the hundreds. This isn't typically the case for lower -order elements even in 3d, but happens for high order elements in 3d; -for example, a vertex degree of freedom of a $Q_5$ element in 3d may -couple to as many as 1700 other degrees of freedom. In such a case -CompressedSparsityPattern will work, but by tuning the memory storage -format used internally in that class a bit will make it work several -times faster. This is what we did with the -CompressedSetSparsityPattern class — it has exactly the same -interface as the CompressedSparsityPattern class but internally stores -things somewhat differently. For most cases, there is not much of a -difference in performance in the classes (though the old class has a -slight advantage for lower order elements in 3d), but for high order -and $hp$ elements in 3d, the CompressedSetSparsityPattern has a -definite edge. We will therefore use it later when we build the -sparsity pattern in this tutorial program. -

Eliminating constrained degrees of freedom