--- /srv/reproducible-results/rbuild-debian/r-b-build.sbdGUJbp/b1/deal.ii_9.6.2-1~exp2_amd64.changes +++ /srv/reproducible-results/rbuild-debian/r-b-build.sbdGUJbp/b2/deal.ii_9.6.2-1~exp2_amd64.changes ├── Files │ @@ -1,5 +1,5 @@ │ │ c180773b3d04becbcd13923d558c5901 911417852 debug optional libdeal.ii-9.6.2-dbgsym_9.6.2-1~exp2_amd64.deb │ ae8ee652af5716e79cc1abcd7e5ec4e6 85954048 libs optional libdeal.ii-9.6.2_9.6.2-1~exp2_amd64.deb │ 5b42a4f885c46f7b908f2d85780d73e4 2258072 libdevel optional libdeal.ii-dev_9.6.2-1~exp2_amd64.deb │ - 45233d252dce41f45ced63fd7d7ab4d2 286235212 doc optional libdeal.ii-doc_9.6.2-1~exp2_all.deb │ + 4197c69fb6c53298a5fdbf9e212fe5f9 286237980 doc optional libdeal.ii-doc_9.6.2-1~exp2_all.deb ├── libdeal.ii-doc_9.6.2-1~exp2_all.deb │ ├── file list │ │ @@ -1,3 +1,3 @@ │ │ -rw-r--r-- 0 0 0 4 2024-12-22 18:01:11.000000 debian-binary │ │ --rw-r--r-- 0 0 0 270548 2024-12-22 18:01:11.000000 control.tar.xz │ │ --rw-r--r-- 0 0 0 285964472 2024-12-22 18:01:11.000000 data.tar.xz │ │ +-rw-r--r-- 0 0 0 270612 2024-12-22 18:01:11.000000 control.tar.xz │ │ +-rw-r--r-- 0 0 0 285967176 2024-12-22 18:01:11.000000 data.tar.xz │ ├── control.tar.xz │ │ ├── control.tar │ │ │ ├── ./md5sums │ │ │ │ ├── ./md5sums │ │ │ │ │┄ Files differ │ ├── data.tar.xz │ │ ├── data.tar │ │ │ ├── file list │ │ │ │ @@ -8973,19 +8973,19 @@ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 276457 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_14.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 12134 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_15.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 4673 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_16.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 125362 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_17.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 258057 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_18.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 157301 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_19.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 220616 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_1a.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 289804 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_1b.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 289315 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_1b.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 40894 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_1c.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 235387 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_1d.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 464546 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_1e.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 260240 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_1f.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 465583 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_1e.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 259941 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_1f.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 3645 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_2.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 56423 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_20.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 167601 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_21.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 36152 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_22.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 3907 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_23.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 269 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_24.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 4076 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_25.js │ │ │ │ @@ -8997,15 +8997,15 @@ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1892 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_7.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 2888 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_8.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 3088 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_9.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 7437 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_a.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 350 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_b.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 258512 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_c.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 107860 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_d.js │ │ │ │ --rw-r--r-- 0 root (0) root (0) 418156 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_e.js │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 417992 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_e.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 200058 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/all_f.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 43245 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/classes_0.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 9809 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/classes_1.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 5320 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/classes_10.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 13686 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/classes_11.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 59275 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/classes_12.js │ │ │ │ -rw-r--r-- 0 root (0) root (0) 38047 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/search/classes_13.js │ │ │ │ @@ -11603,15 +11603,15 @@ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 4917 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/transformations_8cc.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 9185 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/transformations_8cc_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 44728 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/transformations_8h.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 164520 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/transformations_8h_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 6365 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/tria__accessor_8cc.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 659755 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/tria__accessor_8cc_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 18086 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/tria__accessor_8h.html │ │ │ │ --rw-r--r-- 0 root (0) root (0) 439890 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/tria__accessor_8h_source.html │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 440325 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/tria__accessor_8h_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 7132 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/tria__base_8cc.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 162457 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/tria__base_8cc_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 7664 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/tria__base_8h.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 48418 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/tria__base_8h_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 16689 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/tria__description_8cc.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 233874 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/tria__description_8cc_source.html │ │ │ │ -rw-r--r-- 0 root (0) root (0) 16061 2024-12-22 18:01:11.000000 ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/tria__description_8h.html │ │ │ ├── ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/cell__status_8h.html │ │ │ │ @@ -147,21 +147,21 @@ │ │ │ │ │ │ │ │
The cell will be or was refined.
│ │ │ │The children of this cell will be or were coarsened into this cell.
│ │ │ │Invalid status. Will not occur for the user.
│ │ │ │Definition at line 30 of file cell_status.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ├── ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/classAffineConstraints.html │ │ │ │ @@ -636,15 +636,15 @@ │ │ │ │Constructor. The supplied IndexSet defines for which indices this object will store constraints. In a calculation with a DoFHandler object based on parallel::distributed::Triangulation or parallel::shared::Triangulation, one should use the set of locally relevant DoFs (see GlossLocallyRelevantDof).
│ │ │ │The given IndexSet allows the AffineConstraints container to save memory by just not caring about degrees of freedom that are not of importance to the current processor. In contrast, in parallel computations, if you do not provide such an index set (here, or using the reinit() function that takes such an argument), the current object will allocate memory proportional to the total number of degrees of freedom (accumulated over all processes), which is clearly wasteful and not efficient – and should be considered a bug.
│ │ │ │ -Definition at line 2312 of file affine_constraints.h.
│ │ │ │ │ │ │ │clear() the AffineConstraints object and supply an IndexSet that describes for which degrees of freedom this object can store constraints. See the discussion in the documentation of the constructor of this class that takes a single index set as argument.
│ │ │ │ -This function copies the content of constraints_in
with DoFs that are element of the IndexSet filter
. Elements that are not present in the IndexSet are ignored. All DoFs will be transformed to local index space of the filter, both the constrained DoFs and the other DoFs these entries are constrained to. The local index space of the filter is a contiguous numbering of all (global) DoFs that are elements in the filter.
If, for example, the filter represents the range [10,20)
, and the constraints object constraints_in
includes the global indices {7,13,14}
, the indices {3,4}
are added to the calling constraints object (since 13 and 14 are elements in the filter and element 13 is the fourth element in the index, and 14 is the fifth).
This function provides an easy way to create a AffineConstraints for certain vector components in a vector-valued problem from a full AffineConstraints, i.e. extracting a diagonal subblock from a larger AffineConstraints. The block is specified by the IndexSet argument.
│ │ │ │ -The same as above.
│ │ │ │ -The same as above.
│ │ │ │ -The same as above.
│ │ │ │ -Implementation of Arnold-Boffi-Falk (ABF) elements, conforming with the space Hdiv. These elements generate vector fields with normal components continuous between mesh cells.
│ │ │ │These elements are based on an article from Arnold, Boffi and Falk: Quadrilateral H(div) finite elements, SIAM J. Numer. Anal. Vol.42, No.6, pp.2429-2451
│ │ │ │In this article, the authors demonstrate that the usual RT elements and also BDM and other proposed finite dimensional subspaces of H(div) do not work properly on arbitrary FE grids. I.e. the convergence rates deteriorate on these meshes. As a solution the authors propose the ABF elements, which are implemented in this class.
│ │ │ │This class is not implemented for the codimension one case (spacedim != dim
).
The interpolation operators associated with the RT element are constructed such that interpolation and computing the divergence are commuting operations. We require this from interpolating arbitrary functions as well as the restriction matrices. It can be achieved by two interpolation schemes, the simplified one in FE_RaviartThomasNodal and the original one here:
│ │ │ │On edges or faces, the node values are the moments of the normal component of the interpolated function with respect to the traces of the RT polynomials. Since the normal trace of the RT space of degree k on an edge/face is the space Qk, the moments are taken with respect to this space.
│ │ │ │Higher order RT spaces have interior nodes. These are moments taken with respect to the gradient of functions in Qk on the cell (this space is the matching space for RTk in a mixed formulation).
│ │ │ │The Brezzi-Douglas-Marini element.
│ │ │ │The matching pressure space for FE_BDM of order k is the element FE_DGP of order k-1.
│ │ │ │The BDM element of order p
has p+1 degrees of freedom on each face. These are implemented as the function values in the p+1 Gauss points on each face.
Additionally, for order greater or equal 2, we have additional p(p-1), the number of vector valued polynomials in Pp, interior degrees of freedom. These are the vector function values in the first p(p-1)/2 of the p2 Gauss points in the cell.
│ │ │ │ │ │ │ │ │ │ │ │Definition at line 87 of file fe_rt_bubbles.h.
│ │ │ │Ginkgo matrix data structure. First template parameter is for storing the array of the non-zeros of the matrix. The second is for the row pointers and the column indices.
│ │ │ │ -Definition at line 195 of file ginkgo_solver.h.
│ │ │ │ │ │ │ │Ginkgo matrix data structure. First template parameter is for storing the array of the non-zeros of the matrix. The second is for the row pointers and the column indices.
│ │ │ │ -Definition at line 195 of file ginkgo_solver.h.
│ │ │ │ │ │ │ │Ginkgo matrix data structure. First template parameter is for storing the array of the non-zeros of the matrix. The second is for the row pointers and the column indices.
│ │ │ │ -Definition at line 195 of file ginkgo_solver.h.
│ │ │ │ │ │ │ │Ginkgo matrix data structure. First template parameter is for storing the array of the non-zeros of the matrix. The second is for the row pointers and the column indices.
│ │ │ │ -Definition at line 195 of file ginkgo_solver.h.
│ │ │ │ │ │ │ │Ginkgo matrix data structure. First template parameter is for storing the array of the non-zeros of the matrix. The second is for the row pointers and the column indices.
│ │ │ │ -Definition at line 195 of file ginkgo_solver.h.
│ │ │ │ │ │ │ │Ginkgo matrix data structure. First template parameter is for storing the array of the non-zeros of the matrix. The second is for the row pointers and the column indices.
│ │ │ │ -Definition at line 195 of file ginkgo_solver.h.
│ │ │ │ │ │ │ │Ginkgo matrix data structure. First template parameter is for storing the array of the non-zeros of the matrix. The second is for the row pointers and the column indices.
│ │ │ │ -Definition at line 195 of file ginkgo_solver.h.
│ │ │ │ │ │ │ │Definition at line 312 of file read_write_vector.h.
│ │ │ │ │ │ │ │Definition at line 341 of file read_write_vector.h.
│ │ │ │ │ │ │ │Definition at line 371 of file read_write_vector.h.
│ │ │ │ │ │ │ │Definition at line 403 of file read_write_vector.h.
│ │ │ │ │ │ │ │Definition at line 435 of file read_write_vector.h.
│ │ │ │ │ │ │ │Definition at line 464 of file read_write_vector.h.
│ │ │ │ │ │ │ │Definition at line 493 of file read_write_vector.h.
│ │ │ │ │ │ │ │Definition at line 514 of file trilinos_tpetra_vector.h.
│ │ │ │ │ │ │ │Base class used to declare the operations needed by a concrete class implementing prolongation and restriction of vectors in the multigrid context. This class is abstract and has no implementation of these operations.
│ │ │ │There are several derived classes, reflecting the fact that vector types and numbering of the fine-grid discretization and of the multi-level implementation are independent.
│ │ │ │If you use multigrid for a single PDE or for your complete system of equations, you will use MGTransferPrebuilt together with Multigrid. The vector types used on the fine grid as well as for the multilevel operations may be Vector or BlockVector. In both cases, MGTransferPrebuilt will operate on all components of the solution.
│ │ │ │For mixed systems, it may be required to do multigrid only for a single component or for some components. The classes MGTransferSelect and MGTransferBlock handle these cases.
│ │ │ │MGTransferSelect is used if you use multigrid (on Vector objects) for a single component, possibly grouped using mg_target_component
.
The class MGTransferBlock handles the case where your multigrid method operates on BlockVector objects. These can contain all or a consecutive set of the blocks of the complete system. Since most smoothers cannot operate on block structures, it is not clear whether this case is really useful. Therefore, a tested implementation of this case will be supplied when needed.
│ │ │ │ │ │ │ │ │ │ │ │Here, we have not gained very much, except that we do not need to set up empty blocks in the block system.
│ │ │ │Definition at line 110 of file matrix_block.h.
│ │ │ │Add all elements in a FullMatrix into sparse matrix locations given by indices
. This function assumes a quadratic sparse matrix and a quadratic full_matrix. The global locations are translated into locations in this block and ExcBlockIndexMismatch is thrown, if the global index does not point into the block referred to by row and column.
elide_zero_values
is currently ignored.elide_zero_values
is currently ignored.The optional parameter elide_zero_values
can be used to specify whether zero values should be added anyway or these should be filtered away and only non-zero data is added. The default value is true
, i.e., zero values won't be added into the matrix.
Definition at line 757 of file matrix_block.h.
│ │ │ │ │ │ │ │Add all elements in a FullMatrix into global locations given by row_indices
and col_indices
, respectively. The global locations are translated into locations in this block and ExcBlockIndexMismatch is thrown, if the global index does not point into the block referred to by row and column.
elide_zero_values
is currently ignored.elide_zero_values
is currently ignored.The optional parameter elide_zero_values
can be used to specify whether zero values should be added anyway or these should be filtered away and only non-zero data is added. The default value is true
, i.e., zero values won't be added into the matrix.
Definition at line 695 of file matrix_block.h.
│ │ │ │ │ │ │ │Set several elements in the specified row of the matrix with column indices as given by col_indices
to the respective value. This is the function doing the actual work for the ones adding full matrices. The global locations row_index
and col_indices
are translated into locations in this block and ExcBlockIndexMismatch is thrown, if the global index does not point into the block referred to by row and column.
elide_zero_values
is currently ignored.elide_zero_values
is currently ignored.The optional parameter elide_zero_values
can be used to specify whether zero values should be added anyway or these should be filtered away and only non-zero data is added. The default value is true
, i.e., zero values won't be added into the matrix.
Definition at line 780 of file matrix_block.h.
│ │ │ │ │ │ │ │Assemble local matrices into level matrices without using block structure.
│ │ │ │ -Constructor, selecting the solver and other parameters specified in additional_data
.
Definition at line 495 of file nonlinear.h.
│ │ │ │ │ │ │ │Constructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
│ │ │ │ - │ │ │ │ + │ │ │ │ │ │ │ │Definition at line 368 of file petsc_solver.cc.
│ │ │ │ │ │ │ │Constructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
│ │ │ │ - │ │ │ │ + │ │ │ │ │ │ │ │Definition at line 439 of file petsc_solver.cc.
│ │ │ │ │ │ │ │Constructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
│ │ │ │ - │ │ │ │ + │ │ │ │ │ │ │ │Definition at line 341 of file petsc_solver.cc.
│ │ │ │ │ │ │ │Constructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
│ │ │ │ - │ │ │ │ + │ │ │ │ │ │ │ │Definition at line 466 of file petsc_solver.cc.
│ │ │ │ │ │ │ │Constructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
│ │ │ │ - │ │ │ │ + │ │ │ │ │ │ │ │Definition at line 314 of file petsc_solver.cc.
│ │ │ │ │ │ │ │Constructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
│ │ │ │ - │ │ │ │ + │ │ │ │ │ │ │ │Definition at line 404 of file petsc_solver.cc.
│ │ │ │ │ │ │ │Constructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
│ │ │ │ - │ │ │ │ + │ │ │ │ │ │ │ │Definition at line 575 of file petsc_solver.cc.
│ │ │ │ │ │ │ │Constructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
│ │ │ │ - │ │ │ │ + │ │ │ │ │ │ │ │Definition at line 610 of file petsc_solver.cc.
│ │ │ │ │ │ │ │Constructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
│ │ │ │ - │ │ │ │ + │ │ │ │ │ │ │ │Definition at line 264 of file petsc_solver.cc.
│ │ │ │ │ │ │ │Constructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
│ │ │ │ - │ │ │ │ + │ │ │ │ │ │ │ │Definition at line 520 of file petsc_solver.cc.
│ │ │ │ │ │ │ │Constructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
│ │ │ │ - │ │ │ │ + │ │ │ │ │ │ │ │Definition at line 493 of file petsc_solver.cc.
│ │ │ │ │ │ │ │Constructor. This constructor is deprecated and ignores the MPI communicator argument. Use the other constructor instead.
│ │ │ │ - │ │ │ │ + │ │ │ │ │ │ │ │Definition at line 650 of file petsc_solver.cc.
│ │ │ │ │ │ │ │std::function<void(const real_type t, VectorType &y)> PETScWrappers::TimeStepper< VectorType, PMatrixType, AMatrixType >::distribute | │ │ │ │
update_constrained_components
, but is deprecated. Use update_constrained_components
instead. update_constrained_components
, but is deprecated. Use update_constrained_components
instead. Definition at line 621 of file petsc_ts.h.
│ │ │ │ │ │ │ │std::function<void(const real_type t, const unsigned int step, const VectorType &y, bool &resize)> PETScWrappers::TimeStepper< VectorType, PMatrixType, AMatrixType >::decide_for_coarsening_and_refinement | │ │ │ │
decide_and_prepare_for_remeshing
except that it returns the decision whether or not to stop operations via the last reference argument of the function object instead of a plain return value. This callback is deprecated. Use decide_and_prepare_for_remeshing
instead. decide_and_prepare_for_remeshing
except that it returns the decision whether or not to stop operations via the last reference argument of the function object instead of a plain return value. This callback is deprecated. Use decide_and_prepare_for_remeshing
instead. Definition at line 656 of file petsc_ts.h.
│ │ │ │ │ │ │ │std::function<void(const std::vector<VectorType> &all_in, std::vector<VectorType> &all_out)> PETScWrappers::TimeStepper< VectorType, PMatrixType, AMatrixType >::interpolate | │ │ │ │
transfer_solution_vectors_to_new_mesh
, but is deprecated. Use transfer_solution_vectors_to_new_mesh
instead. transfer_solution_vectors_to_new_mesh
, but is deprecated. Use transfer_solution_vectors_to_new_mesh
instead. Definition at line 688 of file petsc_ts.h.
│ │ │ │ │ │ │ │Tell the particle where to store its properties (even if it does not own properties). Usually this is only done once per particle, but since the particle generator does not know about the properties we want to do it not at construction time. Another use for this function is after particle transfer to a new process.
│ │ │ │ -Definition at line 835 of file particle_accessor.h.
│ │ │ │ │ │ │ │Callback function that should be called before every refinement and when writing checkpoints. This function is used to register pack_callback() with the triangulation. This function is used in step-70.
│ │ │ │ -Definition at line 2186 of file particle_handler.cc.
│ │ │ │ │ │ │ │Callback function that should be called after every refinement and after resuming from a checkpoint. This function is used to register unpack_callback() with the triangulation. This function is used in step-70.
│ │ │ │ -Definition at line 2233 of file particle_handler.cc.
│ │ │ │ │ │ │ │The elements of this enum
are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Definition at line 2234 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2241 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2248 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2255 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Fill a vector with all tensor elements.
│ │ │ │This function unrolls all tensor entries into a single, linearly numbered vector. As usual in C++, the rightmost index of the tensor marches fastest.
│ │ │ │ -const Point<spacedim> PolarManifold< dim, spacedim >::center | │ │ │ │
The center of the spherical coordinate system.
│ │ │ │ -Definition at line 150 of file manifold_lib.h.
│ │ │ │ │ │ │ │Determine the orientation of the current entity described by its vertices vertices_1
relative to an entity described by vertices_0
. The two arrays given as arguments can be arrays of global vertex indices or local vertex indices, arrays of vertex locations, or arrays of any other objects identifying the vertices and the order in which they are encountered in a cell.
The size of the arrays, i.e., the template argument N
, must be equal to or larger than the number of vertices of the current entity. If it is larger, only those elements of the input and output arrays are read from or written to that correspond to valid vertex indices.
Definition at line 3183 of file reference_cell.h.
│ │ │ │ │ │ │ │Inverse function of compute_orientation(): Given a set of vertex-associated objects (such as vertex indices, locations, etc.) and a desired orientation permutation, return the permuted vertex information.
│ │ │ │The size of the input and output arrays, i.e., the template argument N
, must be equal to or larger than the number of vertices of the current entity. If it is larger, only those elements of the input and output arrays are read from or written to that correspond to valid vertex indices.
Definition at line 3259 of file reference_cell.h.
│ │ │ │ │ │ │ │An implementation of the transformation interface using the SLEPc Spectrum Folding. This transformation type has been removed in SLEPc 3.5.0 and thus cannot be used in the newer versions.
│ │ │ │ -Definition at line 211 of file slepc_spectral_transformation.h.
│ │ │ │std::function<VectorType &()> SUNDIALS::KINSOL< VectorType >::get_solution_scaling | │ │ │ │
A function object that users may supply and that is intended to return a vector whose components are the weights used by KINSOL to compute the vector norm of the solution. The implementation of this function is optional, and it is used only if implemented.
│ │ │ │ -The intent for this scaling factor is for problems in which the different components of a solution have vastly different numerical magnitudes – typically because they have different physical units and represent different things. For example, if one were to solve a nonlinear Stokes problem, the solution vector has components that correspond to velocities and other components that correspond to pressures. These have different physical units and depending on which units one chooses, they may have roughly comparable numerical sizes or maybe they don't. To give just one example, in simulations of flow in the Earth's interior, one has velocities on the order of maybe ten centimeters per year, and pressures up to around 100 GPa. If one expresses this in SI units, this corresponds to velocities of around \(0.000,000,003=3 \times 10^{-9}\) m/s, and pressures around \(10^9 \text{kg}/\text{m}/\text{s}^2\), i.e., vastly different. In such cases, computing the \(l_2\) norm of a solution-type vector (e.g., the difference between the previous and the current solution) makes no sense because the norm will either be dominated by the velocity components or the pressure components. The scaling vector this function returns is intended to provide each component of the solution with a scaling factor that is generally chosen as the inverse of a "typical velocity" or "typical pressure" so that upon multiplication of a vector component by the corresponding scaling vector component, one obtains a number that is of order of magnitude of one (i.e., a reasonably small multiple of one times the typical velocity/pressure). The KINSOL manual states this as follows: "The user should supply values \_form#2639, │ │ │ │ -which are diagonal elements of the scaling matrix such that \_form#2655 has │ │ │ │ +
The intent for this scaling factor is for problems in which the different components of a solution have vastly different numerical magnitudes – typically because they have different physical units and represent different things. For example, if one were to solve a nonlinear Stokes problem, the solution vector has components that correspond to velocities and other components that correspond to pressures. These have different physical units and depending on which units one chooses, they may have roughly comparable numerical sizes or maybe they don't. To give just one example, in simulations of flow in the Earth's interior, one has velocities on the order of maybe ten centimeters per year, and pressures up to around 100 GPa. If one expresses this in SI units, this corresponds to velocities of around \(0.000,000,003=3 \times 10^{-9}\) m/s, and pressures around \(10^9 \text{kg}/\text{m}/\text{s}^2\), i.e., vastly different. In such cases, computing the \(l_2\) norm of a solution-type vector (e.g., the difference between the previous and the current solution) makes no sense because the norm will either be dominated by the velocity components or the pressure components. The scaling vector this function returns is intended to provide each component of the solution with a scaling factor that is generally chosen as the inverse of a "typical velocity" or "typical pressure" so that upon multiplication of a vector component by the corresponding scaling vector component, one obtains a number that is of order of magnitude of one (i.e., a reasonably small multiple of one times the typical velocity/pressure). The KINSOL manual states this as follows: "The user should supply values \_form#2594, │ │ │ │ +which are diagonal elements of the scaling matrix such that \_form#2610 has │ │ │ │ all components roughly the same magnitude when \_form#304 is close to a │ │ │ │ solution".
│ │ │ │If no function is provided to a KINSOL object, then this is interpreted as implicitly saying that all of these scaling factors should be considered as one.
│ │ │ │Definition at line 651 of file kinsol.h.
│ │ │ │ ├── html2text {} │ │ │ │ │ @@ -367,16 +367,16 @@ │ │ │ │ │ the pressure components. The scaling vector this function returns is intended │ │ │ │ │ to provide each component of the solution with a scaling factor that is │ │ │ │ │ generally chosen as the inverse of a "typical velocity" or "typical pressure" │ │ │ │ │ so that upon multiplication of a vector component by the corresponding scaling │ │ │ │ │ vector component, one obtains a number that is of order of magnitude of one │ │ │ │ │ (i.e., a reasonably small multiple of one times the typical velocity/pressure). │ │ │ │ │ The _K_I_N_S_O_L manual states this as follows: "The user should supply values │ │ │ │ │ -\_form#2639, which are diagonal elements of the scaling matrix such that │ │ │ │ │ -\_form#2655 has all components roughly the same magnitude when \_form#304 is │ │ │ │ │ +\_form#2594, which are diagonal elements of the scaling matrix such that │ │ │ │ │ +\_form#2610 has all components roughly the same magnitude when \_form#304 is │ │ │ │ │ close to a solution". │ │ │ │ │ If no function is provided to a _K_I_N_S_O_L object, then this is interpreted as │ │ │ │ │ implicitly saying that all of these scaling factors should be considered as │ │ │ │ │ one. │ │ │ │ │ Note │ │ │ │ │ This variable represents a _u_s_e_r_ _p_r_o_v_i_d_e_d_ _c_a_l_l_b_a_c_k. See there for a │ │ │ │ │ description of how to deal with errors and other requirements and │ │ │ ├── ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/classSphericalManifold.html │ │ │ │ @@ -1344,15 +1344,15 @@ │ │ │ │const Point<spacedim> SphericalManifold< dim, spacedim >::center | │ │ │ │
The center of the spherical coordinate system.
│ │ │ │ -Definition at line 356 of file manifold_lib.h.
│ │ │ │ │ │ │ │Return a pointer to the first element of the underlying storage.
│ │ │ │ -Return a const pointer to the first element of the underlying storage.
│ │ │ │ -Return a pointer to the element past the end of the underlying storage.
│ │ │ │ -Return a const pointer to the element past the end of the underlying storage.
│ │ │ │ -Fill a vector with all tensor elements.
│ │ │ │This function unrolls all tensor entries into a single, linearly numbered vector. As usual in C++, the rightmost index of the tensor marches fastest.
│ │ │ │ -using Triangulation< dim, spacedim >::CellStatus = ::CellStatus | │ │ │ │
The elements of this enum
are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Definition at line 2234 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2241 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2248 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2255 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 767 of file trilinos_vector.h.
│ │ │ │ │ │ │ │Deprecated constructor.
│ │ │ │ -Definition at line 9399 of file data_out_base.cc.
│ │ │ │ │ │ │ │Deprecated constructor.
│ │ │ │ -Definition at line 9418 of file data_out_base.cc.
│ │ │ │ │ │ │ │Deprecated constructor.
│ │ │ │ -Definition at line 9455 of file data_out_base.cc.
│ │ │ │ │ │ │ │Get the XDMF content associated with this entry. If the entry is not valid, this returns an empty string.
│ │ │ │ -Definition at line 9555 of file data_out_base.cc.
│ │ │ │ │ │ │ │The elements of this enum
are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Definition at line 2234 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2241 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2248 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2255 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │The elements of this enum
are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Definition at line 2234 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2241 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2248 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2255 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │The elements of this enum
are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Load the refinement information saved with save() back in. The mesh must contain the same coarse mesh that was used in save() before calling this function.
│ │ │ │You do not need to load with the same number of MPI processes that you saved with. Rather, if a mesh is loaded with a different number of MPI processes than used at the time of saving, the mesh is repartitioned so that the number of cells is balanced among all processes. Individual repartitioning with non-identical weights for each cell, e.g., based on the number of dofs or particles per cell, needs to be invoked manually by calling repartition() afterwards.
│ │ │ │Cell-based data that was saved with DistributedTriangulationBase::DataTransfer::register_data_attach() can be read in with DistributedTriangulationBase::DataTransfer::notify_ready_to_unpack() after calling load().
│ │ │ │ -Implements parallel::DistributedTriangulationBase< dim, spacedim >.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2234 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2241 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2248 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2255 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │The elements of this enum
are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Definition at line 2234 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2241 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2248 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2255 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │The elements of this enum
are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Load the triangulation saved with save() back in. The mesh must be empty before calling this function.
│ │ │ │You need to load with the same number of MPI processes that you saved with, hence autopartition is disabled.
│ │ │ │Cell-based data that was saved with register_data_attach() can be read in with notify_ready_to_unpack() after calling load().
│ │ │ │ -Implements parallel::DistributedTriangulationBase< dim, spacedim >.
│ │ │ │ │ │ │ │Definition at line 741 of file fully_distributed_tria.cc.
│ │ │ │ │ │ │ │Definition at line 2234 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2241 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2248 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2255 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │The elements of this enum
are used to inform functions how a specific cell is going to change. This is used in the course of transferring data from one mesh to a refined or coarsened version of the mesh, for example. Note that this may me different than the refine_flag() and coarsen_flag() set on a cell, for example in parallel calculations, because of refinement constraints that an individual machine does not see.
Definition at line 2234 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2241 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2248 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Definition at line 2255 of file tria.h.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │std::map
instead. std::map
instead. std::map
instead. std::map
instead. std_cxx20::type_identity
instead. std_cxx20::type_identity
instead. ShortPRM
instead of ShortText
. PRM
instead of Text
. decide_and_prepare_for_remeshing
except that it returns the decision whether or not to stop operations via the last reference argument of the function object instead of a plain return value. This callback is deprecated. Use decide_and_prepare_for_remeshing
instead. decide_and_prepare_for_remeshing
except that it returns the decision whether or not to stop operations via the last reference argument of the function object instead of a plain return value. This callback is deprecated. Use decide_and_prepare_for_remeshing
instead. update_constrained_components
, but is deprecated. Use update_constrained_components
instead. update_constrained_components
, but is deprecated. Use update_constrained_components
instead. transfer_solution_vectors_to_new_mesh
, but is deprecated. Use transfer_solution_vectors_to_new_mesh
instead. transfer_solution_vectors_to_new_mesh
, but is deprecated. Use transfer_solution_vectors_to_new_mesh
instead. vtu
: .vtu
svg
: .svg
deal_II_intermediate
: .d2
. Definition at line 2496 of file data_out_base.cc.
│ │ │ │ │ │ │ │Extract the set of global DoF indices that are active on the current DoFHandler. For regular DoFHandlers, these are all DoF indices, but for DoFHandler objects built on parallel::distributed::Triangulation this set is a superset of DoFHandler::locally_owned_dofs() and contains all DoF indices that live on all locally owned cells (including on the interface to ghost cells). However, it does not contain the DoF indices that are exclusively defined on ghost or artificial cells (see the glossary).
│ │ │ │The degrees of freedom identified by this function equal those obtained from the dof_indices_with_subdomain_association() function when called with the locally owned subdomain id.
│ │ │ │ -Definition at line 1105 of file dof_tools.cc.
│ │ │ │ │ │ │ │Same function as above but for a certain (multigrid-)level. This function returns all DoF indices that live on all locally owned cells (including on the interface to ghost cells) on the given level.
│ │ │ │ -Definition at line 1152 of file dof_tools.cc.
│ │ │ │ │ │ │ │Extract the set of global DoF indices that are active on the current DoFHandler. For regular DoFHandlers, these are all DoF indices, but for DoFHandler objects built on parallel::distributed::Triangulation this set is the union of DoFHandler::locally_owned_dofs() and the DoF indices on all ghost cells. In essence, it is the DoF indices on all cells that are not artificial (see the glossary).
│ │ │ │ -Definition at line 1202 of file dof_tools.cc.
│ │ │ │ │ │ │ │Same as extract_locally_relevant_dofs() but for multigrid DoFs for the given level
.
Definition at line 1258 of file dof_tools.cc.
│ │ │ │ │ │ │ │For each active cell of a DoFHandler, extract the active finite element index and fill the vector given as second argument. This vector is assumed to have as many entries as there are active cells.
│ │ │ │For DoFHandler objects without hp-capabilities given as first argument, the returned vector will consist of only zeros, indicating that all cells use the same finite element. In hp-mode, the values may be different, though.
│ │ │ │As we do not know the active FE index on artificial cells, we set them to the invalid value numbers::invalid_fe_index.
│ │ │ │ -Definition at line 1499 of file dof_tools.cc.
│ │ │ │ │ │ │ │A version of the function of same name that returns the map via its third argument. This function is deprecated.
std::map
instead. A version of the function of same name that returns the map via its third argument. This function is deprecated.
std::map
instead. Definition at line 2430 of file dof_tools.cc.
│ │ │ │ │ │ │ │A version of the function of same name that returns the map via its third argument. This function is deprecated.
std::map
instead. A version of the function of same name that returns the map via its third argument. This function is deprecated.
std::map
instead. Definition at line 2451 of file dof_tools.cc.
│ │ │ │ │ │ │ │This is the opposite function to the one above. It generates a map where the keys are the support points of the degrees of freedom, while the values are the DoF indices. For a definition of support points, see this glossary entry.
│ │ │ │Since there is no natural order in the space of points (except for the 1d case), you have to provide a map with an explicitly specified comparator object. This function is therefore templatized on the comparator object. Previous content of the map object is deleted in this function.
│ │ │ │Just as with the function above, it is assumed that the finite element in use here actually supports the notion of support points of all its components.
│ │ │ │ -Same as above but for a specific number of sub-elements.
│ │ │ │ -Take a FiniteElement
object and return a boolean vector describing the restriction_is_additive_flags
(see the documentation of the FiniteElement class) for each shape function of the mixed element consisting of N1
, N2
, ... copies of the sub-elements fe1
, fe2
, ...
The "restriction is additive" flags are properties of individual shape functions that do not depend on whether the composed element uses the tensor product or combination strategy outlined in the documentation of the FETools::Composition namespace. Consequently, this function does not have a do_tensor_product
argument.
Compute the non-zero vector components of a composed finite element. This function is similar to the previous one, except that the pointers indicate the elements to be composed, and the arguments N1
, N2
, ... the multiplicities. Null pointers indicate that an argument is to be skipped.
If do_tensor_product
is true, the number of components (and thus the size of the ComponentMask objects) is the sum over the product of the number of components in each of the finite elements times the corresponding multiplicity. Otherwise the number of components is taken from the first finite element with non-zero multiplicity, and all other elements with non-zero multiplicities need to have the same number of vector components.
See the documentation of namespace FETools::Compositing for more information about the do_tensor_product
argument.
Definition at line 241 of file grid_tools.cc.
│ │ │ │ │ │ │ │[in] | axis | A unit vector that defines the axis of rotation |
[in] | angle | The rotation angle in radians |
Definition at line 164 of file mpi.cc.
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │The same trick with the mixed system does not work here, because we would end up with both Dirichlet and Neumann boundary conditions for \(u\), but none for \(v\).
│ │ │ │The solution to this conundrum arrived with the Discontinuous Galerkin method wave in the 1990s and early 2000s: In much the same way as one can use discontinuous shape functions for the Laplace equation by penalizing the size of the discontinuity to obtain a scheme for an equation that has one derivative on each shape function, we can use a scheme that uses continuous (but not \(C^1\) continuous) shape functions and penalize the jump in the derivative to obtain a scheme for an equation that has two derivatives on each shape function. In analogy to the Interior Penalty (IP) method for the Laplace equation, this scheme for the biharmonic equation is typically called the \(C^0\) IP (or C0IP) method, since it uses \(C^0\) (continuous but not continuously differentiable) shape functions with an interior penalty formulation.
│ │ │ │It is worth noting that the C0IP method is not the only one that has been developed for the biharmonic equation. step-82 shows an alternative method.
│ │ │ │We base this program on the \(C^0\) IP method presented by Susanne Brenner and Li-Yeng Sung in the paper "C \_form#5272 Interior Penalty Method │ │ │ │ +
We base this program on the \(C^0\) IP method presented by Susanne Brenner and Li-Yeng Sung in the paper "C \_form#5209 Interior Penalty Method │ │ │ │ for Linear Fourth Order Boundary Value Problems on polygonal │ │ │ │ domains" [Brenner2005] where the method is derived for the biharmonic equation with "clamped" boundary conditions.
│ │ │ │As mentioned, this method relies on the use of \(C^0\) Lagrange finite elements where the \(C^1\) continuity requirement is relaxed and has been replaced with interior penalty techniques. To derive this method, we consider a \(C^0\) shape function \(v_h\) which vanishes on \(\partial\Omega\). We introduce notation \( \mathbb{F} \) as the set of all faces of \(\mathbb{T}\), \( \mathbb{F}^b \) as the set of boundary faces, and \( \mathbb{F}^i \) as the set of interior faces for use further down below. Since the higher order derivatives of \(v_h\) have two values on each interface \(e\in \mathbb{F}\) (shared by the two cells \(K_{+},K_{-} \in \mathbb{T}\)), we cope with this discontinuity by defining the following single-valued functions on \(e\):
│ │ │ │ \begin{align*} │ │ │ │ \jump{\frac{\partial^k v_h}{\partial \mathbf n^k}} │ │ │ │ &= │ │ │ │ \frac{\partial^k v_h|_{K_+}}{\partial \mathbf n^k} \bigg |_e │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -175,15 +175,15 @@ │ │ │ │ │ (C^0\) IP (or C0IP) method, since it uses \(C^0\) (continuous but not │ │ │ │ │ continuously differentiable) shape functions with an interior penalty │ │ │ │ │ formulation. │ │ │ │ │ It is worth noting that the C0IP method is not the only one that has been │ │ │ │ │ developed for the biharmonic equation. _s_t_e_p_-_8_2 shows an alternative method. │ │ │ │ │ ******** DDeerriivvaattiioonn ooff tthhee CC00IIPP mmeetthhoodd ******** │ │ │ │ │ We base this program on the \(C^0\) IP method presented by Susanne Brenner and │ │ │ │ │ -Li-Yeng Sung in the paper "C \_form#5272 Interior Penalty Method for Linear │ │ │ │ │ +Li-Yeng Sung in the paper "C \_form#5209 Interior Penalty Method for Linear │ │ │ │ │ Fourth Order Boundary Value Problems on polygonal domains" [[BBrreennnneerr22000055]] where │ │ │ │ │ the method is derived for the biharmonic equation with "clamped" boundary │ │ │ │ │ conditions. │ │ │ │ │ As mentioned, this method relies on the use of \(C^0\) Lagrange finite elements │ │ │ │ │ where the \(C^1\) continuity requirement is relaxed and has been replaced with │ │ │ │ │ interior penalty techniques. To derive this method, we consider a \(C^0\) shape │ │ │ │ │ function \(v_h\) which vanishes on \(\partial\Omega\). We introduce notation \ │ │ │ ├── ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/step_58.html │ │ │ │ @@ -566,16 +566,16 @@ │ │ │ │ \left(\psi^{(n,2)}+\psi^{(n,1)}\right)\right] │ │ │ │ + │ │ │ │ V \left[\frac 12 \left(\psi^{(n,2)}+\psi^{(n,1)}\right)\right] = 0. │ │ │ │ \end{align*} │ │ │ │
│ │ │ │Here, the "previous" solution \(\psi^{(n,1)}\) (or the "initial │ │ │ │ condition" for this part of the time step) is the output of the first phase rotation half-step; the output of the current step will be denoted by \(\psi^{(n,2)}\). \(k_{n+1}=t_{n+1}-t_n\) is the length of the time step. (One could argue whether \(\psi^{(n,1)}\) and \(\psi^{(n,1)}\) live at time step \(n\) or \(n+1\) and what their upper indices should be. This is a philosophical discussion without practical impact, and one might think of \(\psi^{(n,1)}\) as something like \(\psi^{(n+\tfrac 13)}\), and \(\psi^{(n,2)}\) as \(\psi^{(n+\tfrac 23)}\) if that helps clarify things – though, again \(n+\frac 13\) is not to be understood as "one third time step after │ │ │ │ - \_form#432" but more like "we've already done one third of the work necessary │ │ │ │ -for time step \_form#3264".)
│ │ │ │ + \_form#418" but more like "we've already done one third of the work necessary │ │ │ │ +for time step \_form#3181".) │ │ │ │If we multiply the whole equation with \(k_{n+1}\) and sort terms with the unknown \(\psi^{(n+1,2)}\) to the left and those with the known \(\psi^{(n,2)}\) to the right, then we obtain the following (spatial) partial differential equation that needs to be solved in each time step:
│ │ │ │ \begin{align*} │ │ │ │ -i\psi^{(n,2)} │ │ │ │ - │ │ │ │ \frac 14 k_{n+1} \Delta \psi^{(n,2)} │ │ │ │ + │ │ │ │ \frac 12 k_{n+1} V \psi^{(n,2)} │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -378,16 +378,16 @@ │ │ │ │ │ step; the output of the current step will be denoted by \(\psi^{(n,2)}\). \(k_ │ │ │ │ │ {n+1}=t_{n+1}-t_n\) is the length of the time step. (One could argue whether \ │ │ │ │ │ (\psi^{(n,1)}\) and \(\psi^{(n,1)}\) live at time step \(n\) or \(n+1\) and │ │ │ │ │ what their upper indices should be. This is a philosophical discussion without │ │ │ │ │ practical impact, and one might think of \(\psi^{(n,1)}\) as something like \ │ │ │ │ │ (\psi^{(n+\tfrac 13)}\), and \(\psi^{(n,2)}\) as \(\psi^{(n+\tfrac 23)}\) if │ │ │ │ │ that helps clarify things – though, again \(n+\frac 13\) is not to be │ │ │ │ │ -understood as "one third time step after \_form#432" but more like "we've │ │ │ │ │ -already done one third of the work necessary for time step \_form#3264".) │ │ │ │ │ +understood as "one third time step after \_form#418" but more like "we've │ │ │ │ │ +already done one third of the work necessary for time step \_form#3181".) │ │ │ │ │ If we multiply the whole equation with \(k_{n+1}\) and sort terms with the │ │ │ │ │ unknown \(\psi^{(n+1,2)}\) to the left and those with the known \(\psi^{ │ │ │ │ │ (n,2)}\) to the right, then we obtain the following (spatial) partial │ │ │ │ │ differential equation that needs to be solved in each time step: │ │ │ │ │ \begin{align*} -i\psi^{(n,2)} - \frac 14 k_{n+1} \Delta \psi^{(n,2)} + \frac 12 │ │ │ │ │ k_{n+1} V \psi^{(n,2)} = -i\psi^{(n,1)} + \frac 14 k_{n+1} \Delta \psi^{(n,1)} │ │ │ │ │ - \frac 12 k_{n+1} V \psi^{(n,1)}. \end{align*} │ │ │ ├── ./usr/share/doc/libdeal.ii-doc/html/doxygen/deal.II/structDataOutBase_1_1VtkFlags.html │ │ │ │ @@ -183,15 +183,15 @@ │ │ │ │
using DataOutBase::VtkFlags::ZlibCompressionLevel = DataOutBase::CompressionLevel | │ │ │ │
A data type providing the different possible zlib compression levels. These map directly to constants defined by zlib.
│ │ │ │ -Definition at line 1166 of file data_out_base.h.
│ │ │ │ │ │ │ │A data type providing the different possible zlib compression levels. These map directly to constants defined by zlib.
│ │ │ │ -Definition at line 1166 of file data_out_base.h.
│ │ │ │ │ │ │ │A data type providing the different possible zlib compression levels. These map directly to constants defined by zlib.
│ │ │ │ -Definition at line 1166 of file data_out_base.h.
│ │ │ │ │ │ │ │unsigned int SolverGMRES< VectorType >::AdditionalData::max_n_tmp_vectors | │ │ │ │
Maximum number of temporary vectors. Together with max_basis_size, this parameter controls the size of the Arnoldi basis, which corresponds to max_n_tmp_vectors-2 as used in previous versions of the deal.II library. SolverGMRES assumes that there are at least three temporary vectors, so this value must be greater than or equal to three. If both this variable and max_basis_size are set to a non-zero value, the choice in max_basis_size takes precedence.
│ │ │ │ -Definition at line 391 of file solver_gmres.h.
│ │ │ │ │ │ │ │using identity = std_cxx20::type_identity<T> | │ │ │ │
A using
declaration to make the std::identity_type class available under the name that deal.II has used for a long time.
std_cxx20::type_identity
instead. std_cxx20::type_identity
instead. Definition at line 322 of file template_constraints.h.
│ │ │ │ │ │ │ │mapping
argument should be replaced by a hp::MappingCollection in case of a DoFHandler with hp-capabilities. Restriction matrices are missing.
│ │ │ │ -The 3d version exhibits some numerical instabilities, in particular for higher order
│ │ │ │ +Restriction matrices are missing.
│ │ │ │ +The 3d version exhibits some numerical instabilities, in particular for higher order
│ │ │ │elide_zero_values
is currently ignored. elide_zero_values
is currently ignored. elide_zero_values
is currently ignored. elide_zero_values
is currently ignored.