~/f/dealii/RPMS.2017 ~/f/dealii ~/f/dealii RPMS.2017/deal_II-openmpi2-devel-9.5.1-0.0.x86_64.rpm RPMS/deal_II-openmpi2-devel-9.5.1-0.0.x86_64.rpm differ: byte 225, line 1 Comparing deal_II-openmpi2-devel-9.5.1-0.0.x86_64.rpm to deal_II-openmpi2-devel-9.5.1-0.0.x86_64.rpm comparing the rpm tags of deal_II-openmpi2-devel --- old-rpm-tags +++ new-rpm-tags @@ -10144 +10144 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/DEALGlossary.html cccc886f2c724688900b5c53e9de4d5306296ef7d4e10453788d33dfcf711aec 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/DEALGlossary.html 8a49ef8a7b956cf763d9d503aaa9b36fa6026f1f0e67e66e007df420766a2939 2 @@ -10147,3 +10147,3 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/Tutorial.html 5981bc17594d634d5c998b9f9b3c307ffb0ca69ae02e2a31812b14438922439a 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/_formulas.tex 73803629368461e23cf60133a1e5031168a5d8c391f65cdf717d29f63fc49dcf 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/_formulas_dark.tex f8261564f72db13c31931b9dc1d7138f7b2c4e3cb3f68cefb9e68973e451ae08 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/Tutorial.html 686d7c6e24f551f4b8fff6d0a54638fbf071428874fd7c3324c1130a29cc5acb 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/_formulas.tex c7fe65427ecfc7ee1966d36ea1c8059d746279efd33a0f8206afea768ab625d8 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/_formulas_dark.tex f65073c8125709c360fd001c9140e61d1c0ea88742c38e53961edb3369cd03c8 2 @@ -10316 +10316 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_6_1_and_6_2.html 1b031fe309c2f440e93f9e1bc6e529b1f47bf317b4bfa28b5e22e97108afde13 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_6_1_and_6_2.html 00a90296bfa47441d5053629d678ee0b434f3faa6a8020dea6d92373e0243364 2 @@ -10318 +10318 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_6_2_and_6_3.html 177c208d88a035849377449b6f4842842019284186c9b935a383bddb1509fdd0 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_6_2_and_6_3.html 1ac612f4b09451f76edb3712b790e31563d22664065135fe5ea2c6765fc0ae47 2 @@ -10321,2 +10321,2 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_7_0_and_7_1.html 6e6fdf60ed3398db378bb9e9a5dc9a5ff4eefb09e61df6d5c5b3fb23d5df5895 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_7_1_and_7_2.html ac9fb69e9f967304ae73754b996a2039fee7d656cf03c8934b1a2e7a82f61b83 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_7_0_and_7_1.html 0e00db3140984cb4e7a7b716a28808c871b696d59e41a35cc9f577e88934fdf6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_7_1_and_7_2.html f9c8bfbb7ecdce8d500cb68ac61d976b0a4b0addbda86d24076487b38a0020e4 2 @@ -10326 +10326 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_8_1_and_8_2.html 0df11d596510cdfb4458f6afe8d60ed7011634c92962a04357ce2b0982576d22 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_8_1_and_8_2.html 1cfdcfcc7acb5832de926339d2abd9ed6185751598127571455272c450371248 2 @@ -10332 +10332 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_8_4_2_and_8_5_0.html f48846ce65b7d298d116c6f6461bc8a2a5b4a72ef3b286378d1eef96a9480199 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_8_4_2_and_8_5_0.html 621ece18a816c1a5f9eb8f625aa55df9fd071d579a5bd2163a444bcf4e566b4a 2 @@ -10337 +10337 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_9_1_1_and_9_2_0.html ae9add35241009d1c7a0179fd8f1f65fb41538b7ba4c0dca59bf7303a69f1a29 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_9_1_1_and_9_2_0.html d119b01f39c6ed6f23e08dd0df0179e6173280ebd1a89564a57337202bd10a4e 2 @@ -10364 +10364 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAffineConstraints.html b6d8ffb7d21ba0b84112317ddd365bf34c8483db94d704f313032835a6f11491 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAffineConstraints.html 8a7756ec9070e7da12f20f034047bae68edf1c30b50c8aac6bee3f210baf36ff 2 @@ -10382 +10382 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAlgorithms_1_1ThetaTimestepping.html 3c1e42b16ed8049e9838baf969b8c95f9f5e97a1a82dcfba5ba8a835ce179cd3 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAlgorithms_1_1ThetaTimestepping.html 576f3c8590db66b7951c9157b28bc152c22f7c87086a17f53d705d3b475adfde 2 @@ -10399 +10399 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAnisotropicPolynomials.html 30233809b6b0acb44ca3c06a0d467b5c276060ebbd607c0ca3626cbe8d8ca2df 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAnisotropicPolynomials.html ee6bc3f8eb57ee1235ef804f1f2e9d29c734d13760373512418d39d3d48116cf 2 @@ -10436 +10436 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classArpackSolver.html f4fe6adb187ea6c9cb10e14706dc629dbbb741d107013182927ddf6f0ade36bf 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classArpackSolver.html a4193a2b15e9a0012da2b0675e0e86daa26ec6218fdb103d1562ccbd9566ac71 2 @@ -10439 +10439 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classArrayView.html 0f59aa41c866afda2e1ec19598d84fbd66b65a45807b6831be9cafceb5b353d2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classArrayView.html c4de72cee678cb9d3ee48d272a45bcf40c9f6310be3f0e4fc5e5644ca18a2c7b 2 @@ -10442 +10442 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAutoDerivativeFunction.html 868f29a981483d7a2425abc55d1a209724c3b259421b67df9a53e9f90bc4d6aa 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAutoDerivativeFunction.html 4f8671801c631714cc794d5ae33bf991b19cbc62b14b69feca4990d52bf48e2c 2 @@ -10445 +10445 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBarycentricPolynomial.html d80aaced474e3670ab87d597aff4123f1ba3857502c18be63feda313706f73cd 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBarycentricPolynomial.html 145ec71a4c7985a829424d3e2f52b7b2b99be8f6a692b6ac382a1af33163e988 2 @@ -10452 +10452 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBaseQR.html 1f358f363dbc96c776de421ccd1d4b092fa62eac9fc9cd79d60f9107df0e990c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBaseQR.html ce3c7b5c5ce5e4b12cc699aee1a590ea037aa63f93cfe075b03061379cd1245f 2 @@ -10458 +10458 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockIndices.html 91fcbe2550b6e3b60f3fa1628eeb3a791c84843beb6333b3da846358e06f53fc 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockIndices.html 28200009e6843167effa0d4b203bae1293164c5d36fb6cf1cd36780402c34a84 2 @@ -10464 +10464 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockLinearOperator.html add0e4675626fdcd5f75322484a7cd77dab9a4673ad07cf6fea5616d95aa5c42 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockLinearOperator.html da8bf0c014a01e67f480b681723923c4b7ae54dc85e70e22b4baf042a1821252 2 @@ -10469 +10469 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockMatrixBase.html 683a2aa7b8ef5beec4724ee3fa2292c138135c1dee6d729823bef64f96d78e7a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockMatrixBase.html f9a05f50c843e50e2986d7733dce5751116722b943e82a472f85dd9b96de8abd 2 @@ -10482 +10482 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockSparseMatrix.html 9293e59fe6cc7d23a4a7e5d4233d90b6fc7eee5150903c3aa4239c34f979cdc8 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockSparseMatrix.html ad4699b3c60c05c508da0f3741d4cafb0683fb93c1784706517e37fb46a27902 2 @@ -10484 +10484 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockSparseMatrixEZ.html 1c4f0c1d792dc7e23d9ffd70f52a82efcb41191c84d8ac1380ef9c89257d609e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockSparseMatrixEZ.html dfa19685c4c4492248087490089064e73bcb42fe97d62ec1aec53a4afa2139d9 2 @@ -10494 +10494 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockVector.html 93cc630eba389fc58d04ad8864f5adf37c6bc719c0a782377de10b0057952ed4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockVector.html 601eddd7558e32c9423da6643e5ff87029b2a24b43ae2c759f5a02847ca51e0f 2 @@ -10496 +10496 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockVectorBase.html f2c464f7a4a47cca1ca7c3db598b153ad01584f75a19aa8830cc667842e12ee5 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockVectorBase.html 4c620024fb28f9503d0cfb376be6409efac825ff1e5e41ceb83bdffe248e2b00 2 @@ -10500 +10500 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBoundingBox.html 830f3611efa91d9ae05a627ea0d9901e47fd7640b4d2993b84674f3171d22c41 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBoundingBox.html a500431ea5864821f19c79dc1696225dba1e732aa6eed7a25df3577c92955388 2 @@ -10513 +10513 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1PreconditionIC.html 4e920f51099519b0de45507edd6d2de1abc98c121df87e77af51611f0d18617b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1PreconditionIC.html df36a54aba46f922edab321b52484591c460135578ddee0516fea722550de82f 2 @@ -10515 +10515 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1PreconditionILU.html aa7909afac2f195ebf899beae8c3c04b3155500ac5cce357b3de92d452f4d591 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1PreconditionILU.html dec1d68d22e5bd0a41211b98ee3e0c7faef72f1c12047e274d5c3527555f0762 2 @@ -10519 +10519 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1SparseMatrix.html 57f6e4b2f15ec873f5bcb07279e2113ea60cb6b8c9cb7bcc540c0d904f487f03 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1SparseMatrix.html 9b8b63d3564be85403bd6cf49c6d059418d187a3b5053351fb4843428be01fe2 2 @@ -10522 +10522 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCellAccessor.html fc8826537f58cc32c5dc0cc3db063181de48348da07ec4812c1c9985ace64499 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCellAccessor.html 5128adcc69e4e7ae842ccf254f2733d9beb95300f5c066d4652dcfeafa486fdb 2 @@ -10532 +10532 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChartManifold.html da98afc92872a6cd012ba9cc434184a2e111997d88faea7d38a930b433e9e1c9 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChartManifold.html 653cc9c6be5ff839722b0eb4e9cda3bbe74bd46c35b06ab23f37bb3562d1454b 2 @@ -10535 +10535 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChunkSparseMatrix.html 6d8a614b44024b1d87323ed4b403f6d63976637ab4c0583b4010623777a1b6c7 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChunkSparseMatrix.html 7681d718593e81c198cbd1f410a8fbf9dc0f7f5570ffbce3ee0e6f4241bea164 2 @@ -10551 +10551 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChunkSparsityPattern.html f11d2a5f8c460fe76416a66345826a7ac72b20046ac66d11bbb0a89e83299c74 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChunkSparsityPattern.html c5b20eb72b39aea93f1213e5f1fa3500d6c71f57a334138c90397cfb47e53529 2 @@ -10559 +10559 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classComponentMask.html 2d2b15a1b3286c2d4be4b615370f3eca9c4c56c971092deda41a55ab18588d62 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classComponentMask.html bffda4c0c8738e78ad81cb1204a07087efab58a80cab794852b189ae79e8e027 2 @@ -10564 +10564 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCompositionManifold.html 4b7ae352aa53f54f183ace326b85103800ab486c85ad31fff33b57870f414aeb 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCompositionManifold.html e20ab928ec5fcd9760daf4cb8f9254b53c8d9294dade014ef8a6bba3ed52e4a1 2 @@ -10575 +10575 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classConvergenceTable.html 4ae9ebeca5c84fca963161a7c58b3e4f4bde8379406e92d78f1b5db1b0220e61 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classConvergenceTable.html ee123c828755b69b2095c30320e41d12db293a1f5372961c1d275a69050be2ba 2 @@ -10578 +10578 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCylindricalManifold.html 053c3c6dced1b15e33abfbe4bb03f392a45227ee16531e8859ec211c29cb9ea0 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCylindricalManifold.html 3968074e57a065b53e44f46bf13cfcb0a828373ad9f4daf632c5dcb88ae904f8 2 @@ -10607 +10607 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessor.html fd8bf2dd7a6fdd514c950dec7a1566701cbeb524cfbe5a236a5b5c899e498cde 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessor.html 7b02518e218fe72a9a324dee987e61db5c37e486840301d280bbd584f1a57385 2 @@ -10612 +10612 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessorTensor.html f1b2d5f8c2a20111f69b3b89a7e46d4c45d8dd289ee2dbc4ef3dffb9f92ce17e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessorTensor.html b359737a1c87ce772bbc03d117544c82292315eb2b45c77dd9f0c8874e8474fa 2 @@ -10615 +10615 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessorVector.html e3efeb7dd0598936441aa58ea010f9c1b7ca757d38fc0f510d4ea3cd587c27e2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessorVector.html 60ddd00a69f136cf2da90b3ddbb26a149b5a5ced68f61ecc38d0e0c7591fa411 2 @@ -10632 +10632 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1SecondDerivative.html b36662d142b284a426f88405ed4f2d1a727df681e2967134c6e1ddc3f557fcda 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1SecondDerivative.html 2678621a0fc4dbaf9bb3110d25b33060e01227b7de1f74814fc67d885155ed6e 2 @@ -10634 +10634 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1ThirdDerivative.html 0acda2652d2c745f5794259a906e71a21e3fa2acc1a0aaa5bad6352c97e0084f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1ThirdDerivative.html 187970bb379bace7134777a00ce0803679c788056689b240419c2635d826ddb5 2 @@ -10636 +10636 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeForm.html 05f050f73cced26b668da22036d12619cc5929a66e6e17657bf6754f2f018ace 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeForm.html 887cd5ccc8cc212fc19f11c85b7a38e59994c37eb6cf8a5338a986db6a9e8d3c 2 @@ -10642 +10642 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1CellLevelBase.html 9e31fe908eed2651d7884b50ffdd2da83731b9c52d43ad836e25ae8b58c670a8 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1CellLevelBase.html 7423e0d0e71c85c600054be1f0358bf2b9b70439590f095794e74b981aa2229e 2 @@ -10645 +10645 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1EnergyFunctional.html a9593c965e51e35fe7c764a5a4b855370826f456ab5148945a3d4cd5bcb7fe2c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1EnergyFunctional.html a93195f0887f9e87ac8966a9b7787a4502290129ae45216e79063cc5773418e4 2 @@ -10648 +10648 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1HelperBase.html 20e9c3ca748944b6cc1a4888aa83003c43612d77ee0e960acf8522026b90f22f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1HelperBase.html 9f32b5d12b1331952ff7b108ec0c826f72eb4696885f9d190bb2b3906328299c 2 @@ -10651 +10651 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1PointLevelFunctionsBase.html ed6ceaaa2296a41224a205280a4697949b44c3c20f57b3d9defb9396b2fe67d2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1PointLevelFunctionsBase.html d07207991c3ed623a86aa467d881beab19196268e783baf06996261513f0344e 2 @@ -10654 +10654 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1ResidualLinearization.html edfdd42f85b843cb2accb609b423e67f7216a37990129a12e953dc642f66140f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1ResidualLinearization.html ef48435459521b39ed49039c9af355993617654c798f025661cfce7c5f49575b 2 @@ -10657 +10657 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1ScalarFunction.html 56089a9039430bf8e3b9588d1b3d346e33b95201d898a4d9069896e287fa2a17 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1ScalarFunction.html 8b57d9ef39590df35e63563b906f9e418625e2fe3035919d89737e53ff8703f3 2 @@ -10660 +10660 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1VectorFunction.html bad8f5c5a531acb9969e17376c3bcbcefb79a3f30a06f0859988a5a45f00e7cd 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1VectorFunction.html 59d569dbe8f7fe913d56a045d7d8e79308d80460969ec50d626579431c563e60 2 @@ -10672 +10672 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDiscreteTime.html ae0178c435842ef0207802389b3dc03cb4a8477e163c41322ce02dcd97868951 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDiscreteTime.html dd0ac70b9b53d0336dde080afcf12e96683e9fb0c7d373af7a820f010f038e98 2 @@ -10683 +10683 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDoFHandler.html 592598dd0433b3af4e2439d575fbcd1ada399efc15a9cc3fc679eb47c86f93d1 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDoFHandler.html e93c9a08d9bbede725fd467c90b2740a1a296145ec375d85e57f36da51219c2b 2 @@ -10694 +10694 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDynamicSparsityPattern.html 038bad0f76b68ce85932e7439a53e125663f4e4a48dfc01f3e46c546860b825b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDynamicSparsityPattern.html 7dd4c88fa846ea5ab831d2105a15ed6a27d2ecb5c97be9e29a6524e50ac0a59f 2 @@ -10701 +10701 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classEigenInverse.html d782a277da78defff483478e25dfbdb70257dc0a4aa37d59a056e72beb98288c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classEigenInverse.html c7708ecba7b7d44dd12f4244b562217bd47f89aece4fb080e7d769a0ebdd9422 2 @@ -10704 +10704 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classEigenPower.html 8950569edcb16b952c2c5a0e3480be121d1ee9e0a9b0e67f7495d589f1557ae6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classEigenPower.html 0a96debb61fe1512695bdc1b12bd6b24ed2892b99f4503e0c9a204a22bb5207c 2 @@ -10707 +10707 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classEllipticalManifold.html b6cbf294342d9b55bab5da0871151fab448968e37f980f501c161de2cd915716 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classEllipticalManifold.html b6f0ce479a3ccd1d04a29477d2bd370858166f6634e3dc198517d4dd405133d0 2 @@ -10715 +10715 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluation.html 2ddb9364dbe2b61c127b40f397d8a51696c62e5d01dd668e36f4a6529b6df116 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluation.html d91098bc145eba1db5ad2a1cf7e1a1d37414435b5e50b626323851d7fbfb51bb 2 @@ -10717 +10717 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess.html a3a31fec4f7d65c304d294cdd010d3ae3487737d521c355d4128de819b707db7 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess.html a15a59c6ef8bbc64d5bc8874c3e27634f9c860faee83e574ac18e8c49eb4efba 2 @@ -10719 +10719 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_011_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 049a7ed3bd233384b791c887bb610826517fb7cda3de1039bbc6fc85c98823d1 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_011_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html ea7e927d6cf1f8ceacd9effb959eeea9281eb6c2e4c8e0641ce458cd85bcd848 2 @@ -10722 +10722 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 7653ed9468ce0a49d70782d7fb1293167e85e683122cc1c704420c3c61e732a4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 753b41f267761964287a908b9f2acdb3012599eaa1e2d83274c038df1df3d922 2 @@ -10725 +10725 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_01dim_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 5b1b91a808225fb58aa13ac60d395cc7f96ce81651b35302d08242fed0e865b9 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_01dim_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 52ac3df4ee610b121f105675d1302be73b31b25b73e49db440aca0d6337232b2 2 @@ -10729 +10729 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationBase.html d4ebaf15c8e0573c370caa3ddc46f3cc6abd43bdb8f732efafacd05796b777ae 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationBase.html 38dcf916b54259b266b4c59614a265fe8ffa2cbdf687ffa53b1ae8935ac6a294 2 @@ -10732 +10732 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationData.html beae7f98bb292f420e7bdeb2feab4050708f7772c0f6d5d9c83293a61bd7e642 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationData.html 0c639d687a2e056958dba7b4db96e1e5126450bf1528a5854f4f0ed3e29cc4a2 2 @@ -10736 +10736 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceEvaluation.html 965fc798b4f8fb248f25b8295720bb32b51dc06d412b1b97ce2323cf16a7dcca 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceEvaluation.html ee9f31289e8b9c8eb18fceb4f2c2627d19bf132506a8b9233f7d044b8f01487c 2 @@ -10739 +10739 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceValues.html b1b211dbd99468a462284acb1312fe6529505c9a48a15c46c6d0dc21a4912970 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceValues.html 999a0a20bf13cf656f3e78b44ce6b2c063255ed6737b30db0cf245f37583252c 2 @@ -10741 +10741 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceValuesBase.html 4089c9a3a4b9cf2363238bb30ff2c2f470582f144bb6c9439a048a19c4e849c8 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceValuesBase.html 2c21195fab00628db0f691071bc13c6eb458de00a3a651e0f0809a5e7fcceda9 2 @@ -10745 +10745 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceValues.html 08424fe0edfdf3bc5a2b119d2132e972f3628234c120a4613b6e7e68982425de 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceValues.html 2c4929d7fe56bed3fdd68707a8a0ef1440bfc8ba63bfb46f1ace29639327d095 2 @@ -10751 +10751 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceViews_1_1Scalar.html 9c37c86e645bc1dd62c5a9ff9d837f1641a989e9a860bdd902b9010a5655e472 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceViews_1_1Scalar.html beda6af5032121968ebe44ca53fcd927b924bab531221b465813ebb429dda07c 2 @@ -10754 +10754 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceViews_1_1Vector.html 49ed165f87844ee69fb68411217d30e307269b69410159e1e03296bcb25e7188 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceViews_1_1Vector.html 5e13c29f3de8f7158a4a3ddf30242cd2ac8cdbe2171bbf9a0fb1c37b5a9fae73 2 @@ -10759 +10759 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESeries_1_1Fourier.html e5e21a31164042e97603623d3ac2fbe45f668f78a3116524f7f0f41764e8d9ba 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESeries_1_1Fourier.html 668a522d9cabcf50ae8ec53b2117fb77a80c665fca32f51ee092c63f02654a76 2 @@ -10762 +10762 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESeries_1_1Legendre.html 907213c9f302acf20497c0844a2ba675e5ef73831cad6c84b65c71043acab6a4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESeries_1_1Legendre.html f7eec706b4b6e19df99770d5a213d04c6fb3a623b159a30c7ec94a2ea14922ec 2 @@ -10765 +10765 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESubfaceValues.html 4ee001a1fd306cb16aa2ab70ed39795d88278b55e89640bf7dd266712ad78b76 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESubfaceValues.html dce30a2901a7d1e671acbc3e77dda3cf0492067efa2439dc190a033ecc744632 2 @@ -10768 +10768 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESystem.html d1faad2dbcb9374bd61283e72bb681dd1546c711e4582e432b4d3fdf32ba3cf6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESystem.html 9828f56926be0043fb157cab9741dc2b79a4d88087d2bc92615611e57477b218 2 @@ -10780 +10780 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValues.html 1d8529baa926bf3cac79aa5d462db170e9f3ad40599ae5fdd5a35686a590d1b4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValues.html a81685a0984c7faa4dda046a9751143dbbef29b110b57752dfd13d4a3ba988e6 2 @@ -10782 +10782 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesBase.html 618a7ec41244a7ce1a638d2154b68aaa078b681a0a28f1114e4074bd4ccae251 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesBase.html fce86f6a5677f77ac1db6193f28ad2041231ac85f61e592de5cf52ce4c23c9e2 2 @@ -10787 +10787 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Scalar.html 9525b1c5f303ea49728c5b31bce1028b84e390c1f6a52f832895f1f656fb760a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Scalar.html e3f47e33fe5c254fc6566f38560081d717dd4540ccb26bee4de717666ff69959 2 @@ -10791 +10791 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1SymmetricTensor_3_012_00_01dim_00_01spacedim_01_4.html ba3d3ba6fc7df0338c17633a24d3fa5b2d7ae6a5f04cdd4a57cb6393129e856d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1SymmetricTensor_3_012_00_01dim_00_01spacedim_01_4.html 28279a2298af15e54bb88a8130ec592ecd9ba5bf9d6ac8ea403c440feaef5158 2 @@ -10794 +10794 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Tensor_3_012_00_01dim_00_01spacedim_01_4.html 49e0fcbbc896441d22bdb0edb56184f2929aae11c29b75316d87bcfc4cf918d6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Tensor_3_012_00_01dim_00_01spacedim_01_4.html ee0c8c4b6712e3181eb206868f1ee3400b9b766772cf88fd5c573db529905a73 2 @@ -10796 +10796 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Vector.html 8869f78016d272dfb956913d80ee9fd1628adfdb5319fdd18f78cf1756885e5f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Vector.html 14ec23475abaac6e04a6d3bae520170d2b903a14d35aeced8dfc4e920e310525 2 @@ -10800 +10800 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__ABF.html 1ed1a5745d88b1ec904ea135073505cc6489fdfa87b315cbdea66e987bc0fe48 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__ABF.html 4161b072a29395dc207d9602dc3f869b52e1c6055a94fbbb5f34d4475ca7f94d 2 @@ -10806 +10806 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__BDM.html b61345a343bc17fc61a36629983a69e4cda83464cfecdac706591fd6619dedb5 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__BDM.html 5c3dc5f7ef46e9e23043de34e09cfa3acc44f7c25469f3a72bc81669a2544086 2 @@ -10809 +10809 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__BernardiRaugel.html 8c87796c11877e6b890e02dd663c1913c195827a73e92495f0fc2e094c964ac4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__BernardiRaugel.html d0b8c036c3fd93d6a9cb75a00026e238c923f45eeb9e79fd71e2f1506fa95b3d 2 @@ -10812 +10812 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Bernstein.html 7332690635aeef5f359a7ec976026edf01f1ba5459f517a6a9d5451b88916827 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Bernstein.html 9ef02cc657f69183a9a876496e4515721096b7de11764e60755854e1988a20df 2 @@ -10815 +10815 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGBDM.html a3b36adef3e2570612155dd9becba83f329be54f2565382d90141be6488d565a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGBDM.html 5a6e4ca11a87476d0e9b249d9476bad2e299bd6c2f2992b2b30d0c5c917aee50 2 @@ -10818 +10818 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGNedelec.html c577531549de1236cbbcca39054de0186ac4d7570dfd582657ddb48edda107c2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGNedelec.html 5ebd2ddd3345a1145504e1378507ccbe9a2251f1d1fce6c5fe69a54ef11f5ce4 2 @@ -10821 +10821 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGP.html 96cd5cba93e4eaf131088a82f50055c056cecf58cb3bea22005a023bf2077d61 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGP.html 1a9d12d3f0e5b7fcca754577b0149ec33db6089b1d634826a2457d96d5f5c06a 2 @@ -10823 +10823 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGPMonomial.html d8fcaf2093ff6308f1a6ae2878d475d412cd21375b1ed0ed848e08713620e77b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGPMonomial.html 02bbd262c6e0c3067efde1b0273ea94d4a1a074477f07de151ffd2bb48c2ccae 2 @@ -10826 +10826 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGPNonparametric.html 22f51c2aaec5fbbd85ef9d348c7e0c59386ea067936fe3ef66768b5a84e9c506 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGPNonparametric.html 59cf7f0c6c1383db63d098e8e5ff8f32cfb788df0a21bcfc60222c9ad0a0883f 2 @@ -10830 +10830 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQ.html 189f4b77c35474e6df7d74611d3cf424ee20a7d33f9f573feea0eaa4544dbcc2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQ.html 5cc9c60ce4bfd719c110e750fbe921257321b1ff5d6839e9a29d0476f4076607 2 @@ -10832 +10832 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQArbitraryNodes.html 2913251171f8d2db3ee257d8048a7208df0d397598cd884ff121973e0a445944 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQArbitraryNodes.html 7a5b7bdd42c6dbe36a8158231dbf03086b4504653de945a79393de54cf86041e 2 @@ -10835 +10835 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQHermite.html f811e53160ab77319267d7830489f4463056d080136da2cb6ae4efead26449d4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQHermite.html 1dd2713c32bdc1167008b3aa8f854e79ec9bc5b43082d3aec3fbfee15bb296e9 2 @@ -10838 +10838 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQLegendre.html d8fd03b319a29948da3de91a332aa0e19933586d9d5af711e4d8768251033b1c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQLegendre.html 54295453722561f5deb3b1514285bd31686068c9dcdf2c9a70dff56164236799 2 @@ -10842 +10842 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGRaviartThomas.html 6deaaebc1638adf435de279f68845ae861daa2c5b6bcd3354e47c0793d1a99b4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGRaviartThomas.html beab997d261aadcead72786e4c45ebae885d529755fbfe777c41ba84277220e5 2 @@ -10845 +10845 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGVector.html cd00320c33b90d60f96739bd115b0facc0848021caf0fb98461f5b26bfd15b2d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGVector.html d17be38370de96690ac1b47f666b5191696bca909f32846bf040b49176cd3751 2 @@ -10851 +10851 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Enriched.html cfe280fa1c02e0dd3dae13b1c2272e0943d3fc3cb777b86947edfc0f7761b62b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Enriched.html 1d2470d74cf488671984244157b58fc70f1fe8c428ebdf94bdac3e3f42bf478e 2 @@ -10857 +10857 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceP.html e8f8a68b2c18a18c2da5dda61a73937b2bb03f4c732677563ff3de2074f3e9b9 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceP.html f8ce6814d8093aacb2b15e33a03396cf31491c0795006d560037173ae3e54e48 2 @@ -10859 +10859 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceP_3_011_00_01spacedim_01_4.html d38b87a0a6e565a2e86cc1d3a7aa23b6a2757b95a74df4e853ccedd5ba937637 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceP_3_011_00_01spacedim_01_4.html b8280ba17ccf9e97b540835619b83dbcc2f3faec5dce3e6fc92c2bf339809ab2 2 @@ -10863 +10863 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceQ.html 4df2f6bd4d56271e3c03d8ed4dbec75304583dec56e5368fef4f6cf89de85763 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceQ.html 2d8a33515091adca527508d71fc37c39c68893805a415c4d68e87a86aef9267f 2 @@ -10865 +10865 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceQ_3_011_00_01spacedim_01_4.html a2dc367684e9cf5244898f15f9bfb3f058e9595d152ed23198b63307c224076d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceQ_3_011_00_01spacedim_01_4.html 55c560a91c3d48a3da4a61d248846554595214a917be9373d2d5bf045be61104 2 @@ -10869 +10869 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Nedelec.html a64ddcbdbe6dca2b78e60d0afa6532a7dc5b41e4047da3f349fe2ab1b28e31d4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Nedelec.html 9fccc57fb55902ae597aed040d113f61688d4d27c9dc01161bfe891ca5cba56a 2 @@ -10871 +10871 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__NedelecSZ.html 52df00b8916f133163ba710f033076de6528b1b0bf2aee5ae1cc87829aec528a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__NedelecSZ.html 2fbbc9acf8ad5572f9347cbf639ddfbf357f4fdf683e98667bacbb63095f9af5 2 @@ -10873 +10873 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__NedelecSZ_1_1InternalData.html 5fb9ec25691da051781edd67086da3cc3bcd423e312cd2a620596956c863a855 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__NedelecSZ_1_1InternalData.html 9d8be9c4222cbf12592d732dd613b2bb9f91957c2f22241a8e3113ddc9bdbf0d 2 @@ -10878 +10878 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Nothing.html 4763b3451ddc4a596d327b318faefc739cb0256a5e2b843b3a04c1195fc27137 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Nothing.html 80f9f9502366805b14501079037cd4f0e952e0cc340a1ef16edb5b96938f23ad 2 @@ -10882 +10882 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__P1NC.html 0d8eee503f3d26d7be0a42cb12149ee428eb6c9e86bfffd6749a854577e4ede5 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__P1NC.html 8f081949f3c4c81f3d08295b35a89f0fc6f78f78b59d8c0e099a51e66ab4963b 2 @@ -10885 +10885 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Poly.html f1ed86bc54675ab2d453ecdd97e989342dc7da61e8f2926787fff56c1722bb33 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Poly.html 52b237443052163d8c420747f7597db47d6489c82937b98b69ea6dd1ac2a9111 2 @@ -10887 +10887 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PolyFace.html 61e5127842906943e9aa2c37c56b0979ac87c72284412ec8f784d35a0e0bff32 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PolyFace.html 4fe0ec3a0f9a57e13bd5ba3154aa6c6828179bc524461bffea05c1c3682e978b 2 @@ -10893 +10893 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PolyTensor.html b1ba7a504b1f8c58a074e3bfc836a2a21fb7a0c15d80ab0f6b4c014141f80b6b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PolyTensor.html 17d8d27526b49495b0dcace1c8d42f86b1b1457d72df6282b620e2aced2c8da0 2 @@ -10903 +10903 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidDGP.html d8ab63ddea132ae4d015f2f44cafb02e8a60d177ad0748948e5cfd6da08e6bca 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidDGP.html 812d47249b19b29a59a17100b30d4c89112ae26c933b04e8d8eaa26020e65516 2 @@ -10906 +10906 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidP.html cd9a9d33f94e11e538672ba15e140d029f77a63b29956459cbb70ecd783b337f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidP.html a4751f2766abd99c18e9cc6c894a5c95d4e84260bd834b6f1ebb2b6a0274d4d4 2 @@ -10909 +10909 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidPoly.html f75aff98d299b21449c320757ed29668c47f31f442547354e1f75ec726e38fe7 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidPoly.html 8a863123d9bc8b80d55dd8d3771ec6389e50d0d205924feacc778036e1d2c952 2 @@ -10912 +10912 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q.html 79ef9143757c990b8d3fce1fb451e865804f2ffb563cfc855cba1d44341a2c5f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q.html 5787ee78b0943dd51eaa7be9a82941b07e955cf1bb0726167f2eeb3dc95b1106 2 @@ -10914 +10914 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Base.html bc7d61da94f6a9b2d211c9bda6dd44a2a555f324cb7ebb3a48c9bca50d89f8fa 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Base.html 03edb55826232eb0658546eac79ab9f0e9c79b4df7302980d60302aede3ce90f 2 @@ -10917 +10917 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Bubbles.html 529f45a3d3afe9b8da12a12b612da0bd93fd47853fbe8f35f28ce9c64b0497f1 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Bubbles.html f86839aa155291fe3dfe1cdda3bd2d3d124bb0c49c7bc6c2d96892ebe74ab52b 2 @@ -10920 +10920 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__DG0.html a77a86a76402aec7cfc8da1475e8233cb165d8d906455bd4992b79db6d70e600 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__DG0.html 8c4ce11beb09d54ac53990da166ee26a5d505c2943c8bd6b02960dc39f421934 2 @@ -10923 +10923 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Hierarchical.html 939fef7cbcf1357de07242cba949c7510bc084940576bf880399a4da3b98957a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Hierarchical.html 68cb5c9e6dd26040ad3269b969895799b7120f57a50dd43768d6be5dffc4839c 2 @@ -10927 +10927 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__iso__Q1.html de11c7fb8b3086d1d8ce9e4a1e71b49804d06dfd29cdeffbef55027ca936cbe3 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__iso__Q1.html 4cb57d1b8c38646eaf2409715fb0673d872953321749347b9654a9b21a74cf83 2 @@ -10930 +10930 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__RT__Bubbles.html 18d11957847439bb2af846e446a2796120d0c1ee1c638f5a9d50326843c63874 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__RT__Bubbles.html 052e9e2bb01f604abcb1f860edf9dc4bb11f2e4e472e573d9a63187e2999b6f8 2 @@ -10933 +10933 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__RannacherTurek.html f2aa56efdc84fcfe2a9c02db3e4486ebe2830859cf919faeb6fdb1bcabf17538 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__RannacherTurek.html eed287e4b02a75b2e98dc6da33feb74fe1215c75deacaecc020d30b84e3db633 2 @@ -10936 +10936 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__RaviartThomas.html aa2819ecf2628007f4b3b99ddb6a391ad231c63f7d448f6b79846da7ca9c3018 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__RaviartThomas.html 3cdf3053b0d3480dd2dc28bb28d372a86ef3f1425795859163f0b36bf66a6118 2 @@ -10938 +10938 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__RaviartThomasNodal.html c4d53e4212889acaf43c4cbe10abe074097d572a71829833d50456de18f8a720 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__RaviartThomasNodal.html 20e241b749582217e8af9edee7fe19130a122ee1850c751cc64720367df2dc6e 2 @@ -10942 +10942 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__SimplexDGP.html 1849ce9032efe5d8c0d871bd67e30d431a58ab3d38a6ac392302152c4795cf39 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__SimplexDGP.html 69e197b8f3c487e022a20f14c06621882eeb4a0b760d68ccc185307b9ce4d3ce 2 @@ -10945 +10945 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__SimplexP.html 1f045daeb715f68fcc0f30f905cc05fb833a6edc6788f5993fe6706b019dc274 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__SimplexP.html da05d57d0e41e0c5933d7f6e6e8c9b6d6661c5d712b76b9de76cb68334bfe951 2 @@ -10947 +10947 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__SimplexP__Bubbles.html e08e2f1520dd00cc7622e9b256058c12c8ff1125b351072d25f4143ab0f68f4b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__SimplexP__Bubbles.html 4e16bf4d1eef288bbec5375adb0702a0046fd0458a2d43f46ecedb8341b25e90 2 @@ -10951 +10951 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__SimplexPoly.html 17e24a7806f93d1cff52bc7ea8be288252cc78204327223a22f3b867d5a9b26d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__SimplexPoly.html 9fdf539714715762479c9c75135f6ce59ec841c08be8cfaef710b6a7aeb13465 2 @@ -10954 +10954 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__TraceQ.html b4b9c07284ac8da452c8bac8ca40922ce69383eeba1151d9159033978ad3807c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__TraceQ.html 2ef5de9cc35e8265a713cad5fc9c4cc8d68deed657a6a7881e97e0f84055642e 2 @@ -10956 +10956 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__TraceQ_3_011_00_01spacedim_01_4.html 00c1487d56f50b2ab02721ff5115238d5fcc2d0a224ccdf0cb873c39f06cceb6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__TraceQ_3_011_00_01spacedim_01_4.html 5f0b86396fa2015a495357bfd5c885c4fa4c097e73c4d1c66121d7075f743f77 2 @@ -10960 +10960 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__WedgeDGP.html f2d6a389fe929dc814512e308ec23fe03c9c163b3d2ccb4dbbcc03cc261c0044 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__WedgeDGP.html 4fdcbc58889f56dedca9e699034dd79b8cb33fc0efd9f36eb2499d839597e574 2 @@ -10963 +10963 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__WedgeP.html ebcaba09450be2657aac0e0428d1315bc3fcb29a6e8f320da37fd9359a32ad19 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__WedgeP.html 0d39447313edc0b9dcdfe979e1f019dfa414ea65cea1ab4b22c0f2ce86545d85 2 @@ -10966 +10966 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__WedgePoly.html 77014715731a40a403fe26260a66c8adb37428ca8866498e46f31572f080ed4c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__WedgePoly.html 61bc46b85a86b25c7750cc6917bd43a4eb88f7d52d3c715364c6d3b8d6e80c51 2 @@ -10978 +10978 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFiniteElement.html 0823f58c3a350a35f5b8087e81a4015e93a4f3e9c5cb45dbae86e279a8319988 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFiniteElement.html 68e2f832c0c752788a5302030d50f041ba17eeb303cf1073e0d986c665a89796 2 @@ -10980 +10980 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFiniteElementData.html 45472cfc3b36208a506d734d8cae3bc5f991b57630e6019e4d58892243e39718 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFiniteElementData.html a0a14bc3b62b8d6247e990c8837b666224d6903df725e97d47110f7769fc1633 2 @@ -10987 +10987 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFiniteSizeHistory.html f8a57ddb1e80a27989d07ae902c9b6382e67f7036dadae2942c4ff967e3516be 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFiniteSizeHistory.html 0ec6a30d52ddc66cfb307cd3545674f86f31e8fd041b4a73d2a7aca621c8d0d7 2 @@ -10989 +10989 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFlatManifold.html 5a5b2e839c1375d5cf6371b9808cdbabf9163a016173982928701ca42bf31cd1 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFlatManifold.html 6a9cbec60432d964c1f6064e6f7cd8962d874da09c2775a6fe611637fa7bd07a 2 @@ -10992 +10992 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFullMatrix.html 3bd4617066b137cd6858df02d09c6b22fd58f1695c4c817065efc7ec60f0d76b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFullMatrix.html 34c1dbcb2bf8620fc6b0b0280259b8fd6ff33bc9c2392f87ee249d1cd6e220d1 2 @@ -10996 +10996 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunction.html db9b7e9ed49e2604af8edf929e4eb27a57ff6d47d9bba4523ef503d7bf325e3d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunction.html 1427012fc8ae493c5414c205a100cf21a73408c6390e9116a5833e687c317ecd 2 @@ -10998 +10998 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctionDerivative.html a7858fc9cda7e75961246c652e799a44be087ad76e8509921798dac4887dc1eb 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctionDerivative.html 973a4c0394537700eafe82ea72e08114cf6c21a4b3f50701bf2a16cc2ce043ff 2 @@ -11004 +11004 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctionManifold.html 083fc5cb820d632531653e5ff25e979fa9ddb41276664acf7b486d09be505b39 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctionManifold.html 84fe3a09910d7876de79045c093f70aa2ab14d5c98061bf54cdeda8430316f00 2 @@ -11007 +11007 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctionParser.html 003bef4caf95e82e93efac44f8292b1326cfdb802cb381a9e1a44688b2491cee 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctionParser.html c191abdd8fef37a6fc09b560c9b865a3b1e784772151ce386cb61c56dbf4b188 2 @@ -11023 +11023 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1CoordinateRestriction.html a3995bb514d7cd3f5f1dbfb91fb326beaa14909564ebe6752fe19675808cff4d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1CoordinateRestriction.html aa2caf3c4800ea80d7ae596c51d3a9706d5a4dde2a3f8fdddc25f99d1a7838eb 2 @@ -11026 +11026 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1CosineFunction.html 3770cea77099464a8de49f235fb47c5515131c9290b0f7fc43b99b13ec34c522 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1CosineFunction.html 6c663e5b7d36053e19bd180dfbe41aac1db9a91453101f79fa20a3ca5213c980 2 @@ -11035 +11035 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1CutOffFunctionC1.html ca1fd46e2b68326aa6c1ac5c539c2de5a124a39e8db2f18ee6661ba78340bb28 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1CutOffFunctionC1.html 7db5cba1126c45c5dd25df8c1dd51e986294df968de32cfa30e8a1cff9f0346a 2 @@ -11038 +11038 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1CutOffFunctionCinfty.html e08736ad3b517f05a215f0cae3fcd35e6e7b4eb22913fa76d08025b2726368b6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1CutOffFunctionCinfty.html ee8dca78bebf8d1950c4fb8818b4fa2d50a7e0e6294fe2dd3a20e2584a50b6a6 2 @@ -11041 +11041 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1CutOffFunctionLinfty.html dd933f82d9d880a8fa3de5a64de48ba4d5b97e101c7a24ea02dd024d64c34895 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1CutOffFunctionLinfty.html 4355aef6176017c737ada88a71727d332b941737409f6d652a7f784cd3a84208 2 @@ -11059 +11059 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1FourierCosineFunction.html 835da87fcac9b1e63c97ce37aa6a666837b67626f3afcf4282df5ec20a2ea78b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1FourierCosineFunction.html ba073e50be325074888a11481499117bf2e3b948c2ee524c4d84525a77cbd135 2 @@ -11062 +11062 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1FourierCosineSum.html 6b81801f46c9daa8c7845aa210056bd1bf7a3caa818a2c98c2ff0702ab883c7d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1FourierCosineSum.html 2bcb0adbfce80f32331ef3136c145c5d59703708cc32e31bdba2fcc99e62b56a 2 @@ -11065 +11065 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1FourierSineFunction.html 10c2aa9a5699077434ede17522f97bf252e8c01020daabc5aaffaf4a2e9693eb 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1FourierSineFunction.html de187f2d28afa6528161d2a45997b368e48c33ab9415e5c22a025326122bf4bd 2 @@ -11068 +11068 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1FourierSineSum.html 1148b587c6af96d7fd8742e49f111d40f45615b0937d65fdb9c055ebf8bdad82 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1FourierSineSum.html b8e8be311c7a71af5263c9fc46ce1904a2ff893759c940e68a6627e090fff53b 2 @@ -11077 +11077 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1InterpolatedTensorProductGridData.html 3058197facd1c83b5b5030da2c42a0ddece050525619c06ffdedcd3fcc6209ad 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1InterpolatedTensorProductGridData.html a0faa83910996cae76fa7506079d01d2782809ac055995173f23e0f50dfb3204 2 @@ -11080 +11080 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1InterpolatedUniformGridData.html 460cb45595d9fc9fda3b7835f420281813228fa568479c574c418d1ed3cf8d73 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1InterpolatedUniformGridData.html 0bba6a68bb9648cb0c295d3ad96ebbd91bb424c674a3292c7aad2429679df248 2 @@ -11089 +11089 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1LSingularityFunction.html a38987b61f41d564e001e044a1c39f29c44c7c78f6795967a3fad5e57dc39e18 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1LSingularityFunction.html ae0232d94e78639f06cf30b43deacdd64b9aaf072113f04abe0f75741e1b1b43 2 @@ -11095 +11095 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1Monomial.html 37c2232616ee604dd83070a6f6430490dc12bdb2f31f6b9e413cdebe4980c6dc 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1Monomial.html 62932ac48f43810319d3ba37ef97599f4b49facf136427b850ce165f8b264468 2 @@ -11098 +11098 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1ParsedFunction.html 5437dac0a73a3b483d0f95c162b1a2ce34918e08de04af4d86e5fe6f453f00a8 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1ParsedFunction.html 1cb439bfb545a6f2c21e6335933885e9f3be23b7eaa80d98a13ff6d362bbe185 2 @@ -11101 +11101 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1PillowFunction.html 928c554a7a160772d543d7a0ab1ef1d91ff3cfd6235459677d885793b48dcbea 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1PillowFunction.html 654b267e3fd7b3b5294624551ffea9d5ec2b67b6cb45a33cd68944242416deb7 2 @@ -11104 +11104 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1PointRestriction.html 61e995ef4d21be9f0fc3d7b862a6a57d9b28d03ceda70ab01f4167874f17a0cc 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1PointRestriction.html f3daf524a4a98318225b9135863f4b20b283f41aa96c37d1701994fe4d0f0a13 2 @@ -11110 +11110 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1Polynomial.html 379f931ddf921676d868212eb096c9f00856119590cbe5869865b2f50327347e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1Polynomial.html 76d3a2ad85c65829c5d3539bfc991eee78f5935be977703946c1c3e93d9be2e5 2 @@ -11116 +11116 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Ellipsoid.html f83f19c9ea02adbb00310335540cfaffce63ecaab8f9ce44636f2887d2429f5e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Ellipsoid.html 50073cbd6346908ab08ff6aeb4ba54892611171a3bead9373f15e7a779879b51 2 @@ -11119 +11119 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Plane.html dfbb6173d8cd6e2e44f4546a26930dd01a9cf67f561565a41f71e5d88f8c726f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Plane.html a293b23f40f75a453c400f57422ac049efd40a5c5c7b59f570c84b0a2e5f2a2a 2 @@ -11122 +11122 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Rectangle.html 5ee593846b34bd822e4372aa64559a170e19577482c8a172eac4637547432e8b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Rectangle.html a5d874802041bd3b553526e651539e53b907b0140c3f797b62f97337962dedc6 2 @@ -11125 +11125 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Sphere.html f3da09deec24d8f6bd5e5f779fc08a11a5294cca5576d24c9cfbd3a19ae499b4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1Sphere.html 12c9502adbe5e676f9c2a28af96c7f64770dbcdde9c6e59c8d4ae79816f51975 2 @@ -11128 +11128 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1ZalesakDisk.html 6f9cbffbeccc4145f8981453d24f936c0a136d6886c69aa2feb201310941aed6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1SignedDistance_1_1ZalesakDisk.html b6e42f6411d2bdc838dcd30c7bf365edb3e8e723c9715e5539bd0aa5f79e643c 2 @@ -11137 +11137 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1Spherical.html a63d8aa33e53076b1d2ce87d78b2cf55aa1e3993a58ee7f05d05e3b4c6a87750 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1Spherical.html 324cde5863931e28795f0b9aa07a7376cde8d71480db20fc78f9dbc92ea20519 2 @@ -11146 +11146 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1StokesLSingularity.html 5fd4ddc641615156111081dfe1731888b3279ed232e2d87ae33c9dee0dc7f81a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFunctions_1_1StokesLSingularity.html cddc1af746f9a2abbe49606ac7b178321b210cd59057a93914ff22e150b590e7 2 @@ -11183 +11183 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classGridIn.html 1592f2aeb6d73baa7138a3eeb96f21330c6c9356c641fc88970a0bc9f12b7468 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classGridIn.html 5814acf48ae01f084e5ee55db675afffb1ad21e0f5a6b99a2206314a6bf1a84c 2 @@ -11223 +11223 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classHouseholder.html f984bc9266f3b1f3601e9a61815431a94f639ff0388637a0e228e237d4d6a52a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classHouseholder.html 597f9b2801ff836c0d1bc83059caaf3e5b793f05398a246d4862d5a7c1034f62 2 @@ -11226 +11226 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classIdentityMatrix.html 20215eea36f09cb2f0cf6f5ff922c19ebb28e90c2802dd7fa4133bac58241811 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classIdentityMatrix.html 8f29c712312da541b68fbd3e7c7d19af0f5ca71fe4425f9a3e9842c2bdaab427 2 @@ -11228 +11228 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classImplicitQR.html 8fdc05515264b548b77d3f77d90c50f638b68612ccb23394ad68cdd087b3adf0 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classImplicitQR.html e6497b7b42f99e96f239cb4625f39f5e7ec84fe21d41f27f58d42f28f9ec11f5 2 @@ -11231 +11231 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classIndexSet.html acd820febdd4628050f3fcccbb65063824f5cbcac85cf00d1c3517e39a81a65d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classIndexSet.html f8a31973c86b6681f6956d7b1a86e873844e3de390a3e1816f35c7b22e5ac502 2 @@ -11235 +11235 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classIndexSet_1_1IntervalAccessor.html 157ec94945d1f848453eeb6371f92e1d4b3383fbe7857f5c55dfdffb06168910 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classIndexSet_1_1IntervalAccessor.html 82de385980f4e71378033910079d650888dc86f0f9c500761b07d475e27517ac 2 @@ -11237 +11237 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classIndexSet_1_1IntervalIterator.html 2b561955fa2b5bb7e939d511163edc17326276996ad8a4a36e047b7cfae21e42 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classIndexSet_1_1IntervalIterator.html c12adb3dd34bd784055eb123723bee08c9eb5133b713dfd71d325c5e8f51224d 2 @@ -11241 +11241 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classIntegratedLegendreSZ.html 4bb750b7ec932730c8fef7a266e2fa471298cc4d5feeae35679a372c6aacbffd 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classIntegratedLegendreSZ.html 76193e9d152d6ab77392292580921563284046de20792c7f87709fcbd33226da 2 @@ -11283 +11283 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classKellyErrorEstimator.html 7c8b0fb81c69e84b936295ed3cf88769d0c1d24366855387c559d62234b2f134 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classKellyErrorEstimator.html e476a54ceefcf384df99019d664525b9f739b081e34bda0b1e94ae3c721bfda7 2 @@ -11285 +11285 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classKellyErrorEstimator_3_011_00_01spacedim_01_4.html 6af67401a820d8d75c5159be46d9d97a570783c93c0e1b9c202e6f497e56bdc4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classKellyErrorEstimator_3_011_00_01spacedim_01_4.html 0cc687143696d7eee778a876ec05330e9892e4e265d9384c2c5fb79ea25d15ef 2 @@ -11296 +11296 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLAPACKFullMatrix.html d1cbcb3c5a9428f33a4dd2c1024b49aeef6405da8d5272b466eae8c73fa5b1a7 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLAPACKFullMatrix.html c9b60679b6e0bb1e370ddbe7f9b0b4df0b7e6872e3f6b7383e20e9388f8224a4 2 @@ -11300 +11300 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLinearAlgebra_1_1CUDAWrappers_1_1Vector.html 9ef7a8e52b7d3e49adcc7b87e08c31298b05a3966b7bfa06210a2f886ecabb2e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLinearAlgebra_1_1CUDAWrappers_1_1Vector.html eca2a76b47d86a7b2fb662ba33f6011bd948e62ffc188810adde7b02df83fce1 2 @@ -11309 +11309 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLinearAlgebra_1_1ReadWriteVector.html 810ac0037b17a51e5dd5a3bfccac3be3f3b7ca04488a082d833674c2ab2af422 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLinearAlgebra_1_1ReadWriteVector.html f6d1e21c499a891b72c03fe9f0f8f9b86c354b3db4d76aeebd156a9fe87fec08 2 @@ -11326 +11326 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLinearAlgebra_1_1distributed_1_1BlockVector.html 31354709c0b9000f2b4c0a509fad755305d0eeb951162e596b86560eb5ab5af9 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLinearAlgebra_1_1distributed_1_1BlockVector.html 8c79bed5e3ee6b0694a43841b638b1d4c009cbd46ab32065b8bfc33558139d86 2 @@ -11329 +11329 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLinearAlgebra_1_1distributed_1_1Vector.html 904d6ca3cbf697f124d48415e148f864233adf302f6ed7898dda0e6ac6e3b60d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLinearAlgebra_1_1distributed_1_1Vector.html 38ff348f55dbcdbb9600db7d05b09d2df513713fdda2a3ddf3d71e52b37b60e5 2 @@ -11332 +11332 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLinearIndexIterator.html 8441d22f081b417c161cd72bb19d833b8b7a6832ed01a6f2de5abe97a2eef40f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLinearIndexIterator.html 078407751951e0dc78b6f72be6102d5cc5c0d91d1a2aaf1045fc65d4f1899ba0 2 @@ -11335 +11335 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLinearOperator.html c0484c1ede8754a2b247d5c593d037a1f6bbea98054e78efa7da6aad75c4a0ee 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classLinearOperator.html 6643ed4162a905b2be40f3e41f5fb380332ddc0ad7f445e4979d02d7011df03d 2 @@ -11453 +11453 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classManifold.html 6b2002c94fc12d3f3f3b89edff7279e69972156e78f5be736658197ed1baf5fa 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classManifold.html dad41b27bf075962cc6fe15c787d445cc98ee6e4e2ed1e17d0841dbd8ca721d1 2 @@ -11456 +11456 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMapping.html 76ca3e50950bcf1e720f05fb10eb0b9ca21a9e87e86c66eb0af20c3fa90b2306 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMapping.html 63f3dadde9f9b566e94c205ca4ad6da12dd5e312437118e5fbd321067e8e8d52 2 @@ -11458 +11458 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingC1.html 0c17b4363f9bfa21c2c78b162f698a958670d370da10e446a657dd4d28532626 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingC1.html 380ba641c2ec85e41bd9d97b4f7b4bd83b10f7768d0623381233859a605e4169 2 @@ -11461 +11461 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingCartesian.html f54b0d89014cd0627bc27debeaf80f8d50cfea20b88c2a89e3a59db39f2706c6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingCartesian.html 5b1f393cc8f18402c3e94d5073b131bd51ec8a3aa11bc2a095f89765c4952c67 2 @@ -11467 +11467 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingFE.html 8a207dda407894bcf9b7a18ddb212a8bdb820560bc816f568f8de5c7af586d06 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingFE.html ea52f5728160095f39109fb2fe563582864eb785f0b9886d0ebf0cc22f8108ad 2 @@ -11469 +11469 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingFEField.html e2bff61edff01caa7d40d23901498b8738c0779019a43839acf344b9bae5e81d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingFEField.html 9b3297cf187a50d623c04f87cb3a61ce19191773cd79570f81d97ab0d6bb62df 2 @@ -11471 +11471 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingFEField_1_1InternalData.html d3595d0a2a2d41b84d24b3f7e5d72772420ef3545b7c229818fdf5f78aba5348 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingFEField_1_1InternalData.html 67d3893fb7ab3738e617b934553849b6a54c5d9fe1f23e49332d7629c753346a 2 @@ -11475 +11475 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingFE_1_1InternalData.html a954c812545e1323192a868b7e2481da2c3b9301c2ed385c4cc8a6283a86b6bd 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingFE_1_1InternalData.html 4408f06dac6b36f0d38afb2c02ed50362db9ac328902461b1416da169063200f 2 @@ -11479 +11479 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingManifold.html 6d0c6b7a673cb026b9c0734f06194c1a78ef5640ca4b0f649208cd2f15436094 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingManifold.html 02b39c9e50a3578f5f1398eed97d647e158db066ba59d64f7eb830d65cdcb0c8 2 @@ -11481 +11481 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingManifold_1_1InternalData.html 7755340c39b9e70dabc86bef67615737fe4e00daa327215f77d5dc5145736b69 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingManifold_1_1InternalData.html 87e88c9775d9cd77622efbbc3f9637fb5eb0eeb7753fcf84db72befa2c7765e4 2 @@ -11486 +11486 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingQ.html 1d6c82a199ff8b610e5d317ce165ee76f36943d824af398a9da614a8e6c0556f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingQ.html 5e3b2d510fda059440b6bd5b3961cb2b452c878eec99ce78a1dc30582ce21dea 2 @@ -11488 +11488 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingQ1.html b5d8f1c9e40989484d5d44693fc48b74bbf46b05dbb525e4317d008ba7fb6c10 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingQ1.html b439612386864b2ceec36d24c3933376f585fcc8b5c0ae620cc7f825f81bfb75 2 @@ -11490 +11490 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingQ1Eulerian.html 92cb4efd0a03a0ca179f551edab8174a5539adb86dfb1c3bfc0f5bb0e7c26cd7 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingQ1Eulerian.html 1bee44062c9dece0e3d12f942e829139ed8f8d2658e5e4b65dbc4d94cfdfe3b5 2 @@ -11494 +11494 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingQCache.html 9756b92b4d5e65d320ec94d6b4768ac531ccb91fce4516cf88ddb480a4c504a0 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingQCache.html 6dfb1c55b354b8ce62a7acd031e0f6bb261599153d2c6da07cb9158fa4035d5f 2 @@ -11497 +11497 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingQEulerian.html 4528aaf9a13264b4ebe6add675d1743b0ceac8b4de9908b43a31b4e7d835d6de 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingQEulerian.html 697f615f22f5a64023417064f8376abac895d4bbfe88b71172d00de0db1e0100 2 @@ -11503 +11503 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingQ_1_1InternalData.html c27d7318ac349cffd1110eab13dae7aeb2b1f01c9f2481fef95eee203d8b89f6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMappingQ_1_1InternalData.html 4a7020479759fb0498bb15b9beb965fcd7ececa6af7dec1216d562c61e1a95ca 2 @@ -11525 +11525 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMatrixFreeOperators_1_1LaplaceOperator.html abb76fdc61f2ad1bdcc852e078ca9163334c16732cec26af1c984510d337c186 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMatrixFreeOperators_1_1LaplaceOperator.html d22e269127a8b65d0f448c2570393b568d4f463cf3cf1c373e8d6f4e0864e81f 2 @@ -11570 +11570 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMeshWorker_1_1Assembler_1_1ResidualLocalBlocksToGlobalBlocks.html 453d89ce0a292fa943539d861f9696f608b076ea5a2f984cb915ec00cc8992cb 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMeshWorker_1_1Assembler_1_1ResidualLocalBlocksToGlobalBlocks.html 9b868bde1d696f97a0acf485a40a89d7302e8e872ddb9700aa356e8b8f97449e 2 @@ -11580 +11580 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMeshWorker_1_1DoFInfoBox.html 048c8ae851a9596484eb0a5d91c82c67cd44479d77d1860223284864e28066e0 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classMeshWorker_1_1DoFInfoBox.html 27283eed4ef4232e9ed2bcf03f7f7640f921d089ac2b5afafe07b8e489ef78d8 2 @@ -11625 +11625 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1DiscreteFaceQuadratureGenerator.html ab2b2b121613f454a1d02cc5d4961d656a59a31eb0e4ef40f54fe53f57894b92 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1DiscreteFaceQuadratureGenerator.html 9c7d37c4f746e224ceb935ad95acc557fcae4d2093d63143aee302d17641cab6 2 @@ -11628 +11628 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1DiscreteQuadratureGenerator.html 1b892a33aca1cef7ff16b62e098560f3c9fba705fa8e58a11b7ca266fc06e130 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1DiscreteQuadratureGenerator.html 1295bce1b73582ff331132255af6aac212bc4c7a729637d44816c3fde80c4bb9 2 @@ -11631 +11631 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1FEImmersedSurfaceValues.html 679ea863f60c72b33b545e40e0a298ec11ce6cc2e4cbfef447f8ece9098d4401 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1FEImmersedSurfaceValues.html 824ec710396111fb28f4eebac5bee8dd731998b9a01154107538c2259eb9e91d 2 @@ -11634 +11634 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1FEInterfaceValues.html 48810f7442997bb49e7912fff98b76e36c4098a3406d85b447a75028af31c36f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1FEInterfaceValues.html c7afffb48d7c282853df071948012efea708dbec048d087ea5ba1a08a2a0e4c9 2 @@ -11636 +11636 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1FEValues.html 5c4a55c4beadb8c7c55d06168342a27e52c0ee7838eb0028850db26d6a4318dc 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1FEValues.html 8839ad52280ba8deb1b247f026a48a781bc7f3641849c1b539c5eb0ec6a9df09 2 @@ -11638 +11638 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1FaceQuadratureGenerator.html df7b61c68944d54d27b56cc22bc5edfe1edf46cbe2618b21c03110c7ac916aa2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1FaceQuadratureGenerator.html 2e814d5cce40f66e376b4de58f50d32586d2e89ae3d1fe03e914a5d5e7ca8fd6 2 @@ -11640 +11640 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1FaceQuadratureGenerator_3_011_01_4.html e26535e743e30c4b4c4639415912c9e10a9be8c74b3c4745a98096dae9903887 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1FaceQuadratureGenerator_3_011_01_4.html 73fb3a99933b6b221448c4044f77108b4366db61761c62139c7f95025e935800 2 @@ -11643 +11643 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1ImmersedSurfaceQuadrature.html 29fbfea86011922e26344e53d9e5e836675a57d188f74c306592ce8d021729a3 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1ImmersedSurfaceQuadrature.html abecfe02f0d83e4562d3138e6efe9e223d281d552b0ee72af5f36a69c765b956 2 @@ -11652 +11652 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1QuadratureGenerator.html 147bd1d8b59119f45509e59ed5621b2f9004d12a75df3cf65441db3aebb4ef50 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1QuadratureGenerator.html 957fa0c3ad4621c864d3817d9de642b64fbaee38bf60e9930032d1c5e114c718 2 @@ -11660 +11660 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1internal_1_1DiscreteQuadratureGeneratorImplementation_1_1RefSpaceFEFieldFunction.html d095ad902324c480d8b87ca5abf0045341214849d11cddd57b7f1f37d5c8438d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1internal_1_1DiscreteQuadratureGeneratorImplementation_1_1RefSpaceFEFieldFunction.html 4ca571d144bc378e1d837fd32fea5ababa315aad6b85c1b5a49dfd4e82f55664 2 @@ -11675 +11675 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QGenerator.html e90ab14fe9c64661324191a64444dcfff97ede54084badbec54337444009a2b1 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QGenerator.html d69829970add8547f0bb1b06df7c191ecaee2a33e24a7d832bc97359239fca2a 2 @@ -11680 +11680 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QGenerator_3_011_00_01spacedim_01_4.html 2818717a7493c2840b2b0b7a82288eeb062f93b6f23abfde048d705ac7f2fe76 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QGenerator_3_011_00_01spacedim_01_4.html b9d557d4aae75afa32b7a99358c9a9980d8f9ef716fdf906b89ce05292febca5 2 @@ -11684 +11684 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QPartitioning.html 82c0242c16ff1ffd331df6adbaa6311a3da69b45a5e8d5c3c3158e8a901d8a5f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1QPartitioning.html 23d55b603422b882e85e9c90cba479d678419421bdf71897529116bd48aded96 2 @@ -11686 +11686 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1RootFinder.html 9b2edd24e7b38d17e54cecde85bea8b33a85f79a8d768348bf6bba3e000d8391 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1RootFinder.html d0a3d2435c0b69ef959b1909884b97b48f4ab537b373d7b450cf70b9436666ed 2 @@ -11688 +11688 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1UpThroughDimensionCreator.html 1cc7f9e7c8cd5610867ecf6c95db52ca3e0af14458c8af1294822cb2fedb817a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1UpThroughDimensionCreator.html 83f7f467403ce9549f38a73a6d4b839ea8d583ad078c3f528cd04c8a3f131954 2 @@ -11690 +11690 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonlinearSolverSelector.html ee1de12ecd9b837c959d6ea1944e8c6347124dbe01e0f2af664e192677577745 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonlinearSolverSelector.html 94b2d27c9402170a3b3af58b30974f0d982f59c2f5310e526335fbdc998fc608 2 @@ -11692 +11692 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonlinearSolverSelector_1_1AdditionalData.html da1cb691c4d06513c489ffa93fff3e44261ee5ecbd373aaa3a096587270f0e9d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classNonlinearSolverSelector_1_1AdditionalData.html 40f25b1024ef3a9017b6d4967c3c72a1b8571043c628c29526da3452b706de58 2 @@ -11694 +11694 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classOpenCASCADE_1_1ArclengthProjectionLineManifold.html 1ed99ab0831603116cdd19c425fb245e5978588de2f32e817dddc0cbb91b4194 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classOpenCASCADE_1_1ArclengthProjectionLineManifold.html 20ca2a916a37a8f86bb0a5fa9d26e79c45e739fdfd2a77451b5a37c460accd39 2 @@ -11697 +11697 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classOpenCASCADE_1_1DirectionalProjectionManifold.html 03165db96963569332d5e64439324b2da2f761ce47dfb8f177e508d50bf9bde5 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classOpenCASCADE_1_1DirectionalProjectionManifold.html 4784e252a440775cfcb0fbd5b5ec10abf67730ef847fd58ada56a36a2ab53ce3 2 @@ -11700 +11700 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classOpenCASCADE_1_1NURBSPatchManifold.html 5b5535d2c87faece2bfe32b8c68c87c7140c9072f880153ff2e4c4472a68d5b3 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classOpenCASCADE_1_1NURBSPatchManifold.html 4d8b528c6e6dbe5b2a8793c173da786ff3f1f661d3820e88bba5f2434c2f0299 2 @@ -11703 +11703 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classOpenCASCADE_1_1NormalProjectionManifold.html 9332b6efec36d6f63e43bd8a276ecae71b8025246adf9fbe634645dcd8114a02 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classOpenCASCADE_1_1NormalProjectionManifold.html fb514dfa134c09ea71fb8a52527067188dc66e19b3e3ec14ff1ed8a59702cf68 2 @@ -11706 +11706 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classOpenCASCADE_1_1NormalToMeshProjectionManifold.html 032dd0032b02b5ef11e9c45f396134693a50171b79b431438029a863c30c3d78 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classOpenCASCADE_1_1NormalToMeshProjectionManifold.html 94a3f247d7c0d40ef81da35dabc632a3d684b8fad94bd255e76618e6f36181dd 2 @@ -11709 +11709 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPArpackSolver.html ed062556e3782bdd431f169c0015668819ec26eaa7020bdf4e8293c348a39975 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPArpackSolver.html 735d8517e8823fab95a989df0edb2d358702b2fc02dd60b3d7c0a9c7f3e2c836 2 @@ -11712 +11712 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1CommunicationPattern.html eb3bc8d35c0804146cf877467b2ed2e40830ec915babccfa9af9e42d7bbfcede 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1CommunicationPattern.html a4de49db6065f02fac8d69c31b530aeee9f95b96ce56741d5302cad02e22519d 2 @@ -11715 +11715 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1FullMatrix.html c66f70c404f21ed12fa358c66bcb0fe04e5947d083c70e81aee2fe682eb67d67 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1FullMatrix.html a2cde485e67130571afd0ae17b5476252f84532980a258cbfd4ce1f6e6234953 2 @@ -11718 +11718 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1BlockSparseMatrix.html e1c31b5a31ff0d8d937af7716ceb82a0745e4ef26d4b74b0a141e8e4456cd4c5 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1BlockSparseMatrix.html df7f6bddc17a6a08e675172a938a2177f08ed176966024395e6ac33a950b6a92 2 @@ -11721 +11721 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1BlockVector.html 5db337fa6b6384fe2d8b5edbd5cb9482b808655baae3f9cca2066ec64ced2e45 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1BlockVector.html c7839c5cdbc5fe7f19fccbcc094819fc42b36d1219921cc431a3939aaaa68976 2 @@ -11724 +11724 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1SparseMatrix.html bf15400fd952fe9623ea4f6cba3f73fcb244b5ca7ca7efb98124451aa5b2d2e5 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1SparseMatrix.html 3561602f12a7f8c1c0da84626c52776f9b7dbe39f3288c3d4d5d8d7e6ba52f80 2 @@ -11727 +11727 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1Vector.html d8ae54384086e8e9ae435d176e26b0bfb1b77fdd4d030ade177acd4832e5a74a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1MPI_1_1Vector.html 859366cabac3509c6eb6d58b5d6921ab87d9e4189ccef3dea93133060ebed690 2 @@ -11730 +11730 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1MatrixBase.html 46d9985324c0ba3763b69cf013a5c60d04af2d29afdb89a064c8418981697ea7 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1MatrixBase.html aee32fd85cd5b4efbace50f55e0a0dec9abf31c1677bf54a92ae724e071a19c7 2 @@ -11733 +11733 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1MatrixFree.html 9660dfcd1ef5563b2fd77e717a2bd55ce251ed4626661b694ad08563218b4b78 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1MatrixFree.html e8070fe059850c051885714a61713c79aba913a83b73cd7311b5d0aa74b87087 2 @@ -11740 +11740 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1NonlinearSolver.html 5e820fd3bac6f8ea326dd8e370a6465cae2d687c94edb24e26566cc7a7884408 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1NonlinearSolver.html 00b1e0b34d98ae0ba370b0c49bbff12c13647420eab3349fbc154f3ec0163d17 2 @@ -11828 +11828 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1SparseMatrix.html 054918d401115a6a0cde861726b20c5072e09c521cd3c5d37a43f5ebba16e2ba 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1SparseMatrix.html b587f5dc277951f6fc49c14ce7d2aec57437b1cc23aa75fbeaa0a32a5f66c304 2 @@ -11831 +11831 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1TimeStepper.html 2a0dd80fbff4396be2c71972a8c1471fb74232a643c1b4c3ddeb5ad9e4aeed4f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1TimeStepper.html 4a9033966f44b9a563341fcbd5905a02f2a255567552b652b4ff37ee4021661e 2 @@ -11835 +11835 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1VectorBase.html c451a7285662e85a00060a85f9dc75ed4feb69ca03629d0dfeacdef22b1483c8 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPETScWrappers_1_1VectorBase.html e51c83a831f84ec5552c2a48164b4a464fe1c594bac4cc737701f663fe37d37e 2 @@ -11840 +11840 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPackagedOperation.html 73e41290df0e2b3fc7fc3d1d902fb4bcee6ca72d32a779012c8e2cc15bc86414 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPackagedOperation.html e0dd8cc40c02a5c72abf73789f5a351d75e5530d1be0afce88151a5d544d6ee0 2 @@ -11861 +11861 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classParticles_1_1ParticleHandler.html 5ed59b79129de5c639cca8b6e3f13f855ce19d24964de07548604b70cc3a9586 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classParticles_1_1ParticleHandler.html c942db39c0b790753b0962749f922aa7b2e1c7e45a139c4a9d597a76634266bc 2 @@ -11866 +11866 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classParticles_1_1PropertyPool.html 2e1a3703bdd8fe070148e1fbec1d1cb707ace1fad9ca4040f11d4ab2dd6d5f21 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classParticles_1_1PropertyPool.html 9a5c3036b716331ed95c7e260faefae9d7c3f6d47749aafd0f97658e4d8ed8eb 2 @@ -11907 +11907 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPersistentTriangulation.html 50d255937fd75e92a298e882b30e0f5e7cb415ab7fd43520f88527af63fef6f4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPersistentTriangulation.html 94adb56ef9a45557abfa65a6fc1c232f65fabe148d586f6cfca975bcb472ed9e 2 @@ -11910 +11910 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPhysics_1_1Elasticity_1_1StandardTensors.html 25496ec962ce95ba16e8b21941d27d26dc529fd2cc89827673278c03c0557f36 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPhysics_1_1Elasticity_1_1StandardTensors.html c57fef91e215215909ef30f8edf5b1f9bd9f7722d0b33a90e09ddbb17242dc30 2 @@ -11912 +11912 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPoint.html d16846dd1b828fb4d515ac12322440544205f1ac6cbf16f4709aea4b5f09697b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPoint.html 26b283c91176345c0608e3f6adde62da924bb39fa2a5dec4437ffc63fffe1224 2 @@ -11917 +11917 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolarManifold.html 9976277885831caae632f580a292aaf0954f3355226e5915bc04b1d50d3f06e0 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolarManifold.html 08884b81fe03636eeab57fad935f73e6e542a490023a3ee668acde0d9f8ee1bc 2 @@ -11932 +11932 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomialsBernardiRaugel.html 754af85054bb13d02767f1d1fa3682e40cb3cb64c8c3db0289d286f0c7668b05 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomialsBernardiRaugel.html 6b5cbb89229aa08fa0dd285c8517a6363953bc41794b7700c5e7e63642df0907 2 @@ -11935 +11935 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomialsBernstein.html df4fa74945c12dd370b62272af4cf1460915c93dccf01999d5ddf314b668cefc 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomialsBernstein.html 1e6767efbaf0c5bdbe696f3de5a011827887a9a5ac3b69c6f26ae64aaa1b0be0 2 @@ -11953 +11953 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1HermiteInterpolation.html a5a05a5f62ef323cfe332a305fe5f8c159d50eba1df3e9f4ecf245fe02f4a0e0 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1HermiteInterpolation.html 8ac14460c2c9503b4f63a29c23c52baeeff404d35ebf632d9dc8b969773fa6a2 2 @@ -11956 +11956 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1HermiteLikeInterpolation.html 083d6f0d511690703a172d185acf60c2312d8f4db8a68af2ab045cd1e07a2d47 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1HermiteLikeInterpolation.html 8507d8a27fa436d7e8b28ed998a15c4d367c1385afb96460f0f122a1b6fc29c2 2 @@ -11959 +11959 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1Hierarchical.html 9495c4ea1666af95088b2963d14dd8491eac8923e9dc8c4fb6b319f246d31988 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1Hierarchical.html 286521e7e73553b572466eb0ae86211cdbcc252e90f1b63ef8452f5dfcde1be2 2 @@ -11962 +11962 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1LagrangeEquidistant.html fc674ebc245d712a3015141861fc389fbb208de3c2f78a0236846c4923a68973 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1LagrangeEquidistant.html e19cba533fb5e08327d0dd52447adf53fd28fa9b95ef1f932208ab3ff72273a8 2 @@ -11965 +11965 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1Legendre.html 9be8aa68c33b1e32498470f5bcd94d1951a5729f2e656120d8749dbbf223106f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1Legendre.html 5d3997ee2030e672f7261fef2477a499b6f5a974be6d771cbb368b719718116b 2 @@ -11968 +11968 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1Lobatto.html 47af13bb632c4a092bcef417d6e7fdbfa1df8b7b4aaca8f92676fd54416b5729 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1Lobatto.html ef340f53522952db83263e44436451e58a691e25eb11fbc8b27bb37f1ac6995f 2 @@ -11971 +11971 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1Monomial.html d90cbe482689b3431fe41c9038a1c1b12b1e6973a89a610040f432ef2356dd9b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1Monomial.html 72741df4411b810eefe5c5e98f491d225583dd0451b0be3c29babd187e4bda9f 2 @@ -11974 +11974 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1PiecewisePolynomial.html 027aff28446ae24b503f66d5d815d3131e239601d351479eef2b427f5c5ae2b5 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1PiecewisePolynomial.html b7497e85db166e0f6c34630231c3edc746b422b5a577f1a568a59b5d7b8e2dbe 2 @@ -11977 +11977 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1Polynomial.html 18f93ae0ac41fbb890deade8db73e2fcdad995e1057d45b784e86f54d7fb5f20 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1Polynomial.html 6bcfe0076a55496e2c49c8b8133043505b177219432f9b9e84ab2f578bd761aa 2 @@ -11980 +11980 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1PolynomialsHermite.html c3727e008d4841c704967910b37054ca9cbbb7fe4fa4223c62e4942cb2b43671 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classPolynomials_1_1PolynomialsHermite.html c6c46a5db5edff5c66d82f53e2e75cf6dfbcae3e6d041d9e70e520f1819cb920 2 @@ -12057 +12057 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussChebyshev.html b35bfe1d462c40dbc591d75c3f67898d6ed798d80569c4b196ba0717b449bcab 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussChebyshev.html eeff7d0eae0fa4b39fd138caf9b250e21c98a8501cc446bd5a3ffb090b7b9e40 2 @@ -12060 +12060 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussLobatto.html 6cbe4947dc242c99940b02277ef10b1213ae38cb43fac5f0d10d7c49216400a7 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussLobatto.html b4366dfcd6068b6e986912a48a87b66b2d871a857190645a37a6d6c7569fbbeb 2 @@ -12062 +12062 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussLobattoChebyshev.html c2da59e28877ac0bc6a8787147b77b1840ccdd6f186f00c9752ddb228050a431 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussLobattoChebyshev.html cf23180c91280443ee116f0477e76739448fee93231eb4744faaa80cb0c9cf2a 2 @@ -12066 +12066 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussLog.html 84e7c004b0612c2b295559b681d72b6ee18fee82af07691cba97dbb1b8936aa0 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussLog.html 9f888ee3e5bfeb82ec07dc0115daf4897a77827a306db589048d610d835f60e8 2 @@ -12068 +12068 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussLogR.html 3e5fc1dbabecb6680474da3f283fed38d52f888943d04a2b55f391f9dd09d323 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussLogR.html 9df11e160ce296151e3fd98cc1994c4c9c48370b676c447fb4d7e9275ade12ca 2 @@ -12072 +12072 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussOneOverR.html f0c3ddbf456761e14c454da006c2f01ba5658fab7b774a3f8c1be0674999742a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussOneOverR.html be6f30b369a3c05a9086efc46c2f3862b99c5ebf0b9e00dfcc382c23f3f3df56 2 @@ -12078 +12078 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussRadauChebyshev.html 63593cd7ff8cdae3ac9f1a24f6d7bfe4c07d3cd5f0ee96fc560f9466bd151335 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQGaussRadauChebyshev.html f05c542cb3c61d7e18c58b6321b2e94feff4e8ff4f0892b77ec41ec46f856653 2 @@ -12104 +12104 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQR.html 80ca9d24645e1881685a429b8c047cf1eea437d70bf2344702f797b7a07d9805 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQR.html b3e917932f9cd404d34e33ceda6f878541cd775c0fba4bf11b57867327082548 2 @@ -12119 +12119 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQTelles.html e1d357e7ea1a672f0a015d57368d5b057de546a276f2a93d0598e61f8f64bf10 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQTelles.html abbce14e4c0df66c524872ee573d6f333ad5ff9f5a78a31a2215fe9a1d233a26 2 @@ -12131 +12131 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQWitherdenVincentSimplex.html 53dff08df71cb2a78218d381a730147e6158e44a55d573cbf68efcc4014add2c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQWitherdenVincentSimplex.html 3b86a05c24f7713bfab2cbbd7af54e39e939140a11726f1338ede10c75b44024 2 @@ -12134 +12134 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQuadrature.html 5ee8173dec8a0f3f17cd387e908fffb09dd2df8e64aa683e9f483016b0b47254 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classQuadrature.html 753b5822947f20f314243b047c8e001ba29de9b6c847f9212aec450d56182f67 2 @@ -12145 +12145 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classReferenceCell.html 5de0bc66a0bfd60cf1fcdbff4edaa9d56e03ca13680d563679ba684b3d2c4426 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classReferenceCell.html f9e0d92fede12ae90aba193978d76009d44a1ceead0c31b2e399a57aed23d1f9 2 @@ -12183 +12183 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverArnoldi.html e77080f607959d0e462b2fb25c4ed37ab30e54a52f61ec81d051f26999e635b4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverArnoldi.html 9125081e63faad6c32a126d6e9e8a1bfa49151952ad7c4c95dbaead08dc3a530 2 @@ -12186 +12186 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverBase.html 56cfa6e5749689e0608efe748f07941e6cd2d62e9f12f3f074b19aa6c0531337 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverBase.html 0d624efa58e0a87fd724a4068dc6a911ab37d10e0dfcfc494598ff90436d3cde 2 @@ -12189 +12189 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverGeneralizedDavidson.html 5fd3296c434f8819f9caaf5cd25f81ce7e671030b64f19ea95410a6ae087f967 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverGeneralizedDavidson.html 28d44f3efe299041ed05935e98966bd17b4b94514b91bcb560868d3c2495786d 2 @@ -12192 +12192 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverJacobiDavidson.html bb9ee9f5020e3ee2b9d9acc0e06b24de8c8bc19e6d3e86df80208f33b5111e8a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverJacobiDavidson.html acbf3a2c672681f0510a892d0092d373f9ccc8e69f8649562529d428a4fc2446 2 @@ -12195 +12195 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverKrylovSchur.html ae9f4d754ec1f68b92fe0c2308f324dd132d751d824baff9e6c81cd372c2297d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverKrylovSchur.html 6b01e59f0f0d9cfe02c2c0a2110e35d286d734bb3feeaa082962ccc65ff8ea35 2 @@ -12198 +12198 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverLAPACK.html a1aebda139bdeed3d7e16457611908dbff496e32043681f9ee4a2c711c631cd9 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverLAPACK.html 963043c610dddaf8dfe7a136e5a78cac4eb85ee48220601c0164814a1cd62b51 2 @@ -12201 +12201 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverLanczos.html 8790338660ba6b7b6a910c3dff3a56fabe2380ab48e53fdfb1c91f6d6ad18584 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverLanczos.html 12105aa86de3302c15230bf21104da7eb97cd2efc4efc504d23f52fab73602e3 2 @@ -12204 +12204 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverPower.html 2d5b120a9ab1f55e9d0a37648932d29030b2a199ab09748ba701202f10f3775f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSLEPcWrappers_1_1SolverPower.html 8a2819fdbc029f4ed3e3890eef29648eec065b50b4ee9876cb00d8144b1c2e7c 2 @@ -12223 +12223 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1ARKode.html a3d87ae34d917de5e275900586256212e70a99a0755700c30a02de4e119e6fe1 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1ARKode.html 7cbb61b7a6120f86294db994885fbd66a34f78f02f3f9d342a2145db1b173ad8 2 @@ -12227 +12227 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1IDA.html f2bc80c6a0a1c7895a6fd94b0846ad26bb41993671c6db2b79e557f41aa2890d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1IDA.html d8cf6daaef8f13214fd3b2aa8cdc151a06dabfd8679b9e3e468854850cee601c 2 @@ -12229 +12229 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1IDA_1_1AdditionalData.html 5de8b737f07e72b26e527fcdad021a16a58ff5785fd201a40a20fe5970ae70c1 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1IDA_1_1AdditionalData.html 8c22fc3ecf15a54d2f9b3c597975a4dc16c369e269b4be23570a519b19773d55 2 @@ -12231 +12231 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1KINSOL.html 4bd243a0f2b82964baaaef718f3fed6c9d2d38add3600ada0de6902c769e1df2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1KINSOL.html ea524320c15dc8e44f972942d618df674ccf27e4d58f13d9a01ecf177913e8d4 2 @@ -12242 +12242 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classScaLAPACKMatrix.html 5aa56696d97b81b415595c08ff5503892b99612fb69daf71881b322d4eb32ce9 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classScaLAPACKMatrix.html 879916b9779d1578e86178b53dd6bda7f4fbbc43bc7a5c9c1e2c4b1c648ca938 2 @@ -12245 +12245 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classScalarFunctionFromFunctionObject.html ec18ee09350c857e4b2fc8827ead4c6d4fe227b36982329c2a2d72be6ca7204b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classScalarFunctionFromFunctionObject.html ca6399e35143e9f87a354d63fe90a1f481857ed90f9f634dc7839e17c90775cf 2 @@ -12261 +12261 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolutionTransfer.html 63719b6bbac5fd6a5f5d9aebd0de4590830b4a0fa32cca76fe87292abea2f249 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolutionTransfer.html e94d16b4d2d43bdb191001836364f17b97daca0254776b7f722f6b21aa138bdb 2 @@ -12263 +12263 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverBFGS.html df021e012dd96a76e5d728f261c176bc257cf953c1b18c9fcc09cc8063432481 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverBFGS.html 01a28167b9dbe5026ed6af9d86a2616087b64d27a9f3c541a97175054afa5e32 2 @@ -12272 +12272 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverCG.html 435e7111dc4ef5239e9c448752d068b0fe39d3e8e75ca8d7cd29163ba2539a4d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverCG.html 85993e7f5b19bb3e77eb1c50a12d1e60e466baa9af455dcd85218a45f2f43d9e 2 @@ -12281 +12281 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFGMRES.html 3e905d3bc5c570453213915557a9efa7cf42e84d01e479db9c4fa214c301a74f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFGMRES.html 469aad742c0575c9b671469fc72b8daad727103a84f6213b3c561bcd3cfccafe 2 @@ -12284 +12284 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFIRE.html f1c5212e6d6e4c0d6c62f9b1de1384f46cb07ca4e42af737a0dfa793cafb8331 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFIRE.html 8ed3c7404b8cda8c50226cb180c1d83e5fa5f2637b44f42e6d102f48938fe7a5 2 @@ -12287 +12287 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFlexibleCG.html 4cf5df18036961aaf3a586625b6334e347770d52cd22da4c3fea37b802062ac3 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFlexibleCG.html e89dfb57ef7c32306cd81dec77d0424e2856988764ec73d9622438085d519c41 2 @@ -12290 +12290 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverGMRES.html b76888d48804161f6af2c37f64de6f5353490be7ebeede0fe6ff3945f508891a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverGMRES.html ef7192dbed2c861cc334e7cd6fd20dc26fcef1a0ca289d46bc3a37e3c650c5cb 2 @@ -12296 +12296 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverMinRes.html 6e593ffd3e3b1c526544195429aa955f029a2cf2e7b5c71febdde914b5ad4ec7 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverMinRes.html b354c88c23d7dd67902f4a10b90c269445b545ce2e7c5652db0bdab2a2d52bb6 2 @@ -12299 +12299 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverQMRS.html dc76b7d5e0d5819e430260ef8fd48b4920d80e5ae59eed1ad26cd5fc3f9353fe 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverQMRS.html d3713dd4e365c6446d543d63146a777a249d91e9abfa7920324d0b3bd6f1b784 2 @@ -12305 +12305 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverRichardson.html a7e53106d6b1479d9fa59372290888373763159e36bc794e2a2ee99a43da57a2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverRichardson.html ac3ada1e2f526b7a6bc1dcf9f1a3ee0ac531f0ea17293256af104167cbcd5882 2 @@ -12317 +12317 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseDirectUMFPACK.html 15523a34257c73a19d8272ac4e8327b413fb1543c1c2bfd2528881318bc97d58 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseDirectUMFPACK.html 8d6cc2d73ae0061aa4d5f6a06107d1ed48d14c53859a3a73f0cace4112a5fcef 2 @@ -12321 +12321 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseILU.html d59f4b849b0370b20cf03f72aeeb7f390ebbb0be99cee500ea6461916c1aa53b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseILU.html a6e36f6ad03f092ef5ba2992173db1b7c21fbc6a15d4ff78aa7c31926d9704d3 2 @@ -12324 +12324 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseLUDecomposition.html 14956011b8f6dfcf27de28f68217593175a4d023c3f8590035da391bfa48d7c5 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseLUDecomposition.html 12f93c6c70dceed71a1863776995085809eef2e42dc4c7faec704d091269a35e 2 @@ -12329 +12329 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMIC.html c0bcf987f3010ab20b4adb807bad716f8a10b409e0ea9835ab82c1283abff2f0 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMIC.html 8f53e79f03154c00e7e8a278565140557e990aa5b09b0540029891619dc82e76 2 @@ -12332 +12332 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrix.html c75a1e9177db49ab6d31d7d207bfca340a7bfe8d4c20f5ce2d5bc85e4a2afa0d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrix.html 73a02cdb62d56e269ea096d57f6cac993c957d14188a8fc6d3996b550fa424ef 2 @@ -12334 +12334 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrixEZ.html bf689a626ecd75206d641a23a36cdf60cf7514d86753b81ed6af25a8cc4447b2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrixEZ.html 0d0924549f2648e69f47d2be486388a1b7917b5ebe423608437d0459e1cd6200 2 @@ -12352 +12352 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrixIterators_1_1Iterator.html bc3e7b62b281a5a838a8e3b7e4bb1f77581e7e5387efb7a3e152e746e230cac9 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrixIterators_1_1Iterator.html 770397bd19ec48abeaae10079300dde97a4498f0a2e0f331ace7492f6aa517ee 2 @@ -12360 +12360 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparsityPattern.html 0f21619c7aa1abfd5719f35b7f2a7ef14f52f996a2195b8b60244c6b21709788 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparsityPattern.html 42e0eae0b7cdf144d65ce92edf30313354ba0be619c09f49eedc1c9171b5f8f1 2 @@ -12368 +12368 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparsityPatternIterators_1_1Iterator.html b61bbbfe93784396ab19a04c1e51c596264bfbdecc76e9dd3aa5f566cdd1babb 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparsityPatternIterators_1_1Iterator.html b742e380f05ddb8d6e5ad59e5b128a099a132ca55c400b08067ca13f386e3787 2 @@ -12372 +12372 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSphericalManifold.html d2fdeff710deb43f892d6b71111ec7c217f6622cacec9a2a2ff398c91f774904 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSphericalManifold.html ad03f9934287e2f749f3a0304215dfdca1d283ec242f5cbbdeb6fd50bd3902b9 2 @@ -12380 +12380 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSymmetricTensor.html 2f5b6a5ea749d84c320ee53afdc11ae6130ca79fc1e7316fca2bd077229346b6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSymmetricTensor.html d23392198009135b5e018046ccd068eefbf86aad5a54f00025477b0b226fe744 2 @@ -12384 +12384 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTableBase.html b36020ec72408a5cdcbd6c95ab9ee4fc6bbf830799c29ca311ce8e50b5453a7e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTableBase.html 3e104a4474d827453a551f30b49f7e59827c1361e1e4216bc97eea69851f13e6 2 @@ -12387 +12387 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTableHandler.html c00c7a12f4201753c12c0cdf4bac98904b457c3f61987313d9762cbe2198097e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTableHandler.html 07dd10192f234a1efd2094043b69aafabbf05e0b44fbdd79501b635a4ef41735 2 @@ -12415 +12415 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensor.html b60c444b5ccbe3e165bd9307d82e448fac6210d832a6074d6ca31d545912842e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensor.html 59129fab7d9a7b80f465124bd4ca40ddfba910678f03e33cd360c33b0e034f00 2 @@ -12454 +12454 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductManifold.html 4288bf8069c1994ffd4840a1f97cc50e94e0ea480bb120e65c4ce48924af9799 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductManifold.html dfdd41cd5134d33a1a5a4ca6ac28c8bf692084a5a2fc1d2ccc2bb8eef439019d 2 @@ -12457 +12457 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductMatrixSymmetricSum.html 75c2aa14769ccdbdcff7c431f3c73c197273c1c68258a5ebe56f809eb488b57d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductMatrixSymmetricSum.html 1adaa1e87cfa9bea075808a38577d6d7873bcc55454ed4c5f79317e047aa037c 2 @@ -12463 +12463 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductPolynomialsBubbles.html 491aeb962c9fe404c13523c671891551c07e17cedf35dbcb5da702d83a639070 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductPolynomialsBubbles.html 1ff88a1f6f5c4302e8bff8fd077356d0654aee24da21afb9356fc256714b5192 2 @@ -12539 +12539 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTorusManifold.html 338cfbf35d02f5189a6d7c54ddb504bb96e26be5106fa0d1eecbb79e037bf0d1 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTorusManifold.html 822fbbd4587937066ce6e4bd7a4c771d033b3fcf14de3e3ae835c980d18c29ae 2 @@ -12544 +12544 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTransfiniteInterpolationManifold.html ac0efbbeb63aaaeba17e24416f83ca501b76136bcaaad4b4f158ee479edd7a13 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTransfiniteInterpolationManifold.html 05d81869089039d143c1697c286bef8cc79d3cc9544071a93eaaaf1d8b9823d4 2 @@ -12550 +12550 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor.html 44e144e85dc1d82ca65d5234ed49373d570b2ce412dff9bd23e4e8e5269a6349 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor.html ec4f2567b923d7b6b6c320f9d8acd4d64b501c82e90c463435bea64c95d2873b 2 @@ -12555 +12555 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor_3_010_00_011_00_01spacedim_01_4.html c73840247eae154fd1a3105cfb2a8e3f5bcbf4afb48d9208eb09a9e0a6edd3fc 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor_3_010_00_011_00_01spacedim_01_4.html 6bae7ec4a63e862b92d7ba854e07696fef86698db515474eb260233d48b19ca5 2 @@ -12558 +12558 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor_3_010_00_01dim_00_01spacedim_01_4.html 47f6e0f6de88c108a490c1bb9d01a0e61088b79676eb6b001546caaf345ea77f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor_3_010_00_01dim_00_01spacedim_01_4.html 263ff72099ea63bab15a3690028f9103d8f23cd1180351e06bd18b3bf30272dd 2 @@ -12570 +12570 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriangulation.html 396a42db50ab8387870479753081c4f14a340df6acc2e2ce29e0c6ba673b7971 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriangulation.html 29d10673dac999d3493dd81bfdea94f7a446f2e4aeeca9566d30dca475480aa7 2 @@ -12577 +12577 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1BlockSparseMatrix.html 3abdf441794402bcbab919ed2370301f38c01cefd4f914ebb3b868373d3e49fb 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1BlockSparseMatrix.html e03c0c16f44937d2fcf3380967bce009eeb3add5c071bf91deaacb0abe8f48e7 2 @@ -12583 +12583 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1BlockVector.html 005b303ec1f744a2152d233ef189743211e01a47a6d50f0c0ba47b0ed971fdfc 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1BlockVector.html 04d797aeb70c423af627da94f49648a2b1d790b68c10a021dca4a3e5f3c9169a 2 @@ -12586 +12586 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1Vector.html 14203cb9e8b478783185e90ec989458db8f69029dc33d2a600ff225319c8144c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1Vector.html f4ded53dbce721fed81e9362151a63457a68cd25c703cac0b5acb01200736fee 2 @@ -12589 +12589 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1NOXSolver.html 074454a94601934cae7b855c84b269e67aac6a5463452e9c999211913298faf2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1NOXSolver.html 0513017b5ab036c083dd4e7cb3d0dbfc80ee3935beafb126913bde634207cc44 2 @@ -12657 +12657 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1SparseMatrix.html a338a16f7cc03c0babbde4394e0d4028b3d98d630be1861068dcdf8d61f92fc6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1SparseMatrix.html 0faad2cb16440ee0c530a89c2d4f9285b47c2df26b6018879e025ddc55f744b9 2 @@ -12676 +12676 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1SparsityPattern.html 63998790016e3f064334a566b6150dfdaf8afcd97c7916e13721e2a782812fee 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1SparsityPattern.html 5583b3dab19f516956204794c4be1347c4c3b3eb52789c13c4d7264f65fa232f 2 @@ -12725 +12725 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classUtilities_1_1MPI_1_1Partitioner.html 4b60d566ad7141555821e9f356f0052bd2a5ee9135ad9c9cbf28a499ad28584e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classUtilities_1_1MPI_1_1Partitioner.html 677e61d18580714ad2b5eb25c5ec52d16a5a57bb56eb6fa87770aefad5338368 2 @@ -12728 +12728 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classUtilities_1_1MPI_1_1ProcessGrid.html 4e0c159f781366cc4eb45909e96baaa6aaaa1221e09133a5ce2e7a1735930b18 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classUtilities_1_1MPI_1_1ProcessGrid.html 19d740b1df4ab0d62b67e1311722526ad1c0bc1440d7cdb5cf6796555aa49b4d 2 @@ -12740 +12740 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classVector.html b76a410af8ee3a91188967fbdb5327385424064fd44ab41b7d8bf88dffcddb5d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classVector.html f09a46334c72c58f45e28ebafb9313601ba3f727ed0f912dba7cc47826d8623e 2 @@ -12809 +12809 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FECollection.html 77d3de9e693e97facb77d3dd08e2522cc07612499f36bbf213873d3d240f3b4e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FECollection.html 93f162f331fee4aca2438e7c2db015f6f5fc65b74cbee7f2d1205ec2bc5897bc 2 @@ -12812 +12812 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEFaceValues.html 5660b2851035590c83f161de774dfefa15f69d99c1e01bdcae9cd90936f4b4d4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEFaceValues.html 92c13b6f85dac88c8629cca8b0b1dc03107ae7c244167afa07f0403d6afba448 2 @@ -12815 +12815 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FESubfaceValues.html 183f0ef4b7e3e6f63e8bf445bcf82e87afbeab202a96dadea895357a3e5d4d0d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FESubfaceValues.html 759d2e2ac1bcc206547b2200c65bd6646f75dcee9ff6bf3590bac95f1e48152f 2 @@ -12818 +12818 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEValues.html 2d60bf93998f9fbf3bb9cf9cff94975d56adb5707c4cd4534b2081fc352acd62 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEValues.html 8be4f331b94359cb65a15d319eba633e47c37908ed82fa6e6d375cebc58bbf66 2 @@ -12820 +12820 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEValuesBase.html b252142b09c903d368e5d44d5fb4d3c3c7f132fad5341be205ecd4c9f4cf9a7a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEValuesBase.html 7156f8b73d44119c7d6d39d7da91b35fc762f2a9f26b0d26aaef84b646fb43f1 2 @@ -12931 +12931 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1MappingQImplementation_1_1InverseQuadraticApproximation.html 73f76da7e94ff59000359ef8bd50b05d1d22bea2ac0f5ce48344c2369bdcb4e3 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1MappingQImplementation_1_1InverseQuadraticApproximation.html 61ef12fefbc42c0684a0409085a5b34c1b982cdfadf6c69f2b359cc01b2a87e1 2 @@ -12939 +12939 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html 1713a48ccbc10553ed9870d27c2194735fa5eaed6600453c709842ad677e2d09 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html e24873cb8d2d77a4deda6fc1d7b5cb00221446181f4bdf2804f76929b2319a44 2 @@ -12982 +12982 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1TriangulationImplementation_1_1TriaLevel.html 2e761370cc27527beb24fa4baa9b93100aafbfa068e1f4c8c5eec39830ed4fcc 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1TriangulationImplementation_1_1TriaLevel.html f9faa562c8397034e6f843a54ac84411e89106d1876b3ce03aa9f9000d5080ef 2 @@ -13004 +13004 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1DistributedTriangulationBase.html ea886d3325e7647146158047f0a58cda879b715a7c0f363edd1df91ef26c8b4a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1DistributedTriangulationBase.html 9cdeff4b0f8182f107dce24a0bb36535a9101e4532876b3182f781462c51f4d5 2 @@ -13009 +13009 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1TriangulationBase.html f20902cc9accac7865d9294b29092f05f1e08a307f355aba03eac54fe1217896 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1TriangulationBase.html 5b3a9981dd4d950eb00e5b41ef9aa53804a50da8feeff78a504c586a1ec45e7f 2 @@ -13022 +13022 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation.html 8fcf8cc06e533c5235485ca38b4d631d52ce635a3636e9f8b56849110ff5ac64 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation.html 17821d708410f8c0d110ce48fe8b64bbd61fd4b546006e1b237bb6f0c767988f 2 @@ -13024 +13024 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation_3_011_00_01spacedim_01_4.html 5d27311ea6b5bc402d0384cd3daadefac1222cbec9712de63e221623d8438cc6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation_3_011_00_01spacedim_01_4.html 54eb4029307a0cfbb23a59f0707d3b1d82634a5a2001ece9d66dfd29f2cb936b 2 @@ -13031 +13031 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1fullydistributed_1_1Triangulation.html 6e4577c0686fb90908c380d5bc30dda2561498c99d0b631e399829e64b93a7e5 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1fullydistributed_1_1Triangulation.html fc36a77183134570d3c63f66e273deafa013ff3d7aab45c99b7f3eb2059cc921 2 @@ -13036 +13036 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1shared_1_1Triangulation.html b92979a2ea9bdafdca6db7e384e8c751f0f80850e06111dc0892208b3363543c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1shared_1_1Triangulation.html 832578a19a4b6089ae9ed97f3ca83a11b519d07fbf58acc5f567d349377f7c58 2 @@ -13211 +13211 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/deprecated.html 991f29914314808600d5c536585e2a0f885d05bb320c9533b8a5c8e6eba0f725 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/deprecated.html 99e4c567bd0fe1b5f49485ac6ddb5e8443d8673f4402cd6892bf6c2e2ea71863 2 @@ -13216 +13216 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/derivative__form_8h.html 3742f8146e92bf1954e64317c11a2df5864a312f6a83a38a25f91bedbabc5a76 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/derivative__form_8h.html c9624fa4c850b86a9485a65ac84704ab52f36ff3b63b11949be873c7997f4b0d 2 @@ -14361 +14361 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__CPP11.html 2eec39ea9fc0d49e95160fade9edc1e65616de241b01313a23daa23935efc297 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__CPP11.html 7443a36a8ed0f3cef21fcfedf25534f14a9013c5dc610b479585853a0a7da8cd 2 @@ -14364 +14364 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__Concepts.html f1337f13ac202cedc34f4ee207c68c595e50bce7716152847e9b97bee1bc53be 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__Concepts.html 4f64132370de54c7fdbcab1828988a8a093e30557790e6070fcde0c05e14c081 2 @@ -14366 +14366 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__Exceptions.html c0b4371ab888b0fd2aded819830fe9fc62fb261454bdbc2e829b39a175033e7f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__Exceptions.html 6a37c409539c050ed1ef251d1ad5054e402fd6921c88a37aa501e75b04504596 2 @@ -14378 +14378 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__LAOperators.html e17903bd9f16cf60075a8c7a0a128392db3b274b7b3f9e0f2345ec44df5e84dc 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__LAOperators.html 45c666f8a27f554b838a020375d13e31a63e02d6dd7fe971d1690697be4076c9 2 @@ -14406 +14406 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__UpdateFlags.html 532dcba9810d7be65654067976236040c82793eb50db11aef88bf831519f4fed 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__UpdateFlags.html 0f1336d352cb4056291e7aa299c5661274ba088f8bba05bb98b30a30b33de21b 2 @@ -14411 +14411 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__auto__symb__diff.html af4e0e29638a8dd6e8065c5edd4aa4296f6796b430163552fffc9262c7f8d4f4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__auto__symb__diff.html 9dfbae349d23ddd82100576aa2518a0685f11e3b4a66dbc3084bd69c8d25d269 2 @@ -14413 +14413 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__constraints.html 8f554c4b718f00f884368f62276489b1af83232d4e0ff66861eec82d2a4a70a2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__constraints.html ae08c58d9447df2f39ee0e1e5f8e7de4c9b32770d2444e5a3e745ca33e199e54 2 @@ -14423 +14423 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__feaccess.html 34639a532021b92d0865c935bbc6a182f69c59d331f52e046022d5a75532dcd3 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__feaccess.html 8ac353ce14f5ba322cae5f618a44eaadc81414abf4f45124c416be30c8195320 2 @@ -14437 +14437 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__hpcollection.html fd6f49b983c55ecb2a1f4278a2ed018de946fdaaadfac3bffcc0d54a095b037a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__hpcollection.html 3cca710732ca36f40772d1655a2b1b4f61caadae81a317f16f1a9585700cdb9a 2 @@ -14441 +14441 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__manifold.html 6532a074371c3c22a7789d8f2f36709e65a6c543b8ee91cd8b8f5fe510431c2e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__manifold.html 5d52d47bad3f1e9109735a6e2c3500c9c3d43623b24fbf66ca9abd77b784977b 2 @@ -14443,2 +14443,2 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__mapping.html 60b20d45af1549ff70e116ab8fb3b0ae962d09cb32bac85773e8fee8d64732a0 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__matrixfree.html 22144d281b6cc106d683f44e1a288c7d9abff99837ef96eb42aed024b61691ef 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__mapping.html e91a37369710c19f079643c471b815478cfa2f4e4145f164d42733b679bbcc50 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__matrixfree.html 6235c7e81d8b2e2348e0c0c13cf980d9c596a1623432952931fd82bc1c96e526 2 @@ -14454 +14454 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__reordering.html c5ca5efadf35712a0d830c28c101cfb9ced96e39b6910c40cc29a48bfa0d1783 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__reordering.html e919be7468b46cf592f8d80d551074ce1868fc752dd56504e36743654ae29d21 2 @@ -14459 +14459 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__threads.html e5785821b64f9bb9623ef1d9c11af8213ed0e9433a65f71a812244bea6f3f1e4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__threads.html f3009e522330ea6e4b0decdcf797f44386c1f78d93ba41599860c3a727d0b5f7 2 @@ -14463 +14463 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__vector__valued.html 188c0194bc18492e81b9738b3d15a4c4990026ae1cec2f31d7e73df433aa340c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__vector__valued.html 7018adc6ad5238298644dab06958da3b4d73a00da024d5dbfdf8fde26974d45e 2 @@ -14556 +14556 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/index.html 640cfb8c69f9b44643bc62cbe74d92e1afe1f7c81521927c38fded4089287082 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/index.html f455aa19a246b6548fd2596912d8a8e15aea8ac8ebc44be1f4a22324b8bf2818 2 @@ -14559 +14559 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/index__set_8h.html 86541f02a374ed3313e6e1245a1bdb2e9f9fd1754bbbd20745d6e930268104f9 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/index__set_8h.html 7f5026ac945042ebc0576319f17d38cac68682297ef1620d1219739d33455da5 2 @@ -14893,2 +14893,2 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceAdaptationStrategies_1_1Coarsening.html 826ba31e7b7f6e436661de9fdf74ab18aa4442aaeaabc8d29a8286b4839b2125 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceAdaptationStrategies_1_1Refinement.html 07f88c6e19eeeeed4508af312656de92aefc9ee7a3535d4de2e2c26ed4b1af9c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceAdaptationStrategies_1_1Coarsening.html d005ad98eecd62fb740fe0eb3fa762d9423992cdc6dd8491e2be3c4e4d7773b0 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceAdaptationStrategies_1_1Refinement.html 82b75346969b480692d09d313567ebfbfa4a06381d6c2724f8ef6fbb431a2567 2 @@ -14909,2 +14909,2 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDataComponentInterpretation.html 98b2360f199fb01224b72d418a1315115ba5e04f3e47c7641fe3bebcd2c27e7a 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDataOutBase.html 4a368d2dd873ce63f35c6339e163ed4e61e7d419ea5e8f7f92514909196c612b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDataComponentInterpretation.html 6cd40085419662e8bc5a683bb532c1e9a8079a731ca6e2354b14742738650f67 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDataOutBase.html c1f5c7eb55769018150787e530cd9439de7a1c5a2e3c0798f7e2716f8eefae9e 2 @@ -14914 +14914 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDerivativeApproximation.html af3e4d5fb39accb42a72282f6f53e8dcd4d87897da53f8c2bbe7e106c30fcb17 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDerivativeApproximation.html ce0008995d8824ebf85ac8c992c75e1e3d2874fd9fb5d9701205c9671752f9dd 2 @@ -14920 +14920 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDifferentiation_1_1SD.html 8873a552513ee1d2a13100e9b2053b8dd33c516edc46433fa0574990a976922d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDifferentiation_1_1SD.html 6c32a4787f5b7524c7231965875012a19972ea8ed366db9c1dbedaa7bf4d70d8 2 @@ -14925 +14925 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDoFRenumbering.html 1487a925ce8311d41be2aa0662980ccd01111d688827e2f6af9e19fe31dea5a4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDoFRenumbering.html e43241079147cc0abdcc7e4984134f1248f332457c245712c3723a055a542d77 2 @@ -14930 +14930 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDoFTools.html bafb43f2a70159af82e1423f3ee7caf1364e3da7f8e986b76741b5f2dee2d929 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDoFTools.html 023673ea6941ca3d732bd7ea55968c5c77e29671951ada0c94f782c8ec4978a8 2 @@ -14938,3 +14938,3 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFESeries.html eabd339eb879dfb78b9ee921320973be02062ab16f36a467265879af343a7a28 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFETools.html cc582de68991e931cd2dde75106815dba4b25f091cbbe9f84114da912f9168d4 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFETools_1_1Compositing.html ec3bc679a36565411b41bf3436ee9cf9ec4b9b44a9851b5dae1cc2a61ec96602 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFESeries.html 491aa750f117d235ff1adddddaec526c71d487f3466e59fb1a18ad0af3fc1445 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFETools.html 8d85bfbaa2e91feb302ea1b968b85e333017cecc90e4165a02c1eb21540ca0e2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFETools_1_1Compositing.html c74bcd6a122fc7b030a99e23aaca3ae5bf1b72f90fff08a184ce1c47e0907914 2 @@ -14945,2 +14945,2 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFiniteElementDomination.html 1e0656b5b07c38090ef3f51694da9f19bbf8f0e224e03a6d5747e34c73214709 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFunctionTools.html c87f9cb1ee44f0269bbec56998dfd0d4af897162f4121c275bef6a04cc7af49c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFiniteElementDomination.html f36ecb4cc38a819dad0a360358edf42cb9a3e870cc942d6cf0214244cdfe518b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFunctionTools.html 8ee67ad1a3f13564b904aefa921789bc1c7161f29f02ea75eafc2dc4cce417d3 2 @@ -14951 +14951 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGeometricUtilities_1_1Coordinates.html f50f83b4e5374a6ecfa9493720567d1f980ab6a31796409e3d6f17f67c7541d4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGeometricUtilities_1_1Coordinates.html 024634e74bcad04209bfd699af17dbe5e9fc444962f25074c49557f262f87e71 2 @@ -14954 +14954 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGraphColoring.html 0914767e18c6a1eb91c2df5ad9e6e27e84c6ea07cedcd379f0a9bb3d128fcb1e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGraphColoring.html 198473783154190ec39485d3c8dc90669e56bd57eb213b2a781fe23692f12692 2 @@ -14956 +14956 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridGenerator.html cb29b4681f2969ccba9a9440e379ae01ef8d2b8fbf2f9c1178ab6fdd1307cbce 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridGenerator.html 3ae46252edb3ef30e3ab0369537aed06e0c43162d38d8c2a434da06444321c77 2 @@ -14959,2 +14959,2 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridRefinement.html 244fdaf46454d437a30c49543c019cccb157057968c109566f1180c66a23df17 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridTools.html 58e3419f57aa32fa019c0201204cd66f663b1a8e03d24e74fd8302b56f9fb6cf 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridRefinement.html c70bfd76999a2ea33ca296d170a849ae2a688efce4b0ce09d1f08817eab2fede 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridTools.html 76774cfc2445346bfe4f3aee078521d62ad7f159c8f1ae70254ac4e1b20cd89c 2 @@ -14983,8 +14983,8 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators.html 2a3d2af5adb62d80d87878d3d4a462bc83742615d00f9c6c948d7117259d10fc 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Advection.html 6f8ce1d7f6bc5b0dcaaf8b7dd10a84672b760bc6f2b5feccb033536b294a93cf 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Divergence.html a1cbe3853c3955bcd8e0208d67a1d06a655631fb3d3e2b54628ba9241b33b8e1 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Elasticity.html 0e6d0a9b626188d119cc5d963cd704c52dc256a6177993213061a6d34730fb41 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1GradDiv.html 322f0732dae9002643a7ca22c35ac4625ed37a658920c4d5d3d6cc19122b3df4 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1L2.html 30f27529f2f49631e6616db0c0aac8cfc825632e87098208878ad25af6e0ed94 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Laplace.html 91d7e9b469d95d00e701a6c301489421530da77c25c8d3c1b07b6dd00a30f3a8 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Maxwell.html 518ec0fafd38198cbd05c216e3eb3b627c9d0c4dc80bd095ba5cab97ddeab4b5 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators.html 407abe35e88d7500d6e285371c805984ef2e8fb62d7b2ccd09908bbb6b439f40 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Advection.html 4f7cb7148e4fde0b560b6ff75910c7f4cb324d5269aad709dd6267561c30afce 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Divergence.html 39f2d840493c16c84721dca50b3c7b464fa6f7ff7cd9bd47ae38583e639358ff 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Elasticity.html fc164ca780e3926c511b0f871c8868e24fe18bfc65338bca7cd17b4015efa743 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1GradDiv.html a81fa818343bd3dab379eeea88f5bdd8cc61ad57948453330b527711b97c85f4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1L2.html d3f80c8fadab799be8d06d2a476af5c453a2038186daff5fb73dff4d4410b1ac 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Laplace.html 0fbd69551f2bf0b29e7b933a0fc9348c0eb5db3c9240a6eb89123da744ac5dfa 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Maxwell.html 306b9e910d5813d27feecd71e57c3935a4baaaa7c94ec2ac54f1149debc3ff54 2 @@ -14996 +14996 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceMatrixCreator.html 754f5f8052416ce764db22f7548f1e9d78af62da328e845e250d130210bfaeb1 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceMatrixCreator.html 301086f46806e9150682e4aa3f4e404cdfda3f17484c859240dd278f0884bcb7 2 @@ -15010 +15010 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceNonMatching.html 8550ef0f42af53c12530a1ecf98256d9362b39ce02cd95840ac22a19fb3e1c6b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceNonMatching.html a9629c01b8523d65702c388d520c50d869e81cb0ed9f14836fba43a68764a81c 2 @@ -15014,2 +15014,2 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceNonMatching_1_1internal_1_1QuadratureGeneratorImplementation.html 153a91012d5d2d9bec9e8069f3b65f458182cb71d7dad85937a853759cce3482 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceOpenCASCADE.html 42185f7aeb3bbc1ddbafe35be427281ac0980f47ba0227093b4eee2a2c1d5ccf 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceNonMatching_1_1internal_1_1QuadratureGeneratorImplementation.html 42f94da0246ddfd45a7b1f36158e458a2a325d6c116206b810361b54e8c28c2f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceOpenCASCADE.html af1200fada2225622b94efeddb04461d3de0c729113849c91d9d61a9cd6aa3d4 2 @@ -15023 +15023 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceParticles_1_1Utilities.html 89f13659d237066004e779845bb21a4450ab5b99f15ee8dd888b8b65ddefcdbc 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceParticles_1_1Utilities.html 9a03198764d7f3623d447f7b47e009f28f5cb17f7f8a573ebab2da6b4b90a0fe 2 @@ -15030,10 +15030,10 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Elasticity.html 05f54142789b79a919c3590ed109d8d4b92d0dc9d8c571dff044c01087b2d42b 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Elasticity_1_1Kinematics.html cfa3b7a4aaa4e7b7c7e1f513ef14c903c92dd3c9cc108229c4029ccc52d761ae 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Notation.html 137008a8237264bd96dfb18d0ccad91888371396d8cd50a0ee2951322fdfaffb 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Notation_1_1Kelvin.html 0660e39ad3ab750be4b8737675e6396f5d6170ea00474c76796952d5478afc45 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations.html 8cefd1b0ab208667dfb47c275aa1312ab27943c4c71855461a00526be619a4b1 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Contravariant.html 58f0990a4322595830687de173febb9f1edd4f380b50f4a7c49b2db847bad4a0 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Covariant.html 974e8db2431fd8a37a4b04b39decc53e2b7a79fd49f53860ada38253edca9d35 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Piola.html 416c692cb15fc7ae76c22ef272561debeae09ac1c2c7e90494e9e0e764a4d248 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Rotations.html a98ccf55bfd7c02a734f6c59670166d213de64ae421efdc605039b5a334dab71 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1VectorRelations.html 0cc52863ff5ae3959d865f5683e4ac12aea2cb767e59e7c6c72b9fd1b435bfb1 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Elasticity.html 5b45fdc0f3b7b41ce6519faa8d61ec1a310c3b0cf2d77d836ae15064c0235075 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Elasticity_1_1Kinematics.html 8d714582a04702923bd03f2132c85f65718b2f2f91db71e2de2425a6f23d053f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Notation.html 6edb90b63f6bf31cf6be532244aeaa217698cc8387b709908ec67e4ab432183b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Notation_1_1Kelvin.html 14940913c77ea978b512b3c4047fc0fba741256b3f22a009639e4e1e0bc67d1e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations.html ddd9a3f852056ec2555f6fe3d78f9e2ced0c90a554b2fd8d99882cbf4cacc7fc 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Contravariant.html cdeaa962e4c9ce888a1511609db759fc32ffc7edfec59c141df25bf2c7d9040c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Covariant.html 296d2fc06d1272e26ba93a08703c6db21dbf79e4142f13397321ddf2d4e0afcf 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Piola.html c985e9afcb3505e942c6e1c600406bea53a21d78b11204b448ff139cad87bb9e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Rotations.html 529bf19c4b52578f8cc1c637bf643998ee87bc1957019342e3f02ae1c45f38aa 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1VectorRelations.html 5003731e875ea30075f4b9d0c83570bc3999f769306af713e1f28efe3fe9adde 2 @@ -15047,2 +15047,2 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSLEPcWrappers.html cfcfe2a9873d232188b892736805a4248000e478516606cc01af07759103c1a7 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSUNDIALS.html 48134a3ba938a9359eddee674bb9b9f94fc8c574533b78c6bb56964358ea49cf 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSLEPcWrappers.html a3f4522f7447e2cef49863e9dc5bd1a403bf029f50bb19116e68650eb633d8c3 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSUNDIALS.html 97cabfd440707a6ad818dcdc031f8ed796db03dd9c2045c7b00df75d6ab5604d 2 @@ -15052,2 +15052,2 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSmoothnessEstimator_1_1Fourier.html aa3e759f2f80bac934597b767f58d43f0607aef887846a4caed18a67876fbd26 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSmoothnessEstimator_1_1Legendre.html 6bce3c92e2497f7c5dd08353511287b27f5968e6f0f19527057b7dfd63fc99e7 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSmoothnessEstimator_1_1Fourier.html c4744aeaf1ed543e5d45015a882b10fc3c5f8734049b43125be385bad960fb35 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSmoothnessEstimator_1_1Legendre.html 332320c772732e0934d4275e44dd8f5b3c6b87bacf078aaedeaebd96ffa85bc4 2 @@ -15055 +15055 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSparseMatrixTools.html a0a1b596e3bb781ac76651787c6f8519d52d5ac0ffb280fbb635ffbac399b441 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSparseMatrixTools.html bf2a1dadb57dabd0003d38a9bed29039829e0d9ed2d897b46031d2a9fe0ef717 2 @@ -15060 +15060 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceTensorAccessors.html a94c468355d211167f4a7e7f0d128d946ff5d552f531db0d2bab2325bb1913c7 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceTensorAccessors.html fb0930fa3d36ad50caf02cf3382aa3c9676291bfad62f0328b9595520b3318be 2 @@ -15083 +15083 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceUtilities_1_1LinearAlgebra.html 98ffc8db72e222f85c8599b8d64d8d465adce206aa938dcd607faa23a4bbb255 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceUtilities_1_1LinearAlgebra.html 46b4fe803b6a400f2964a0bbf106dca63b14bc6eeb9b921fe94beb7824536738 2 @@ -15085 +15085 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceUtilities_1_1MPI_1_1ConsensusAlgorithms.html 50fc8ab54e043e3c0540ae056191dd2aa36f6db5044c104cdd70d5917396b631 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceUtilities_1_1MPI_1_1ConsensusAlgorithms.html f51894fb552974a709f7cba19ca77453755e88c392bcd28fe2764e72b01dea7f 2 @@ -15096 +15096 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceVectorTools.html f8eff9bdc0f830d93244c65612012505e347ee773b4f827a7eafbdfd214a3ca4 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceVectorTools.html f693540e7bfc387cbb7bbc2fedf3f59a975024f661c750c263cba01c66e9ceff 2 @@ -15116,2 +15116,2 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacehp_1_1Refinement.html 96639254eab2a0f3e7e726b44aeebe4014de3bdc1c1c25beee985f059ebae8f7 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceinternal.html 4a6e4068692974b468e3494a4407c98bfa6784f585046c3f039f9feb2ee87fad 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacehp_1_1Refinement.html 2843a4a99640f260b691f4568406dc17adb4f810afce84065ad41ff05b04cc3c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceinternal.html f45075d10ce406998137d92401d8aac9ddcb905ca6f24d0f8a91684c3087076f 2 @@ -15251 +15251 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceparallel.html abd9c4a8dc4dfe86faf64510d3ecb7f56928fcf8908745622c2547a6a2643041 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceparallel.html 91076a12b04e52593e0c26272abfdd75fdd984a7d6efddddefbe37a0476072ee 2 @@ -15693 +15693 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_10.js c62a591cdbb4f122db6727e1901b54f15f4f5c93cc486af5c2e59a81c5c1ac0c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_10.js dc7d72cc7866a18f5121bb4853717be21a70e21504c54f9ef6865b81b5b8d74f 2 @@ -15700 +15700 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_17.js e862e114a0410973cbbdb171d4a49e8ea79e76da1e69a3544436fc5ab66131eb 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_17.js e012e763c83a05ccbc87e3e62a9d461b9249a89f0cb8f5e5f4dd0a7086bc44c3 2 @@ -15726 +15726 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_d.js 9e5b28df137235a40cacaa753f542b7438bfa12adfcaff53b158e07ec627c4d5 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_d.js e3599b4c0a3acb09e8df0c213bfbc732c9a1f131400f6abb2fce0163d32aad06 2 @@ -15819 +15819 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_15.js 9333795cee2ab79403dba36dd2a22756d8d14df1aae3936a7622fffdf2e27a5c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_15.js be773d21e6fc021c5e148851bf230ec52a0686874f72b53f3cdf5dce76534d7d 2 @@ -15839 +15839 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_b.js 77e88dc09ab2312a09f57343685b80cfa27b86a29eacd8c8c31f2eed1d402b38 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_b.js f88be5e88c5c654f4d1cc780dfb04d6b4bda959d0558d050db5ebdec16baf88c 2 @@ -15842 +15842 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_e.js c328f657d390b8ceb91a34e2c4bb430b02d3857282cec16755b6a76a6d83236c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_e.js fed7d830785f0c62535a98fce912df47a3c6f974f41832fb8906c667e3dc1ba6 2 @@ -16300,5 +16300,5 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_1.html 564c336e94929c8759de4d111411886165208deb4b3a71053c68eca87a553f60 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_10.html ec3470dc08fdfab2056d8e582f25849da937975b319f2e6bbca11a8a598c5568 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_11.html 14e10d3530b281869c1dddcf4d019a383d6fafe62f4d213281464494e7f33576 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_12.html 4d1fb819215aefb2a1581f7d8f26bf2742835d0bd3f2c68e2483089aeaa2f536 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_12b.html 4551ddb309bfb52f501ab68165a43e3d22ada46522ae84d94dac077620efca3f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_1.html b0c32f89fae9274119ba7e7bebc11cf4caf15ab09a3af23463620d6db887275c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_10.html 79d9034206dae5b7210fcf3ee5c34f283212c385cbdb6cbb428317fbee018cbb 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_11.html c8379e08120b035738b564e96e85d02c7547d864a4b79cd9fb7d6d578af2ca40 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_12.html 625ff1acfc184fbc7948ff6179137c182bf800ff7faba7ac5031d811275d89bd 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_12b.html c4d091a910453131b8b665e208fc9c1be3437550ab3adcdec15cc71dd69b92b5 2 @@ -16306,3 +16306,3 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_14.html 22982faf6f713a84b41fe6e5b123ad07681c22383a61bdc30b658187728f93f5 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_15.html 41a1ebc1abf353882225400f3c1649a97f5f082452f14fbd714be675a26534f0 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_16.html 640128b9a5a96c9a151f3535e225be40f12171c8bb7388d5b896dc35b502350f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_14.html 81f77428a7f67297bf7625f7a90638af3ec4eee1c4266cb5ada64975d6075b95 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_15.html ccce36289ccbbcd6b3a75524d74dec14d499b16d21a98d31ab3765823bb4614e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_16.html c522546077a8cb189010d87fea0b3f74ac6eac9772f2ba43185b5ead72207f1d 2 @@ -16311,40 +16311,40 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_18.html 1db1ef10d9c6efa2e8ee43c79bb62fe8eda9c5371da34cb919df89e0fe026ef8 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_19.html 545e9244690261d57d563038ecdff2796eaa85739d769c185e1e2178d8fc4b6e 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_2.html bb78a6fa9643a272e4aec7ce6f39f41f47f050976d48d3d0cfba8aade4e209cd 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_20.html 883d3ae9657c780494b11e6b1edaebe5b8af8af5eed35fb777058af96db9ca1a 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_21.html 5492086131a0cd46111bdb50c248ad1f0c922396434b9e357963a291fcff1010 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_22.html c805f66a988b2df61df637cb46c134e280c53bf7bb544dc095901c2715f3829b 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_23.html 92f2b0640722220f7414fcf5a4bd2fd49cb4bfd29ed3813df0b62c4269b9f4e4 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_24.html 97fe483d938d7c67f7d4029b6bdcaeaa53d2cbe593ba5b577ae6236c1a55cad1 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_25.html e9d447112b328d1b40844faeaecf61f9e25a9e9d9004908bc281ae8bb7d44cbf 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_26.html e58d5b786a88994bea4c93c79d9560e4cca80a96c1e32b7cdca70e0b7c3faa4b 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_27.html f459be59e51fd50fb67b5888e678060f8c81c4d96230843b4873642ffcbf958e 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_28.html ce2683d95a9b82f77d5ea3269cbeed9ae90b9bcce4bb77544f4236e57dcd645c 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_29.html 8db2b9070d1598732b207ee8f444dacad353893197fe7f644e1ba7cc6f29f142 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_3.html 841987fd718f2691ae1e29e1c27625d8fc1b7f4f8291bbd0c40766f18c6d2964 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_30.html 0eea17bee96b143b66dc31d216e5d04a8bca89974be0738fa4f5c8560bc57191 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_31.html cb44e40d3683419316e0fc9a3f0271473e53b2514b8ebacb5fc70891f38d4903 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_32.html a1040e05cc73a5b24ff0efff629277c3de9483172022bd185f9021e0a61acb4d 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_33.html f450f574f8821b42543e1c4fafbf13781df99ff3627350d2fec27cbdc200e8d1 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_34.html 3e317448dad2b7e1abacac1ced1946c959ed1386941dc24aabda04829864e2a2 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_35.html 1998b24de442715afa10ad5902de54fcbfb99dd9acb695e95c7f07c74f17f611 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_36.html aafdf52c1b10ababdb2747246ed5404e676b4641e57efc1c56b938936f193273 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_37.html 0c1256b96070c34a966f67682d0e6c7ffaef0c02a473d71d29d258b4cf9c95ee 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_38.html 7667461a220829b08ef7a450b3459be513334316a0202f5c9fa5ab4247b00db9 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_39.html d454005c021e8941c5ba292a04b6033479d298f3daa7f0cb8bad4a86f64aa8e8 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_4.html 88e3fbc0eeea04832afb14e3a734cd02b73538629a7f54b1202fab9bd433a691 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_40.html 5eb888b7171ec6056bce30b000e67b21c560bef34b9ca710f448426c8a454e73 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_41.html d02ce162033b41c46701a34dac84c937fa3bebb7a44a7f5bec98138fb908fb47 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_42.html 25dcb1940086e5a92d1e3ff6d35ae182c82e2e6a64dd6e1f474d44e7847378d7 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_43.html c85d14e1b0e4da04fd09d45ca0aa5d9e6630259145ec9443e260504378cce994 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_44.html 7eabf2371b4bb7c61377c308d794ff2aaa8d397829779da7986dc528eb35df27 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_45.html 322977bbf64a4aec20201a459cc9d3db6b0bea1bd5d6fd1d13578e9c0bdf7b6f 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_46.html 35d4a5a439087e08a2bf1369bdd865096288b4880f8bb4739c25b8cd374af8f9 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_47.html 4efc55a8ae4b661334938655be57c547a7663a168b30363d8bc67572a7660496 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_48.html 73c6d69ef1704a03bbc941b146cfc576db08a15472b730f437a25a9ef6595b58 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_49.html aaa33093e28822959af572abe03137b415661342d0a9fea2018bb346a954aa22 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_5.html 9b91d3519d90b8242c94bc0d17f04307aad83595ead02e666e83eec11f1dcdc6 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_50.html b81bc2afcdbb83c5d2001dc955337e4094fcd146f8d1e20cd72e33144f365af7 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_51.html 943560c384d2ffb3ca93df27cc7b98f348a204e7834248db2fe3eaa07ae8aa94 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_52.html bd0a8321410d8459e99cf36ff6af04269c0db13872899000a0d0c5c015e2ba4f 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_53.html 8b6534b3e2128aa82184f33123c4230449a1ff7989be50af5e845ae6278dbe9b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_18.html b7a52008633e96c2bb05096588e331a14345c10090cea4b25d9c8fcd09da42f6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_19.html 795a35799cf9e69a0c9e69725e96c60db752341154775253db0af896b7c1f6b7 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_2.html a2e57e4d4703f2a235a8567684ab09c44cb61de62b52dc21c8f9472d5e27d935 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_20.html 8eee53c570d085208c041f65840efe30ebf7047d4127074045e9c68c00325385 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_21.html 3b672e392ddd0994404917726e93f61a38ff98bb7e7962cfecbbae565d90e5bb 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_22.html 797c31264e62bc6bb77729ee3795fc668ac943715015ac14772bb48bceabd599 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_23.html 0ebb8c2dcfc038032370ca02b0f62992b31d650067bab542f0005dd00512a6d9 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_24.html e492e9449dd08aa0210a837f1c982558eb64830ca6bc8c81324c7073aea8af64 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_25.html 9b269d8479ce8f017a3df4c51dbfbdeb28ddd2e770d2e81752ff885786d1b967 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_26.html eceaa6285e0bae3e200fd88e13fcee29905f2674d8f6eb9ebedf1e17c2cb9e6d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_27.html 97419d2a8f84b04f84ffc19228dee21ff881fb03ae3a4593ff0b9130729c6de5 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_28.html 0aaeb230a203092440a8274c807a856e2be382ab4789753b5bd2cb75c6e14f48 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_29.html a92cd6235058f6168ee7f1b7fe10e88f994a5b92298ae11eb68426e4c7cafedc 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_3.html 1097131f5c64c5f5e0050a6502f6fffbe05aa09f97f2854958484671dad2157c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_30.html 30afda04bb85b4842b0feb96cb5a9bc629468afeeabdc8b4cf0532cf87d23f32 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_31.html 28221ace62ec717c91cb84ec080aec433a1d8b0af7b3fe4474219400ea30b55d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_32.html 4576418b41fdbcb6a7cacdd08aaf65e14cafb620c31516be08cd97dac1de483a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_33.html 725de7882d128b7b11467deecc83362364c2cd15f027117dcac7a0bbb11a0790 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_34.html 7d6684db6027e0f53fff4662e2fec41d3e7707c0f1e6e7c8aa7371082ed762f3 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_35.html 0a72c551ca43a8f903f652639f46ed9c6078c5745346dbad7bb8152ae9f163a6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_36.html aef3ee52725b5ca12295bc85c0b030af8477d57930f0e50efd086d1cb8690465 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_37.html f0037b74b5b9015b4ce85cacd6d945f48707ecf60fb36d7a1f5cf018dd590a23 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_38.html f9c424b8ebee2b99c05a58670a01eed2151ca9cb4a386b126a1fa33fe25baddc 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_39.html 2719b409b1982b71c32cb4510500b38d98fe766348056e07d607cdfa09b3e377 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_4.html e018c6cced3a15ccc59c15b323b85bc755460220efef6844ba929d7593b9f450 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_40.html 4b191c03794f6744c2921eb2176d61b61b96a4e9841d33840b1eace7c260e527 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_41.html 7e1bd74453e7c0e4663b76966aa7c56f3f0bbcdb310a5aae7620f644ce24a96f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_42.html 6b45ca9e9635a5016ea455ec25e01b9b2d0741088490e923770f5383ee5c4da2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_43.html 0d1d32dcdd3a7da145ddd1f3a7dea137142d2d426574645b905e41804f3e212d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_44.html b3cb7263b244754c5790e9ef6358720fb5088b5172fa8f9203c3b104946a85c8 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_45.html 509904b7b981668f2a84321a15362fbd4ca4a90fce1c4d792e81b9e1f9e5a480 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_46.html b914a78bae236a47c5b311ad82cc5b1e94158bfe543768bc2c938648ce23ee2d 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_47.html e22e8425c422ff980df382266610689458d00c837a7d3de1c1321d0373850448 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_48.html 940c97d8068960cfda5a4c8cbe206b5218a99079de2ba5c15162e7e911e9f2a2 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_49.html d3232625b71299f4fe486bc7e290b4ba8132c2c29bec4b41f02d7e15f9de26f1 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_5.html 041bcd4249856f56a6bb0b320c989ed980fc9ed8751de2565b0d033bc54e9243 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_50.html f46f2a9520a3f608235f44d8cd964dd7ad17ff5d0c16ef6710a01b88d54e26ea 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_51.html 800dd586ef9ce4f9ffc35ac9a4b636498b9abdfc035d0ad4cec884612bd3b522 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_52.html e515a074f2e9ad5c7146059a4d98d6d4a5cf7b601542364a04dabf48befe2b88 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_53.html aa0bf178c6f47100cb3a6a10173b74409f1cdc26c6b8d3901eca3acc99a778ec 2 @@ -16352,31 +16352,31 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_55.html 11fceb61ac068b11d3affdadf467ec96ff6aa80ca938e90b3c620a3ca590dcb1 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_56.html da511f30020b55902716b68c62e7a0f6cfff4f03cbc045aadf0a0d278e7f58bc 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_57.html 184b5f25f6a40a48c255744a8f9aeee25e14e96c69f53bb74d89b23c3b3866a9 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_58.html 1356f01507679836a3f182038315bcc915b0cf9b3add9eb8c95929f5638bec0c 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_59.html 68a5c15a2b8f8477beeecb42cda00657e6a44f7cec24e95c35b77f277ae77085 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_6.html 2a97e6b59e43cfc4c3d10e448b1183656a2626f1c3eaa8d6d1e8814f7a5c824a 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_60.html a022e6b72e0ef31c69cbc18d551b296d470b668aa901fc0bb4167b56aa03ede9 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_61.html 90e9e464e7e319ad1612c553f6ef5dcda68b27aaf9c53edec6364c8c25ac084c 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_62.html 49213a223718c8dd2725cddcc33097985678303313b8d33c78bab0bc7f198f3c 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_63.html a05631f315b695bae46f0d6cca8793632fdbcd8a36056a38b10659e6c69397d8 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_64.html 46d201113d39b8df06dcfa2ec29a1bf72c54de8e6c1ff9db0c334742025ccc3c 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_65.html a6aeaa10edcd1363eeae6784d0a3b350396e0fe6b2c09ba1e39f248adbc82027 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_66.html e93313418c337cf1c607d5dc95624ba214e788b4e8c2588523451336d6752152 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_67.html 5719df59ef78b226101ff9818cc3184f7cbbbace496b9fa635f7fedf83df5eb9 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_68.html a63306ffc7673e203460e10cd4e2b24f08362a33de329688cda09dc02d48e76f 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_69.html 6013c4ddae830634ba7f11a90f6bf8767a636085c89758cea432325970800fee 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_7.html f9692aee4aa75088ad801823b5a85e74d328b1288d278f503d1d68587c253a1b 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_70.html 7decbabaedf6a6aa2292ace56e8a8acb6f6135e61a329bf4a23920281ff1c7eb 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_71.html 379aeb5a835ebd11a082215ffcb8eefe8267fe7572d970c608c2c88714019960 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_72.html faeb2e2527747b56c8dd71f2bda82c448d1eea66694e1a6185bcff8a99c9f16a 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_74.html de436f6d868a36a2b6fcc2e024bceea1794f6b7f91447da278df28c98bf6b2e0 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_75.html b2c8bbf66082722f810b27ba97b3720e7b31bc6a388cca0eddd7be09dde4125f 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_76.html 8c428964cd340b3a64847f48c489ee792b5e46a68b48d792b5b69f7ca629bc0a 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_77.html 3b47ffc6bcafb043c8d49be4337ddca041a2e63ba029347a7911a48cfcc76d87 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_78.html ae887b4a7ca9e2f00eeac85aa3a210aa2b405dbdb720245c9ac2965d78e8a963 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_79.html 2f2169c1882859fb5138d7f47b312ac1a253fe57cbd9d6f4392bec2b35d1fb1b 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_8.html 67c54d9c20f47f530817d5f68b910f029b47491238235519e3b62da93dc6eeca 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_81.html 47cb5d605196c3f0d3b85bbbfcdc7281dee649e76570fa84217fab58ad3a5b79 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_82.html fbccea139933248d6425c0164132d20ed5d79ee6e7e15f837957d2c129f4cfc2 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_85.html 7bb464332b75f782ee9591648e64d8f374f37bd85d9f4552770234b0d62a7820 2 -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_9.html e582f6acfb699df4299238704df62cb51f2f4ad24b7e99fa4c909f587c4c8cf3 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_55.html f03b958c85560d6fbfb77474e477bcb5410325789b39325028d4bd36f4c95626 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_56.html c7d8e2127fc46bf88b10c6f1627907c83cac5159ea5e1efed523b9d1face1169 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_57.html 5b0b3e8de9be45a8db7b8fdc633cddb88a4b1ca917e72fc8834ed526008dba71 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_58.html 27576f7969efe114c2c67da16568ce5b1f0026a147078101a65934b7d10ac66c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_59.html 8297039787f554d2d0188b1a235979ff029f93329d393cf22847db763536cb3b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_6.html bdb5a667c66d3c7db889d3e7dba841b3e9249dc3ac9953bfb2eaec93c537e7cf 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_60.html d70c334a118c74c0af3e44e4d7df58a9da3b456db1586922cdfdf16c3b99ff96 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_61.html fd94802adfe821bd37df53b9c2e02603aec80ee7d12f2eb4611317c3b7febcd8 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_62.html cf5d49c9c38323b899712a44d1afe5cdb0d3542c47fea77b8758518f4f8dddbb 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_63.html 5d80928bdd0f6f26fa5e28c3fc62bfd78ec00c0529572459b863c06d26a4b297 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_64.html 395c3ab291f56f99aba97480a5b9743a485c78ece18c6cbd36b33352d808bcfa 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_65.html 1f9a334aa99df52499b5606ecaa30db01f315011b08f073725d8ccf6144958df 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_66.html 10f75d1792f3baea327877731b62ffb22351d0cb0242e3ebb4c7161290685b24 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_67.html 52401dc6f8f3d4b7b70f38f405ce43d1bd68f6719f3c260aa1a778e5b6e66ee6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_68.html d709c10caf2ba54e9442447804cca131efb60179c70016bb0b1844242c43b732 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_69.html 707ee951d7854400c2c4c4d9098454280562db404e0aaba7d5b375c9d1c5d193 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_7.html e4f91c406c69b354f120960947513e693aece28c67e805f4d33f4e34a9871def 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_70.html 3e6f2a94a1d33e9c0b98c032b7f9d918064d2dcc271e1f7f5cf40c0717bf62d0 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_71.html 3ab396fd811a6c3a8eff8f8bd0250d104f0746cb39805aebbbb71dbaf1399821 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_72.html 30b367577b275059519335bc583fd7d8fc39fd4775773941357933a171e60aae 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_74.html a0d0ca04f522421bb572d53f3b6c264dd5a2725c396336feeefc218a2e2f9567 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_75.html 95d08172fba72bd2a63a8faeef592f768ff93994a4412a2367770104f753f933 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_76.html a7d8995cb3578ea1a8c3774d9248a85d755d2faf93899981148032b09a6bab9a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_77.html 09ea852ffd74c63258efba7bd0eb1be3af5ee08f0aa8a7970b483210dd3c2f8c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_78.html ce8b1e8d44cdc655d469fdf1f8733bf9c5f0bfc776f715829759cc1b0b1b446e 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_79.html 309f6a594dee25270b438460f304fee41eec3485f73881af6527adf6a94dbdbf 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_8.html 8d9f6981159a0a322fd5b703829377e1981620033c9e8f3742ab591640ee2a83 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_81.html 98951e0d4f27064ff4bf05d512972524c248907349a1454691ae99cd2589af48 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_82.html 0022ac510797b4c004173a5f0e1b9b7a1a12fb832fed18da9e51a84bb04e8630 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_85.html 28f9ceb75079c72e33adfd9b0a0f9fd95e7100045b9d9d3fc0ee13911b75e8b9 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_9.html 0fd743ad70e0253eaef13054ff22821137c128a4682b3211a4e802b0e2f411e9 2 @@ -16436 +16436 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structCellData.html afce7b80e250056d99512aa72f5551be9b8226d98676c5bc9705779a3d83e698 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structCellData.html 591817c3a0d60f0c69d1047f5945acac93a0c72b4c457ad8927e07f1fdab2df3 2 @@ -16441 +16441 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structColorEnriched_1_1Helper.html 4aae0d64956a34cc464a13798909dd81843c4be0ea3c0793da096bcfdb6844d0 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structColorEnriched_1_1Helper.html 8e0bf8e9ad3eb304cd2e314690aa6109f7e204b165909d0f5f95764739e5f012 2 @@ -16492 +16492 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structDataPostprocessorInputs_1_1CommonInputs.html de5b68aacd06b900ee494e42469eb3ac9cb9add0250b09f4199bc5e5c8249215 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structDataPostprocessorInputs_1_1CommonInputs.html b5020a0ed1f1f5acb5373c344f82ddea36fb065189017bf4880946adb1155cc6 2 @@ -16498 +16498 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structDataPostprocessorInputs_1_1Vector.html 1ebe750809cba5a6a52b4d642f10d925614e885ec00f2275edfa6e26be494619 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structDataPostprocessorInputs_1_1Vector.html bbbd9e449f5ed0d78b8f604391f41e5306b431fcf22ae158ef27cfffe814df56 2 @@ -16652 +16652 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structFEValuesViews_1_1Scalar_1_1OutputType.html c1a4c26a34ce26aed5715602628bb105a14dfc157e5de6247607efb5fbf414db 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structFEValuesViews_1_1Scalar_1_1OutputType.html fc9c299df554319dd995c84251e04aab3578512a5958bb37585802f261e1e87a 2 @@ -16656 +16656 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structFEValuesViews_1_1SymmetricTensor_3_012_00_01dim_00_01spacedim_01_4_1_1OutputType.html fe5a6edc900130b45850a951af55fab20c0a17ac6eb3f6c51c8f1406d6573617 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structFEValuesViews_1_1SymmetricTensor_3_012_00_01dim_00_01spacedim_01_4_1_1OutputType.html 7d001cfbc5d2fc68c7309360d910e563516adc64f20c2c98cabf44fffdd438fd 2 @@ -16660 +16660 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structFEValuesViews_1_1Tensor_3_012_00_01dim_00_01spacedim_01_4_1_1OutputType.html d541c2108bca314534e91a0a8d0dbcbaf8dbff3206cfbcccd0da0c6a5fef2925 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structFEValuesViews_1_1Tensor_3_012_00_01dim_00_01spacedim_01_4_1_1OutputType.html 26d6107fc7c6118b654aea1dd8685caeecf16d8ddc739fabc6bb822e193a3127 2 @@ -16664 +16664 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structFEValuesViews_1_1Vector_1_1OutputType.html 152901536d173dea95937845dc7e7ce6aa3be217544046a0304fbb2e33996ac9 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structFEValuesViews_1_1Vector_1_1OutputType.html 372a4f38e035bd0d4a642e9577dfef81e7267f106744093f1f327748da2246d2 2 @@ -16674 +16674 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structGeometryInfo.html c26d802eec9887444e7c142f99fba758c531a88ebcac2c47eabb1b2bd69adfce 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structGeometryInfo.html 568d96137ad3e244879cffffe227ab2654aa4809530bbc3e146d3f07aa5c3e6c 2 @@ -16692 +16692 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structGridOutFlags_1_1EpsFlagsBase.html 28b75423d3fc7445889a87caa0518f4a1dd52a80c8cdd46ca19657a17da45fc6 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structGridOutFlags_1_1EpsFlagsBase.html 2f4aa9e299fdb86c0151700d126c747124753c9b10b58e7e2999471da4779dc8 2 @@ -16695 +16695 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structGridOutFlags_1_1Eps_3_011_01_4.html 6e385c8919a49bf98d1bcfdd6ce400a79fbb0079605a5a3f3bf636d39146e88c 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structGridOutFlags_1_1Eps_3_011_01_4.html bf92ffd56a65391cb18d599123379ba3ccb4a337f98e8dd1c262bb0e117c9236 2 @@ -16698 +16698 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structGridOutFlags_1_1Eps_3_012_01_4.html 800eb536c2cf55547bec1d7f53ea464bc81be37bdca86d11dc3f0882f08a4328 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structGridOutFlags_1_1Eps_3_012_01_4.html 5718b9f6a2960e7089924e8f1ad065ab7615d330199f93b89e4055e70f7a2f01 2 @@ -16701 +16701 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structGridOutFlags_1_1Eps_3_013_01_4.html 0d73b0347bd0a422001f4025f523dc3db7c2b434eb567ec1c59103e0f60dee8f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structGridOutFlags_1_1Eps_3_013_01_4.html 910e0814aac1f0533ab29197256ec47d5af0cf9d68cdfbcb330f59569c9f3307 2 @@ -16795 +16795 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structNonMatching_1_1AdditionalQGeneratorData.html 2ff6d591ed39532d8a8d9c4eacb869f812c752686a641dce0bd083487444c972 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structNonMatching_1_1AdditionalQGeneratorData.html 214ece7f7f82040e5f4e5cac26aff1a322a1f1069a48c12c825b3510d5d8f4cb 2 @@ -16799 +16799 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structNonMatching_1_1RegionUpdateFlags.html 2e94f9505fcd9408dd51359d7276aad218bb3da0800052410643af5a638ce79b 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structNonMatching_1_1RegionUpdateFlags.html f23111fa04fc5c35e5cdc082cb637d270eb7e0c59947c330cd74cb0fa164cd5d 2 @@ -16803 +16803 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1HeightDirectionData.html b8b38304d5b4017bf1eae7cd47e55bc5ce54ebf8a9d4a614178546ab1c6c3834 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structNonMatching_1_1internal_1_1QuadratureGeneratorImplementation_1_1HeightDirectionData.html 9693bb904f2b57489de1b1b00421fe54d987e9d91df2319407973edba9cdbc52 2 @@ -16944 +16944 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structProductType.html 778145fc78cfeb75e932b127311b2a586b3708cf032427e11126d2f510b3325f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structProductType.html 7d44d08f4099e51ebc4103ab73496db5ea59e6ef0530a0d63f208ee49ab4ba77 2 @@ -16975 +16975 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structSUNDIALS_1_1SundialsPreconditioner.html ac3a1267a291c38ed61f113b99d851514247618b520d1b3f565c8af7d87d6ff3 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structSUNDIALS_1_1SundialsPreconditioner.html f1814681429b1a6750aed26a58a88402175f77f27619c5caf3bd815abf9d83a9 2 @@ -17016 +17016 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structStaticMappingQ1.html 8478285c973eb3d87a8d00021e57e16202220c15fa0d02f2c466e724fe326a90 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structStaticMappingQ1.html 5247047554a2b227011825b5674fae8a7fa2bc9acbac06f1126f4372be50fd74 2 @@ -17020 +17020 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structSynchronousIterators.html fb02c8b7504085be6fbf9f6d7bbd031cd9b551ce191d362b475a824206278833 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structSynchronousIterators.html 79be7602cc43321123796a775e0300ac66303cdd00b6892183b2dce0b2ae18a6 2 @@ -17097 +17097 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structTriangulation_1_1Signals.html 4986857acc143875472deb8ee6e8d1ceef886007369a5cf156a472e6aa5f69f8 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structTriangulation_1_1Signals.html 75fcec6f7c21827704453443d7434fa5e9402824cf3ae54ab2dccefa01e22218 2 @@ -17120 +17120 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structTrilinosWrappers_1_1PreconditionILU_1_1AdditionalData.html 8a6109747de5a981de4895ac88d4d8ba6b358cc7005715bf11bc6a6cd1ea0d39 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structTrilinosWrappers_1_1PreconditionILU_1_1AdditionalData.html 54354acedb09b297170ffe7878792ca1e85ea1f11e317d2822d96834c80bf92f 2 @@ -17193 +17193 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structhp_1_1StaticMappingQ1.html 85d872b9065071370463d484e1daff17d352037a12ea00665dac35833d40b71f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structhp_1_1StaticMappingQ1.html e2074d2e99a22aa9869e93a06c639ec532f938cb79699ad8c094f1573bdd50f6 2 @@ -17385 +17385 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structinternal_1_1MatrixFreeFunctions_1_1MappingInfoStorage.html 47d623c961ec39830a59a901c39162ea80723804dba7586f618f165ae92859c0 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structinternal_1_1MatrixFreeFunctions_1_1MappingInfoStorage.html 06f214b03a2c17431078aa0ecfc78d8552f775904b8ec7180ea591a5c6756279 2 @@ -17396 +17396 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structinternal_1_1MatrixFreeFunctions_1_1UnivariateShapeData.html cd47e871ce19e91476a2572cc452fb7c9517846f820778f4206bc2e336557ceb 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/structinternal_1_1MatrixFreeFunctions_1_1UnivariateShapeData.html b1ca67c4ab89b423ac4dfdafd52cdfcd9bc6fb2a2cf73368a83017919308687d 2 @@ -17924 +17924 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/symmetric__tensor_8h.html 8dc3d2b4b1efef463eeb7f92482e96cd4b4160c42a4f9b54934470543e815143 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/symmetric__tensor_8h.html f54a889b8b786e280225b6d9a12207d21ef7d876b9fd7e6bca59cdead5e71dab 2 @@ -17928 +17928 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/synchronous__iterator_8h.html 6b90ef60bc12c3a0448b1ac45bb0ac184098d734d7797143ab9d0788ca3cbf4f 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/synchronous__iterator_8h.html d4d8bf691727f67d69a2db6e1b7c507f33cca24df7fb515f341a52a7aa6d97ae 2 @@ -17958 +17958 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/tensor_8h.html a6f6c47bc14547973fa7d137b8bc8f28a82d60dffb1673b7a1cd1689fbb45ae5 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/tensor_8h.html 45b1ee5362f0ca2cd0f0de8640f6d58cf7c00204b6a0464350ad23de37a91a37 2 @@ -18020 +18020 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/todo.html 9d803e6ea59742b4e2d9acb6d38ad78f5f2c1c0ab22e599ee4b1abfd9ce5d3de 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/todo.html 8a49ccd0ee2d938c2f3f963fa44fb436a3c03fb6e1d64a66523f5a0ad6c79915 2 @@ -18239 +18239 @@ -/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.tag 82493d6b48948563bf31cc0c2566178ccce3e3c37ee1def4264fd01a6721b96a 2 +/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.tag 82eb445a6756690e7e538a2834beb32cd1f665d0efbffdf57d87a4612992465b 2 comparing rpmtags comparing RELEASE comparing PROVIDES comparing scripts comparing filelist comparing file checksum creating rename script RPM file checksum differs. Extracting packages /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/DEALGlossary.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/DEALGlossary.html 2023-08-09 23:38:36.602463591 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/DEALGlossary.html 2023-08-09 23:38:36.602463591 +0000 @@ -100,8 +100,8 @@

Block (linear algebra)
-

It is often convenient to treat a matrix or vector as a collection of individual blocks. For example, in step-20 (and other tutorial programs), we want to consider the global linear system $Ax=b$ in the form

-\begin{eqnarray*}
+<dd><p class=It is often convenient to treat a matrix or vector as a collection of individual blocks. For example, in step-20 (and other tutorial programs), we want to consider the global linear system $Ax=b$ in the form

+\begin{eqnarray*}
   \left(\begin{array}{cc}
     M & B^T \\ B & 0
   \end{array}\right)
@@ -112,9 +112,9 @@
   \left(\begin{array}{cc}
     F \\ G
   \end{array}\right),
-   \end{eqnarray*} + \end{eqnarray*}" src="form_92.png"/>

-

where $U,P$ are the values of velocity and pressure degrees of freedom, respectively, $M$ is the mass matrix on the velocity space, $B$ corresponds to the negative divergence operator, and $B^T$ is its transpose and corresponds to the negative gradient.

+

where $U,P$ are the values of velocity and pressure degrees of freedom, respectively, $M$ is the mass matrix on the velocity space, $B$ corresponds to the negative divergence operator, and $B^T$ is its transpose and corresponds to the negative gradient.

Using such a decomposition into blocks, one can then define preconditioners that are based on the individual operators that are present in a system of equations (for example the Schur complement, in the case of step-20), rather than the entire matrix. In essence, blocks are used to reflect the structure of a PDE system in linear algebra, in particular allowing for modular solvers for problems with multiple solution components. On the other hand, the matrix and right hand side vector can also treated as a unit, which is convenient for example during assembly of the linear system when one may not want to make a distinction between the individual components, or for an outer Krylov space solver that doesn't care about the block structure (e.g. if only the preconditioner needs the block structure).

Splitting matrices and vectors into blocks is supported by the BlockSparseMatrix, BlockVector, and related classes. See the overview of the various linear algebra classes in the Linear algebra classes module. The objects present two interfaces: one that makes the object look like a matrix or vector with global indexing operations, and one that makes the object look like a collection of sub-blocks that can be individually addressed. Depending on context, one may wish to use one or the other interface.

Typically, one defines the sub-structure of a matrix or vector by grouping the degrees of freedom that make up groups of physical quantities (for example all velocities) into individual blocks of the linear system. This is defined in more detail below in the glossary entry on Block (finite element).

@@ -133,7 +133,7 @@
FE_Q<dim>(1), 1);

With the exception of the number of blocks, the two objects are the same for all practical purposes, however.

Global degrees of freedom: While we have defined blocks above in terms of the vector components of a vector-valued solution function (or, equivalently, in terms of the vector-valued finite element space), every shape function of a finite element is part of one block or another. Consequently, we can partition all degrees of freedom defined on a DoFHandler into individual blocks. Since by default the DoFHandler class enumerates degrees of freedom in a more or less random way, you will first want to call the DoFRenumbering::component_wise function to make sure that all degrees of freedom that correspond to a single block are enumerated consecutively.

-

If you do this, you naturally partition matrices and vectors into blocks as well (see block (linear algebra)). In most cases, when you subdivide a matrix or vector into blocks, you do so by creating one block for each block defined by the finite element (i.e. in most practical cases the FESystem object). However, this needs not be so: the DoFRenumbering::component_wise function allows to group several vector components or finite element blocks into the same logical block (see, for example, the step-22 or step-31 tutorial programs, as opposed to step-20). As a consequence, using this feature, we can achieve the same result, i.e. subdividing matrices into $2\times 2$ blocks and vectors into 2 blocks, for the second way of creating a Stokes element outlined above using an extra argument as we would have using the first way of creating the Stokes element with two blocks right away.

+

If you do this, you naturally partition matrices and vectors into blocks as well (see block (linear algebra)). In most cases, when you subdivide a matrix or vector into blocks, you do so by creating one block for each block defined by the finite element (i.e. in most practical cases the FESystem object). However, this needs not be so: the DoFRenumbering::component_wise function allows to group several vector components or finite element blocks into the same logical block (see, for example, the step-22 or step-31 tutorial programs, as opposed to step-20). As a consequence, using this feature, we can achieve the same result, i.e. subdividing matrices into $2\times 2$ blocks and vectors into 2 blocks, for the second way of creating a Stokes element outlined above using an extra argument as we would have using the first way of creating the Stokes element with two blocks right away.

More information on this topic can be found in the documentation of FESystem, the Handling vector valued problems module and the tutorial programs referenced therein.

Selecting blocks: Many functions allow you to restrict their operation to certain vector components or blocks. For example, this is the case for the functions that interpolate boundary values: one may want to only interpolate the boundary values for the velocity block of a finite element field but not the pressure block. The way to do this is by passing a BlockMask argument to such functions, see the block mask entry of this glossary.

@@ -162,14 +162,14 @@
Boundary form

For a dim-dimensional triangulation in dim-dimensional space, the boundary form is a vector defined on faces. It is the vector product of the image of coordinate vectors on the surface of the unit cell. It is a vector normal to the surface, pointing outwards and having the length of the surface element.

-

A more general definition would be that (at least up to the length of this vector) it is exactly that vector that is necessary when considering integration by parts, i.e. equalities of the form $\int_\Omega \text{div} \vec \phi = -\int_{\partial\Omega} \vec n
-   \cdot \vec \phi$. Using this definition then also explains what this vector should be in the case of domains (and corresponding triangulations) of dimension dim that are embedded in a space spacedim: in that case, the boundary form is still a vector defined on the faces of the triangulation; it is orthogonal to all tangent directions of the boundary and within the tangent plane of the domain. Note that this is compatible with case dim==spacedim since there the tangent plane is the entire space ${\mathbb R}^\text{dim}$.

+

A more general definition would be that (at least up to the length of this vector) it is exactly that vector that is necessary when considering integration by parts, i.e. equalities of the form $\int_\Omega \text{div} \vec \phi = -\int_{\partial\Omega} \vec n
+   \cdot \vec \phi$. Using this definition then also explains what this vector should be in the case of domains (and corresponding triangulations) of dimension dim that are embedded in a space spacedim: in that case, the boundary form is still a vector defined on the faces of the triangulation; it is orthogonal to all tangent directions of the boundary and within the tangent plane of the domain. Note that this is compatible with case dim==spacedim since there the tangent plane is the entire space ${\mathbb R}^\text{dim}$.

In either case, the length of the vector equals the determinant of the transformation of reference face to the face of the current cell.

Boundary indicator

In a Triangulation object, every part of the boundary may be associated with a unique number (of type types::boundary_id) that is used to determine what kinds of boundary conditions are to be applied to a particular part of a boundary. The boundary is composed of the faces of the cells and, in 3d, the edges of these faces.

-

By default, all boundary indicators of a mesh are zero, unless you are reading from a mesh file that specifically sets them to something different, or unless you use one of the mesh generation functions in namespace GridGenerator that have a colorize option. A typical piece of code that sets the boundary indicator on part of the boundary to something else would look like this, here setting the boundary indicator to 42 for all faces located at $x=-1$:

for (auto &face : triangulation.active_face_iterators())
+

By default, all boundary indicators of a mesh are zero, unless you are reading from a mesh file that specifically sets them to something different, or unless you use one of the mesh generation functions in namespace GridGenerator that have a colorize option. A typical piece of code that sets the boundary indicator on part of the boundary to something else would look like this, here setting the boundary indicator to 42 for all faces located at $x=-1$:

for (auto &face : triangulation.active_face_iterators())
if (face->at_boundary())
if (face->center()[0] == -1)
face->set_boundary_id (42);
@@ -237,7 +237,7 @@

Component
-

When considering systems of equations in which the solution is not just a single scalar function, we say that we have a vector system with a vector-valued solution. For example, the vector solution in the elasticity equation considered in step-8 is $u=(u_x,u_y,u_z)^T$ consisting of the displacements in each of the three coordinate directions. The solution then has three elements. Similarly, the 3d Stokes equation considered in step-22 has four elements: $u=(v_x,v_y,v_z,p)^T$. We call the elements of the vector-valued solution components in deal.II. To be well-posed, for the solution to have $n$ components, there need to be $n$ partial differential equations to describe them. This concept is discussed in great detail in the Handling vector valued problems module.

+

When considering systems of equations in which the solution is not just a single scalar function, we say that we have a vector system with a vector-valued solution. For example, the vector solution in the elasticity equation considered in step-8 is $u=(u_x,u_y,u_z)^T$ consisting of the displacements in each of the three coordinate directions. The solution then has three elements. Similarly, the 3d Stokes equation considered in step-22 has four elements: $u=(v_x,v_y,v_z,p)^T$. We call the elements of the vector-valued solution components in deal.II. To be well-posed, for the solution to have $n$ components, there need to be $n$ partial differential equations to describe them. This concept is discussed in great detail in the Handling vector valued problems module.

In finite element programs, one frequently wants to address individual elements (components) of this vector-valued solution, or sets of components. For example, we do this extensively in step-8, and a lot of documentation is also provided in the module on Handling vector valued problems. If you are thinking only in terms of the partial differential equation (not in terms of its discretization), then the concept of components is the natural one.

On the other hand, when talking about finite elements and degrees of freedom, components are not always the correct concept because components are not always individually addressable. In particular, this is the case for non-primitive finite elements. Similarly, one may not always want to address individual components but rather sets of components — e.g. all velocity components together, and separate from the pressure in the Stokes system, without further splitting the velocities into their individual components. In either case, the correct concept to think in is that of a block. Since each component, if individually addressable, is also a block, thinking in terms of blocks is most frequently the better strategy.

For a given finite element, the number of components can be queried using the FiniteElementData::n_components() function, and you can find out which vector components are nonzero for a given finite element shape function using FiniteElement::get_nonzero_components(). The values and gradients of individual components of a shape function (if the element is primitive) can be queried using the FiniteElement::shape_value_component() and FiniteElement::shape_grad_component() functions on the reference cell. The FEValues::shape_value_component() and FEValues::shape_grad_component() functions do the same on a real cell. See also the documentation of the FiniteElement and FEValues classes.

@@ -259,7 +259,7 @@

would result in a mask [true, true, false] in 2d. Of course, in 3d, the result would be [true, true, true, false].

Note
Just as one can think of composed elements as being made up of components or blocks, there are component masks (represented by the ComponentMask class) and block masks (represented by the BlockMask class). The FiniteElement class has functions that convert between the two kinds of objects.
-Not all component masks actually make sense. For example, if you have a FE_RaviartThomas object in 2d, then it doesn't make any sense to have a component mask of the form [true, false] because you try to select individual vector components of a finite element where each shape function has both $x$ and $y$ velocities. In essence, while you can of course create such a component mask, there is nothing you can do with it.
+Not all component masks actually make sense. For example, if you have a FE_RaviartThomas object in 2d, then it doesn't make any sense to have a component mask of the form [true, false] because you try to select individual vector components of a finite element where each shape function has both $x$ and $y$ velocities. In essence, while you can of course create such a component mask, there is nothing you can do with it.
Compressing distributed vectors and matrices

For parallel computations, deal.II uses the vector and matrix classes defined in the PETScWrappers and TrilinosWrappers namespaces. When running programs in parallel using MPI, these classes only store a certain number of rows or elements on the current processor, whereas the rest of the vector or matrix is stored on the other processors that belong to our MPI universe. This presents a certain problem when you assemble linear systems: we add elements to the matrix and right hand side vectors that may or may not be stored locally. Sometimes, we may also want to just set an element, not add to it.

@@ -301,9 +301,9 @@

Degree of freedom
-

The term "degree of freedom" (often abbreviated as "DoF") is commonly used in the finite element community to indicate two slightly different, but related things. The first is that we'd like to represent the finite element solution as a linear combination of shape functions, in the form $u_h(\mathbf{x}) = \sum_{j=0}^{N-1} U_j \varphi_j(\mathbf{x})$. Here, $U_j$ is a vector of expansion coefficients. Because we don't know their values yet (we will compute them as the solution of a linear or nonlinear system), they are called "unknowns" or "degrees of freedom". The second meaning of the term can be explained as follows: A mathematical description of finite element problem is often to say that we are looking for a finite dimensional function $u_h \in V_h$ that satisfies some set of equations (e.g. $a(u_h,\varphi_h)=(f,\varphi_h)$ for all test functions $\varphi_h\in
-   V_h$). In other words, all we say here that the solution needs to lie in some space $V_h$. However, to actually solve this problem on a computer we need to choose a basis of this space; this is the set of shape functions $\varphi_j(\mathbf{x})$ we have used above in the expansion of $u_h(\mathbf
-   x)$ with coefficients $U_j$. There are of course many bases of the space $V_h$, but we will specifically choose the one that is described by the finite element functions that are traditionally defined locally on the cells of the mesh. Describing "degrees of freedom" in this context requires us to simply enumerate the basis functions of the space $V_h$. For $Q_1$ elements this means simply enumerating the vertices of the mesh in some way, but for higher elements one also has to enumerate the shape functions that are associated with edges, faces, or cell interiors of the mesh. The class that provides this enumeration of the basis functions of $V_h$ is called DoFHandler. The process of enumerating degrees of freedom is referred to as "distributing DoFs" in deal.II.

+

The term "degree of freedom" (often abbreviated as "DoF") is commonly used in the finite element community to indicate two slightly different, but related things. The first is that we'd like to represent the finite element solution as a linear combination of shape functions, in the form $u_h(\mathbf{x}) = \sum_{j=0}^{N-1} U_j \varphi_j(\mathbf{x})$. Here, $U_j$ is a vector of expansion coefficients. Because we don't know their values yet (we will compute them as the solution of a linear or nonlinear system), they are called "unknowns" or "degrees of freedom". The second meaning of the term can be explained as follows: A mathematical description of finite element problem is often to say that we are looking for a finite dimensional function $u_h \in V_h$ that satisfies some set of equations (e.g. $a(u_h,\varphi_h)=(f,\varphi_h)$ for all test functions $\varphi_h\in
+   V_h$). In other words, all we say here that the solution needs to lie in some space $V_h$. However, to actually solve this problem on a computer we need to choose a basis of this space; this is the set of shape functions $\varphi_j(\mathbf{x})$ we have used above in the expansion of $u_h(\mathbf
+   x)$ with coefficients $U_j$. There are of course many bases of the space $V_h$, but we will specifically choose the one that is described by the finite element functions that are traditionally defined locally on the cells of the mesh. Describing "degrees of freedom" in this context requires us to simply enumerate the basis functions of the space $V_h$. For $Q_1$ elements this means simply enumerating the vertices of the mesh in some way, but for higher elements one also has to enumerate the shape functions that are associated with edges, faces, or cell interiors of the mesh. The class that provides this enumeration of the basis functions of $V_h$ is called DoFHandler. The process of enumerating degrees of freedom is referred to as "distributing DoFs" in deal.II.

Direction flags
@@ -324,7 +324,7 @@
Distorted cells

A distorted cell is a cell for which the mapping from the reference cell to real cell has a Jacobian whose determinant is non-positive somewhere in the cell. Typically, we only check the sign of this determinant at the vertices of the cell. The function GeometryInfo::alternating_form_at_vertices computes these determinants at the vertices.

-

By way of example, if all of the determinants are of roughly equal value and on the order of $h^\text{dim}$ then the cell is well-shaped. For example, a square cell or face has determinants equal to $h^\text{dim}$ whereas a strongly sheared parallelogram has a determinant much smaller. Similarly, a cell with very unequal edge lengths will have widely varying determinants. Conversely, a pinched cell in which the location of two or more vertices is collapsed to a single point has a zero determinant at this location. Finally, an inverted or twisted cell in which the location of two vertices is out of order will have negative determinants.

+

By way of example, if all of the determinants are of roughly equal value and on the order of $h^\text{dim}$ then the cell is well-shaped. For example, a square cell or face has determinants equal to $h^\text{dim}$ whereas a strongly sheared parallelogram has a determinant much smaller. Similarly, a cell with very unequal edge lengths will have widely varying determinants. Conversely, a pinched cell in which the location of two or more vertices is collapsed to a single point has a zero determinant at this location. Finally, an inverted or twisted cell in which the location of two vertices is out of order will have negative determinants.

The following two images show a well-formed, a pinched, and a twisted cell for both 2d and 3d:

@@ -363,19 +363,19 @@

Generalized support points
-

"Generalized support points" are, as the name suggests, a generalization of support points. The latter are used to describe that a finite element simply interpolates values at individual points (the "support points"). If we call these points $\hat{\mathbf{x}}_i$ (where the hat indicates that these points are defined on the reference cell $\hat{K}$), then one typically defines shape functions $\varphi_j(\mathbf{x})$ in such a way that the nodal functionals $\Psi_i[\cdot]$ simply evaluate the function at the support point, i.e., that $\Psi_i[\varphi]=\varphi(\hat{\mathbf{x}}_i)$, and the basis is chosen so that $\Psi_i[\varphi_j]=\delta_{ij}$ where $\delta_{ij}$ is the Kronecker delta function. This leads to the common Lagrange elements.

-

(In the vector valued case, the only other piece of information besides the support points $\hat{\mathbf{x}}_i$ that one needs to provide is the vector component $c(i)$ the $i$th node functional corresponds, so that $\Psi_i[\varphi]=\varphi(\hat{\mathbf{x}}_i)_{c(i)}$.)

-

On the other hand, there are other kinds of elements that are not defined this way. For example, for the lowest order Raviart-Thomas element (see the FE_RaviartThomas class), the node functional evaluates not individual components of a vector-valued finite element function with dim components, but the normal component of this vector: $\Psi_i[\varphi]
+<dd><p class="Generalized support points" are, as the name suggests, a generalization of support points. The latter are used to describe that a finite element simply interpolates values at individual points (the "support points"). If we call these points $\hat{\mathbf{x}}_i$ (where the hat indicates that these points are defined on the reference cell $\hat{K}$), then one typically defines shape functions $\varphi_j(\mathbf{x})$ in such a way that the nodal functionals $\Psi_i[\cdot]$ simply evaluate the function at the support point, i.e., that $\Psi_i[\varphi]=\varphi(\hat{\mathbf{x}}_i)$, and the basis is chosen so that $\Psi_i[\varphi_j]=\delta_{ij}$ where $\delta_{ij}$ is the Kronecker delta function. This leads to the common Lagrange elements.

+

(In the vector valued case, the only other piece of information besides the support points $\hat{\mathbf{x}}_i$ that one needs to provide is the vector component $c(i)$ the $i$th node functional corresponds, so that $\Psi_i[\varphi]=\varphi(\hat{\mathbf{x}}_i)_{c(i)}$.)

+

On the other hand, there are other kinds of elements that are not defined this way. For example, for the lowest order Raviart-Thomas element (see the FE_RaviartThomas class), the node functional evaluates not individual components of a vector-valued finite element function with dim components, but the normal component of this vector: $\Psi_i[\varphi]
     =
     \varphi(\hat{\mathbf{x}}_i) \cdot \mathbf{n}_i
-   $, where the $\mathbf{n}_i$ are the normal vectors to the face of the cell on which $\hat{\mathbf{x}}_i$ is located. In other words, the node functional is a linear combination of the components of $\varphi$ when evaluated at $\hat{\mathbf{x}}_i$. Similar things happen for the BDM, ABF, and Nedelec elements (see the FE_BDM, FE_ABF, FE_Nedelec classes).

-

In these cases, the element does not have support points because it is not purely interpolatory; however, some kind of interpolation is still involved when defining shape functions as the node functionals still require point evaluations at special points $\hat{\mathbf{x}}_i$. In these cases, we call the points generalized support points.

-

Finally, there are elements that still do not fit into this scheme. For example, some hierarchical basis functions (see, for example the FE_Q_Hierarchical element) are defined so that the node functionals are moments of finite element functions, $\Psi_i[\varphi]
+   $, where the $\mathbf{n}_i$ are the normal vectors to the face of the cell on which $\hat{\mathbf{x}}_i$ is located. In other words, the node functional is a linear combination of the components of $\varphi$ when evaluated at $\hat{\mathbf{x}}_i$. Similar things happen for the BDM, ABF, and Nedelec elements (see the FE_BDM, FE_ABF, FE_Nedelec classes).

+

In these cases, the element does not have support points because it is not purely interpolatory; however, some kind of interpolation is still involved when defining shape functions as the node functionals still require point evaluations at special points $\hat{\mathbf{x}}_i$. In these cases, we call the points generalized support points.

+

Finally, there are elements that still do not fit into this scheme. For example, some hierarchical basis functions (see, for example the FE_Q_Hierarchical element) are defined so that the node functionals are moments of finite element functions, $\Psi_i[\varphi]
     =
     \int_{\hat{K}} \varphi(\hat{\mathbf{x}})
     {\hat{x}_1}^{p_1(i)}
     {\hat{x}_2}^{p_2(i)}
-   $ in 2d, and similarly for 3d, where the $p_d(i)$ are the order of the moment described by shape function $i$. Some other elements use moments over edges or faces. In all of these cases, node functionals are not defined through interpolation at all, and these elements then have neither support points, nor generalized support points.

+ $" src="form_124.png"/> in 2d, and similarly for 3d, where the $p_d(i)$ are the order of the moment described by shape function $i$. Some other elements use moments over edges or faces. In all of these cases, node functionals are not defined through interpolation at all, and these elements then have neither support points, nor generalized support points.

geometry paper
@@ -450,47 +450,47 @@
Lumped mass matrix

The mass matrix is a matrix of the form

-\begin{align*}
+<picture><source srcset=\begin{align*}
        M_{ij} = \int_\Omega \varphi_i(\mathbf x) \varphi_j(\mathbf x)\; dx,
-     \end{align*} + \end{align*}" src="form_126.png"/>

It frequently appears in the solution of time dependent problems where, if one uses an explicit time stepping method, it then leads to the need to solve problems of the form

-\begin{align*}
+<picture><source srcset=\begin{align*}
        MU^n = MU^{n-1} + k_n BU^{n-1},
-     \end{align*} + \end{align*}" src="form_127.png"/>

-

in time step $n$, where $U^n$ is the solution to be computed, $U^{n-1}$ is the known solution from the first time step, and $B$ is a matrix related to the differential operator in the PDE. $k_n$ is the size of the time step. A similar linear system of equations also arises out of the discretization of second-order differential equations.

-

The presence of the matrix $M$ on the left side is a nuisance because, even though we have used an explicit time stepping method, we still have to solve a linear system in each time step. It would be much preferable if the matrix were diagonal. "Lumping" the mass matrix is a strategy to replace $M$ by a matrix $M_\text{diagonal}$ that actually is diagonal, yet does not destroy the accuracy of the resulting solution.

-

Historically, mass lumping was performed by adding the elements of a row together and setting the diagonal entries of $M_\text{diagonal}$ to that sum. This works for $Q_1$ and $P_1$ elements, for example, and can be understood mechanically by replacing the continuous medium we are discretizating by one where the continuous mass distribution is replaced by one where (finite amounts of) mass are located only at the nodes. That is, we are "lumping together" the mass of an element at its vertices, thus giving rise to the name "lumped mass matrix". A more mathematical perspective is to compute the integral above for $M_{ij}$ via special quadrature rules; in particular, we replace the computation of

-\begin{align*}
+<p> in time step <picture><source srcset=$n$, where $U^n$ is the solution to be computed, $U^{n-1}$ is the known solution from the first time step, and $B$ is a matrix related to the differential operator in the PDE. $k_n$ is the size of the time step. A similar linear system of equations also arises out of the discretization of second-order differential equations.

+

The presence of the matrix $M$ on the left side is a nuisance because, even though we have used an explicit time stepping method, we still have to solve a linear system in each time step. It would be much preferable if the matrix were diagonal. "Lumping" the mass matrix is a strategy to replace $M$ by a matrix $M_\text{diagonal}$ that actually is diagonal, yet does not destroy the accuracy of the resulting solution.

+

Historically, mass lumping was performed by adding the elements of a row together and setting the diagonal entries of $M_\text{diagonal}$ to that sum. This works for $Q_1$ and $P_1$ elements, for example, and can be understood mechanically by replacing the continuous medium we are discretizating by one where the continuous mass distribution is replaced by one where (finite amounts of) mass are located only at the nodes. That is, we are "lumping together" the mass of an element at its vertices, thus giving rise to the name "lumped mass matrix". A more mathematical perspective is to compute the integral above for $M_{ij}$ via special quadrature rules; in particular, we replace the computation of

+\begin{align*}
        M_{ij} = \int_\Omega \varphi_i(\mathbf x) \varphi_j(\mathbf x)\; dx
               = \sum_K \int_K \varphi_i(\mathbf x) \varphi_j(\mathbf x)\; dx,
-     \end{align*} + \end{align*}" src="form_134.png"/>

by quadrature

-\begin{align*}
+<picture><source srcset=\begin{align*}
        (M_{\text{diagonal}})_{ij} = \sum_K \sum_q \varphi_i(\mathbf x_q^K) \varphi_j(\mathbf x_q^K)
        |K| w_q,
-     \end{align*} + \end{align*}" src="form_135.png"/>

where we choose the quadrature points as the nodes at which the shape functions are defined. If we order the quadrature points in the same way as the shape functions, then

-\begin{align*}
+<picture><source srcset=\begin{align*}
        \varphi_i(\mathbf x_q^K) = \delta_{iq},
-     \end{align*} + \end{align*}" src="form_136.png"/>

and consequently

-\begin{align*}
+<picture><source srcset=\begin{align*}
        (M_{\text{diagonal}})_{ij} = \delta_{ij} \sum_{K, \text{supp}\varphi_i \cap K \neq \emptyset} |K| w_i,
-     \end{align*} + \end{align*}" src="form_137.png"/>

-

where the sum extends over those cells on which $\varphi_i$ is nonzero. The so-computed mass matrix is therefore diagonal.

-

Whether or not this particular choice of quadrature formula is sufficient to retain the convergence rate of the discretization is a separate question. For the usual $Q_k$ finite elements (implemented by FE_Q and FE_DGQ), the appropriate quadrature formulas are of QGaussLobatto type. Mass lumping can also be done with FE_SimplexP_Bubbles, for example, if appropriate quadrature rules are chosen.

+

where the sum extends over those cells on which $\varphi_i$ is nonzero. The so-computed mass matrix is therefore diagonal.

+

Whether or not this particular choice of quadrature formula is sufficient to retain the convergence rate of the discretization is a separate question. For the usual $Q_k$ finite elements (implemented by FE_Q and FE_DGQ), the appropriate quadrature formulas are of QGaussLobatto type. Mass lumping can also be done with FE_SimplexP_Bubbles, for example, if appropriate quadrature rules are chosen.

For an example of where lumped mass matrices play a role, see step-69.

Manifold indicator

Every object that makes up a Triangulation (cells, faces, edges, etc.), is associated with a unique number (of type types::manifold_id) that is used to identify which manifold object is responsible to generate new points when the mesh is refined.

-

By default, all manifold indicators of a mesh are set to numbers::flat_manifold_id. A typical piece of code that sets the manifold indicator on a object to something else would look like this, here setting the manifold indicator to 42 for all cells whose center has an $x$ component less than zero:

+

By default, all manifold indicators of a mesh are set to numbers::flat_manifold_id. A typical piece of code that sets the manifold indicator on a object to something else would look like this, here setting the manifold indicator to 42 for all cells whose center has an $x$ component less than zero:

for (auto &cell : triangulation.active_cell_iterators())
if (cell->center()[0] < 0)
cell->set_manifold_id (42);
@@ -501,41 +501,41 @@
Mass matrix

The "mass matrix" is a matrix of the form

-\begin{align*}
+<picture><source srcset=\begin{align*}
        M_{ij} = \int_\Omega \varphi_i(\mathbf x) \varphi_j(\mathbf x)\; dx,
-     \end{align*} + \end{align*}" src="form_126.png"/>

-

possibly with a coefficient inside the integral, and where $\varphi_i(\mathbf x)$ are the shape functions of a finite element. The origin of the term refers to the fact that in structural mechanics (where the finite element method originated), one often starts from the elastodynamics (wave) equation

-\begin{align*}
+<p> possibly with a coefficient inside the integral, and where <picture><source srcset=$\varphi_i(\mathbf x)$ are the shape functions of a finite element. The origin of the term refers to the fact that in structural mechanics (where the finite element method originated), one often starts from the elastodynamics (wave) equation

+\begin{align*}
        \rho \frac{\partial^2 u}{\partial t^2}
/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/Tutorial.html differs (HTML document, UTF-8 Unicode text, with very long lines)
--- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/Tutorial.html	2023-08-09 23:38:36.634463830 +0000
+++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/Tutorial.html	2023-08-09 23:38:36.634463830 +0000
@@ -338,7 +338,7 @@
 <p class=

-step-47

Solving the fourth-order biharmonic equation using the $C^0$ Interior Penalty (C0IP) method.
+step-47

Solving the fourth-order biharmonic equation using the $C^0$ Interior Penalty (C0IP) method.
Keywords: FEInterfaceValues

/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/_formulas.tex differs (LaTeX 2e document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/_formulas.tex 2023-07-22 00:00:00.000000000 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/_formulas.tex 2023-07-22 00:00:00.000000000 +0000 @@ -16,15 +16,6 @@ \pagestyle{empty} \begin{document} -$O(\text{dim}^3)$ -\pagebreak - -$u = u - P^{-1} (A u - v)$ -\pagebreak - -$u = u - P^{-T} (A u - v)$ -\pagebreak - $F(u,\nabla u)=0$ \pagebreak @@ -43,54 +34,18 @@ $f (\mathbf{x}) = \sin (x_{1}) + x_{1} x_{2}$ \pagebreak -$u|_{\partial\Omega}=g$ -\pagebreak - -$x_{12}=42$ -\pagebreak - -$g(\mathbf x)$ -\pagebreak - -$u(\mathbf x)$ -\pagebreak - -$\mathbf n \cdot - \mathbf u=0$ -\pagebreak - $w$ \pagebreak -$\mathbf{n}\times\mathbf{u}= - \mathbf{n}\times\mathbf{f}$ -\pagebreak - $i$ \pagebreak $\dot{w} = \dfrac{d w}{d x_{i}}$ \pagebreak -$\frac 1{\sqrt{14}} - (1,2,3)^T$ -\pagebreak - -$x$ -\pagebreak - -$y$ -\pagebreak - -$z$ -\pagebreak - $f(x)$ \pagebreak -$\frac 1{\sqrt{14}} (x_{12}+2x_{28}+3x_{40})=0$ -\pagebreak - \[ f (\mathbf{x}) = f_{0} \circ f_{1} \circ f_{2} \circ \ldots \circ f_{n} (\mathbf{x}) @@ -101,34 +56,12 @@ $f_{n}$ \pagebreak -$x_{12}$ -\pagebreak - -$x_{28}$ -\pagebreak - -$x_{40}$ -\pagebreak - -$x_{12}= - \frac 12 (x_{28}+x_{40})$ -\pagebreak - $f$ \pagebreak $\dfrac{d f(x)}{d \mathbf{x}}$ \pagebreak -$x_2=\frac 12 x_0 + \frac 12 x_1$ -\pagebreak - -$x_4=\frac 14 x_0 + \frac 34 x_1$ -\pagebreak - -$x_3=x_1$ -\pagebreak - \[ \dfrac{d f (\mathbf{x})}{d \mathbf{x}} = \dfrac{d f_{0}}{d f_{1}} \dfrac{d f_{1}}{d f_{2}} \dfrac{d f_{2}}{d f_{3}} \ldots \dfrac{d f_{n} (\mathbf{x})}{d \mathbf{x}} @@ -136,9 +69,6 @@ \] \pagebreak -$x_{i_1} = \sum_{j=2}^M a_{i_j} x_{i_j} + b_i$ -\pagebreak - $f'_{i} \vert_{f'_{i+1}}$ \pagebreak @@ -159,277 +89,237 @@ $\dfrac{d f_{i-1}}{d f_{i}}$ \pagebreak -$x_{13}=42$ -\pagebreak - -$13$ -\pagebreak - -$b_{13}/A_{13,13}=42$ -\pagebreak - -$Ax=b$ -\pagebreak - -$x_{3}=\tfrac 12 x_1 + \tfrac 12$ -\pagebreak - -$x_{3}=\tfrac 12 (x_1 + -x_2)$ -\pagebreak - -$x_2$ -\pagebreak - -$x_2=1$ -\pagebreak - -$x_3$ -\pagebreak - -$x_0$ -\pagebreak - -$x_0=\frac 12 (x_{1}+x_{2})$ -\pagebreak - -$x_0=g_0$ -\pagebreak - -$g_0$ +$f(x,y) = [2x+1]^{y}$ \pagebreak -$g$ +$x$ \pagebreak -$Q_1$ +$y$ \pagebreak -$H^1$ +$\dfrac{d f(x,y)}{d x} = 2y[2x+1]^{y-1}$ \pagebreak -\[ - (C^T A C + Id_c) \tilde x = C^T (b - A\,k) -\] +$\dfrac{d f(x,y)}{d y} = [2x+1]^{y} \ln(2x+1)$ \pagebreak -$f(x,y) = [2x+1]^{y}$ +$\dfrac{d f(x, y)}{d x}$ \pagebreak -$A$ +$x=1, y=2.5$ \pagebreak -$b$ +$x=3.25, y=-6$ \pagebreak -$A\,x=b$ +$g(x) = \dfrac{d f(x, y)}{d x} \vert_{y=1}$ \pagebreak -$C$ +$g(x)$ \pagebreak /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/_formulas_dark.tex differs (LaTeX 2e document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/_formulas_dark.tex 2023-07-22 00:00:00.000000000 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/_formulas_dark.tex 2023-07-22 00:00:00.000000000 +0000 @@ -18,15 +18,6 @@ \pagestyle{empty} \begin{document} -$O(\text{dim}^3)$ -\pagebreak - -$u = u - P^{-1} (A u - v)$ -\pagebreak - -$u = u - P^{-T} (A u - v)$ -\pagebreak - $F(u,\nabla u)=0$ \pagebreak @@ -45,54 +36,18 @@ $f (\mathbf{x}) = \sin (x_{1}) + x_{1} x_{2}$ \pagebreak -$u|_{\partial\Omega}=g$ -\pagebreak - -$x_{12}=42$ -\pagebreak - -$g(\mathbf x)$ -\pagebreak - -$u(\mathbf x)$ -\pagebreak - -$\mathbf n \cdot - \mathbf u=0$ -\pagebreak - $w$ \pagebreak -$\mathbf{n}\times\mathbf{u}= - \mathbf{n}\times\mathbf{f}$ -\pagebreak - $i$ \pagebreak $\dot{w} = \dfrac{d w}{d x_{i}}$ \pagebreak -$\frac 1{\sqrt{14}} - (1,2,3)^T$ -\pagebreak - -$x$ -\pagebreak - -$y$ -\pagebreak - -$z$ -\pagebreak - $f(x)$ \pagebreak -$\frac 1{\sqrt{14}} (x_{12}+2x_{28}+3x_{40})=0$ -\pagebreak - \[ f (\mathbf{x}) = f_{0} \circ f_{1} \circ f_{2} \circ \ldots \circ f_{n} (\mathbf{x}) @@ -103,34 +58,12 @@ $f_{n}$ \pagebreak -$x_{12}$ -\pagebreak - -$x_{28}$ -\pagebreak - -$x_{40}$ -\pagebreak - -$x_{12}= - \frac 12 (x_{28}+x_{40})$ -\pagebreak - $f$ \pagebreak $\dfrac{d f(x)}{d \mathbf{x}}$ \pagebreak -$x_2=\frac 12 x_0 + \frac 12 x_1$ -\pagebreak - -$x_4=\frac 14 x_0 + \frac 34 x_1$ -\pagebreak - -$x_3=x_1$ -\pagebreak - \[ \dfrac{d f (\mathbf{x})}{d \mathbf{x}} = \dfrac{d f_{0}}{d f_{1}} \dfrac{d f_{1}}{d f_{2}} \dfrac{d f_{2}}{d f_{3}} \ldots \dfrac{d f_{n} (\mathbf{x})}{d \mathbf{x}} @@ -138,9 +71,6 @@ \] \pagebreak -$x_{i_1} = \sum_{j=2}^M a_{i_j} x_{i_j} + b_i$ -\pagebreak - $f'_{i} \vert_{f'_{i+1}}$ \pagebreak @@ -161,277 +91,237 @@ $\dfrac{d f_{i-1}}{d f_{i}}$ \pagebreak -$x_{13}=42$ -\pagebreak - -$13$ -\pagebreak - -$b_{13}/A_{13,13}=42$ -\pagebreak - -$Ax=b$ -\pagebreak - -$x_{3}=\tfrac 12 x_1 + \tfrac 12$ -\pagebreak - -$x_{3}=\tfrac 12 (x_1 + -x_2)$ -\pagebreak - -$x_2$ -\pagebreak - -$x_2=1$ -\pagebreak - -$x_3$ -\pagebreak - -$x_0$ -\pagebreak - -$x_0=\frac 12 (x_{1}+x_{2})$ -\pagebreak - -$x_0=g_0$ -\pagebreak - -$g_0$ +$f(x,y) = [2x+1]^{y}$ \pagebreak -$g$ +$x$ \pagebreak -$Q_1$ +$y$ \pagebreak -$H^1$ +$\dfrac{d f(x,y)}{d x} = 2y[2x+1]^{y-1}$ \pagebreak -\[ - (C^T A C + Id_c) \tilde x = C^T (b - A\,k) -\] +$\dfrac{d f(x,y)}{d y} = [2x+1]^{y} \ln(2x+1)$ \pagebreak -$f(x,y) = [2x+1]^{y}$ +$\dfrac{d f(x, y)}{d x}$ \pagebreak -$A$ +$x=1, y=2.5$ \pagebreak -$b$ +$x=3.25, y=-6$ \pagebreak -$A\,x=b$ +$g(x) = \dfrac{d f(x, y)}{d x} \vert_{y=1}$ \pagebreak -$C$ +$g(x)$ \pagebreak /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_6_1_and_6_2.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_6_1_and_6_2.html 2023-08-09 23:38:37.134467563 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_6_1_and_6_2.html 2023-08-09 23:38:37.138467593 +0000 @@ -391,7 +391,7 @@
  • New: There is a new function scalar_product(const Tensor<2,dim> &, - const Tensor<2,dim> &) that computes the scalar product $a:b=\sum_{i,j} a_{ij}b_{ij}$ between two tensors of rank 2.
    + const Tensor<2,dim> &) that computes the scalar product $a:b=\sum_{i,j} a_{ij}b_{ij}$ between two tensors of rank 2.
    (WB 2008/08/15)

    @@ -693,7 +693,7 @@
  • -

    Improved: The FEValuesViews objects that one gets when writing things like fe_values[velocities] (see Handling vector valued problems) have become a lot smarter. They now compute a significant amount of data at creation time, rather than on the fly. This means that creating such objects becomes more expensive but using them is cheaper. To offset this cost, FEValuesBase objects now create all possible FEValuesViews objects at creation time, rather than whenever you do things like fe_values[velocities], and simply return a reference to a pre-generated object. This turns an $O(N)$ effort into an $O(1)$ effort, where $N$ is the number of cells.
    +

    Improved: The FEValuesViews objects that one gets when writing things like fe_values[velocities] (see Handling vector valued problems) have become a lot smarter. They now compute a significant amount of data at creation time, rather than on the fly. This means that creating such objects becomes more expensive but using them is cheaper. To offset this cost, FEValuesBase objects now create all possible FEValuesViews objects at creation time, rather than whenever you do things like fe_values[velocities], and simply return a reference to a pre-generated object. This turns an $O(N)$ effort into an $O(1)$ effort, where $N$ is the number of cells.
    (WB 2008/12/10)

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_6_2_and_6_3.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_6_2_and_6_3.html 2023-08-09 23:38:37.162467772 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_6_2_and_6_3.html 2023-08-09 23:38:37.162467772 +0000 @@ -197,11 +197,11 @@
  • -

    Fixed: step-31 had a bug in the computation of the global scaling parameter in the function that evaluates the artificial viscosity: we computed $c(\mathbf{u},T) =
+<p class=Fixed: step-31 had a bug in the computation of the global scaling parameter in the function that evaluates the artificial viscosity: we computed $c(\mathbf{u},T) =
     c_R\ \|\mathbf{u}\|_{L^\infty(\Omega)} \ \mathrm{var}(T)
-    \frac{1}{|\mathrm{diam}(\Omega)|^{\alpha-2}}$ when it should have been $c(\mathbf{u},T) =
+    \frac{1}{|\mathrm{diam}(\Omega)|^{\alpha-2}}$ when it should have been $c(\mathbf{u},T) =
     c_R\ \|\mathbf{u}\|_{L^\infty(\Omega)} \ \mathrm{var}(T)
-    \ |\mathrm{diam}(\Omega)|^{\alpha-2}$. This didn't matter much in this program because $\mathrm{diam}(\Omega)=2^{1/\textrm{dim}}$ and so is close to one. It would matter, however, if the domain had been different, as it is, for example, in the future step 32.
    + \ |\mathrm{diam}(\Omega)|^{\alpha-2}$" src="form_2728.png"/>
    . This didn't matter much in this program because $\mathrm{diam}(\Omega)=2^{1/\textrm{dim}}$ and so is close to one. It would matter, however, if the domain had been different, as it is, for example, in the future step 32.
    (WB 2009/08/19)

    @@ -364,7 +364,7 @@
  • -

    New: The GeometryInfo::d_linear_shape_function and GeometryInfo::d_linear_shape_function_gradient functions can be used to represent the $d$-linear shape functions that are frequently used to map the reference cell to real cells (though the Mapping class hierarchy also allows to use higher order mappings).
    +

    New: The GeometryInfo::d_linear_shape_function and GeometryInfo::d_linear_shape_function_gradient functions can be used to represent the $d$-linear shape functions that are frequently used to map the reference cell to real cells (though the Mapping class hierarchy also allows to use higher order mappings).
    (WB 2009/06/28)

    @@ -499,7 +499,7 @@
  • -

    New: There are new functions FullMatrix::cholesky and FullMatrix::outer_product. FullMatrix::cholesky finds the Cholesky decomposition of a matrix in lower triangular form. FullMatrix::outer_product calculates *this $= VW^T$ where $V$ and $W$ are vectors.
    +

    New: There are new functions FullMatrix::cholesky and FullMatrix::outer_product. FullMatrix::cholesky finds the Cholesky decomposition of a matrix in lower triangular form. FullMatrix::outer_product calculates *this $= VW^T$ where $V$ and $W$ are vectors.
    (Jean Marie Linhart 2009/07/27)

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_7_0_and_7_1.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_7_0_and_7_1.html 2023-08-09 23:38:37.186467951 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_7_0_and_7_1.html 2023-08-09 23:38:37.186467951 +0000 @@ -374,7 +374,7 @@

  • -

    Improved: Evaluation of Lagrangian basis functions has been made stable by exchanging polynomial evaluation from the standard form $a_n x^n+\ldots+a_1 x + a_0$ to a product of linear factors, $c (x - x_0) (x-x_1)\ldots (x-x_n)$. This ensures accurate evaluation up to very high order and avoids inaccuracies when using high order finite elements.
    +

    Improved: Evaluation of Lagrangian basis functions has been made stable by exchanging polynomial evaluation from the standard form $a_n x^n+\ldots+a_1 x + a_0$ to a product of linear factors, $c (x - x_0) (x-x_1)\ldots (x-x_n)$. This ensures accurate evaluation up to very high order and avoids inaccuracies when using high order finite elements.
    (Martin Kronbichler 2011/07/26)

  • /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_7_1_and_7_2.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_7_1_and_7_2.html 2023-08-09 23:38:37.206468101 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_7_1_and_7_2.html 2023-08-09 23:38:37.206468101 +0000 @@ -330,7 +330,7 @@

  • -

    Fixed: Computing the $W^{1,\infty}$ norm and seminorm in VectorTools::integrate_difference was not implemented. This is now fixed.
    +

    Fixed: Computing the $W^{1,\infty}$ norm and seminorm in VectorTools::integrate_difference was not implemented. This is now fixed.
    (Wolfgang Bangerth 2012/06/02)

  • /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_8_1_and_8_2.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_8_1_and_8_2.html 2023-08-09 23:38:37.234468310 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_8_1_and_8_2.html 2023-08-09 23:38:37.234468310 +0000 @@ -837,7 +837,7 @@

  • -

    New: There is now a new class Functions::InterpolatedTensorProductGridData that can be used to (bi-/tri-)linearly interpolate data given on a tensor product mesh of $x$ (and $y$ and $z$) values, for example to evaluate experimentally determined coefficients, or to assess the accuracy of a solution by comparing with a solution generated by a different code and written in gridded data. There is also a new class Functions::InterpolatedUniformGridData that can perform the same task more efficiently if the data is stored on meshes that are uniform in each coordinate direction.
    +

    New: There is now a new class Functions::InterpolatedTensorProductGridData that can be used to (bi-/tri-)linearly interpolate data given on a tensor product mesh of $x$ (and $y$ and $z$) values, for example to evaluate experimentally determined coefficients, or to assess the accuracy of a solution by comparing with a solution generated by a different code and written in gridded data. There is also a new class Functions::InterpolatedUniformGridData that can perform the same task more efficiently if the data is stored on meshes that are uniform in each coordinate direction.
    (Wolfgang Bangerth, 2013/12/20)

  • /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_8_4_2_and_8_5_0.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_8_4_2_and_8_5_0.html 2023-08-09 23:38:37.266468549 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_8_4_2_and_8_5_0.html 2023-08-09 23:38:37.266468549 +0000 @@ -516,7 +516,7 @@

  • -

    Fixed: The FE_ABF class reported the maximal polynomial degree (via FiniteElement::degree) for elements of order $r$ as $r+1$, but this is wrong. It should be $r+2$ (see Section 5 of the original paper of Arnold, Boffi, and Falk). This is now fixed.
    +

    Fixed: The FE_ABF class reported the maximal polynomial degree (via FiniteElement::degree) for elements of order $r$ as $r+1$, but this is wrong. It should be $r+2$ (see Section 5 of the original paper of Arnold, Boffi, and Falk). This is now fixed.
    (Wolfgang Bangerth, 2017/01/13)

  • /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_9_1_1_and_9_2_0.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_9_1_1_and_9_2_0.html 2023-08-09 23:38:37.302468818 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/changes_between_9_1_1_and_9_2_0.html 2023-08-09 23:38:37.302468818 +0000 @@ -606,7 +606,7 @@

  • -

    Improved: GridGenerator::hyper_shell() in 3d now supports more n_cells options. While previously only 6, 12, or 96 cells were possible, the function now supports any number of the kind $6 \times 2^m$ with $m$ a non-negative integer. The new cases $m=2,3$ and $m\geq 5$ correspond to refinement in the azimuthal direction of the 6 or 12 cell case with a single mesh layer in radial direction, and are intended for shells that are thin and should be given more resolution in azimuthal direction.
    +

    Improved: GridGenerator::hyper_shell() in 3d now supports more n_cells options. While previously only 6, 12, or 96 cells were possible, the function now supports any number of the kind $6 \times 2^m$ with $m$ a non-negative integer. The new cases $m=2,3$ and $m\geq 5$ correspond to refinement in the azimuthal direction of the 6 or 12 cell case with a single mesh layer in radial direction, and are intended for shells that are thin and should be given more resolution in azimuthal direction.
    (Martin Kronbichler, 2020/04/07)

  • @@ -1560,7 +1560,7 @@

  • -

    Improved: The additional roots of the HermiteLikeInterpolation with degree $p$ greater than four have been switched to the roots of the Jacobi polynomial $P^{(4,4)}_{p-3}$, making the interior bubble functions $L_2$ orthogonal and improving the conditioning of interpolation slightly.
    +

    Improved: The additional roots of the HermiteLikeInterpolation with degree $p$ greater than four have been switched to the roots of the Jacobi polynomial $P^{(4,4)}_{p-3}$, making the interior bubble functions $L_2$ orthogonal and improving the conditioning of interpolation slightly.
    (Martin Kronbichler, 2019/07/12)

  • /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAffineConstraints.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAffineConstraints.html 2023-08-09 23:38:37.366469296 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAffineConstraints.html 2023-08-09 23:38:37.366469296 +0000 @@ -357,9 +357,9 @@

    The algorithms used in the implementation of this class are described in some detail in the hp-paper. There is also a significant amount of documentation on how to use this class in the Constraints on degrees of freedom module.

    Description of constraints

    Each "line" in objects of this class corresponds to one constrained degree of freedom, with the number of the line being i, entered by using add_line() or add_lines(). The entries in this line are pairs of the form (j,aij), which are added by add_entry() or add_entries(). The organization is essentially a SparsityPattern, but with only a few lines containing nonzero elements, and therefore no data wasted on the others. For each line, which has been added by the mechanism above, an elimination of the constrained degree of freedom of the form

    -\[
+<picture><source srcset=\[
  x_i = \sum_j a_{ij} x_j + b_i
-\] +\]" src="form_1577.png"/>

    is performed, where bi is optional and set by set_inhomogeneity(). Thus, if a constraint is formulated for instance as a zero mean value of several degrees of freedom, one of the degrees has to be chosen to be eliminated.

    Note that the constraints are linear in the xi, and that there might be a constant (non-homogeneous) term in the constraint. This is exactly the form we need for hanging node constraints, where we need to constrain one degree of freedom in terms of others. There are other conditions of this form possible, for example for implementing mean value conditions as is done in the step-11 tutorial program. The name of the class stems from the fact that these constraints can be represented in matrix form as X x = b, and this object then describes the matrix X and the vector b. The most frequent way to create/fill objects of this type is using the DoFTools::make_hanging_node_constraints() function. The use of these objects is first explained in step-6.

    @@ -929,13 +929,13 @@
    -

    Add an entry to a given line. In other words, this function adds a term $a_{ij} x_j$ to the constraints for the $i$th degree of freedom.

    +

    Add an entry to a given line. In other words, this function adds a term $a_{ij} x_j$ to the constraints for the $i$th degree of freedom.

    If an entry with the same indices as the one this function call denotes already exists, then this function simply returns provided that the value of the entry is the same. Thus, it does no harm to enter a constraint twice.

    Parameters
    - - - + + +
    [in]constrained_dof_indexThe index $i$ of the degree of freedom that is being constrained.
    [in]columnThe index $j$ of the degree of freedom being entered into the constraint for degree of freedom $i$.
    [in]weightThe factor $a_{ij}$ that multiplies $x_j$.
    [in]constrained_dof_indexThe index $i$ of the degree of freedom that is being constrained.
    [in]columnThe index $j$ of the degree of freedom being entered into the constraint for degree of freedom $i$.
    [in]weightThe factor $a_{ij}$ that multiplies $x_j$.
    @@ -1010,11 +1010,11 @@
    -

    Set an inhomogeneity to the constraint for a degree of freedom. In other words, it adds a constant $b_i$ to the constraint for degree of freedom $i$. For this to work, you need to call add_line() first for the given degree of freedom.

    +

    Set an inhomogeneity to the constraint for a degree of freedom. In other words, it adds a constant $b_i$ to the constraint for degree of freedom $i$. For this to work, you need to call add_line() first for the given degree of freedom.

    Parameters
    - - + +
    [in]constrained_dof_indexThe index $i$ of the degree of freedom that is being constrained.
    [in]valueThe right hand side value $b_i$ for the constraint on the degree of freedom $i$.
    [in]constrained_dof_indexThe index $i$ of the degree of freedom that is being constrained.
    [in]valueThe right hand side value $b_i$ for the constraint on the degree of freedom $i$.
    @@ -1042,9 +1042,9 @@

    Close the filling of entries. Since the lines of a matrix of this type are usually filled in an arbitrary order and since we do not want to use associative constrainers to store the lines, we need to sort the lines and within the lines the columns before usage of the matrix. This is done through this function.

    Also, zero entries are discarded, since they are not needed.

    After closing, no more entries are accepted. If the object was already closed, then this function returns immediately.

    -

    This function also resolves chains of constraints. For example, degree of freedom 13 may be constrained to $u_{13} = \frac{u_3}{2} + \frac{u_7}{2}$ while degree of freedom 7 is itself constrained as $u_{7} = \frac{u_2}{2}
-+ \frac{u_4}{2}$. Then, the resolution will be that $u_{13} =
-\frac{u_3}{2} + \frac{u_2}{4} + \frac{u_4}{4}$. Note, however, that cycles in this graph of constraints are not allowed, i.e., for example $u_4$ may not itself be constrained, directly or indirectly, to $u_{13}$ again.

    +

    This function also resolves chains of constraints. For example, degree of freedom 13 may be constrained to $u_{13} = \frac{u_3}{2} + \frac{u_7}{2}$ while degree of freedom 7 is itself constrained as $u_{7} = \frac{u_2}{2}
++ \frac{u_4}{2}$. Then, the resolution will be that $u_{13} =
+\frac{u_3}{2} + \frac{u_2}{4} + \frac{u_4}{4}$. Note, however, that cycles in this graph of constraints are not allowed, i.e., for example $u_4$ may not itself be constrained, directly or indirectly, to $u_{13}$ again.

    @@ -1487,9 +1487,9 @@

    Print the constraints represented by the current object to the given stream.

    For each constraint of the form

    -\[
+<picture><source srcset=\[
  x_{42} = 0.5 x_2 + 0.25 x_{14} + 2.75
-\] +\]" src="form_1586.png"/>

    this function will write a sequence of lines that look like this:

    42 2 : 0.5
    42 14 : 0.25
    @@ -2150,7 +2150,7 @@

    This function takes a matrix of local contributions (local_matrix) corresponding to the degrees of freedom indices given in local_dof_indices and distributes them to the global matrix. In other words, this function implements a scatter operation. In most cases, these local contributions will be the result of an integration over a cell or face of a cell. However, as long as local_matrix and local_dof_indices have the same number of elements, this function is happy with whatever it is given.

    In contrast to the similar function in the DoFAccessor class, this function also takes care of constraints, i.e. if one of the elements of local_dof_indices belongs to a constrained node, then rather than writing the corresponding element of local_matrix into global_matrix, the element is distributed to the entries in the global matrix to which this particular degree of freedom is constrained.

    -

    With this scheme, we never write into rows or columns of constrained degrees of freedom. In order to make sure that the resulting matrix can still be inverted, we need to do something with the diagonal elements corresponding to constrained nodes. Thus, if a degree of freedom in local_dof_indices is constrained, we distribute the corresponding entries in the matrix, but also add the absolute value of the diagonal entry of the local matrix to the corresponding entry in the global matrix. Assuming the discretized operator is positive definite, this guarantees that the diagonal entry is always non-zero, positive, and of the same order of magnitude as the other entries of the matrix. On the other hand, when solving a source problem $Au=f$ the exact value of the diagonal element is not important, since the value of the respective degree of freedom will be overwritten by the distribute() call later on anyway.

    +

    With this scheme, we never write into rows or columns of constrained degrees of freedom. In order to make sure that the resulting matrix can still be inverted, we need to do something with the diagonal elements corresponding to constrained nodes. Thus, if a degree of freedom in local_dof_indices is constrained, we distribute the corresponding entries in the matrix, but also add the absolute value of the diagonal entry of the local matrix to the corresponding entry in the global matrix. Assuming the discretized operator is positive definite, this guarantees that the diagonal entry is always non-zero, positive, and of the same order of magnitude as the other entries of the matrix. On the other hand, when solving a source problem $Au=f$ the exact value of the diagonal element is not important, since the value of the respective degree of freedom will be overwritten by the distribute() call later on anyway.

    Note
    The procedure described above adds an unforeseeable number of artificial eigenvalues to the spectrum of the matrix. Therefore, it is recommended to use the equivalent function with two local index vectors in such a case.

    By using this function to distribute local contributions to the global object, one saves the call to the condense function after the vectors and matrices are fully assembled.

    Note
    This function in itself is thread-safe, i.e., it works properly also when several threads call it simultaneously. However, the function call is only thread-safe if the underlying global matrix allows for simultaneous access and the access is not to rows with the same global index at the same time. This needs to be made sure from the caller's site. There is no locking mechanism inside this method to prevent data races.
    @@ -2200,7 +2200,7 @@

    This function does almost the same as the function above but can treat general rectangular matrices. The main difference to achieve this is that the diagonal entries in constrained rows are left untouched instead of being filled with arbitrary values.

    -

    Since the diagonal entries corresponding to eliminated degrees of freedom are not set, the result may have a zero eigenvalue, if applied to a square matrix. This has to be considered when solving the resulting problems. For solving a source problem $Au=f$, it is possible to set the diagonal entry after building the matrix by a piece of code of the form

    +

    Since the diagonal entries corresponding to eliminated degrees of freedom are not set, the result may have a zero eigenvalue, if applied to a square matrix. This has to be considered when solving the resulting problems. For solving a source problem $Au=f$, it is possible to set the diagonal entry after building the matrix by a piece of code of the form

    for (unsigned int i=0;i<matrix.m();++i)
    if (constraints.is_constrained(i))
    matrix.diag_element(i) = 1.;
    @@ -2541,7 +2541,7 @@
    -

    Given a vector, set all constrained degrees of freedom to values so that the constraints are satisfied. For example, if the current object stores the constraint $x_3=\frac 12 x_1 + \frac 12 x_2$, then this function will read the values of $x_1$ and $x_2$ from the given vector and set the element $x_3$ according to this constraints. Similarly, if the current object stores the constraint $x_{42}=208$, then this function will set the 42nd element of the given vector to 208.

    +

    Given a vector, set all constrained degrees of freedom to values so that the constraints are satisfied. For example, if the current object stores the constraint $x_3=\frac 12 x_1 + \frac 12 x_2$, then this function will read the values of $x_1$ and $x_2$ from the given vector and set the element $x_3$ according to this constraints. Similarly, if the current object stores the constraint $x_{42}=208$, then this function will set the 42nd element of the given vector to 208.

    Note
    If this function is called with a parallel vector vec, then the vector must not contain ghost elements.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAlgorithms_1_1ThetaTimestepping.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAlgorithms_1_1ThetaTimestepping.html 2023-08-09 23:38:37.406469594 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAlgorithms_1_1ThetaTimestepping.html 2023-08-09 23:38:37.406469594 +0000 @@ -218,9 +218,9 @@

    For fixed theta, the Crank-Nicolson scheme is the only second order scheme. Nevertheless, further stability may be achieved by choosing theta larger than ½, thereby introducing a first order error term. In order to avoid a loss of convergence order, the adaptive theta scheme can be used, where theta=½+c dt.

    Assume that we want to solve the equation u' + F(u) = 0 with a step size k. A step of the theta scheme can be written as

    -\[
+<picture><source srcset=\[
   M u_{n+1} + \theta k F(u_{n+1})  = M u_n - (1-\theta)k F(u_n).
-\] +\]" src="form_351.png"/>

    Here, M is the mass matrix. We see, that the right hand side amounts to an explicit Euler step with modified step size in weak form (up to inversion of M). The left hand side corresponds to an implicit Euler step with modified step size (right hand side given). Thus, the implementation of the theta scheme will use two Operator objects, one for the explicit, one for the implicit part. Each of these will use its own TimestepData to account for the modified step sizes (and different times if the problem is not autonomous). Note that once the explicit part has been computed, the left hand side actually constitutes a linear or nonlinear system which has to be solved.

    Usage AnyData

    @@ -300,8 +300,8 @@
    }
    size_type n() const
    size_type m() const
    -

    Now we need to study the application of the implicit and explicit operator. We assume that the pointer matrix points to the matrix created in the main program (the constructor did this for us). Here, we first get the time step size from the AnyData object that was provided as input. Then, if we are in the first step or if the timestep has changed, we fill the local matrix $m$, such that with the given matrix $M$, it becomes

    -\[ m = I - \Delta t M. \] +

    Now we need to study the application of the implicit and explicit operator. We assume that the pointer matrix points to the matrix created in the main program (the constructor did this for us). Here, we first get the time step size from the AnyData object that was provided as input. Then, if we are in the first step or if the timestep has changed, we fill the local matrix $m$, such that with the given matrix $M$, it becomes

    +\[ m = I - \Delta t M. \]

    After we have worked off the notifications, we clear them, such that the matrix is only generated when necessary.

    void Explicit::operator()(AnyData &out, const AnyData &in)
    @@ -1174,7 +1174,7 @@

    The operator computing the explicit part of the scheme. This will receive in its input data the value at the current time with name "Current time solution". It should obtain the current time and time step size from explicit_data().

    -

    Its return value is $ Mu+cF(u) $, where $u$ is the current state vector, $M$ the mass matrix, $F$ the operator in space and $c$ is the adjusted time step size $(1-\theta) \Delta t$.

    +

    Its return value is $ Mu+cF(u) $, where $u$ is the current state vector, $M$ the mass matrix, $F$ the operator in space and $c$ is the adjusted time step size $(1-\theta) \Delta t$.

    Definition at line 416 of file theta_timestepping.h.

    @@ -1202,7 +1202,7 @@

    The operator solving the implicit part of the scheme. It will receive in its input data the vector "Previous time". Information on the timestep should be obtained from implicit_data().

    -

    Its return value is the solution u of Mu-cF(u)=f, where f is the dual space vector found in the "Previous time" entry of the input data, M the mass matrix, F the operator in space and c is the adjusted time step size $ \theta \Delta t$

    +

    Its return value is the solution u of Mu-cF(u)=f, where f is the dual space vector found in the "Previous time" entry of the input data, M the mass matrix, F the operator in space and c is the adjusted time step size $ \theta \Delta t$

    Definition at line 428 of file theta_timestepping.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAnisotropicPolynomials.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAnisotropicPolynomials.html 2023-08-09 23:38:37.438469833 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAnisotropicPolynomials.html 2023-08-09 23:38:37.438469833 +0000 @@ -153,10 +153,10 @@

    Detailed Description

    template<int dim>
    class AnisotropicPolynomials< dim >

    Anisotropic tensor product of given polynomials.

    -

    Given one-dimensional polynomials $P^x_1(x), P^x_2(x), \ldots$ in $x$-direction, $P^y_1(y), P^y_2(y), \ldots$ in $y$-direction, and so on, this class generates polynomials of the form $Q_{ijk}(x,y,z)
-= P^x_i(x)P^y_j(y)P^z_k(z)$. (With obvious generalization if dim is in fact only 2. If dim is in fact only 1, then the result is simply the same set of one-dimensional polynomials passed to the constructor.)

    -

    If the elements of each set of base polynomials are mutually orthogonal on the interval $[-1,1]$ or $[0,1]$, then the tensor product polynomials are orthogonal on $[-1,1]^d$ or $[0,1]^d$, respectively.

    -

    The resulting dim-dimensional tensor product polynomials are ordered as follows: We iterate over the $x$ coordinates running fastest, then the $y$ coordinate, etc. For example, for dim==2, the first few polynomials are thus $P^x_1(x)P^y_1(y)$, $P^x_2(x)P^y_1(y)$, $P^x_3(x)P^y_1(y)$, ..., $P^x_1(x)P^y_2(y)$, $P^x_2(x)P^y_2(y)$, $P^x_3(x)P^y_2(y)$, etc.

    +

    Given one-dimensional polynomials $P^x_1(x), P^x_2(x), \ldots$ in $x$-direction, $P^y_1(y), P^y_2(y), \ldots$ in $y$-direction, and so on, this class generates polynomials of the form $Q_{ijk}(x,y,z)
+= P^x_i(x)P^y_j(y)P^z_k(z)$. (With obvious generalization if dim is in fact only 2. If dim is in fact only 1, then the result is simply the same set of one-dimensional polynomials passed to the constructor.)

    +

    If the elements of each set of base polynomials are mutually orthogonal on the interval $[-1,1]$ or $[0,1]$, then the tensor product polynomials are orthogonal on $[-1,1]^d$ or $[0,1]^d$, respectively.

    +

    The resulting dim-dimensional tensor product polynomials are ordered as follows: We iterate over the $x$ coordinates running fastest, then the $y$ coordinate, etc. For example, for dim==2, the first few polynomials are thus $P^x_1(x)P^y_1(y)$, $P^x_2(x)P^y_1(y)$, $P^x_3(x)P^y_1(y)$, ..., $P^x_1(x)P^y_2(y)$, $P^x_2(x)P^y_2(y)$, $P^x_3(x)P^y_2(y)$, etc.

    Definition at line 322 of file tensor_product_polynomials.h.

    Constructor & Destructor Documentation

    @@ -676,7 +676,7 @@
    -

    Each tensor product polynomial $p_i$ is a product of one-dimensional polynomials in each space direction. Compute the indices of these one- dimensional polynomials for each space direction, given the index i.

    +

    Each tensor product polynomial $p_i$ is a product of one-dimensional polynomials in each space direction. Compute the indices of these one- dimensional polynomials for each space direction, given the index i.

    Definition at line 538 of file tensor_product_polynomials.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classArpackSolver.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classArpackSolver.html 2023-08-09 23:38:37.466470042 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classArpackSolver.html 2023-08-09 23:38:37.466470042 +0000 @@ -229,14 +229,14 @@

    Detailed Description

    Interface for using ARPACK. ARPACK is a collection of Fortran77 subroutines designed to solve large scale eigenvalue problems. Here we interface to the routines dnaupd and dneupd of ARPACK. If the operator is specified to be symmetric we use the symmetric interface dsaupd and dseupd of ARPACK instead. The package is designed to compute a few eigenvalues and corresponding eigenvectors of a general n by n matrix A. It is most appropriate for large sparse matrices A.

    -

    In this class we make use of the method applied to the generalized eigenspectrum problem $(A-\lambda B)x=0$, for $x\neq0$; where $A$ is a system matrix, $B$ is a mass matrix, and $\lambda, x$ are a set of eigenvalues and eigenvectors respectively.

    +

    In this class we make use of the method applied to the generalized eigenspectrum problem $(A-\lambda B)x=0$, for $x\neq0$; where $A$ is a system matrix, $B$ is a mass matrix, and $\lambda, x$ are a set of eigenvalues and eigenvectors respectively.

    The ArpackSolver can be used in application codes with serial objects in the following way:

    solver.solve(A, B, OP, lambda, x, size_of_spectrum);
    SolverControl & solver_control
    -

    for the generalized eigenvalue problem $Ax=B\lambda x$, where the variable size_of_spectrum tells ARPACK the number of eigenvector/eigenvalue pairs to solve for. Here, lambda is a vector that will contain the eigenvalues computed, x a vector that will contain the eigenvectors computed, and OP is an inverse operation for the matrix A. Shift and invert transformation around zero is applied.

    +

    for the generalized eigenvalue problem $Ax=B\lambda x$, where the variable size_of_spectrum tells ARPACK the number of eigenvector/eigenvalue pairs to solve for. Here, lambda is a vector that will contain the eigenvalues computed, x a vector that will contain the eigenvectors computed, and OP is an inverse operation for the matrix A. Shift and invert transformation around zero is applied.

    Through the AdditionalData the user can specify some of the parameters to be set.

    For further information on how the ARPACK routines dsaupd, dseupd, dnaupd and dneupd work and also how to set the parameters appropriately please take a look into the ARPACK manual.

    Note
    Whenever you eliminate degrees of freedom using AffineConstraints, you generate spurious eigenvalues and eigenvectors. If you make sure that the diagonals of eliminated matrix rows are all equal to one, you get a single additional eigenvalue. But beware that some functions in deal.II set these diagonals to rather arbitrary (from the point of view of eigenvalue problems) values. See also step-36 for an example.
    @@ -525,7 +525,7 @@
    -

    Solve the generalized eigensprectrum problem $A x=\lambda B x$ by calling the dsaupd and dseupd or dnaupd and dneupd functions of ARPACK.

    +

    Solve the generalized eigensprectrum problem $A x=\lambda B x$ by calling the dsaupd and dseupd or dnaupd and dneupd functions of ARPACK.

    The function returns a vector of eigenvalues of length n and a vector of eigenvectors of length n in the symmetric case and of length n+1 in the non-symmetric case. In the symmetric case all eigenvectors are real. In the non-symmetric case complex eigenvalues always occur as complex conjugate pairs. Therefore the eigenvector for an eigenvalue with nonzero complex part is stored by putting the real and the imaginary parts in consecutive real-valued vectors. The eigenvector of the complex conjugate eigenvalue does not need to be stored, since it is just the complex conjugate of the stored eigenvector. Thus, if the last n-th eigenvalue has a nonzero imaginary part, Arpack needs in total n+1 real-valued vectors to store real and imaginary parts of the eigenvectors.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classArrayView.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classArrayView.html 2023-08-09 23:38:37.514470400 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classArrayView.html 2023-08-09 23:38:37.514470400 +0000 @@ -1025,7 +1025,7 @@
    -

    Return a reference to the $i$th element of the range represented by the current object.

    +

    Return a reference to the $i$th element of the range represented by the current object.

    This function is marked as const because it does not change the view object. It may however return a reference to a non-const memory location depending on whether the template type of the class is const or not.

    This function is only allowed to be called if the underlying data is indeed stored in CPU memory.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAutoDerivativeFunction.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAutoDerivativeFunction.html 2023-08-09 23:38:37.558470728 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classAutoDerivativeFunction.html 2023-08-09 23:38:37.558470728 +0000 @@ -346,27 +346,27 @@

    Names of difference formulas.

    Enumerator
    Euler 

    The symmetric Euler formula of second order:

    -\[
+<picture><source srcset=\[
 u'(t) \approx
 \frac{u(t+h) -
 u(t-h)}{2h}.
-\] +\]" src="form_359.png"/>

    UpwindEuler 

    The upwind Euler formula of first order:

    -\[
+<picture><source srcset=\[
 u'(t) \approx
 \frac{u(t) -
 u(t-h)}{h}.
-\] +\]" src="form_360.png"/>

    FourthOrder 

    The fourth order scheme

    -\[
+<picture><source srcset=\[
 u'(t) \approx
 \frac{u(t-2h) - 8u(t-h)
 +  8u(t+h) - u(t+2h)}{12h}.
-\] +\]" src="form_361.png"/>

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBarycentricPolynomial.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBarycentricPolynomial.html 2023-08-09 23:38:37.582470908 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBarycentricPolynomial.html 2023-08-09 23:38:37.582470908 +0000 @@ -151,7 +151,7 @@ (x, y) = c_0 (x_0, y_0) + c_1 (x_1, y_1) + c_2 (x_2, y_2). \]" src="form_626.png"/>

    -

    where each value $c_i$ is the relative weight of each vertex (so the centroid is, in 2d, where each $c_i = 1/3$). Since we only consider convex combinations we can rewrite this equation as

    +

    where each value $c_i$ is the relative weight of each vertex (so the centroid is, in 2d, where each $c_i = 1/3$). Since we only consider convex combinations we can rewrite this equation as

    \[
   (x, y) = (1 - c_1 - c_2) (x_0, y_0) + c_1 (x_1, y_1) + c_2 (x_2, y_2).
/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBaseQR.html differs (HTML document, ASCII text, with very long lines)
--- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBaseQR.html	2023-08-09 23:38:37.602471057 +0000
+++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBaseQR.html	2023-08-09 23:38:37.602471057 +0000
@@ -155,8 +155,8 @@
 <a name=

    Detailed Description

    template<typename VectorType>
    class BaseQR< VectorType >

    A base class for thin QR implementations.

    -

    This class and classes derived from it are meant to build $Q$ and $R$ matrices one row/column at a time, i.e., by growing $R$ matrix from an empty $0\times 0$ matrix to $N\times N$, where $N$ is the number of added column vectors.

    -

    As a consequence, matrices which have the same number of rows as each vector (i.e. $Q$ matrix) is stored as a collection of vectors of VectorType.

    +

    This class and classes derived from it are meant to build $Q$ and $R$ matrices one row/column at a time, i.e., by growing $R$ matrix from an empty $0\times 0$ matrix to $N\times N$, where $N$ is the number of added column vectors.

    +

    As a consequence, matrices which have the same number of rows as each vector (i.e. $Q$ matrix) is stored as a collection of vectors of VectorType.

    Definition at line 44 of file qr.h.

    Member Typedef Documentation

    @@ -377,7 +377,7 @@
    -

    Solve $Rx=y$. Vectors x and y should be consistent with the current size of the subspace. If transpose is true, $R^Tx=y$ is solved instead.

    +

    Solve $Rx=y$. Vectors x and y should be consistent with the current size of the subspace. If transpose is true, $R^Tx=y$ is solved instead.

    @@ -415,7 +415,7 @@
    -

    Set $y = Qx$. The size of $x$ should be consistent with the size of the R matrix.

    +

    Set $y = Qx$. The size of $x$ should be consistent with the size of the R matrix.

    Implemented in QR< VectorType >, and ImplicitQR< VectorType >.

    @@ -456,7 +456,7 @@
    -

    Set $y = Q^Tx$. The size of $x$ should be consistent with the size of column vectors.

    +

    Set $y = Q^Tx$. The size of $x$ should be consistent with the size of column vectors.

    Implemented in QR< VectorType >, and ImplicitQR< VectorType >.

    @@ -496,7 +496,7 @@
    -

    Set $y = QRx$. The size of $x$ should be consistent with the size of the R matrix.

    +

    Set $y = QRx$. The size of $x$ should be consistent with the size of the R matrix.

    Implemented in QR< VectorType >, and ImplicitQR< VectorType >.

    @@ -537,7 +537,7 @@
    -

    Set $y = R^T Q^Tx$. The size of $x$ should be consistent with the size of column vectors.

    +

    Set $y = R^T Q^Tx$. The size of $x$ should be consistent with the size of column vectors.

    Implemented in QR< VectorType >, and ImplicitQR< VectorType >.

    @@ -599,7 +599,7 @@
    -

    Compute $y=Hx$ where $H$ is the matrix formed by the column vectors stored by this object.

    +

    Compute $y=Hx$ where $H$ is the matrix formed by the column vectors stored by this object.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockIndices.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockIndices.html 2023-08-09 23:38:37.630471266 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockIndices.html 2023-08-09 23:38:37.634471296 +0000 @@ -209,7 +209,7 @@ void swap (BlockIndices &u, BlockIndices &v) &#href_anchor"details" id="details">

    Detailed Description

    -

    BlockIndices represents a range of indices (such as the range $[0,N)$ of valid indices for elements of a vector) and how this one range is broken down into smaller but contiguous "blocks" (such as the velocity and pressure parts of a solution vector). In particular, it provides the ability to translate between global indices and the indices within a block. This class is used, for example, in the BlockVector, BlockSparsityPattern, and BlockMatrixBase classes.

    +

    BlockIndices represents a range of indices (such as the range $[0,N)$ of valid indices for elements of a vector) and how this one range is broken down into smaller but contiguous "blocks" (such as the velocity and pressure parts of a solution vector). In particular, it provides the ability to translate between global indices and the indices within a block. This class is used, for example, in the BlockVector, BlockSparsityPattern, and BlockMatrixBase classes.

    The information that can be obtained from this class falls into two groups. First, it is possible to query the global size of the index space (through the total_size() member function), and the number of blocks and their sizes (via size() and the block_size() functions).

    Secondly, this class manages the conversion of global indices to the local indices within this block, and the other way around. This is required, for example, when you address a global element in a block vector and want to know within which block this is, and which index within this block it corresponds to. It is also useful if a matrix is composed of several blocks, where you have to translate global row and column indices to local ones.

    See also
    Block (linear algebra)
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockLinearOperator.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockLinearOperator.html 2023-08-09 23:38:37.682471655 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockLinearOperator.html 2023-08-09 23:38:37.682471655 +0000 @@ -274,7 +274,7 @@
    LinearOperator< Range, Domain, BlockPayload::BlockType > linear_operator(const Matrix &matrix)
    BlockLinearOperator< Range, Domain, BlockPayload > block_diagonal_operator(const BlockMatrixType &block_matrix)

    A BlockLinearOperator can be sliced to a LinearOperator at any time. This removes all information about the underlying block structure (because above std::function objects are no longer available) - the linear operator interface, however, remains intact.

    -
    Note
    This class makes heavy use of std::function objects and lambda functions. This flexibility comes with a run-time penalty. Only use this object to encapsulate object with medium to large individual block sizes, and small block structure (as a rule of thumb, matrix blocks greater than $1000\times1000$).
    +
    Note
    This class makes heavy use of std::function objects and lambda functions. This flexibility comes with a run-time penalty. Only use this object to encapsulate object with medium to large individual block sizes, and small block structure (as a rule of thumb, matrix blocks greater than $1000\times1000$).

    Definition at line 166 of file block_linear_operator.h.

    Member Typedef Documentation

    @@ -812,11 +812,11 @@
    LinearOperator< Range, Domain, BlockPayload::BlockType > distribute_constraints_linear_operator(const AffineConstraints< typename Range::value_type > &constraints, const LinearOperator< Range, Domain, BlockPayload::BlockType > &exemplar)

    and Id_c is the projection to the subspace consisting of all vector entries associated with constrained degrees of freedom.

    This LinearOperator object is used together with constrained_right_hand_side() to build up the following modified system of linear equations:

    -\[
+<picture><source srcset=\[
   (C^T A C + Id_c) x = C^T (b - A\,k)
-\] +\]" src="form_1616.png"/>

    -

    with a given (unconstrained) system matrix $A$, right hand side $b$, and linear constraints $C$ with inhomogeneities $k$.

    +

    with a given (unconstrained) system matrix $A$, right hand side $b$, and linear constraints $C$ with inhomogeneities $k$.

    A detailed explanation of this approach is given in the Constraints on degrees of freedom module.

    Note
    Currently, this function may not work correctly for distributed data structures.
    @@ -865,11 +865,11 @@

    with

    This LinearOperator object is used together with constrained_right_hand_side() to build up the following modified system of linear equations:

    -\[
+<picture><source srcset=\[
   (C^T A C + Id_c) x = C^T (b - A\,k)
-\] +\]" src="form_1616.png"/>

    -

    with a given (unconstrained) system matrix $A$, right hand side $b$, and linear constraints $C$ with inhomogeneities $k$.

    +

    with a given (unconstrained) system matrix $A$, right hand side $b$, and linear constraints $C$ with inhomogeneities $k$.

    A detailed explanation of this approach is given in the Constraints on degrees of freedom module.

    Note
    Currently, this function may not work correctly for distributed data structures.
    @@ -908,8 +908,8 @@
    -

    Addition of two linear operators first_op and second_op given by $(\mathrm{first\_op}+\mathrm{second\_op})x \dealcoloneq \mathrm{first\_op}(x)
-+ \mathrm{second\_op}(x)$

    +

    Addition of two linear operators first_op and second_op given by $(\mathrm{first\_op}+\mathrm{second\_op})x \dealcoloneq \mathrm{first\_op}(x)
++ \mathrm{second\_op}(x)$

    Definition at line 390 of file linear_operator.h.

    @@ -946,8 +946,8 @@
    -

    Subtraction of two linear operators first_op and second_op given by $(\mathrm{first\_op}-\mathrm{second\_op})x \dealcoloneq \mathrm{first\_op}(x)
-- \mathrm{second\_op}(x)$

    +

    Subtraction of two linear operators first_op and second_op given by $(\mathrm{first\_op}-\mathrm{second\_op})x \dealcoloneq \mathrm{first\_op}(x)
+- \mathrm{second\_op}(x)$

    Definition at line 449 of file linear_operator.h.

    @@ -1066,8 +1066,8 @@
    -

    Composition of two linear operators first_op and second_op given by $(\mathrm{first\_op}*\mathrm{second\_op})x \dealcoloneq
-\mathrm{first\_op}(\mathrm{second\_op}(x))$

    +

    Composition of two linear operators first_op and second_op given by $(\mathrm{first\_op}*\mathrm{second\_op})x \dealcoloneq
+\mathrm{first\_op}(\mathrm{second\_op}(x))$

    Definition at line 587 of file linear_operator.h.

    @@ -1701,7 +1701,7 @@

    Return a LinearOperator that performs the operations associated with the Schur complement. There are two additional helper functions, condense_schur_rhs() and postprocess_schur_solution(), that are likely necessary to be used in order to perform any useful tasks in linear algebra with this operator.

    We construct the definition of the Schur complement in the following way:

    Consider a general system of linear equations that can be decomposed into two major sets of equations:

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
 \mathbf{K}\mathbf{d} = \mathbf{f}
 \quad \Rightarrow\quad
 \left(\begin{array}{cc}
@@ -1714,60 +1714,60 @@
 \left(\begin{array}{cc}
    f \\ g
 \end{array}\right),
-\end{eqnarray*} +\end{eqnarray*}" src="form_1852.png"/>

    -

    where $ A,B,C,D $ represent general subblocks of the matrix $ \mathbf{K} $ and, similarly, general subvectors of $ \mathbf{d},\mathbf{f} $ are given by $ x,y,f,g $ .

    +

    where $ A,B,C,D $ represent general subblocks of the matrix $ \mathbf{K} $ and, similarly, general subvectors of $ \mathbf{d},\mathbf{f} $ are given by $ x,y,f,g $ .

    This is equivalent to the following two statements:

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   (1) \quad Ax + By &=& f \\
   (2) \quad Cx + Dy &=& g \quad .
-\end{eqnarray*} +\end{eqnarray*}" src="form_1857.png"/>

    -

    Assuming that $ A,D $ are both square and invertible, we could then perform one of two possible substitutions,

    -\begin{eqnarray*}
+<p>Assuming that <picture><source srcset=$ A,D $ are both square and invertible, we could then perform one of two possible substitutions,

    +\begin{eqnarray*}
   (3) \quad x &=& A^{-1}(f - By) \quad \text{from} \quad (1) \\
   (4) \quad y &=& D^{-1}(g - Cx) \quad \text{from} \quad (2) ,
-\end{eqnarray*} +\end{eqnarray*}" src="form_1859.png"/>

    which amount to performing block Gaussian elimination on this system of equations.

    For the purpose of the current implementation, we choose to substitute (3) into (2)

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   C \: A^{-1}(f - By) + Dy &=& g \\
   -C \: A^{-1} \: By + Dy &=& g - C \: A^{-1} \: f \quad .
-\end{eqnarray*} +\end{eqnarray*}" src="form_1860.png"/>

    This leads to the result

    -\[
+<picture><source srcset=\[
   (5) \quad (D - C\: A^{-1} \:B)y  = g - C \: A^{-1} f
       \quad \Rightarrow \quad Sy = g'
-\] +\]" src="form_1861.png"/>

    -

    with $ S = (D - C\: A^{-1} \:B) $ being the Schur complement and the modified right-hand side vector $ g' = g - C \: A^{-1} f $ arising from the condensation step. Note that for this choice of $ S $, submatrix $ D $ need not be invertible and may thus be the null matrix. Ideally $ A $ should be well-conditioned.

    -

    So for any arbitrary vector $ a $, the Schur complement performs the following operation:

    -\[
+<p> with <picture><source srcset=$ S = (D - C\: A^{-1} \:B) $ being the Schur complement and the modified right-hand side vector $ g' = g - C \: A^{-1} f $ arising from the condensation step. Note that for this choice of $ S $, submatrix $ D $ need not be invertible and may thus be the null matrix. Ideally $ A $ should be well-conditioned.

    +

    So for any arbitrary vector $ a $, the Schur complement performs the following operation:

    +\[
   (6) \quad Sa = (D - C \: A^{-1} \: B)a
-\] +\]" src="form_1868.png"/>

    A typical set of steps needed the solve a linear system (1),(2) would be:

    1. Define the inverse matrix A_inv (using inverse_operator()).
    2. -
    3. Define the Schur complement $ S $ (using schur_complement()).
    4. -
    5. Define iterative inverse matrix $ S^{-1} $ such that (6) holds. It is necessary to use a solver with a preconditioner to compute the approximate inverse operation of $ S $ since we never compute $ S $ directly, but rather the result of its operation. To achieve this, one may again use the inverse_operator() in conjunction with the Schur complement that we've just constructed. Observe that the both $ S $ and its preconditioner operate over the same space as $ D $.
    6. +
    7. Define the Schur complement $ S $ (using schur_complement()).
    8. +
    9. Define iterative inverse matrix $ S^{-1} $ such that (6) holds. It is necessary to use a solver with a preconditioner to compute the approximate inverse operation of $ S $ since we never compute $ S $ directly, but rather the result of its operation. To achieve this, one may again use the inverse_operator() in conjunction with the Schur complement that we've just constructed. Observe that the both $ S $ and its preconditioner operate over the same space as $ D $.
    10. Perform pre-processing step on the RHS of (5) using condense_schur_rhs():

      -\[
+<picture><source srcset=\[
      g' = g - C \: A^{-1} \: f
-   \] + \]" src="form_1870.png"/>

    11. -
    12. Solve for $ y $ in (5):

      -\[
+<li>Solve for <picture><source srcset=$ y $ in (5):

      +\[
      y =  S^{-1} g'
-   \] + \]" src="form_1872.png"/>

    13. Perform the post-processing step from (3) using postprocess_schur_solution():

      -\[
+<picture><source srcset=\[
      x =  A^{-1} (f - By)
-   \] + \]" src="form_1873.png"/>

    @@ -1813,10 +1813,10 @@
    LinearOperator< Domain, Range, BlockPayload::BlockType > inverse_operator(const LinearOperator< Range, Domain, BlockPayload::BlockType > &op, Solver &solver, const Preconditioner &preconditioner)
    PackagedOperation< Domain_1 > postprocess_schur_solution(const LinearOperator< Range_1, Domain_1, Payload > &A_inv, const LinearOperator< Range_1, Domain_2, Payload > &B, const Domain_2 &y, const Range_1 &f)
    -

    In the above example, the preconditioner for $ S $ was defined as the preconditioner for $ D $, which is valid since they operate on the same space. However, if $ D $ and $ S $ are too dissimilar, then this may lead to a large number of solver iterations as $ \text{prec}(D) $ is not a good approximation for $ S^{-1} $.

    -

    A better preconditioner in such a case would be one that provides a more representative approximation for $ S^{-1} $. One approach is shown in step-22, where $ D $ is the null matrix and the preconditioner for $ S^{-1}
-$ is derived from the mass matrix over this space.

    -

    From another viewpoint, a similar result can be achieved by first constructing an object that represents an approximation for $ S $ wherein expensive operation, namely $ A^{-1} $, is approximated. Thereafter we construct the approximate inverse operator $ \tilde{S}^{-1} $ which is then used as the preconditioner for computing $ S^{-1} $.

    // Construction of approximate inverse of Schur complement
    +

    In the above example, the preconditioner for $ S $ was defined as the preconditioner for $ D $, which is valid since they operate on the same space. However, if $ D $ and $ S $ are too dissimilar, then this may lead to a large number of solver iterations as $ \text{prec}(D) $ is not a good approximation for $ S^{-1} $.

    +

    A better preconditioner in such a case would be one that provides a more representative approximation for $ S^{-1} $. One approach is shown in step-22, where $ D $ is the null matrix and the preconditioner for $ S^{-1}
+$ is derived from the mass matrix over this space.

    +

    From another viewpoint, a similar result can be achieved by first constructing an object that represents an approximation for $ S $ wherein expensive operation, namely $ A^{-1} $, is approximated. Thereafter we construct the approximate inverse operator $ \tilde{S}^{-1} $ which is then used as the preconditioner for computing $ S^{-1} $.

    // Construction of approximate inverse of Schur complement
    const auto A_inv_approx = linear_operator(preconditioner_A);
    const auto S_approx = schur_complement(A_inv_approx,B,C,D);
    @@ -1839,8 +1839,8 @@
    // Solve for y
    y = S_inv * rhs;
    x = postprocess_schur_solution (A_inv,B,y,f);
    -

    Note that due to the construction of S_inv_approx and subsequently S_inv, there are a pair of nested iterative solvers which could collectively consume a lot of resources. Therefore care should be taken in the choices leading to the construction of the iterative inverse_operators. One might consider the use of a IterationNumberControl (or a similar mechanism) to limit the number of inner solver iterations. This controls the accuracy of the approximate inverse operation $ \tilde{S}^{-1} $ which acts only as the preconditioner for $ S^{-1} $. Furthermore, the preconditioner to $ \tilde{S}^{-1} $, which in this example is $
-\text{prec}(D) $, should ideally be computationally inexpensive.

    +

    Note that due to the construction of S_inv_approx and subsequently S_inv, there are a pair of nested iterative solvers which could collectively consume a lot of resources. Therefore care should be taken in the choices leading to the construction of the iterative inverse_operators. One might consider the use of a IterationNumberControl (or a similar mechanism) to limit the number of inner solver iterations. This controls the accuracy of the approximate inverse operation $ \tilde{S}^{-1} $ which acts only as the preconditioner for $ S^{-1} $. Furthermore, the preconditioner to $ \tilde{S}^{-1} $, which in this example is $
+\text{prec}(D) $, should ideally be computationally inexpensive.

    However, if an iterative solver based on IterationNumberControl is used as a preconditioner then the preconditioning operation is not a linear operation. Here a flexible solver like SolverFGMRES (flexible GMRES) is best employed as an outer solver in order to deal with the variable behavior of the preconditioner. Otherwise the iterative solver can stagnate somewhere near the tolerance of the preconditioner or generally behave erratically. Alternatively, using a ReductionControl would ensure that the preconditioner always solves to the same tolerance, thereby rendering its behavior constant.

    Further examples of this functionality can be found in the test-suite, such as tests/lac/schur_complement_01.cc . The solution of a multi- component problem (namely step-22) using the schur_complement can be found in tests/lac/schur_complement_03.cc .

    See also
    Block (linear algebra)
    @@ -1863,7 +1863,7 @@
    -

    Return the number of blocks in a column (i.e, the number of "block rows", or the number $m$, if interpreted as a $m\times n$ block system).

    +

    Return the number of blocks in a column (i.e, the number of "block rows", or the number $m$, if interpreted as a $m\times n$ block system).

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockMatrixBase.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockMatrixBase.html 2023-08-09 23:38:37.730472013 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockMatrixBase.html 2023-08-09 23:38:37.730472013 +0000 @@ -1440,7 +1440,7 @@
    -

    Adding Matrix-vector multiplication. Add $M*src$ on $dst$ with $M$ being this matrix.

    +

    Adding Matrix-vector multiplication. Add $M*src$ on $dst$ with $M$ being this matrix.

    @@ -1547,7 +1547,7 @@
    -

    Compute the matrix scalar product $\left(u,Mv\right)$.

    +

    Compute the matrix scalar product $\left(u,Mv\right)$.

    @@ -1938,7 +1938,7 @@
    -

    Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix.

    +

    Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix.

    Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.

    @@ -2102,7 +2102,7 @@
    -

    Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult() but takes the transposed matrix.

    +

    Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult() but takes the transposed matrix.

    Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockSparseMatrix.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockSparseMatrix.html 2023-08-09 23:38:37.790472461 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockSparseMatrix.html 2023-08-09 23:38:37.790472461 +0000 @@ -950,7 +950,7 @@
    -

    Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix.

    +

    Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix.

    Definition at line 396 of file block_sparse_matrix.h.

    @@ -1114,7 +1114,7 @@
    -

    Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult() but takes the transposed matrix.

    +

    Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult() but takes the transposed matrix.

    Definition at line 440 of file block_sparse_matrix.h.

    @@ -2328,7 +2328,7 @@
    -

    Adding Matrix-vector multiplication. Add $M*src$ on $dst$ with $M$ being this matrix.

    +

    Adding Matrix-vector multiplication. Add $M*src$ on $dst$ with $M$ being this matrix.

    @@ -2453,7 +2453,7 @@
    -

    Compute the matrix scalar product $\left(u,Mv\right)$.

    +

    Compute the matrix scalar product $\left(u,Mv\right)$.

    @@ -2948,7 +2948,7 @@
    -

    Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix.

    +

    Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix.

    Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.

    @@ -3096,7 +3096,7 @@
    -

    Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult() but takes the transposed matrix.

    +

    Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult() but takes the transposed matrix.

    Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockSparseMatrixEZ.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockSparseMatrixEZ.html 2023-08-09 23:38:37.822472700 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockSparseMatrixEZ.html 2023-08-09 23:38:37.822472700 +0000 @@ -799,7 +799,7 @@
    -

    Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix.

    +

    Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix.

    Definition at line 371 of file block_sparse_matrix_ez.h.

    @@ -832,7 +832,7 @@
    -

    Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult() but takes the transposed matrix.

    +

    Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult() but takes the transposed matrix.

    Definition at line 409 of file block_sparse_matrix_ez.h.

    @@ -865,7 +865,7 @@
    -

    Adding Matrix-vector multiplication. Add $M*src$ on $dst$ with $M$ being this matrix.

    +

    Adding Matrix-vector multiplication. Add $M*src$ on $dst$ with $M$ being this matrix.

    Definition at line 391 of file block_sparse_matrix_ez.h.

    @@ -898,7 +898,7 @@
    -

    Adding Matrix-vector multiplication. Add $M^T*src$ to $dst$ with $M$ being this matrix. This function does the same as vmult_add() but takes the transposed matrix.

    +

    Adding Matrix-vector multiplication. Add $M^T*src$ to $dst$ with $M$ being this matrix. This function does the same as vmult_add() but takes the transposed matrix.

    Definition at line 429 of file block_sparse_matrix_ez.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockVector.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockVector.html 2023-08-09 23:38:37.874473088 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockVector.html 2023-08-09 23:38:37.874473088 +0000 @@ -1848,7 +1848,7 @@
    -

    Return the square of the $l_2$-norm.

    +

    Return the square of the $l_2$-norm.

    @@ -1900,7 +1900,7 @@
    -

    Return the $l_1$-norm of the vector, i.e. the sum of the absolute values.

    +

    Return the $l_1$-norm of the vector, i.e. the sum of the absolute values.

    @@ -1926,7 +1926,7 @@
    -

    Return the $l_2$-norm of the vector, i.e. the square root of the sum of the squares of the elements.

    +

    Return the $l_2$-norm of the vector, i.e. the square root of the sum of the squares of the elements.

    @@ -1952,7 +1952,7 @@
    -

    Return the maximum absolute value of the elements of this vector, which is the $l_\infty$-norm of a vector.

    +

    Return the maximum absolute value of the elements of this vector, which is the $l_\infty$-norm of a vector.

    @@ -2271,7 +2271,7 @@
    -

    $U(0-DIM)+=s$. Addition of s to all components. Note that s is a scalar and not a vector.

    +

    $U(0-DIM)+=s$. Addition of s to all components. Note that s is a scalar and not a vector.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockVectorBase.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockVectorBase.html 2023-08-09 23:38:37.922473447 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBlockVectorBase.html 2023-08-09 23:38:37.922473447 +0000 @@ -1233,7 +1233,7 @@
    -

    Return the square of the $l_2$-norm.

    +

    Return the square of the $l_2$-norm.

    @@ -1273,7 +1273,7 @@
    -

    Return the $l_1$-norm of the vector, i.e. the sum of the absolute values.

    +

    Return the $l_1$-norm of the vector, i.e. the sum of the absolute values.

    @@ -1293,7 +1293,7 @@
    -

    Return the $l_2$-norm of the vector, i.e. the square root of the sum of the squares of the elements.

    +

    Return the $l_2$-norm of the vector, i.e. the square root of the sum of the squares of the elements.

    @@ -1313,7 +1313,7 @@
    -

    Return the maximum absolute value of the elements of this vector, which is the $l_\infty$-norm of a vector.

    +

    Return the maximum absolute value of the elements of this vector, which is the $l_\infty$-norm of a vector.

    @@ -1578,7 +1578,7 @@
    -

    $U(0-DIM)+=s$. Addition of s to all components. Note that s is a scalar and not a vector.

    +

    $U(0-DIM)+=s$. Addition of s to all components. Note that s is a scalar and not a vector.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBoundingBox.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBoundingBox.html 2023-08-09 23:38:37.954473686 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classBoundingBox.html 2023-08-09 23:38:37.954473686 +0000 @@ -165,11 +165,11 @@ &#href_anchor"details" id="details">

    Detailed Description

    template<int spacedim, typename Number = double>
    class BoundingBox< spacedim, Number >

    A class that represents a box of arbitrary dimension spacedim and with sides parallel to the coordinate axes, that is, a region

    -\[
+<picture><source srcset=\[
 [x_0^L, x_0^U] \times ... \times [x_{spacedim-1}^L, x_{spacedim-1}^U],
-\] +\]" src="form_362.png"/>

    -

    where $(x_0^L , ..., x_{spacedim-1}^L)$ and $(x_0^U , ..., x_{spacedim-1}^U)$ denote the two vertices (bottom left and top right) which are used to represent the box. The quantities $x_k^L$ and $x_k^U$ denote the "lower" and "upper" bounds of values that are within the box for each coordinate direction $k$.

    +

    where $(x_0^L , ..., x_{spacedim-1}^L)$ and $(x_0^U , ..., x_{spacedim-1}^U)$ denote the two vertices (bottom left and top right) which are used to represent the box. The quantities $x_k^L$ and $x_k^U$ denote the "lower" and "upper" bounds of values that are within the box for each coordinate direction $k$.

    Geometrically, a bounding box is thus:

    Bounding boxes are, for example, useful in parallel distributed meshes to give a general description of the owners of each portion of the mesh. More generally, bounding boxes are often used to roughly describe a region of space in which an object is contained; if a candidate point is not within the bounding box (a test that is cheap to execute), then it is not necessary to perform an expensive test whether the candidate point is in fact inside the object itself. Bounding boxes are therefore often used as a first, cheap rejection test before more detailed checks. As such, bounding boxes serve many of the same purposes as the convex hull, for which it is also relatively straightforward to compute whether a point is inside or outside, though not quite as cheap as for the bounding box.

    -

    Taking the cross section of a BoundingBox<spacedim> orthogonal to a given direction gives a box in one dimension lower: BoundingBox<spacedim - 1>. In 3d, the 2 coordinates of the cross section of BoundingBox<3> can be ordered in 2 different ways. That is, if we take the cross section orthogonal to the y direction we could either order a 3d-coordinate into a 2d-coordinate as $(x,z)$ or as $(z,x)$. This class uses the second convention, corresponding to the coordinates being ordered cyclicly $x \rightarrow y \rightarrow z \rightarrow x \rightarrow ... $ To be precise, if we take a cross section:

    +

    Taking the cross section of a BoundingBox<spacedim> orthogonal to a given direction gives a box in one dimension lower: BoundingBox<spacedim - 1>. In 3d, the 2 coordinates of the cross section of BoundingBox<3> can be ordered in 2 different ways. That is, if we take the cross section orthogonal to the y direction we could either order a 3d-coordinate into a 2d-coordinate as $(x,z)$ or as $(z,x)$. This class uses the second convention, corresponding to the coordinates being ordered cyclicly $x \rightarrow y \rightarrow z \rightarrow x \rightarrow ... $ To be precise, if we take a cross section:

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1PreconditionIC.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1PreconditionIC.html 2023-08-09 23:38:37.978473865 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1PreconditionIC.html 2023-08-09 23:38:37.978473865 +0000 @@ -491,7 +491,7 @@
    Orthogonal to Cross section coordinates ordered as
    -

    cuSPARSE description of the lower triangular matrix $L$.

    +

    cuSPARSE description of the lower triangular matrix $L$.

    Definition at line 176 of file cuda_precondition.h.

    @@ -545,7 +545,7 @@
    -

    Solve and analysis structure for the lower triangular matrix $L$.

    +

    Solve and analysis structure for the lower triangular matrix $L$.

    Definition at line 186 of file cuda_precondition.h.

    @@ -761,7 +761,7 @@
    -

    Determine if level information should be generated for the lower triangular matrix $L$. This value can be modified through an AdditionalData object.

    +

    Determine if level information should be generated for the lower triangular matrix $L$. This value can be modified through an AdditionalData object.

    Definition at line 233 of file cuda_precondition.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1PreconditionILU.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1PreconditionILU.html 2023-08-09 23:38:38.002474044 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1PreconditionILU.html 2023-08-09 23:38:38.002474044 +0000 @@ -493,7 +493,7 @@
    -

    cuSPARSE description of the lower triangular matrix $L$.

    +

    cuSPARSE description of the lower triangular matrix $L$.

    Definition at line 388 of file cuda_precondition.h.

    @@ -574,7 +574,7 @@
    -

    Solve and analysis structure for the lower triangular matrix $L$.

    +

    Solve and analysis structure for the lower triangular matrix $L$.

    Definition at line 403 of file cuda_precondition.h.

    @@ -790,7 +790,7 @@
    -

    Determine if level information should be generated for the lower triangular matrix $L$. This value can be modified through an AdditionalData object.

    +

    Determine if level information should be generated for the lower triangular matrix $L$. This value can be modified through an AdditionalData object.

    Definition at line 450 of file cuda_precondition.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1SparseMatrix.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1SparseMatrix.html 2023-08-09 23:38:38.038474313 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCUDAWrappers_1_1SparseMatrix.html 2023-08-09 23:38:38.038474313 +0000 @@ -802,7 +802,7 @@
    -

    Matrix-vector multiplication: let $dst = M \cdot src$ with $M$ being this matrix.

    +

    Matrix-vector multiplication: let $dst = M \cdot src$ with $M$ being this matrix.

    Definition at line 512 of file cuda_sparse_matrix.cc.

    @@ -833,7 +833,7 @@
    -

    Matrix-vector multiplication: let $dst = M^T \cdot src$ with $M$ being this matrix. This function does the same as vmult() but takes this transposed matrix.

    +

    Matrix-vector multiplication: let $dst = M^T \cdot src$ with $M$ being this matrix. This function does the same as vmult() but takes this transposed matrix.

    Definition at line 530 of file cuda_sparse_matrix.cc.

    @@ -864,7 +864,7 @@
    -

    Adding matrix-vector multiplication. Add $M \cdot src$ on $dst$ with $M$ being this matrix.

    +

    Adding matrix-vector multiplication. Add $M \cdot src$ on $dst$ with $M$ being this matrix.

    Definition at line 548 of file cuda_sparse_matrix.cc.

    @@ -895,7 +895,7 @@
    -

    Adding matrix-vector multiplication. Add $M^T \cdot src$ to $dst$ with $M$ being this matrix. This function foes the same as vmult_add() but takes the transposed matrix.

    +

    Adding matrix-vector multiplication. Add $M^T \cdot src$ to $dst$ with $M$ being this matrix. This function foes the same as vmult_add() but takes the transposed matrix.

    Definition at line 566 of file cuda_sparse_matrix.cc.

    @@ -917,7 +917,7 @@
    -

    Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e., $\left(v,Mv\right)$. This is useful, e.g., in the finite context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

    +

    Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e., $\left(v,Mv\right)$. This is useful, e.g., in the finite context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

    Obviously, the matrix needs to be quadratic for this operation.

    Definition at line 584 of file cuda_sparse_matrix.cc.

    @@ -949,7 +949,7 @@
    -

    Compute the matrix scalar product $\left(u,Mv\right)$.

    +

    Compute the matrix scalar product $\left(u,Mv\right)$.

    Definition at line 597 of file cuda_sparse_matrix.cc.

    @@ -985,8 +985,8 @@
    -

    Compute the residual of an equation $M \cdot x=b$, where the residual is defined to be $r=b-M \cdot x$. Write the residual into $dst$. The $l_2$ norm of the residual vector is returned.

    -

    Source $x$ and destination $dst$ must not be the same vector.

    +

    Compute the residual of an equation $M \cdot x=b$, where the residual is defined to be $r=b-M \cdot x$. Write the residual into $dst$. The $l_2$ norm of the residual vector is returned.

    +

    Source $x$ and destination $dst$ must not be the same vector.

    Definition at line 611 of file cuda_sparse_matrix.cc.

    @@ -1005,8 +1005,8 @@
    -

    Return the $l_1$-norm of the matrix, that is $|M|_1=\max_{\mathrm{all\
-columns\ }j}\sum_{\mathrm{all\ rows\ }i} |M_{ij}|$, (max. sum of columns). This is the natural matrix norm that is compatible to the $l_1$-norm for vectors, i.e., $|Mv|_1\leq |M|_1 |v|_1$.

    +

    Return the $l_1$-norm of the matrix, that is $|M|_1=\max_{\mathrm{all\
+columns\ }j}\sum_{\mathrm{all\ rows\ }i} |M_{ij}|$, (max. sum of columns). This is the natural matrix norm that is compatible to the $l_1$-norm for vectors, i.e., $|Mv|_1\leq |M|_1 |v|_1$.

    Definition at line 626 of file cuda_sparse_matrix.cc.

    @@ -1025,8 +1025,8 @@
    -

    Return the $l_\infty$-norm of the matrix, that is $|M|_\infty=\max_{\mathrm{all\ rows\ }i}\sum_{\mathrm{all\ columns\ }j}
-|M_{ij}|$, (max. sum of rows). This is the natural norm that is compatible to the $l_\infty$-norm of vectors, i.e., $|Mv|_\infty \leq
+<p>Return the <picture><source srcset=$l_\infty$-norm of the matrix, that is $|M|_\infty=\max_{\mathrm{all\ rows\ }i}\sum_{\mathrm{all\ columns\ }j}
+|M_{ij}|$, (max. sum of rows). This is the natural norm that is compatible to the $l_\infty$-norm of vectors, i.e., $|Mv|_\infty \leq
 |M|_\infty |v|_\infty$.

    Definition at line 645 of file cuda_sparse_matrix.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCellAccessor.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCellAccessor.html 2023-08-09 23:38:38.134475029 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCellAccessor.html 2023-08-09 23:38:38.138475059 +0000 @@ -4164,8 +4164,8 @@
    -

    This function computes a fast approximate transformation from the real to the unit cell by inversion of an affine approximation of the $d$-linear function from the reference $d$-dimensional cell.

    -

    The affine approximation of the unit to real cell mapping is found by a least squares fit of an affine function to the $2^d$ vertices of the present object. For any valid mesh cell whose geometry is not degenerate, this operation results in a unique affine mapping. Thus, this function will return a finite result for all given input points, even in cases where the actual transformation by an actual bi-/trilinear or higher order mapping might be singular. Besides only approximating the mapping from the vertex points, this function also ignores the attached manifold descriptions. The result is only exact in case the transformation from the unit to the real cell is indeed affine, such as in one dimension or for Cartesian and affine (parallelogram) meshes in 2d/3d.

    +

    This function computes a fast approximate transformation from the real to the unit cell by inversion of an affine approximation of the $d$-linear function from the reference $d$-dimensional cell.

    +

    The affine approximation of the unit to real cell mapping is found by a least squares fit of an affine function to the $2^d$ vertices of the present object. For any valid mesh cell whose geometry is not degenerate, this operation results in a unique affine mapping. Thus, this function will return a finite result for all given input points, even in cases where the actual transformation by an actual bi-/trilinear or higher order mapping might be singular. Besides only approximating the mapping from the vertex points, this function also ignores the attached manifold descriptions. The result is only exact in case the transformation from the unit to the real cell is indeed affine, such as in one dimension or for Cartesian and affine (parallelogram) meshes in 2d/3d.

    For exact transformations to the unit cell, use Mapping::transform_real_to_unit_cell().

    Note
    If dim<spacedim we first project p onto the plane.
    @@ -4206,7 +4206,7 @@
    -

    Center of the object. The center of an object is defined to be the average of the locations of the vertices, which is also where a $Q_1$ mapping would map the center of the reference cell. However, you can also ask this function to instead return the average of the vertices as computed by the underlying Manifold object associated with the current object, by setting to true the optional parameter respect_manifold. Manifolds would then typically pull back the coordinates of the vertices to a reference domain (not necessarily the reference cell), compute the average there, and then push forward the coordinates of the averaged point to the physical space again; the resulting point is guaranteed to lie within the manifold, even if the manifold is curved.

    +

    Center of the object. The center of an object is defined to be the average of the locations of the vertices, which is also where a $Q_1$ mapping would map the center of the reference cell. However, you can also ask this function to instead return the average of the vertices as computed by the underlying Manifold object associated with the current object, by setting to true the optional parameter respect_manifold. Manifolds would then typically pull back the coordinates of the vertices to a reference domain (not necessarily the reference cell), compute the average there, and then push forward the coordinates of the averaged point to the physical space again; the resulting point is guaranteed to lie within the manifold, even if the manifold is curved.

    When the object uses a different manifold description as its surrounding, like when part of the bounding objects of this TriaAccessor use a non-flat manifold description but the object itself is flat, the result given by the TriaAccessor::center() function may not be accurate enough, even when parameter respect_manifold is set to true. If you find this to be case, than you can further refine the computation of the center by setting to true the second additional parameter interpolate_from_surrounding. This computes the location of the center by a so-called transfinite interpolation from the center of all the bounding objects. For a 2d object, it puts a weight of 1/2 on each of the four surrounding lines and a weight -1/4 on the four vertices. This corresponds to a linear interpolation between the descriptions of the four faces, subtracting the contribution of the vertices that is added twice when coming through both lines adjacent to the vertex. In 3d, the weights for faces are 1/2, the weights for lines are -1/4, and the weights for vertices are 1/8. For further information, also confer to the TransfiniteInterpolationManifold class that is able to not only apply this beneficial description to a single cell but all children of a coarse cell.

    Definition at line 1787 of file tria_accessor.cc.

    @@ -4234,17 +4234,17 @@
    -

    Return the barycenter (also called centroid) of the object. The barycenter for an object $K$ of dimension $d$ in $D$ space dimensions is given by the $D$-dimensional vector $\mathbf x_K$ defined by

    -\[
+<p>Return the barycenter (also called centroid) of the object. The barycenter for an object <picture><source srcset=$K$ of dimension $d$ in $D$ space dimensions is given by the $D$-dimensional vector $\mathbf x_K$ defined by

    +\[
   \mathbf x_K = \frac{1}{|K|} \int_K \mathbf x \; \textrm{d}x
-\] +\]" src="form_1482.png"/>

    where the measure of the object is given by

    -\[
+<picture><source srcset=\[
   |K| = \int_K \mathbf 1 \; \textrm{d}x.
-\] +\]" src="form_1483.png"/>

    -

    This function assumes that $K$ is mapped by a $d$-linear function from the reference $d$-dimensional cell. Then the integrals above can be pulled back to the reference cell and evaluated exactly (if through lengthy and, compared to the center() function, expensive computations).

    +

    This function assumes that $K$ is mapped by a $d$-linear function from the reference $d$-dimensional cell. Then the integrals above can be pulled back to the reference cell and evaluated exactly (if through lengthy and, compared to the center() function, expensive computations).

    Definition at line 1597 of file tria_accessor.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChartManifold.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChartManifold.html 2023-08-09 23:38:38.178475358 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChartManifold.html 2023-08-09 23:38:38.178475358 +0000 @@ -204,37 +204,37 @@

    Detailed Description

    template<int dim, int spacedim = dim, int chartdim = dim>
    class ChartManifold< dim, spacedim, chartdim >

    This class describes mappings that can be expressed in terms of charts. Specifically, this class with its template arguments describes a chart of dimension chartdim, which is part of a Manifold<dim,spacedim> and is used in an object of type Triangulation<dim,spacedim>: It specializes a Manifold of dimension chartdim embedded in a manifold of dimension spacedim, for which you have explicit pull_back() and push_forward() transformations. Its use is explained in great detail in step-53.

    -

    This is a helper class which is useful when you have an explicit map from an Euclidean space of dimension chartdim to an Euclidean space of dimension spacedim which represents your manifold, i.e., when your manifold $\mathcal{M}$ can be represented by a map

    -\[ F: \mathcal{B} \subset
-R^{\text{chartdim}} \mapsto \mathcal{M} \subset R^{\text{spacedim}} \] +

    This is a helper class which is useful when you have an explicit map from an Euclidean space of dimension chartdim to an Euclidean space of dimension spacedim which represents your manifold, i.e., when your manifold $\mathcal{M}$ can be represented by a map

    +\[ F: \mathcal{B} \subset
+R^{\text{chartdim}} \mapsto \mathcal{M} \subset R^{\text{spacedim}} \]

    (the push_forward() function) and that admits the inverse transformation

    -\[ F^{-1}: \mathcal{M} \subset R^{\text{spacedim}} \mapsto \mathcal{B}
-\subset R^{\text{chartdim}} \] +\[ F^{-1}: \mathcal{M} \subset R^{\text{spacedim}} \mapsto \mathcal{B}
+\subset R^{\text{chartdim}} \]

    (the pull_back() function).

    The get_new_point() function of the ChartManifold class is implemented by calling the pull_back() method for all surrounding_points, computing their weighted average in the chartdim Euclidean space, and calling the push_forward() method with the resulting point, i.e.,

    -\[
-\mathbf x^{\text{new}} = F(\sum_i w_i F^{-1}(\mathbf x_i)).  \] +\[
+\mathbf x^{\text{new}} = F(\sum_i w_i F^{-1}(\mathbf x_i)).  \]

    Derived classes are required to implement the push_forward() and the pull_back() methods. All other functions (with the exception of the push_forward_gradient() function, see below) that are required by mappings will then be provided by this class.

    Providing function gradients

    -

    In order to compute vectors that are tangent to the manifold (for example, tangent to a surface embedded in higher dimensional space, or simply the three unit vectors of ${\mathbb R}^3$), one needs to also have access to the gradient of the push-forward function $F$. The gradient is the matrix $(\nabla F)_{ij}=\partial_j F_i$, where we take the derivative with regard to the chartdim reference coordinates on the flat Euclidean space in which $\mathcal B$ is located. In other words, at a point $\mathbf x$, $\nabla F(\mathbf x)$ is a matrix of size spacedim times chartdim.

    +

    In order to compute vectors that are tangent to the manifold (for example, tangent to a surface embedded in higher dimensional space, or simply the three unit vectors of ${\mathbb R}^3$), one needs to also have access to the gradient of the push-forward function $F$. The gradient is the matrix $(\nabla F)_{ij}=\partial_j F_i$, where we take the derivative with regard to the chartdim reference coordinates on the flat Euclidean space in which $\mathcal B$ is located. In other words, at a point $\mathbf x$, $\nabla F(\mathbf x)$ is a matrix of size spacedim times chartdim.

    Only the ChartManifold::get_tangent_vector() function uses the gradient of the push-forward, but only a subset of all finite element codes actually require the computation of tangent vectors. Consequently, while derived classes need to implement the abstract virtual push_forward() and pull_back() functions of this class, they do not need to implement the virtual push_forward_gradient() function. Rather, that function has a default implementation (and consequently is not abstract, therefore not forcing derived classes to overload it), but the default implementation clearly can not compute anything useful and therefore simply triggers and exception.

    A note on the template arguments

    The dimension arguments chartdim, dim and spacedim must satisfy the following relationships:

    dim <= spacedim
    chartdim <= spacedim

    However, there is no a priori relationship between dim and chartdim. For example, if you want to describe a mapping for an edge (a 1d object) in a 2d triangulation embedded in 3d space, you could do so by parameterizing it via a line

    -\[
+<picture><source srcset=\[
      F: [0,1] \rightarrow {\mathbb R}^3
-  \] + \]" src="form_1426.png"/>

    in which case chartdim is 1. On the other hand, there is no reason why one can't describe this as a mapping

    -\[
+<picture><source srcset=\[
      F: {\mathbb R}^3 \rightarrow {\mathbb R}^3
-  \] + \]" src="form_1427.png"/>

    -

    in such a way that the line $[0,1]\times \{0\}\times \{0\}$ happens to be mapped onto the edge in question. Here, chartdim is 3. This may seem cumbersome but satisfies the requirements of an invertible function $F$ just fine as long as it is possible to get from the edge to the pull-back space and then back again. Finally, given that we are dealing with a 2d triangulation in 3d, one will often have a mapping from, say, the 2d unit square or unit disk to the domain in 3d space, and the edge in question may simply be the mapped edge of the unit domain in 2d space. In this case, chartdim is 2.

    +

    in such a way that the line $[0,1]\times \{0\}\times \{0\}$ happens to be mapped onto the edge in question. Here, chartdim is 3. This may seem cumbersome but satisfies the requirements of an invertible function $F$ just fine as long as it is possible to get from the edge to the pull-back space and then back again. Finally, given that we are dealing with a 2d triangulation in 3d, one will often have a mapping from, say, the 2d unit square or unit disk to the domain in 3d space, and the edge in question may simply be the mapped edge of the unit domain in 2d space. In this case, chartdim is 2.

    Definition at line 902 of file manifold.h.

    Member Typedef Documentation

    @@ -589,7 +589,7 @@
    -

    Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function $F$ that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size $\text{spacedim}\times\text{chartdim}$.

    +

    Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function $F$ that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size $\text{spacedim}\times\text{chartdim}$.

    This function is used in the computations required by the get_tangent_vector() function. Since not all users of the Manifold class interface will require calling that function, the current function is implemented but will trigger an exception whenever called. This allows derived classes to avoid implementing the push_forward_gradient function if this functionality is not needed in the user program.

    Refer to the general documentation of this class for more information.

    @@ -632,24 +632,24 @@
    -

    Return a vector that, at $\mathbf x_1$, is tangential to the geodesic that connects two points $\mathbf x_1,\mathbf x_2$. See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.

    -

    For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are $\xi_1=F^{-1}(\mathbf x_1), \xi_2=F^{-1}(\mathbf x_2)$, then the geodesic in preimage (the chartdim-dimensional Euclidean) space is

    -\begin{align*}
+<p>Return a vector that, at <picture><source srcset=$\mathbf x_1$, is tangential to the geodesic that connects two points $\mathbf x_1,\mathbf x_2$. See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.

    +

    For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are $\xi_1=F^{-1}(\mathbf x_1), \xi_2=F^{-1}(\mathbf x_2)$, then the geodesic in preimage (the chartdim-dimensional Euclidean) space is

    +\begin{align*}
   \zeta(t) &= \xi_1 +  t (\xi_2-\xi_1)
  \\          &= F^{-1}(\mathbf x_1) + t\left[F^{-1}(\mathbf x_2)
                                             -F^{-1}(\mathbf x_1)\right]
-\end{align*} +\end{align*}" src="form_1440.png"/>

    In image space, i.e., in the space in which we operate, this leads to the curve

    -\begin{align*}
+<picture><source srcset=\begin{align*}
   \mathbf s(t) &= F(\zeta(t))
  \\          &= F(\xi_1 +  t (\xi_2-\xi_1))
  \\          &= F\left(F^{-1}(\mathbf x_1) + t\left[F^{-1}(\mathbf x_2)
                                     -F^{-1}(\mathbf x_1)\right]\right).
-\end{align*} +\end{align*}" src="form_1441.png"/>

    -

    What the current function is supposed to return is $\mathbf s'(0)$. By the chain rule, this is equal to

    -\begin{align*}
+<p> What the current function is supposed to return is <picture><source srcset=$\mathbf s'(0)$. By the chain rule, this is equal to

    +\begin{align*}
   \mathbf s'(0) &=
     \frac{d}{dt}\left. F\left(F^{-1}(\mathbf x_1)
                        + t\left[F^{-1}(\mathbf x_2)
@@ -658,11 +658,11 @@
 \\ &= \nabla_\xi F\left(F^{-1}(\mathbf x_1)\right)
                    \left[F^{-1}(\mathbf x_2)
                                 -F^{-1}(\mathbf x_1)\right].
-\end{align*} +\end{align*}" src="form_1442.png"/>

    This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.

    -

    Thus, the computation of tangent vectors also requires the implementation of derivatives $\nabla_\xi F(\xi)$ of the push-forward mapping. Here, $F^{-1}(\mathbf x_2)-F^{-1}(\mathbf x_1)$ is a chartdim-dimensional vector, and $\nabla_\xi F\left(F^{-1}(\mathbf
-x_1)\right) = \nabla_\xi F\left(\xi_1\right)$ is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.

    +

    Thus, the computation of tangent vectors also requires the implementation of derivatives $\nabla_\xi F(\xi)$ of the push-forward mapping. Here, $F^{-1}(\mathbf x_2)-F^{-1}(\mathbf x_1)$ is a chartdim-dimensional vector, and $\nabla_\xi F\left(F^{-1}(\mathbf
+x_1)\right) = \nabla_\xi F\left(\xi_1\right)$ is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChunkSparseMatrix.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChunkSparseMatrix.html 2023-08-09 23:38:38.242475836 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChunkSparseMatrix.html 2023-08-09 23:38:38.234475776 +0000 @@ -1071,7 +1071,7 @@
    x1The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
    -

    Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, $A = \frac 12(A+A^T)$.

    +

    Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, $A = \frac 12(A+A^T)$.

    This operation assumes that the underlying sparsity pattern represents a symmetric object. If this is not the case, then the result of this operation will not be a symmetric matrix, since it only explicitly symmetrizes by looping over the lower left triangular part for efficiency reasons; if there are entries in the upper right triangle, then these elements are missed in the symmetrization. Symmetrization of the sparsity pattern can be obtain by ChunkSparsityPattern::symmetrize().

    @@ -1480,7 +1480,7 @@
    -

    Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e. $\left(v,Mv\right)$. This is useful, e.g. in the finite element context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

    +

    Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e. $\left(v,Mv\right)$. This is useful, e.g. in the finite element context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

    Obviously, the matrix needs to be quadratic for this operation, and for the result to actually be a norm it also needs to be either real symmetric or complex hermitian.

    The underlying template types of both this matrix and the given vector should either both be real or complex-valued, but not mixed, for this function to make sense.

    @@ -1513,7 +1513,7 @@
    -

    Compute the matrix scalar product $\left(u,Mv\right)$.

    +

    Compute the matrix scalar product $\left(u,Mv\right)$.

    @@ -1570,8 +1570,8 @@
    -

    Return the l1-norm of the matrix, that is $|M|_1=max_{all columns
-j}\sum_{all rows i} |M_ij|$, (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. $|Mv|_1\leq |M|_1 |v|_1$. (cf. Haemmerlin-Hoffmann : Numerische Mathematik)

    +

    Return the l1-norm of the matrix, that is $|M|_1=max_{all columns
+j}\sum_{all rows i} |M_ij|$, (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. $|Mv|_1\leq |M|_1 |v|_1$. (cf. Haemmerlin-Hoffmann : Numerische Mathematik)

    @@ -1591,8 +1591,8 @@
    -

    Return the linfty-norm of the matrix, that is $|M|_infty=max_{all rows
-i}\sum_{all columns j} |M_ij|$, (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. $|Mv|_infty \leq |M|_infty |v|_infty$. (cf. Haemmerlin-Hoffmann : Numerische Mathematik)

    +

    Return the linfty-norm of the matrix, that is $|M|_infty=max_{all rows
+i}\sum_{all columns j} |M_ij|$, (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. $|Mv|_infty \leq |M|_infty |v|_infty$. (cf. Haemmerlin-Hoffmann : Numerische Mathematik)

    @@ -2418,7 +2418,7 @@
    -

    Return the location of entry $(i,j)$ within the val array.

    +

    Return the location of entry $(i,j)$ within the val array.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChunkSparsityPattern.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChunkSparsityPattern.html 2023-08-09 23:38:38.290476194 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classChunkSparsityPattern.html 2023-08-09 23:38:38.290476194 +0000 @@ -1233,7 +1233,7 @@
    -

    Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of $|i-j|$ for which the index pair $(i,j)$ represents a nonzero entry of the matrix. Consequently, the maximum bandwidth a $n\times m$ matrix can have is $\max\{n-1,m-1\}$.

    +

    Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of $|i-j|$ for which the index pair $(i,j)$ represents a nonzero entry of the matrix. Consequently, the maximum bandwidth a $n\times m$ matrix can have is $\max\{n-1,m-1\}$.

    Definition at line 520 of file chunk_sparsity_pattern.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classComponentMask.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classComponentMask.html 2023-08-09 23:38:38.310476344 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classComponentMask.html 2023-08-09 23:38:38.310476344 +0000 @@ -137,7 +137,7 @@ std::ostream & operator<< (std::ostream &out, const ComponentMask &mask) &#href_anchor"details" id="details">

    Detailed Description

    This class represents a mask that can be used to select individual vector components of a finite element (see also this glossary entry). It will typically have as many elements as the finite element has vector components, and one can use operator[] to query whether a particular component has been selected.

    -
    Note
    A "mask" represents a data structure with true and false entries that is generally used to enable or disable an operation for a particular vector component. By this definition, disabled vector components still exist – they are simply not touched. As a consequence, when you apply a component mask for interpolating boundary values (to choose just one example) of a problem with $C$ vector components, the input argument that describes the boundary values will still have to provide $C$ components even if the mask says that we only want to interpolate a subset of these components onto the finite element space. In other words, a component mask does not represent a reduction operation; it represents a selection.
    +
    Note
    A "mask" represents a data structure with true and false entries that is generally used to enable or disable an operation for a particular vector component. By this definition, disabled vector components still exist – they are simply not touched. As a consequence, when you apply a component mask for interpolating boundary values (to choose just one example) of a problem with $C$ vector components, the input argument that describes the boundary values will still have to provide $C$ components even if the mask says that we only want to interpolate a subset of these components onto the finite element space. In other words, a component mask does not represent a reduction operation; it represents a selection.

    Objects of this kind are used in many places where one wants to restrict operations to a certain subset of components, e.g. in DoFTools::make_zero_boundary_values() or VectorTools::interpolate_boundary_values(). These objects can either be created by hand, or, simpler, by asking the finite element to generate a component mask from certain selected components using code such as this where we create a mask that only denotes the velocity components of a Stokes element (see Handling vector valued problems):

    // Q2 element for the velocities, Q1 element for the pressure
    FESystem<dim> stokes_fe (FE_Q<dim>(2), dim,
    FE_Q<dim>(1), 1);
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCompositionManifold.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCompositionManifold.html 2023-08-09 23:38:38.350476642 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCompositionManifold.html 2023-08-09 23:38:38.350476642 +0000 @@ -631,24 +631,24 @@
    -

    Return a vector that, at $\mathbf x_1$, is tangential to the geodesic that connects two points $\mathbf x_1,\mathbf x_2$. See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.

    -

    For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are $\xi_1=F^{-1}(\mathbf x_1), \xi_2=F^{-1}(\mathbf x_2)$, then the geodesic in preimage (the chartdim-dimensional Euclidean) space is

    -\begin{align*}
+<p>Return a vector that, at <picture><source srcset=$\mathbf x_1$, is tangential to the geodesic that connects two points $\mathbf x_1,\mathbf x_2$. See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.

    +

    For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are $\xi_1=F^{-1}(\mathbf x_1), \xi_2=F^{-1}(\mathbf x_2)$, then the geodesic in preimage (the chartdim-dimensional Euclidean) space is

    +\begin{align*}
   \zeta(t) &= \xi_1 +  t (\xi_2-\xi_1)
  \\          &= F^{-1}(\mathbf x_1) + t\left[F^{-1}(\mathbf x_2)
                                             -F^{-1}(\mathbf x_1)\right]
-\end{align*} +\end{align*}" src="form_1440.png"/>

    In image space, i.e., in the space in which we operate, this leads to the curve

    -\begin{align*}
+<picture><source srcset=\begin{align*}
   \mathbf s(t) &= F(\zeta(t))
  \\          &= F(\xi_1 +  t (\xi_2-\xi_1))
  \\          &= F\left(F^{-1}(\mathbf x_1) + t\left[F^{-1}(\mathbf x_2)
                                     -F^{-1}(\mathbf x_1)\right]\right).
-\end{align*} +\end{align*}" src="form_1441.png"/>

    -

    What the current function is supposed to return is $\mathbf s'(0)$. By the chain rule, this is equal to

    -\begin{align*}
+<p> What the current function is supposed to return is <picture><source srcset=$\mathbf s'(0)$. By the chain rule, this is equal to

    +\begin{align*}
   \mathbf s'(0) &=
     \frac{d}{dt}\left. F\left(F^{-1}(\mathbf x_1)
                        + t\left[F^{-1}(\mathbf x_2)
@@ -657,11 +657,11 @@
 \\ &= \nabla_\xi F\left(F^{-1}(\mathbf x_1)\right)
                    \left[F^{-1}(\mathbf x_2)
                                 -F^{-1}(\mathbf x_1)\right].
-\end{align*} +\end{align*}" src="form_1442.png"/>

    This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.

    -

    Thus, the computation of tangent vectors also requires the implementation of derivatives $\nabla_\xi F(\xi)$ of the push-forward mapping. Here, $F^{-1}(\mathbf x_2)-F^{-1}(\mathbf x_1)$ is a chartdim-dimensional vector, and $\nabla_\xi F\left(F^{-1}(\mathbf
-x_1)\right) = \nabla_\xi F\left(\xi_1\right)$ is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.

    +

    Thus, the computation of tangent vectors also requires the implementation of derivatives $\nabla_\xi F(\xi)$ of the push-forward mapping. Here, $F^{-1}(\mathbf x_2)-F^{-1}(\mathbf x_1)$ is a chartdim-dimensional vector, and $\nabla_\xi F\left(F^{-1}(\mathbf
+x_1)\right) = \nabla_\xi F\left(\xi_1\right)$ is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classConvergenceTable.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classConvergenceTable.html 2023-08-09 23:38:38.378476852 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classConvergenceTable.html 2023-08-09 23:38:38.382476881 +0000 @@ -372,14 +372,14 @@
    x1The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.

    Evaluate the convergence rates of the data column data_column_key due to the RateMode in relation to the reference column reference_column_key. Be sure that the value types of the table entries of the data column and the reference data column is a number, i.e. double, float, (unsigned) int, and so on.

    -

    As this class has no information on the space dimension upon which the reference column vs. the value column is based upon, it needs to be passed as last argument to this method. The default dimension for the reference column is 2, which is appropriate for the number of cells in 2d. If you work in 3d, set the number to 3. If the reference column is $1/h$, remember to set the dimension to 1 also when working in 3d to get correct rates.

    +

    As this class has no information on the space dimension upon which the reference column vs. the value column is based upon, it needs to be passed as last argument to this method. The default dimension for the reference column is 2, which is appropriate for the number of cells in 2d. If you work in 3d, set the number to 3. If the reference column is $1/h$, remember to set the dimension to 1 also when working in 3d to get correct rates.

    The new rate column and the data column will be merged to a supercolumn. The tex caption of the supercolumn will be (by default) the same as the one of the data column. This may be changed by using the set_tex_supercaption (...) function of the base class TableHandler.

    This method behaves in the following way:

    -

    If RateMode is reduction_rate, then the computed output is $
-\frac{e_{n-1}/k_{n-1}}{e_n/k_n}, $ where $k$ is the reference column (no dimension dependence!).

    -

    If RateMode is reduction_rate_log2, then the computed output is $ dim
-\frac{\log |e_{n-1}/e_{n}|}{\log |k_n/k_{n-1}|} $.

    -

    This is useful, for example, if we use as reference key the number of degrees of freedom or better, the number of cells. Assuming that the error is proportional to $ C (1/\sqrt{k})^r $ in 2d, then this method will produce the rate $r$ as a result. For general dimension, as described by the last parameter of this function, the formula needs to be $ C (1/\sqrt[dim]{k})^r $.

    +

    If RateMode is reduction_rate, then the computed output is $
+\frac{e_{n-1}/k_{n-1}}{e_n/k_n}, $ where $k$ is the reference column (no dimension dependence!).

    +

    If RateMode is reduction_rate_log2, then the computed output is $ dim
+\frac{\log |e_{n-1}/e_{n}|}{\log |k_n/k_{n-1}|} $.

    +

    This is useful, for example, if we use as reference key the number of degrees of freedom or better, the number of cells. Assuming that the error is proportional to $ C (1/\sqrt{k})^r $ in 2d, then this method will produce the rate $r$ as a result. For general dimension, as described by the last parameter of this function, the formula needs to be $ C (1/\sqrt[dim]{k})^r $.

    Note
    Since this function adds columns to the table after several rows have already been filled, it switches off the auto fill mode of the TableHandler base class. If you intend to add further data with auto fill, you will have to re-enable it after calling this function.

    Definition at line 23 of file convergence_table.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCylindricalManifold.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCylindricalManifold.html 2023-08-09 23:38:38.422477180 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classCylindricalManifold.html 2023-08-09 23:38:38.422477180 +0000 @@ -423,7 +423,7 @@
    -

    Compute the cylindrical coordinates $(r, \phi, \lambda)$ for the given space point where $r$ denotes the distance from the axis, $\phi$ the angle between the given point and the computed normal direction, and $\lambda$ the axial position.

    +

    Compute the cylindrical coordinates $(r, \phi, \lambda)$ for the given space point where $r$ denotes the distance from the axis, $\phi$ the angle between the given point and the computed normal direction, and $\lambda$ the axial position.

    Implements ChartManifold< dim, spacedim, chartdim >.

    @@ -455,7 +455,7 @@
    -

    Compute the Cartesian coordinates for a chart point given in cylindrical coordinates $(r, \phi, \lambda)$, where $r$ denotes the distance from the axis, $\phi$ the angle between the given point and the computed normal direction, and $\lambda$ the axial position.

    +

    Compute the Cartesian coordinates for a chart point given in cylindrical coordinates $(r, \phi, \lambda)$, where $r$ denotes the distance from the axis, $\phi$ the angle between the given point and the computed normal direction, and $\lambda$ the axial position.

    Definition at line 1144 of file manifold_lib.cc.

    @@ -485,7 +485,7 @@
    -

    Compute the derivatives of the mapping from cylindrical coordinates $(r, \phi, \lambda)$ to cartesian coordinates where $r$ denotes the distance from the axis, $\phi$ the angle between the given point and the computed normal direction, and $\lambda$ the axial position.

    +

    Compute the derivatives of the mapping from cylindrical coordinates $(r, \phi, \lambda)$ to cartesian coordinates where $r$ denotes the distance from the axis, $\phi$ the angle between the given point and the computed normal direction, and $\lambda$ the axial position.

    Definition at line 1164 of file manifold_lib.cc.

    @@ -682,7 +682,7 @@
    -

    Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function $F$ that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size $\text{spacedim}\times\text{chartdim}$.

    +

    Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function $F$ that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size $\text{spacedim}\times\text{chartdim}$.

    This function is used in the computations required by the get_tangent_vector() function. Since not all users of the Manifold class interface will require calling that function, the current function is implemented but will trigger an exception whenever called. This allows derived classes to avoid implementing the push_forward_gradient function if this functionality is not needed in the user program.

    Refer to the general documentation of this class for more information.

    @@ -725,24 +725,24 @@
    -

    Return a vector that, at $\mathbf x_1$, is tangential to the geodesic that connects two points $\mathbf x_1,\mathbf x_2$. See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.

    -

    For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are $\xi_1=F^{-1}(\mathbf x_1), \xi_2=F^{-1}(\mathbf x_2)$, then the geodesic in preimage (the chartdim-dimensional Euclidean) space is

    -\begin{align*}
+<p>Return a vector that, at <picture><source srcset=$\mathbf x_1$, is tangential to the geodesic that connects two points $\mathbf x_1,\mathbf x_2$. See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.

    +

    For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are $\xi_1=F^{-1}(\mathbf x_1), \xi_2=F^{-1}(\mathbf x_2)$, then the geodesic in preimage (the chartdim-dimensional Euclidean) space is

    +\begin{align*}
   \zeta(t) &= \xi_1 +  t (\xi_2-\xi_1)
  \\          &= F^{-1}(\mathbf x_1) + t\left[F^{-1}(\mathbf x_2)
                                             -F^{-1}(\mathbf x_1)\right]
-\end{align*} +\end{align*}" src="form_1440.png"/>

    In image space, i.e., in the space in which we operate, this leads to the curve

    -\begin{align*}
+<picture><source srcset=\begin{align*}
   \mathbf s(t) &= F(\zeta(t))
  \\          &= F(\xi_1 +  t (\xi_2-\xi_1))
  \\          &= F\left(F^{-1}(\mathbf x_1) + t\left[F^{-1}(\mathbf x_2)
                                     -F^{-1}(\mathbf x_1)\right]\right).
-\end{align*} +\end{align*}" src="form_1441.png"/>

    -

    What the current function is supposed to return is $\mathbf s'(0)$. By the chain rule, this is equal to

    -\begin{align*}
+<p> What the current function is supposed to return is <picture><source srcset=$\mathbf s'(0)$. By the chain rule, this is equal to

    +\begin{align*}
   \mathbf s'(0) &=
     \frac{d}{dt}\left. F\left(F^{-1}(\mathbf x_1)
                        + t\left[F^{-1}(\mathbf x_2)
@@ -751,11 +751,11 @@
 \\ &= \nabla_\xi F\left(F^{-1}(\mathbf x_1)\right)
                    \left[F^{-1}(\mathbf x_2)
                                 -F^{-1}(\mathbf x_1)\right].
-\end{align*} +\end{align*}" src="form_1442.png"/>

    This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.

    -

    Thus, the computation of tangent vectors also requires the implementation of derivatives $\nabla_\xi F(\xi)$ of the push-forward mapping. Here, $F^{-1}(\mathbf x_2)-F^{-1}(\mathbf x_1)$ is a chartdim-dimensional vector, and $\nabla_\xi F\left(F^{-1}(\mathbf
-x_1)\right) = \nabla_\xi F\left(\xi_1\right)$ is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.

    +

    Thus, the computation of tangent vectors also requires the implementation of derivatives $\nabla_\xi F(\xi)$ of the push-forward mapping. Here, $F^{-1}(\mathbf x_2)-F^{-1}(\mathbf x_1)$ is a chartdim-dimensional vector, and $\nabla_\xi F\left(F^{-1}(\mathbf
+x_1)\right) = \nabla_\xi F\left(\xi_1\right)$ is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessor.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessor.html 2023-08-09 23:38:38.450477389 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessor.html 2023-08-09 23:38:38.450477389 +0000 @@ -182,7 +182,7 @@

    As a consequence, DataOut is forced to take things apart into their real and imaginary parts, and both are output as separate quantities. This is the case for data that is written directly to a file by DataOut, but it is also the case for data that is first routed through DataPostprocessor objects (or objects of their derived classes): All these objects see is a collection of real values, even if the underlying solution vector was complex-valued.

    All of this has two implications:

    • If a solution vector is complex-valued, then this results in at least two input components at each evaluation point. As a consequence, the DataPostprocessor::evaluate_scalar_field() function is never called, even if the underlying finite element had only a single solution component. Instead, DataOut will always call DataPostprocessor::evaluate_vector_field().
    • -
    • Implementations of the DataPostprocessor::evaluate_vector_field() in derived classes must understand how the solution values are arranged in the DataPostprocessorInputs::Vector objects they receive as input. The rule here is: If the finite element has $N$ vector components (including the case $N=1$, i.e., a scalar element), then the inputs for complex-valued solution vectors will have $2N$ components. These first contain the values (or gradients, or Hessians) of the real parts of all solution components, and then the values (or gradients, or Hessians) of the imaginary parts of all solution components.
    • +
    • Implementations of the DataPostprocessor::evaluate_vector_field() in derived classes must understand how the solution values are arranged in the DataPostprocessorInputs::Vector objects they receive as input. The rule here is: If the finite element has $N$ vector components (including the case $N=1$, i.e., a scalar element), then the inputs for complex-valued solution vectors will have $2N$ components. These first contain the values (or gradients, or Hessians) of the real parts of all solution components, and then the values (or gradients, or Hessians) of the imaginary parts of all solution components.

    step-58 provides an example of how this class (or, rather, the derived DataPostprocessorScalar class) is used in a complex-valued situation.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessorTensor.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessorTensor.html 2023-08-09 23:38:38.478477598 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessorTensor.html 2023-08-09 23:38:38.478477598 +0000 @@ -254,7 +254,7 @@

    These pictures show an ellipse representing the gradient tensor at, on average, every tenth mesh point. You may want to read through the documentation of the VisIt visualization program (see https://wci.llnl.gov/simulation/computer-codes/visit/) for an interpretation of how exactly tensors are visualizated.

    -

    In elasticity, one is often interested not in the gradient of the displacement, but in the "strain", i.e., the symmetrized version of the gradient $\varepsilon=\frac 12 (\nabla u + \nabla u^T)$. This is easily facilitated with the following minor modification:

    template <int dim>
    +

    In elasticity, one is often interested not in the gradient of the displacement, but in the "strain", i.e., the symmetrized version of the gradient $\varepsilon=\frac 12 (\nabla u + \nabla u^T)$. This is easily facilitated with the following minor modification:

    template <int dim>
    class StrainPostprocessor : public DataPostprocessorTensor<dim>
    {
    public:
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessorVector.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessorVector.html 2023-08-09 23:38:38.510477837 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDataPostprocessorVector.html 2023-08-09 23:38:38.510477837 +0000 @@ -245,7 +245,7 @@

    In the second image, the background color corresponds to the magnitude of the gradient vector and the vector glyphs to the gradient itself. It may be surprising at first to see that from each vertex, multiple vectors originate, going in different directions. But that is because the solution is only continuous: in general, the gradient is discontinuous across edges, and so the multiple vectors originating from each vertex simply represent the differing gradients of the solution at each adjacent cell.

    -

    The output above – namely, the gradient $\nabla u$ of the solution – corresponds to the temperature gradient if one interpreted step-6 as solving a steady-state heat transfer problem. It is very small in the central part of the domain because in step-6 we are solving an equation that has a coefficient $a(\mathbf x)$ that is large in the central part and small on the outside. This can be thought as a material that conducts heat well, and consequently the temperature gradient is small. On the other hand, the "heat flux" corresponds to the quantity $a(\mathbf x) \nabla u(\mathbf x)$. For the solution of that equation, the flux should be continuous across the interface. This is easily verified by the following modification of the postprocessor:

    template <int dim>
    +

    The output above – namely, the gradient $\nabla u$ of the solution – corresponds to the temperature gradient if one interpreted step-6 as solving a steady-state heat transfer problem. It is very small in the central part of the domain because in step-6 we are solving an equation that has a coefficient $a(\mathbf x)$ that is large in the central part and small on the outside. This can be thought as a material that conducts heat well, and consequently the temperature gradient is small. On the other hand, the "heat flux" corresponds to the quantity $a(\mathbf x) \nabla u(\mathbf x)$. For the solution of that equation, the flux should be continuous across the interface. This is easily verified by the following modification of the postprocessor:

    template <int dim>
    class HeatFluxPostprocessor : public DataPostprocessorVector<dim>
    {
    public:
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1SecondDerivative.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1SecondDerivative.html 2023-08-09 23:38:38.526477957 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1SecondDerivative.html 2023-08-09 23:38:38.530477987 +0000 @@ -244,7 +244,7 @@
    x1The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
    -

    Return the norm of the derivative object. Here, for the (symmetric) tensor of second derivatives, we choose the absolute value of the largest eigenvalue, which is the matrix norm associated to the $l_2$ norm of vectors. It is also the largest value of the curvature of the solution.

    +

    Return the norm of the derivative object. Here, for the (symmetric) tensor of second derivatives, we choose the absolute value of the largest eigenvalue, which is the matrix norm associated to the $l_2$ norm of vectors. It is also the largest value of the curvature of the solution.

    Definition at line 492 of file derivative_approximation.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1ThirdDerivative.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1ThirdDerivative.html 2023-08-09 23:38:38.546478106 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeApproximation_1_1internal_1_1ThirdDerivative.html 2023-08-09 23:38:38.546478106 +0000 @@ -239,7 +239,7 @@
    -

    Return the norm of the derivative object. Here, for the (symmetric) tensor of second derivatives, we choose the absolute value of the largest eigenvalue, which is the matrix norm associated to the $l_2$ norm of vectors. It is also the largest value of the curvature of the solution.

    +

    Return the norm of the derivative object. Here, for the (symmetric) tensor of second derivatives, we choose the absolute value of the largest eigenvalue, which is the matrix norm associated to the $l_2$ norm of vectors. It is also the largest value of the curvature of the solution.

    Definition at line 631 of file derivative_approximation.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeForm.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeForm.html 2023-08-09 23:38:38.574478315 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDerivativeForm.html 2023-08-09 23:38:38.574478315 +0000 @@ -163,24 +163,24 @@ DerivativeForm< 1, spacedim, dim, Number >&#href_anchor"memTemplItemRight" valign="bottom">transpose (const DerivativeForm< 1, dim, spacedim, Number > &DF) &#href_anchor"details" id="details">

    Detailed Description

    template<int order, int dim, int spacedim, typename Number = double>
    -class DerivativeForm< order, dim, spacedim, Number >

    This class represents the (tangential) derivatives of a function $ \mathbf F:
-{\mathbb R}^{\text{dim}} \rightarrow {\mathbb R}^{\text{spacedim}}$. Such functions are always used to map the reference dim-dimensional cell into spacedim-dimensional space. For such objects, the first derivative of the function is a linear map from ${\mathbb R}^{\text{dim}}$ to ${\mathbb
-R}^{\text{spacedim}}$, i.e., it can be represented as a matrix in ${\mathbb
-R}^{\text{spacedim}\times \text{dim}}$. This makes sense since one would represent the first derivative, $\nabla \mathbf F(\mathbf x)$ with $\mathbf
+class DerivativeForm< order, dim, spacedim, Number ></div><p>This class represents the (tangential) derivatives of a function <picture><source srcset=$ \mathbf F:
+{\mathbb R}^{\text{dim}} \rightarrow {\mathbb R}^{\text{spacedim}}$. Such functions are always used to map the reference dim-dimensional cell into spacedim-dimensional space. For such objects, the first derivative of the function is a linear map from ${\mathbb R}^{\text{dim}}$ to ${\mathbb
+R}^{\text{spacedim}}$, i.e., it can be represented as a matrix in ${\mathbb
+R}^{\text{spacedim}\times \text{dim}}$. This makes sense since one would represent the first derivative, $\nabla \mathbf F(\mathbf x)$ with $\mathbf
 x\in
-{\mathbb R}^{\text{dim}}$, in such a way that the directional derivative in direction $\mathbf d\in {\mathbb R}^{\text{dim}}$ so that

    -\begin{align*}
+{\mathbb R}^{\text{dim}}$, in such a way that the directional derivative in direction $\mathbf d\in {\mathbb R}^{\text{dim}}$ so that

    +\begin{align*}
   \nabla \mathbf F(\mathbf x) \mathbf d
   = \lim_{\varepsilon\rightarrow 0}
     \frac{\mathbf F(\mathbf x + \varepsilon \mathbf d) - \mathbf F(\mathbf
 x)}{\varepsilon},
-\end{align*} +\end{align*}" src="form_387.png"/>

    -

    i.e., one needs to be able to multiply the matrix $\nabla \mathbf F(\mathbf
-x)$ by a vector in ${\mathbb R}^{\text{dim}}$, and the result is a difference of function values, which are in ${\mathbb R}^{\text{spacedim}}$. Consequently, the matrix must be of size $\text{spacedim}\times\text{dim}$.

    -

    Similarly, the second derivative is a bilinear map from ${\mathbb
-R}^{\text{dim}} \times  {\mathbb R}^{\text{dim}}$ to ${\mathbb
-R}^{\text{spacedim}}$, which one can think of a rank-3 object of size $\text{spacedim}\times\text{dim}\times\text{dim}$.

    +

    i.e., one needs to be able to multiply the matrix $\nabla \mathbf F(\mathbf
+x)$ by a vector in ${\mathbb R}^{\text{dim}}$, and the result is a difference of function values, which are in ${\mathbb R}^{\text{spacedim}}$. Consequently, the matrix must be of size $\text{spacedim}\times\text{dim}$.

    +

    Similarly, the second derivative is a bilinear map from ${\mathbb
+R}^{\text{dim}} \times  {\mathbb R}^{\text{dim}}$ to ${\mathbb
+R}^{\text{spacedim}}$, which one can think of a rank-3 object of size $\text{spacedim}\times\text{dim}\times\text{dim}$.

    In deal.II we represent these derivatives using objects of type DerivativeForm<1,dim,spacedim,Number>, DerivativeForm<2,dim,spacedim,Number> and so on.

    Definition at line 58 of file derivative_form.h.

    @@ -392,7 +392,7 @@
    -

    Converts a DerivativeForm <order, dim, dim, Number> to Tensor<order+1, dim, Number>. In particular, if order == 1 and the derivative is the Jacobian of $\mathbf F(\mathbf x)$, then Tensor[i] = $\nabla F_i(\mathbf x)$.

    +

    Converts a DerivativeForm <order, dim, dim, Number> to Tensor<order+1, dim, Number>. In particular, if order == 1 and the derivative is the Jacobian of $\mathbf F(\mathbf x)$, then Tensor[i] = $\nabla F_i(\mathbf x)$.

    @@ -473,7 +473,7 @@
    -

    Compute the volume element associated with the jacobian of the transformation $\mathbf F$. That is to say if $DF$ is square, it computes $\det(DF)$, in case DF is not square returns $\sqrt{\det(DF^T \,DF)}$.

    +

    Compute the volume element associated with the jacobian of the transformation $\mathbf F$. That is to say if $DF$ is square, it computes $\det(DF)$, in case DF is not square returns $\sqrt{\det(DF^T \,DF)}$.

    @@ -493,7 +493,7 @@
    -

    Assuming that the current object stores the Jacobian of a mapping $\mathbf F$, then the current function computes the covariant form of the derivative, namely $(\nabla \mathbf F) {\mathbf G}^{-1}$, where $\mathbf G = (\nabla \mathbf F)^{T}(\nabla \mathbf F)$. If $\nabla \mathbf
+<p>Assuming that the current object stores the Jacobian of a mapping <picture><source srcset=$\mathbf F$, then the current function computes the covariant form of the derivative, namely $(\nabla \mathbf F) {\mathbf G}^{-1}$, where $\mathbf G = (\nabla \mathbf F)^{T}(\nabla \mathbf F)$. If $\nabla \mathbf
 F$ is a square matrix (i.e., $\mathbf F:
 {\mathbb R}^n \mapsto {\mathbb R}^n$), then this function simplifies to computing $\nabla {\mathbf F}^{-T}$.

    @@ -589,21 +589,21 @@
    -

    One of the uses of DerivativeForm is to apply it as a linear transformation. This function returns $\nabla \mathbf F(\mathbf x) \Delta \mathbf x$, which approximates the change in $\mathbf F(\mathbf x)$ when $\mathbf x$ is changed by the amount $\Delta \mathbf x$

    -\[
+<p>One of the uses of <a class=DerivativeForm is to apply it as a linear transformation. This function returns $\nabla \mathbf F(\mathbf x) \Delta \mathbf x$, which approximates the change in $\mathbf F(\mathbf x)$ when $\mathbf x$ is changed by the amount $\Delta \mathbf x$

    +\[
   \nabla \mathbf F(\mathbf x) \; \Delta \mathbf x
   \approx
   \mathbf F(\mathbf x + \Delta \mathbf x) - \mathbf F(\mathbf x).
-\] +\]" src="form_396.png"/>

    The transformation corresponds to

    -\[
+<picture><source srcset=\[
   [\text{result}]_{i_1,\dots,i_k} = i\sum_{j}
   \left[\nabla \mathbf F(\mathbf x)\right]_{i_1,\dots,i_k, j}
   \Delta x_j
-\] +\]" src="form_397.png"/>

    -

    in index notation and corresponds to $[\Delta \mathbf x] [\nabla \mathbf F(\mathbf x)]^T$ in matrix notation.

    +

    in index notation and corresponds to $[\Delta \mathbf x] [\nabla \mathbf F(\mathbf x)]^T$ in matrix notation.

    Definition at line 454 of file derivative_form.h.

    @@ -642,7 +642,7 @@
    -

    Similar to the previous apply_transformation(). Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to $\mathrm{D\_X} \, \mathrm{grad\_F}^T$ in matrix notation.

    +

    Similar to the previous apply_transformation(). Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to $\mathrm{D\_X} \, \mathrm{grad\_F}^T$ in matrix notation.

    Definition at line 479 of file derivative_form.h.

    @@ -681,7 +681,7 @@
    -

    Similar to the previous apply_transformation(), specialized for the case dim == spacedim where we can return a rank-2 tensor instead of the more general DerivativeForm. Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to $\mathrm{D\_X} \, \mathrm{grad\_F}^T$ in matrix notation.

    +

    Similar to the previous apply_transformation(), specialized for the case dim == spacedim where we can return a rank-2 tensor instead of the more general DerivativeForm. Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to $\mathrm{D\_X} \, \mathrm{grad\_F}^T$ in matrix notation.

    Definition at line 505 of file derivative_form.h.

    @@ -759,7 +759,7 @@
    -

    Similar to the previous apply_transformation(). In matrix notation, it computes $DF2 \, DF1^{T}$. Moreover, the result of this operation $\mathbf A$ can be interpreted as a metric tensor in ${\mathbb R}^\text{spacedim}$ which corresponds to the Euclidean metric tensor in ${\mathbb R}^\text{dim}$. For every pair of vectors $\mathbf u, \mathbf v \in {\mathbb R}^\text{spacedim}$, we have:

    +

    Similar to the previous apply_transformation(). In matrix notation, it computes $DF2 \, DF1^{T}$. Moreover, the result of this operation $\mathbf A$ can be interpreted as a metric tensor in ${\mathbb R}^\text{spacedim}$ which corresponds to the Euclidean metric tensor in ${\mathbb R}^\text{dim}$. For every pair of vectors $\mathbf u, \mathbf v \in {\mathbb R}^\text{spacedim}$, we have:

    \[
   \mathbf u \cdot \mathbf A \mathbf v =
   \text{DF2}^{-1}(\mathbf u) \cdot \text{DF1}^{-1}(\mathbf v)
/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1CellLevelBase.html differs (HTML document, ASCII text, with very long lines)
--- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1CellLevelBase.html	2023-08-09 23:38:38.618478644 +0000
+++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1CellLevelBase.html	2023-08-09 23:38:38.618478644 +0000
@@ -295,7 +295,7 @@
 <p>The constructor for the class.</p>
 <dl class=

    Parameters
    - +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_dependent_variablesThe number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of outputs $\mathbf{f}$, i.e., the dimension of the image space.
    @@ -351,7 +351,7 @@
    -

    Register the complete set of independent variables $\mathbf{X}$ that represent the local degree of freedom values.

    +

    Register the complete set of independent variables $\mathbf{X}$ that represent the local degree of freedom values.

    Parameters
    @@ -394,7 +394,7 @@
    [in]dof_valuesA vector field associated with local degree of freedom values on the current finite element. These define the values of all independent variables. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and linearized around.
    -

    Register the complete set of independent variables $\mathbf{X}$ that represent the local degree of freedom values.

    +

    Register the complete set of independent variables $\mathbf{X}$ that represent the local degree of freedom values.

    Parameters
    @@ -419,7 +419,7 @@
    [in]valuesA global field from which the values of all independent variables will be extracted. This typically will be the solution vector around which point a residual vector is to be computed and around which linearization is to occur. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and linearized around.
    -

    Return the complete set of degree of freedom values as represented by auto-differentiable numbers. These are the independent variables $\mathbf{X}$ about which the solution is linearized.

    +

    Return the complete set of degree of freedom values as represented by auto-differentiable numbers. These are the independent variables $\mathbf{X}$ about which the solution is linearized.

    This function indicates to the AD library that implements the auto-differentiable number type that operations performed on these numbers are to be tracked so they are considered "sensitive" variables. This is, therefore, the set of variables with which one would then perform computations, and based on which one can then extract both the value of the function and its derivatives with the member functions below. The values of the components of the returned object are initialized to the values set with register_independent_variable().

    Returns
    An array of auto-differentiable type numbers representing the local degree of freedom values.
    Note
    For taped AD numbers, this operation is only valid in recording mode.
    @@ -445,7 +445,7 @@
    -

    Set the values for the independent variables $\mathbf{X}$, i.e., the linearization point.

    +

    Set the values for the independent variables $\mathbf{X}$, i.e., the linearization point.

    Parameters
    @@ -488,7 +488,7 @@
    [in]dof_valuesA vector field associated with local degree of freedom values on the current finite element. These define the values of all independent variables.
    -

    Set the values for the independent variables $\mathbf{X}$, i.e., the linearization point.

    +

    Set the values for the independent variables $\mathbf{X}$, i.e., the linearization point.

    Parameters
    @@ -525,7 +525,7 @@
    [in]valuesA vector field from which the values of all independent variables is to be extracted.
    -

    Compute the value of the residual vector field $\mathbf{r}(\mathbf{X})$.

    +

    Compute the value of the residual vector field $\mathbf{r}(\mathbf{X})$.

    Parameters
    @@ -564,9 +564,9 @@
    [out]residualA Vector object with the value for each component of the vector field evaluated at the point defined by the independent variable values.

    Compute the gradient (first derivative) of the residual vector field with respect to all independent variables, i.e.

    -\[
+<picture><source srcset=\[
   \frac{\partial\mathbf{r}(\mathbf{X})}{\partial\mathbf{X}}
-\] +\]" src="form_904.png"/>

    Parameters
    @@ -839,7 +839,7 @@

    In the rare case that the number of independent or dependent variables has changed, this can also reconfigured by passing in the appropriate arguments to the function.

    Parameters
    - +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_dependent_variablesThe number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of outputs $\mathbf{f}$, i.e., the dimension of the image space.
    [in]clear_registered_tapesA flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
    @@ -1605,7 +1605,7 @@
    -

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    +

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    Parameters
    @@ -1697,7 +1697,7 @@
    [in]indexThe index of the entry in the global list of dependent variables that this function belongs to.
    -

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed at these finite values.

    Definition at line 635 of file ad_helpers.h.

    @@ -1725,7 +1725,7 @@
    -

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed using these configured AD numbers. Note that only reverse-mode AD requires that the sensitive independent variables be stored.

    Definition at line 645 of file ad_helpers.h.

    @@ -1807,8 +1807,8 @@
    -

    The set of dependent variables $\mathbf{f}(\mathbf{X})$ of which the derivatives with respect to $\mathbf{X}$ will be computed.

    -

    The gradients and Hessians of these dependent variables will be computed at the values $\mathbf{X}$ set with the set_sensitivity_value() function.

    +

    The set of dependent variables $\mathbf{f}(\mathbf{X})$ of which the derivatives with respect to $\mathbf{X}$ will be computed.

    +

    The gradients and Hessians of these dependent variables will be computed at the values $\mathbf{X}$ set with the set_sensitivity_value() function.

    Note
    These are stored as an ad_type so that we can use them to compute function values and directional derivatives in the case that tapeless numbers are used

    Definition at line 749 of file ad_helpers.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1EnergyFunctional.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1EnergyFunctional.html 2023-08-09 23:38:38.662478972 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1EnergyFunctional.html 2023-08-09 23:38:38.662478972 +0000 @@ -430,11 +430,11 @@

    The constructor for the class.

    Parameters
    - +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\Psi(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\Psi(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    -
    Note
    There is only one dependent variable associated with the total energy attributed to the local finite element. That is to say, this class assumes that the (local) right hand side and matrix contribution is computed from the first and second derivatives of a scalar function $\Psi(\mathbf{X})$.
    +
    Note
    There is only one dependent variable associated with the total energy attributed to the local finite element. That is to say, this class assumes that the (local) right hand side and matrix contribution is computed from the first and second derivatives of a scalar function $\Psi(\mathbf{X})$.

    Definition at line 793 of file ad_helpers.cc.

    @@ -486,7 +486,7 @@
    -

    Register the definition of the total cell energy $\Psi(\mathbf{X})$.

    +

    Register the definition of the total cell energy $\Psi(\mathbf{X})$.

    Parameters
    @@ -515,11 +515,11 @@
    [in]energyA recorded function that defines the total cell energy. This represents the single dependent variable from which both the residual and its linearization are to be computed.

    Evaluation of the total scalar energy functional for a chosen set of degree of freedom values, i.e.

    -\[
+<picture><source srcset=\[
   \Psi(\mathbf{X}) \vert_{\mathbf{X}}
-\] +\]" src="form_906.png"/>

    -

    The values at the evaluation point $\mathbf{X}$ are obtained by calling CellLevelBase::set_dof_values().

    +

    The values at the evaluation point $\mathbf{X}$ are obtained by calling CellLevelBase::set_dof_values().

    Returns
    The value of the energy functional at the evaluation point corresponding to a chosen set of local degree of freedom values.

    Definition at line 814 of file ad_helpers.cc.

    @@ -551,14 +551,14 @@
    -

    Evaluation of the residual for a chosen set of degree of freedom values. Underlying this is the computation of the gradient (first derivative) of the scalar function $\Psi$ with respect to all independent variables, i.e.

    -\[
+<p>Evaluation of the residual for a chosen set of degree of freedom values. Underlying this is the computation of the gradient (first derivative) of the scalar function <picture><source srcset=$\Psi$ with respect to all independent variables, i.e.

    +\[
   \mathbf{r}(\mathbf{X}) =
 \frac{\partial\Psi(\mathbf{X})}{\partial\mathbf{X}}
 \Big\vert_{\mathbf{X}}
-\] +\]" src="form_907.png"/>

    -

    The values at the evaluation point $\mathbf{X}$ are obtained by calling CellLevelBase::set_dof_values().

    +

    The values at the evaluation point $\mathbf{X}$ are obtained by calling CellLevelBase::set_dof_values().

    Parameters
    @@ -597,15 +597,15 @@
    [out]residualA Vector object, for which the value for each entry represents the residual value for the corresponding local degree of freedom. The output residual vector has a length corresponding to n_independent_variables.
    -

    Compute the linearization of the residual vector around a chosen set of degree of freedom values. Underlying this is the computation of the Hessian (second derivative) of the scalar function $\Psi$ with respect to all independent variables, i.e.

    -\[
+<p>Compute the linearization of the residual vector around a chosen set of degree of freedom values. Underlying this is the computation of the Hessian (second derivative) of the scalar function <picture><source srcset=$\Psi$ with respect to all independent variables, i.e.

    +\[
   \frac{\partial\mathbf{r}(\mathbf{X})}{\partial\mathbf{X}}
     =
 \frac{\partial^{2}\Psi(\mathbf{X})}{\partial\mathbf{X}
 \otimes \partial\mathbf{X}} \Big\vert_{\mathbf{X}}
-\] +\]" src="form_908.png"/>

    -

    The values at the evaluation point $\mathbf{X}$ are obtained by calling CellLevelBase::set_dof_values().

    +

    The values at the evaluation point $\mathbf{X}$ are obtained by calling CellLevelBase::set_dof_values().

    Parameters
    @@ -644,7 +644,7 @@
    [out]linearizationA FullMatrix representing the linearization of the residual vector. The output linearization matrix has dimensions corresponding to n_independent_variables $\times$n_independent_variables.
    -

    Register the complete set of independent variables $\mathbf{X}$ that represent the local degree of freedom values.

    +

    Register the complete set of independent variables $\mathbf{X}$ that represent the local degree of freedom values.

    Parameters
    @@ -695,7 +695,7 @@
    [in]dof_valuesA vector field associated with local degree of freedom values on the current finite element. These define the values of all independent variables. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and linearized around.
    -

    Register the complete set of independent variables $\mathbf{X}$ that represent the local degree of freedom values.

    +

    Register the complete set of independent variables $\mathbf{X}$ that represent the local degree of freedom values.

    Parameters
    @@ -728,7 +728,7 @@
    [in]valuesA global field from which the values of all independent variables will be extracted. This typically will be the solution vector around which point a residual vector is to be computed and around which linearization is to occur. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and linearized around.
    -

    Return the complete set of degree of freedom values as represented by auto-differentiable numbers. These are the independent variables $\mathbf{X}$ about which the solution is linearized.

    +

    Return the complete set of degree of freedom values as represented by auto-differentiable numbers. These are the independent variables $\mathbf{X}$ about which the solution is linearized.

    This function indicates to the AD library that implements the auto-differentiable number type that operations performed on these numbers are to be tracked so they are considered "sensitive" variables. This is, therefore, the set of variables with which one would then perform computations, and based on which one can then extract both the value of the function and its derivatives with the member functions below. The values of the components of the returned object are initialized to the values set with register_independent_variable().

    Returns
    An array of auto-differentiable type numbers representing the local degree of freedom values.
    Note
    For taped AD numbers, this operation is only valid in recording mode.
    @@ -762,7 +762,7 @@
    -

    Set the values for the independent variables $\mathbf{X}$, i.e., the linearization point.

    +

    Set the values for the independent variables $\mathbf{X}$, i.e., the linearization point.

    Parameters
    @@ -813,7 +813,7 @@
    [in]dof_valuesA vector field associated with local degree of freedom values on the current finite element. These define the values of all independent variables.
    -

    Set the values for the independent variables $\mathbf{X}$, i.e., the linearization point.

    +

    Set the values for the independent variables $\mathbf{X}$, i.e., the linearization point.

    Parameters
    @@ -1084,7 +1084,7 @@

    In the rare case that the number of independent or dependent variables has changed, this can also reconfigured by passing in the appropriate arguments to the function.

    Parameters
    [in]valuesA vector field from which the values of all independent variables is to be extracted.
    - +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_dependent_variablesThe number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of outputs $\mathbf{f}$, i.e., the dimension of the image space.
    [in]clear_registered_tapesA flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
    @@ -1850,7 +1850,7 @@
    -

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    +

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    Parameters
    @@ -1942,7 +1942,7 @@
    [in]indexThe index of the entry in the global list of dependent variables that this function belongs to.
    -

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed at these finite values.

    Definition at line 635 of file ad_helpers.h.

    @@ -1970,7 +1970,7 @@
    -

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed using these configured AD numbers. Note that only reverse-mode AD requires that the sensitive independent variables be stored.

    Definition at line 645 of file ad_helpers.h.

    @@ -2052,8 +2052,8 @@
    -

    The set of dependent variables $\mathbf{f}(\mathbf{X})$ of which the derivatives with respect to $\mathbf{X}$ will be computed.

    -

    The gradients and Hessians of these dependent variables will be computed at the values $\mathbf{X}$ set with the set_sensitivity_value() function.

    +

    The set of dependent variables $\mathbf{f}(\mathbf{X})$ of which the derivatives with respect to $\mathbf{X}$ will be computed.

    +

    The gradients and Hessians of these dependent variables will be computed at the values $\mathbf{X}$ set with the set_sensitivity_value() function.

    Note
    These are stored as an ad_type so that we can use them to compute function values and directional derivatives in the case that tapeless numbers are used

    Definition at line 749 of file ad_helpers.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1HelperBase.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1HelperBase.html 2023-08-09 23:38:38.706479301 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1HelperBase.html 2023-08-09 23:38:38.706479301 +0000 @@ -195,7 +195,7 @@

    Detailed Description

    template<enum AD::NumberTypes ADNumberTypeCode, typename ScalarType = double>
    -class Differentiation::AD::HelperBase< ADNumberTypeCode, ScalarType >

    A base helper class that facilitates the evaluation of the derivative(s) of a number of user-defined dependent variables $\mathbf{f}(\mathbf{X})$ with respect to a set of independent variables $\mathbf{X}$, that is $\dfrac{d^{i} \mathbf{f}(\mathbf{X})}{d \mathbf{X}^{i}}$.

    +class Differentiation::AD::HelperBase< ADNumberTypeCode, ScalarType >

    A base helper class that facilitates the evaluation of the derivative(s) of a number of user-defined dependent variables $\mathbf{f}(\mathbf{X})$ with respect to a set of independent variables $\mathbf{X}$, that is $\dfrac{d^{i} \mathbf{f}(\mathbf{X})}{d \mathbf{X}^{i}}$.

    This class is templated on the floating point type scalar_type of the number that we'd like to differentiate, as well as an enumeration indicating the ADNumberTypeCode . The ADNumberTypeCode dictates which auto-differentiation library is to be used, and what the nature of the underlying auto-differentiable number is. Refer to the Automatic and symbolic differentiation module for more details in this regard.

    For all of the classes derived from this base class, there are two possible ways that the code in which they are used can be structured. The one approach is effectively a subset of the other, and which might be necessary to use depends on the nature of the chosen auto-differentiable number.

    When "tapeless" numbers are employed, the most simple code structure would be of the following form:

    @@ -345,7 +345,7 @@

    The constructor for the class.

    Parameters
    - +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_dependent_variablesThe number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of outputs $\mathbf{f}$, i.e., the dimension of the image space.
    @@ -603,7 +603,7 @@

    In the rare case that the number of independent or dependent variables has changed, this can also reconfigured by passing in the appropriate arguments to the function.

    Parameters
    - +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_dependent_variablesThe number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of outputs $\mathbf{f}$, i.e., the dimension of the image space.
    [in]clear_registered_tapesA flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
    @@ -1289,7 +1289,7 @@
    -

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    +

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    Parameters
    @@ -1381,7 +1381,7 @@
    [in]indexThe index of the entry in the global list of dependent variables that this function belongs to.
    -

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed at these finite values.

    Definition at line 635 of file ad_helpers.h.

    @@ -1409,7 +1409,7 @@
    -

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed using these configured AD numbers. Note that only reverse-mode AD requires that the sensitive independent variables be stored.

    Definition at line 645 of file ad_helpers.h.

    @@ -1491,8 +1491,8 @@
    -

    The set of dependent variables $\mathbf{f}(\mathbf{X})$ of which the derivatives with respect to $\mathbf{X}$ will be computed.

    -

    The gradients and Hessians of these dependent variables will be computed at the values $\mathbf{X}$ set with the set_sensitivity_value() function.

    +

    The set of dependent variables $\mathbf{f}(\mathbf{X})$ of which the derivatives with respect to $\mathbf{X}$ will be computed.

    +

    The gradients and Hessians of these dependent variables will be computed at the values $\mathbf{X}$ set with the set_sensitivity_value() function.

    Note
    These are stored as an ad_type so that we can use them to compute function values and directional derivatives in the case that tapeless numbers are used

    Definition at line 749 of file ad_helpers.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1PointLevelFunctionsBase.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1PointLevelFunctionsBase.html 2023-08-09 23:38:38.750479629 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1PointLevelFunctionsBase.html 2023-08-09 23:38:38.750479629 +0000 @@ -299,7 +299,7 @@

    The constructor for the class.

    Parameters
    - +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_dependent_variablesThe number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of outputs $\mathbf{f}$, i.e., the dimension of the image space.
    @@ -381,7 +381,7 @@

    In the rare case that the number of independent or dependent variables has changed, this can also be reconfigured by passing in the appropriate arguments to the function.

    Parameters
    - +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_dependent_variablesThe number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of outputs $\mathbf{f}$, i.e., the dimension of the image space.
    [in]clear_registered_tapesA flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
    @@ -412,7 +412,7 @@
    -

    Register the complete set of independent variables $\mathbf{X}$.

    +

    Register the complete set of independent variables $\mathbf{X}$.

    Parameters
    @@ -455,7 +455,7 @@
    [in]valuesA field that defines the values of all independent variables. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and differentiated around.
    -

    Register the subset of independent variables $\mathbf{A} \subset \mathbf{X}$.

    +

    Register the subset of independent variables $\mathbf{A} \subset \mathbf{X}$.

    Parameters
    @@ -486,7 +486,7 @@
    [in]valueA field that defines a number of independent variables. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and differentiated around.
    -

    Return the complete set of independent variables as represented by auto-differentiable numbers. These are the independent variables $\mathbf{X}$ at which the dependent values are evaluated and differentiated.

    +

    Return the complete set of independent variables as represented by auto-differentiable numbers. These are the independent variables $\mathbf{X}$ at which the dependent values are evaluated and differentiated.

    This function indicates to the AD library that implements the auto-differentiable number type that operations performed on these numbers are to be tracked so they are considered "sensitive" variables. This is, therefore, the set of variables with which one would then perform computations, and based on which one can then extract both the value of the function and its derivatives with the member functions below. The values of the components of the returned object are initialized to the values set with register_independent_variable().

    Returns
    An array of auto-differentiable type numbers.
    Note
    For taped AD numbers, this operation is only valid in recording mode.
    @@ -533,7 +533,7 @@
    -

    Set the values for the independent variables $\mathbf{X}$.

    +

    Set the values for the independent variables $\mathbf{X}$.

    Parameters
    @@ -576,7 +576,7 @@
    [in]valuesA vector that defines the values of all independent variables.
    -

    Set the values for a subset of independent variables $\mathbf{A} \subset \mathbf{X}$.

    +

    Set the values for a subset of independent variables $\mathbf{A} \subset \mathbf{X}$.

    Parameters
    @@ -1670,7 +1670,7 @@
    [in]valueA field that defines the values of a number of independent variables.
    -

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    +

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    Parameters
    @@ -1816,7 +1816,7 @@
    [in]indexThe index of the entry in the global list of dependent variables that this function belongs to.
    -

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed at these finite values.

    Definition at line 635 of file ad_helpers.h.

    @@ -1844,7 +1844,7 @@
    -

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed using these configured AD numbers. Note that only reverse-mode AD requires that the sensitive independent variables be stored.

    Definition at line 645 of file ad_helpers.h.

    @@ -1926,8 +1926,8 @@
    -

    The set of dependent variables $\mathbf{f}(\mathbf{X})$ of which the derivatives with respect to $\mathbf{X}$ will be computed.

    -

    The gradients and Hessians of these dependent variables will be computed at the values $\mathbf{X}$ set with the set_sensitivity_value() function.

    +

    The set of dependent variables $\mathbf{f}(\mathbf{X})$ of which the derivatives with respect to $\mathbf{X}$ will be computed.

    +

    The gradients and Hessians of these dependent variables will be computed at the values $\mathbf{X}$ set with the set_sensitivity_value() function.

    Note
    These are stored as an ad_type so that we can use them to compute function values and directional derivatives in the case that tapeless numbers are used

    Definition at line 749 of file ad_helpers.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1ResidualLinearization.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1ResidualLinearization.html 2023-08-09 23:38:38.802480017 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1ResidualLinearization.html 2023-08-09 23:38:38.802480017 +0000 @@ -452,8 +452,8 @@

    The constructor for the class.

    Parameters
    - - + +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{r}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_dependent_variablesThe number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of $\mathbf{r}(\mathbf{X})$, this will be the number of outputs $\mathbf{r}$, i.e., the dimension of the image space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{r}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_dependent_variablesThe number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of $\mathbf{r}(\mathbf{X})$, this will be the number of outputs $\mathbf{r}$, i.e., the dimension of the image space.
    @@ -508,7 +508,7 @@
    -

    Register the definition of the cell residual vector $\mathbf{r}(\mathbf{X})$.

    +

    Register the definition of the cell residual vector $\mathbf{r}(\mathbf{X})$.

    Parameters
    @@ -549,11 +549,11 @@
    [in]residualA vector of recorded functions that defines the residual. The components of this vector represents the dependent variables.

    Evaluation of the residual for a chosen set of degree of freedom values. This corresponds to the computation of the residual vector, i.e.

    -\[
+<picture><source srcset=\[
   \mathbf{r}(\mathbf{X}) \vert_{\mathbf{X}}
-\] +\]" src="form_910.png"/>

    -

    The values at the evaluation point $\mathbf{X}$ are obtained by calling CellLevelBase::set_dof_values().

    +

    The values at the evaluation point $\mathbf{X}$ are obtained by calling CellLevelBase::set_dof_values().

    Parameters
    @@ -592,12 +592,12 @@
    [out]residualA Vector object, for which the value for each entry represents the residual value for the corresponding local degree of freedom. The output residual vector has a length corresponding to n_dependent_variables.
    -

    Compute the linearization of the residual vector around a chosen set of degree of freedom values. Underlying this is the computation of the gradient (first derivative) of the residual vector $\mathbf{r}$ with respect to all independent variables, i.e.

    -\[
+<p>Compute the linearization of the residual vector around a chosen set of degree of freedom values. Underlying this is the computation of the gradient (first derivative) of the residual vector <picture><source srcset=$\mathbf{r}$ with respect to all independent variables, i.e.

    +\[
   \frac{\partial\mathbf{r}(\mathbf{X})}{\partial\mathbf{X}}
-\] +\]" src="form_904.png"/>

    -

    The values at the evaluation point $\mathbf{X}$ are obtained by calling CellLevelBase::set_dof_values().

    +

    The values at the evaluation point $\mathbf{X}$ are obtained by calling CellLevelBase::set_dof_values().

    Parameters
    @@ -636,7 +636,7 @@
    [out]linearizationA FullMatrix representing the linearization of the residual vector. The output linearization matrix has dimensions corresponding to n_dependent_variables $\times$n_independent_variables.
    -

    Register the complete set of independent variables $\mathbf{X}$ that represent the local degree of freedom values.

    +

    Register the complete set of independent variables $\mathbf{X}$ that represent the local degree of freedom values.

    Parameters
    @@ -687,7 +687,7 @@
    [in]dof_valuesA vector field associated with local degree of freedom values on the current finite element. These define the values of all independent variables. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and linearized around.
    -

    Register the complete set of independent variables $\mathbf{X}$ that represent the local degree of freedom values.

    +

    Register the complete set of independent variables $\mathbf{X}$ that represent the local degree of freedom values.

    Parameters
    @@ -720,7 +720,7 @@
    [in]valuesA global field from which the values of all independent variables will be extracted. This typically will be the solution vector around which point a residual vector is to be computed and around which linearization is to occur. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and linearized around.
    -

    Return the complete set of degree of freedom values as represented by auto-differentiable numbers. These are the independent variables $\mathbf{X}$ about which the solution is linearized.

    +

    Return the complete set of degree of freedom values as represented by auto-differentiable numbers. These are the independent variables $\mathbf{X}$ about which the solution is linearized.

    This function indicates to the AD library that implements the auto-differentiable number type that operations performed on these numbers are to be tracked so they are considered "sensitive" variables. This is, therefore, the set of variables with which one would then perform computations, and based on which one can then extract both the value of the function and its derivatives with the member functions below. The values of the components of the returned object are initialized to the values set with register_independent_variable().

    Returns
    An array of auto-differentiable type numbers representing the local degree of freedom values.
    Note
    For taped AD numbers, this operation is only valid in recording mode.
    @@ -754,7 +754,7 @@
    -

    Set the values for the independent variables $\mathbf{X}$, i.e., the linearization point.

    +

    Set the values for the independent variables $\mathbf{X}$, i.e., the linearization point.

    Parameters
    @@ -805,7 +805,7 @@
    [in]dof_valuesA vector field associated with local degree of freedom values on the current finite element. These define the values of all independent variables.
    -

    Set the values for the independent variables $\mathbf{X}$, i.e., the linearization point.

    +

    Set the values for the independent variables $\mathbf{X}$, i.e., the linearization point.

    Parameters
    @@ -1076,7 +1076,7 @@

    In the rare case that the number of independent or dependent variables has changed, this can also reconfigured by passing in the appropriate arguments to the function.

    Parameters
    [in]valuesA vector field from which the values of all independent variables is to be extracted.
    - +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_dependent_variablesThe number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of outputs $\mathbf{f}$, i.e., the dimension of the image space.
    [in]clear_registered_tapesA flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
    @@ -1842,7 +1842,7 @@
    -

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    +

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    Parameters
    @@ -1934,7 +1934,7 @@
    [in]indexThe index of the entry in the global list of dependent variables that this function belongs to.
    -

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed at these finite values.

    Definition at line 635 of file ad_helpers.h.

    @@ -1962,7 +1962,7 @@
    -

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed using these configured AD numbers. Note that only reverse-mode AD requires that the sensitive independent variables be stored.

    Definition at line 645 of file ad_helpers.h.

    @@ -2044,8 +2044,8 @@
    -

    The set of dependent variables $\mathbf{f}(\mathbf{X})$ of which the derivatives with respect to $\mathbf{X}$ will be computed.

    -

    The gradients and Hessians of these dependent variables will be computed at the values $\mathbf{X}$ set with the set_sensitivity_value() function.

    +

    The set of dependent variables $\mathbf{f}(\mathbf{X})$ of which the derivatives with respect to $\mathbf{X}$ will be computed.

    +

    The gradients and Hessians of these dependent variables will be computed at the values $\mathbf{X}$ set with the set_sensitivity_value() function.

    Note
    These are stored as an ad_type so that we can use them to compute function values and directional derivatives in the case that tapeless numbers are used

    Definition at line 749 of file ad_helpers.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1ScalarFunction.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1ScalarFunction.html 2023-08-09 23:38:38.858480435 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1ScalarFunction.html 2023-08-09 23:38:38.858480435 +0000 @@ -457,7 +457,7 @@

    The constructor for the class.

    Parameters
    - +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    @@ -512,7 +512,7 @@
    -

    Register the definition of the scalar field $\Psi(\mathbf{X})$.

    +

    Register the definition of the scalar field $\Psi(\mathbf{X})$.

    Parameters
    @@ -540,7 +540,7 @@
    [in]funcThe recorded function that defines a dependent variable.
    -

    Compute the value of the scalar field $\Psi(\mathbf{X})$ using the tape as opposed to executing the source code.

    +

    Compute the value of the scalar field $\Psi(\mathbf{X})$ using the tape as opposed to executing the source code.

    Returns
    A scalar object with the value for the scalar field evaluated at the point defined by the independent variable values.

    Definition at line 1348 of file ad_helpers.cc.

    @@ -565,9 +565,9 @@

    Compute the gradient (first derivative) of the scalar field with respect to all independent variables, i.e.

    -\[
+<picture><source srcset=\[
   \frac{\partial\Psi(\mathbf{X})}{\partial\mathbf{X}}
-\] +\]" src="form_912.png"/>

    Parameters
    @@ -598,10 +598,10 @@

    Compute the Hessian (second derivative) of the scalar field with respect to all independent variables, i.e.

    -\[
+<picture><source srcset=\[
   \frac{\partial^{2}\Psi(\mathbf{X})}{\partial\mathbf{X} \otimes
 \partial\mathbf{X}}
-\] +\]" src="form_913.png"/>

    Parameters
    @@ -651,10 +651,10 @@
    -

    Extract the function gradient for a subset of independent variables $\mathbf{A} \subset \mathbf{X}$, i.e.

    -\[
+<p>Extract the function gradient for a subset of independent variables <picture><source srcset=$\mathbf{A} \subset \mathbf{X}$, i.e.

    +\[
   \frac{\partial\Psi(\mathbf{X})}{\partial\mathbf{A}}
-\] +\]" src="form_914.png"/>

    Parameters
    @@ -710,13 +710,13 @@
    -

    Extract the function Hessian for a subset of independent variables $\mathbf{A},\mathbf{B} \subset \mathbf{X}$, i.e.

    -\[
+<p>Extract the function Hessian for a subset of independent variables <picture><source srcset=$\mathbf{A},\mathbf{B} \subset \mathbf{X}$, i.e.

    +\[
   \frac{}{\partial\mathbf{B}} \left[
 \frac{\partial\Psi(\mathbf{X})}{\partial\mathbf{A}} \right] =
 \frac{\partial^{2}\Psi(\mathbf{X})}{\partial\mathbf{B} \otimes
 \partial\mathbf{A}}
-\] +\]" src="form_916.png"/>

    Parameters
    @@ -769,11 +769,11 @@
    -

    Extract the function Hessian for a subset of independent variables $\mathbf{A},\mathbf{B} \subset \mathbf{X}$, i.e.

    -\[
+<p>Extract the function Hessian for a subset of independent variables <picture><source srcset=$\mathbf{A},\mathbf{B} \subset \mathbf{X}$, i.e.

    +\[
   \frac{}{\partial\mathbf{B}} \left[
 \frac{\partial\Psi(\mathbf{X})}{\partial\mathbf{A}} \right]
-\] +\]" src="form_917.png"/>

    This function is a specialization of the above for rank-0 tensors (scalars). This corresponds to extracting a single entry of the Hessian matrix because both extractors imply selection of just a single row or column of the matrix.

    @@ -820,11 +820,11 @@
    -

    Extract the function Hessian for a subset of independent variables $\mathbf{A},\mathbf{B} \subset \mathbf{X}$, i.e.

    -\[
+<p>Extract the function Hessian for a subset of independent variables <picture><source srcset=$\mathbf{A},\mathbf{B} \subset \mathbf{X}$, i.e.

    +\[
   \frac{}{\partial\mathbf{B}} \left[
 \frac{\partial\Psi(\mathbf{X})}{\partial\mathbf{A}} \right]
-\] +\]" src="form_917.png"/>

    This function is a specialization of the above for rank-4 symmetric tensors.

    @@ -875,7 +875,7 @@

    In the rare case that the number of independent or dependent variables has changed, this can also be reconfigured by passing in the appropriate arguments to the function.

    Parameters
    - +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_dependent_variablesThe number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of outputs $\mathbf{f}$, i.e., the dimension of the image space.
    [in]clear_registered_tapesA flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
    @@ -914,7 +914,7 @@
    -

    Register the complete set of independent variables $\mathbf{X}$.

    +

    Register the complete set of independent variables $\mathbf{X}$.

    Parameters
    @@ -965,7 +965,7 @@
    [in]valuesA field that defines the values of all independent variables. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and differentiated around.
    -

    Register the subset of independent variables $\mathbf{A} \subset \mathbf{X}$.

    +

    Register the subset of independent variables $\mathbf{A} \subset \mathbf{X}$.

    Parameters
    @@ -1004,7 +1004,7 @@
    [in]valueA field that defines a number of independent variables. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and differentiated around.
    -

    Return the complete set of independent variables as represented by auto-differentiable numbers. These are the independent variables $\mathbf{X}$ at which the dependent values are evaluated and differentiated.

    +

    Return the complete set of independent variables as represented by auto-differentiable numbers. These are the independent variables $\mathbf{X}$ at which the dependent values are evaluated and differentiated.

    This function indicates to the AD library that implements the auto-differentiable number type that operations performed on these numbers are to be tracked so they are considered "sensitive" variables. This is, therefore, the set of variables with which one would then perform computations, and based on which one can then extract both the value of the function and its derivatives with the member functions below. The values of the components of the returned object are initialized to the values set with register_independent_variable().

    Returns
    An array of auto-differentiable type numbers.
    Note
    For taped AD numbers, this operation is only valid in recording mode.
    @@ -1067,7 +1067,7 @@
    -

    Set the values for the independent variables $\mathbf{X}$.

    +

    Set the values for the independent variables $\mathbf{X}$.

    Parameters
    @@ -1118,7 +1118,7 @@
    [in]valuesA vector that defines the values of all independent variables.
    -

    Set the values for a subset of independent variables $\mathbf{A} \subset \mathbf{X}$.

    +

    Set the values for a subset of independent variables $\mathbf{A} \subset \mathbf{X}$.

    Parameters
    @@ -2212,7 +2212,7 @@
    [in]valueA field that defines the values of a number of independent variables.
    -

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    +

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    Parameters
    @@ -2358,7 +2358,7 @@
    [in]indexThe index of the entry in the global list of dependent variables that this function belongs to.
    -

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed at these finite values.

    Definition at line 635 of file ad_helpers.h.

    @@ -2386,7 +2386,7 @@
    -

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed using these configured AD numbers. Note that only reverse-mode AD requires that the sensitive independent variables be stored.

    Definition at line 645 of file ad_helpers.h.

    @@ -2468,8 +2468,8 @@
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1VectorFunction.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1VectorFunction.html 2023-08-09 23:38:38.914480854 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDifferentiation_1_1AD_1_1VectorFunction.html 2023-08-09 23:38:38.914480854 +0000 @@ -468,7 +468,7 @@

    The constructor for the class.

    Parameters
    - +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_dependent_variablesThe number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of outputs $\mathbf{f}$, i.e., the dimension of the image space.
    @@ -524,7 +524,7 @@
    -

    Register the definition of the vector field $\boldsymbol{\Psi}(\mathbf{X})$.

    +

    Register the definition of the vector field $\boldsymbol{\Psi}(\mathbf{X})$.

    Parameters
    @@ -567,7 +567,7 @@
    [in]funcsA vector of recorded functions that defines the dependent variables.
    -

    Register the definition of the vector field $\hat{\mathbf{g}}(\mathbf{X}) \subset \boldsymbol{\Psi}(\mathbf{X})$ that may represent a subset of the dependent variables.

    +

    Register the definition of the vector field $\hat{\mathbf{g}}(\mathbf{X}) \subset \boldsymbol{\Psi}(\mathbf{X})$ that may represent a subset of the dependent variables.

    Parameters
    @@ -598,7 +598,7 @@
    [in]funcsThe recorded functions that define a set of dependent variables.
    -

    Compute the value of the vector field $\boldsymbol{\Psi}(\mathbf{X})$.

    +

    Compute the value of the vector field $\boldsymbol{\Psi}(\mathbf{X})$.

    Parameters
    @@ -628,10 +628,10 @@
    [out]valuesA Vector object with the value for each component of the vector field evaluated at the point defined by the independent variable values. The output values vector has a length corresponding to n_dependent_variables.

    Compute the Jacobian (first derivative) of the vector field with respect to all independent variables, i.e.

    -\[
+<picture><source srcset=\[
   \mathbf{J}(\boldsymbol{\Psi})
      = \frac{\partial\boldsymbol{\Psi}(\mathbf{X})}{\partial\mathbf{X}}
-\] +\]" src="form_920.png"/>

    Parameters
    @@ -681,7 +681,7 @@
    -

    Extract the set of functions' values for a subset of dependent variables $\mathbf{g} \subset \boldsymbol{\Psi}(\mathbf{X})$.

    +

    Extract the set of functions' values for a subset of dependent variables $\mathbf{g} \subset \boldsymbol{\Psi}(\mathbf{X})$.

    Parameters
    @@ -735,13 +735,13 @@
    [in]valuesA Vector object with the value for each component of the vector field evaluated at the point defined by the independent variable values.
    -

    Extract the Jacobian of the subset of dependent functions $\mathbf{g} \subset \boldsymbol{\Psi}(\mathbf{X})$ for a subset of independent variables $\mathbf{A} \subset \mathbf{X}$, i.e.

    -\[
+<p>Extract the Jacobian of the subset of dependent functions <picture><source srcset=$\mathbf{g} \subset \boldsymbol{\Psi}(\mathbf{X})$ for a subset of independent variables $\mathbf{A} \subset \mathbf{X}$, i.e.

    +\[
   \mathbf{J}(\mathbf{g})
      = \frac{\partial\mathbf{g}(\mathbf{X})}{\partial\mathbf{A}}
-\] +\]" src="form_922.png"/>

    -

    The first index of the Jacobian matrix $\mathbf{J}(\mathbf{g})$ relates to the dependent variables, while the second index relates to the independent variables.

    +

    The first index of the Jacobian matrix $\mathbf{J}(\mathbf{g})$ relates to the dependent variables, while the second index relates to the independent variables.

    Parameters
    @@ -793,11 +793,11 @@
    [in]jacobianThe Jacobian of the vector function with respect to all independent variables, i.e., that returned by compute_jacobian().
    -

    Extract the Jacobian of the subset of dependent functions $\mathbf{g} \subset \boldsymbol{\Psi}(\mathbf{X})$ for a subset of independent variables $\mathbf{A} \subset \mathbf{X}$, i.e.

    -\[
+<p>Extract the Jacobian of the subset of dependent functions <picture><source srcset=$\mathbf{g} \subset \boldsymbol{\Psi}(\mathbf{X})$ for a subset of independent variables $\mathbf{A} \subset \mathbf{X}$, i.e.

    +\[
   \mathbf{J}(\mathbf{g})
      = \frac{\partial\mathbf{g}(\mathbf{X})}{\partial\mathbf{A}}
-\] +\]" src="form_922.png"/>

    This function is a specialization of the above for rank-0 tensors (scalars). This corresponds to extracting a single entry of the Jacobian matrix because both extractors imply selection of just a single row or column of the matrix.

    @@ -844,11 +844,11 @@
    -

    Extract the Jacobian of the subset of dependent functions $\mathbf{g} \subset \boldsymbol{\Psi}(\mathbf{X})$ for a subset of independent variables $\mathbf{A} \subset \mathbf{X}$, i.e.

    -\[
+<p>Extract the Jacobian of the subset of dependent functions <picture><source srcset=$\mathbf{g} \subset \boldsymbol{\Psi}(\mathbf{X})$ for a subset of independent variables $\mathbf{A} \subset \mathbf{X}$, i.e.

    +\[
   \mathbf{J}(\mathbf{g})
      = \frac{\partial\mathbf{g}(\mathbf{X})}{\partial\mathbf{A}}
-\] +\]" src="form_922.png"/>

    This function is a specialization of the above for rank-4 symmetric tensors.

    @@ -899,7 +899,7 @@

    In the rare case that the number of independent or dependent variables has changed, this can also be reconfigured by passing in the appropriate arguments to the function.

    Parameters
    - +
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_independent_variablesThe number of independent variables that will be used in the definition of the functions that it is desired to compute the sensitivities of. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of inputs $\mathbf{X}$, i.e., the dimension of the domain space.
    [in]n_dependent_variablesThe number of scalar functions to be defined that will have a sensitivity to the given independent variables. In the computation of $\mathbf{f}(\mathbf{X})$, this will be the number of outputs $\mathbf{f}$, i.e., the dimension of the image space.
    [in]clear_registered_tapesA flag that indicates the that list of registered_tapes must be cleared. If set to true then the data structure that tracks which tapes have been recorded is cleared as well. It is then expected that any preexisting tapes be re-recorded.
    @@ -938,7 +938,7 @@
    -

    Register the complete set of independent variables $\mathbf{X}$.

    +

    Register the complete set of independent variables $\mathbf{X}$.

    Parameters
    @@ -989,7 +989,7 @@
    [in]valuesA field that defines the values of all independent variables. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and differentiated around.
    -

    Register the subset of independent variables $\mathbf{A} \subset \mathbf{X}$.

    +

    Register the subset of independent variables $\mathbf{A} \subset \mathbf{X}$.

    Parameters
    @@ -1028,7 +1028,7 @@
    [in]valueA field that defines a number of independent variables. When considering taped AD numbers with branching functions, to avoid potential issues with branch switching it may be a good idea to choose these values close or equal to those that will be later evaluated and differentiated around.
    -

    Return the complete set of independent variables as represented by auto-differentiable numbers. These are the independent variables $\mathbf{X}$ at which the dependent values are evaluated and differentiated.

    +

    Return the complete set of independent variables as represented by auto-differentiable numbers. These are the independent variables $\mathbf{X}$ at which the dependent values are evaluated and differentiated.

    This function indicates to the AD library that implements the auto-differentiable number type that operations performed on these numbers are to be tracked so they are considered "sensitive" variables. This is, therefore, the set of variables with which one would then perform computations, and based on which one can then extract both the value of the function and its derivatives with the member functions below. The values of the components of the returned object are initialized to the values set with register_independent_variable().

    Returns
    An array of auto-differentiable type numbers.
    Note
    For taped AD numbers, this operation is only valid in recording mode.
    @@ -1091,7 +1091,7 @@
    -

    Set the values for the independent variables $\mathbf{X}$.

    +

    Set the values for the independent variables $\mathbf{X}$.

    Parameters
    @@ -1142,7 +1142,7 @@
    [in]valuesA vector that defines the values of all independent variables.
    -

    Set the values for a subset of independent variables $\mathbf{A} \subset \mathbf{X}$.

    +

    Set the values for a subset of independent variables $\mathbf{A} \subset \mathbf{X}$.

    Parameters
    @@ -2236,7 +2236,7 @@
    [in]valueA field that defines the values of a number of independent variables.
    -

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    +

    Register the definition of the index'th dependent variable $f(\mathbf{X})$.

    Parameters
    @@ -2382,7 +2382,7 @@
    [in]indexThe index of the entry in the global list of dependent variables that this function belongs to.
    -

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed at these finite values.

    Definition at line 635 of file ad_helpers.h.

    @@ -2410,7 +2410,7 @@
    -

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    +

    A set of sensitive independent variables $\mathbf{X}$ that differentiation will be performed with respect to.

    The gradients and Hessians of dependent variables will be computed using these configured AD numbers. Note that only reverse-mode AD requires that the sensitive independent variables be stored.

    Definition at line 645 of file ad_helpers.h.

    @@ -2492,8 +2492,8 @@
    -

    The set of dependent variables $\mathbf{f}(\mathbf{X})$ of which the derivatives with respect to $\mathbf{X}$ will be computed.

    -

    The gradients and Hessians of these dependent variables will be computed at the values $\mathbf{X}$ set with the set_sensitivity_value() function.

    +

    The set of dependent variables $\mathbf{f}(\mathbf{X})$ of which the derivatives with respect to $\mathbf{X}$ will be computed.

    +

    The gradients and Hessians of these dependent variables will be computed at the values $\mathbf{X}$ set with the set_sensitivity_value() function.

    Note
    These are stored as an ad_type so that we can use them to compute function values and directional derivatives in the case that tapeless numbers are used

    Definition at line 749 of file ad_helpers.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDiscreteTime.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDiscreteTime.html 2023-08-09 23:38:38.938481033 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classDiscreteTime.html 2023-08-09 23:38:38.942481063 +0000 @@ -183,7 +183,7 @@

    Since time is marched forward in a discrete manner in our simulations, we need to discuss how we increment time. During time stepping we enter two separate alternating regimes in every step.

    -

    Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face: $\boldsymbol \nabla u(\mathbf x_q) \cdot \mathbf n(\mathbf
-x_q)$

    +

    Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face: $\boldsymbol \nabla u(\mathbf x_q) \cdot \mathbf n(\mathbf
+x_q)$

    This call is equivalent to calling get_gradient() * normal_vector() but will use a more efficient internal representation of data.

    Note
    The derived class FEEvaluationAccess overloads this operation with specializations for the scalar case (n_components == 1) and for the vector-valued case (n_components == dim).
    @@ -1518,7 +1518,7 @@
    -

    Return the curl of the vector field, $\nabla \times v$ after a call to evaluate(EvaluationFlags::gradients).

    +

    Return the curl of the vector field, $\nabla \times v$ after a call to evaluate(EvaluationFlags::gradients).

    Note
    Only available for the vector-valued case (n_components == dim).
    @@ -2037,8 +2037,8 @@
    -

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
-T} \hat{\nabla} u_h$.

    +

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
+T} \hat{\nabla} u_h$.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_011_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_011_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 2023-08-09 23:38:39.414484587 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_011_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 2023-08-09 23:38:39.414484587 +0000 @@ -973,8 +973,8 @@

    -

    Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face: $\boldsymbol \nabla u(\mathbf x_q) \cdot \mathbf n(\mathbf
-x_q)$

    +

    Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face: $\boldsymbol \nabla u(\mathbf x_q) \cdot \mathbf n(\mathbf
+x_q)$

    This call is equivalent to calling get_gradient() * normal_vector() but will use a more efficient internal representation of data.

    Note
    The derived class FEEvaluationAccess overloads this operation with specializations for the scalar case (n_components == 1) and for the vector-valued case (n_components == dim).
    @@ -1753,7 +1753,7 @@
    -

    Return the curl of the vector field, $\nabla \times v$ after a call to evaluate(EvaluationFlags::gradients).

    +

    Return the curl of the vector field, $\nabla \times v$ after a call to evaluate(EvaluationFlags::gradients).

    Note
    Only available for the vector-valued case (n_components == dim).
    @@ -2221,8 +2221,8 @@
    -

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
-T} \hat{\nabla} u_h$.

    +

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
+T} \hat{\nabla} u_h$.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 2023-08-09 23:38:39.502485244 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 2023-08-09 23:38:39.502485244 +0000 @@ -946,8 +946,8 @@

    -

    Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face: $\boldsymbol \nabla u(\mathbf x_q) \cdot \mathbf n(\mathbf
-x_q)$

    +

    Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face: $\boldsymbol \nabla u(\mathbf x_q) \cdot \mathbf n(\mathbf
+x_q)$

    This call is equivalent to calling get_gradient() * normal_vector() but will use a more efficient internal representation of data.

    Note
    The derived class FEEvaluationAccess overloads this operation with specializations for the scalar case (n_components == 1) and for the vector-valued case (n_components == dim).
    @@ -1653,7 +1653,7 @@
    -

    Return the curl of the vector field, $\nabla \times v$ after a call to evaluate(EvaluationFlags::gradients).

    +

    Return the curl of the vector field, $\nabla \times v$ after a call to evaluate(EvaluationFlags::gradients).

    Note
    Only available for the vector-valued case (n_components == dim).
    @@ -2121,8 +2121,8 @@
    -

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
-T} \hat{\nabla} u_h$.

    +

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
+T} \hat{\nabla} u_h$.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_01dim_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_01dim_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 2023-08-09 23:38:39.578485812 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationAccess_3_01dim_00_01dim_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html 2023-08-09 23:38:39.582485842 +0000 @@ -865,7 +865,7 @@
    -

    Return the curl of the vector field, $\nabla \times v$ after a call to evaluate(EvaluationFlags::gradients).

    +

    Return the curl of the vector field, $\nabla \times v$ after a call to evaluate(EvaluationFlags::gradients).

    @@ -1463,8 +1463,8 @@
    -

    Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face: $\boldsymbol \nabla u(\mathbf x_q) \cdot \mathbf n(\mathbf
-x_q)$

    +

    Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face: $\boldsymbol \nabla u(\mathbf x_q) \cdot \mathbf n(\mathbf
+x_q)$

    This call is equivalent to calling get_gradient() * normal_vector() but will use a more efficient internal representation of data.

    Note
    The derived class FEEvaluationAccess overloads this operation with specializations for the scalar case (n_components == 1) and for the vector-valued case (n_components == dim).
    @@ -1986,8 +1986,8 @@
    -

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
-T} \hat{\nabla} u_h$.

    +

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
+T} \hat{\nabla} u_h$.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationBase.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationBase.html 2023-08-09 23:38:39.658486409 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationBase.html 2023-08-09 23:38:39.658486409 +0000 @@ -1123,8 +1123,8 @@
    -

    Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face: $\boldsymbol \nabla u(\mathbf x_q) \cdot \mathbf n(\mathbf
-x_q)$

    +

    Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face: $\boldsymbol \nabla u(\mathbf x_q) \cdot \mathbf n(\mathbf
+x_q)$

    This call is equivalent to calling get_gradient() * normal_vector() but will use a more efficient internal representation of data.

    Note
    The derived class FEEvaluationAccess overloads this operation with specializations for the scalar case (n_components == 1) and for the vector-valued case (n_components == dim).
    @@ -1346,7 +1346,7 @@
    -

    Return the curl of the vector field, $\nabla \times v$ after a call to evaluate(EvaluationFlags::gradients).

    +

    Return the curl of the vector field, $\nabla \times v$ after a call to evaluate(EvaluationFlags::gradients).

    Note
    Only available for the vector-valued case (n_components == dim).
    @@ -1853,8 +1853,8 @@
    -

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
-T} \hat{\nabla} u_h$.

    +

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
+T} \hat{\nabla} u_h$.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationData.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationData.html 2023-08-09 23:38:39.718486857 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEEvaluationData.html 2023-08-09 23:38:39.718486857 +0000 @@ -796,8 +796,8 @@
    -

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
-T} \hat{\nabla} u_h$.

    +

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
+T} \hat{\nabla} u_h$.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceEvaluation.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceEvaluation.html 2023-08-09 23:38:39.810487544 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceEvaluation.html 2023-08-09 23:38:39.810487544 +0000 @@ -1744,8 +1744,8 @@
    -

    Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face: $\boldsymbol \nabla u(\mathbf x_q) \cdot \mathbf n(\mathbf
-x_q)$

    +

    Return the derivative of a finite element function at quadrature point number q_point after a call to FEEvaluation::evaluate(EvaluationFlags::gradients) the direction normal to the face: $\boldsymbol \nabla u(\mathbf x_q) \cdot \mathbf n(\mathbf
+x_q)$

    This call is equivalent to calling get_gradient() * normal_vector() but will use a more efficient internal representation of data.

    Note
    The derived class FEEvaluationAccess overloads this operation with specializations for the scalar case (n_components == 1) and for the vector-valued case (n_components == dim).
    @@ -2039,7 +2039,7 @@
    -

    Return the curl of the vector field, $\nabla \times v$ after a call to evaluate(EvaluationFlags::gradients).

    +

    Return the curl of the vector field, $\nabla \times v$ after a call to evaluate(EvaluationFlags::gradients).

    Note
    Only available for the vector-valued case (n_components == dim).
    @@ -2558,8 +2558,8 @@
    -

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
-T} \hat{\nabla} u_h$.

    +

    Return the inverse and transposed version $J^{-\mathrm T}$ of the Jacobian of the mapping between the unit to the real cell defined as $J_{ij} = d x_i / d\hat x_j$. The $(i,j)$ entry of the returned tensor contains $d\hat x_j/dx_i$, i.e., columns refer to reference space coordinates and rows to real cell coordinates. Thus, the returned tensor represents a covariant transformation, which is used in the FEEvaluationBase::get_gradient() function to transform the unit cell gradients to gradients on the real cell by a multiplication $J^{-\mathrm
+T} \hat{\nabla} u_h$.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceValues.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceValues.html 2023-08-09 23:38:39.902488232 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceValues.html 2023-08-09 23:38:39.906488261 +0000 @@ -551,7 +551,7 @@
    -

    Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

    +

    Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

    @@ -996,7 +996,7 @@

    If the shape function is vector-valued, then this returns the only non- zero component. If the shape function has more than one non-zero component (i.e. it is not primitive), then throw an exception of type ExcShapeFunctionNotPrimitive. In that case, use the shape_value_component() function.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
    iNumber of the shape function $\varphi_i$ to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
    q_pointNumber of the quadrature point at which function is to be evaluated
    @@ -1046,7 +1046,7 @@

    Compute one vector component of the value of a shape function at a quadrature point. If the finite element is scalar, then only component zero is allowed and the return value equals that of the shape_value() function. If the finite element is vector valued but all shape functions are primitive (i.e. they are non-zero in only one component), then the value returned by shape_value() equals that of this function for exactly one component. This function is therefore only of greater interest if the shape function is not primitive, but then it is necessary since the other function cannot be used.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated.
    iNumber of the shape function $\varphi_i$ to be evaluated.
    q_pointNumber of the quadrature point at which function is to be evaluated.
    componentvector component to be evaluated.
    @@ -1094,7 +1094,7 @@

    The same holds for the arguments of this function as for the shape_value() function.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated.
    iNumber of the shape function $\varphi_i$ to be evaluated.
    q_pointNumber of the quadrature point at which function is to be evaluated.
    @@ -1351,17 +1351,17 @@
    -

    Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.

    +

    Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.

    If the current cell is not active (i.e., it has children), then the finite element function is, strictly speaking, defined by shape functions that live on these child cells. Rather than evaluating the shape functions on the child cells, with the quadrature points defined on the current cell, this function first interpolates the finite element function to shape functions defined on the current cell, and then evaluates this interpolated function.

    This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. To get values of multi-component elements, there is another get_function_values() below, returning a vector of vectors of results.

    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]valuesThe values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
    [out]valuesThe values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
    -
    Postcondition
    values[q] will contain the value of the field described by fe_function at the $q$th quadrature point.
    +
    Postcondition
    values[q] will contain the value of the field described by fe_function at the $q$th quadrature point.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1406,7 +1406,7 @@

    This function does the same as the other get_function_values(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    values[q] is a vector of values of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the $c$th vector component at the $q$th quadrature point.
    +
    Postcondition
    values[q] is a vector of values of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the $c$th vector component at the $q$th quadrature point.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3320 of file fe_values.cc.

    @@ -1614,16 +1614,16 @@
    -

    Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $\nabla u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.

    +

    Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $\nabla u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.

    This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. There is a corresponding function of the same name for vector-valued finite elements.

    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]gradientsThe gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]gradientsThe gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    gradients[q] will contain the gradient of the field described by fe_function at the $q$th quadrature point. gradients[q][d] represents the derivative in coordinate direction $d$ at quadrature point $q$.
    +
    Postcondition
    gradients[q] will contain the gradient of the field described by fe_function at the $q$th quadrature point. gradients[q][d] represents the derivative in coordinate direction $d$ at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1668,7 +1668,7 @@

    This function does the same as the other get_function_gradients(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    gradients[q] is a vector of gradients of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the $c$th vector component at the $q$th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction $d$ of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    gradients[q] is a vector of gradients of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the $c$th vector component at the $q$th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction $d$ of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3463 of file fe_values.cc.

    @@ -1816,11 +1816,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]hessiansThe Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]hessiansThe Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    hessians[q] will contain the Hessian of the field described by fe_function at the $q$th quadrature point. hessians[q][i][j] represents the $(i,j)$th component of the matrix of second derivatives at quadrature point $q$.
    +
    Postcondition
    hessians[q] will contain the Hessian of the field described by fe_function at the $q$th quadrature point. hessians[q][i][j] represents the $(i,j)$th component of the matrix of second derivatives at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1870,7 +1870,7 @@

    This function does the same as the other get_function_hessians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    hessians[q] is a vector of Hessians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the $c$th vector component at the $q$th quadrature point. Consequently, hessians[q][c][i][j] is the $(i,j)$th component of the matrix of second derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    hessians[q] is a vector of Hessians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the $c$th vector component at the $q$th quadrature point. Consequently, hessians[q][c][i][j] is the $(i,j)$th component of the matrix of second derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3576 of file fe_values.cc.

    @@ -2019,11 +2019,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]laplaciansThe Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
    [out]laplaciansThe Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
    -
    Postcondition
    laplacians[q] will contain the Laplacian of the field described by fe_function at the $q$th quadrature point.
    +
    Postcondition
    laplacians[q] will contain the Laplacian of the field described by fe_function at the $q$th quadrature point.
    For each component of the output vector, there holds laplacians[q]=trace(hessians[q]), where hessians would be the output of the get_function_hessians() function.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    @@ -2070,7 +2070,7 @@

    This function does the same as the other get_function_laplacians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    laplacians[q] is a vector of Laplacians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the $c$th vector component at the $q$th quadrature point.
    +
    Postcondition
    laplacians[q] is a vector of Laplacians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the $c$th vector component at the $q$th quadrature point.
    For each component of the output vector, there holds laplacians[q][c]=trace(hessians[q][c]), where hessians would be the output of the get_function_hessians() function.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2270,11 +2270,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]third_derivativesThe third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]third_derivativesThe third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    third_derivatives[q] will contain the third derivatives of the field described by fe_function at the $q$th quadrature point. third_derivatives[q][i][j][k] represents the $(i,j,k)$th component of the 3rd order tensor of third derivatives at quadrature point $q$.
    +
    Postcondition
    third_derivatives[q] will contain the third derivatives of the field described by fe_function at the $q$th quadrature point. third_derivatives[q][i][j][k] represents the $(i,j,k)$th component of the 3rd order tensor of third derivatives at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_3rd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2324,7 +2324,7 @@

    This function does the same as the other get_function_third_derivatives(), but applied to multi-component (vector- valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the $c$th vector component at the $q$th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the $(i,j,k)$th component of the tensor of third derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the $c$th vector component at the $q$th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the $(i,j,k)$th component of the tensor of third derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_3rd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3826 of file fe_values.cc.

    @@ -2681,7 +2681,7 @@

    Mapped quadrature weight. If this object refers to a volume evaluation (i.e. the derived class is of type FEValues), then this is the Jacobi determinant times the weight of the q_pointth unit quadrature point.

    For surface evaluations (i.e. classes FEFaceValues or FESubfaceValues), it is the mapped surface element times the weight of the quadrature point.

    -

    You can think of the quantity returned by this function as the volume or surface element $dx, ds$ in the integral that we implement here by quadrature.

    +

    You can think of the quantity returned by this function as the volume or surface element $dx, ds$ in the integral that we implement here by quadrature.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_JxW_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2738,7 +2738,7 @@
    -

    Return the Jacobian of the transformation at the specified quadrature point, i.e. $J_{ij}=dx_i/d\hat x_j$

    +

    Return the Jacobian of the transformation at the specified quadrature point, i.e. $J_{ij}=dx_i/d\hat x_j$

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2796,7 +2796,7 @@
    -

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijk}=dJ_{jk}/d\hat x_i$.

    +

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijk}=dJ_{jk}/d\hat x_i$.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2854,7 +2854,7 @@
    -

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. $G_{ijk}=dJ_{iJ}/d\hat x_K (J_{jJ})^{-1} (J_{kK})^{-1}$.

    +

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. $G_{ijk}=dJ_{iJ}/d\hat x_K (J_{jJ})^{-1} (J_{kK})^{-1}$.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_pushed_forward_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceValuesBase.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceValuesBase.html 2023-08-09 23:38:39.994488918 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEFaceValuesBase.html 2023-08-09 23:38:39.994488918 +0000 @@ -675,7 +675,7 @@

    If the shape function is vector-valued, then this returns the only non- zero component. If the shape function has more than one non-zero component (i.e. it is not primitive), then throw an exception of type ExcShapeFunctionNotPrimitive. In that case, use the shape_value_component() function.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
    iNumber of the shape function $\varphi_i$ to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
    q_pointNumber of the quadrature point at which function is to be evaluated
    @@ -725,7 +725,7 @@

    Compute one vector component of the value of a shape function at a quadrature point. If the finite element is scalar, then only component zero is allowed and the return value equals that of the shape_value() function. If the finite element is vector valued but all shape functions are primitive (i.e. they are non-zero in only one component), then the value returned by shape_value() equals that of this function for exactly one component. This function is therefore only of greater interest if the shape function is not primitive, but then it is necessary since the other function cannot be used.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated.
    iNumber of the shape function $\varphi_i$ to be evaluated.
    q_pointNumber of the quadrature point at which function is to be evaluated.
    componentvector component to be evaluated.
    @@ -773,7 +773,7 @@

    The same holds for the arguments of this function as for the shape_value() function.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated.
    iNumber of the shape function $\varphi_i$ to be evaluated.
    q_pointNumber of the quadrature point at which function is to be evaluated.
    @@ -1030,17 +1030,17 @@
    -

    Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.

    +

    Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.

    If the current cell is not active (i.e., it has children), then the finite element function is, strictly speaking, defined by shape functions that live on these child cells. Rather than evaluating the shape functions on the child cells, with the quadrature points defined on the current cell, this function first interpolates the finite element function to shape functions defined on the current cell, and then evaluates this interpolated function.

    This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. To get values of multi-component elements, there is another get_function_values() below, returning a vector of vectors of results.

    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]valuesThe values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
    [out]valuesThe values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
    -
    Postcondition
    values[q] will contain the value of the field described by fe_function at the $q$th quadrature point.
    +
    Postcondition
    values[q] will contain the value of the field described by fe_function at the $q$th quadrature point.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1085,7 +1085,7 @@

    This function does the same as the other get_function_values(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    values[q] is a vector of values of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the $c$th vector component at the $q$th quadrature point.
    +
    Postcondition
    values[q] is a vector of values of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the $c$th vector component at the $q$th quadrature point.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3320 of file fe_values.cc.

    @@ -1293,16 +1293,16 @@
    -

    Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $\nabla u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.

    +

    Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $\nabla u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.

    This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. There is a corresponding function of the same name for vector-valued finite elements.

    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]gradientsThe gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]gradientsThe gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    gradients[q] will contain the gradient of the field described by fe_function at the $q$th quadrature point. gradients[q][d] represents the derivative in coordinate direction $d$ at quadrature point $q$.
    +
    Postcondition
    gradients[q] will contain the gradient of the field described by fe_function at the $q$th quadrature point. gradients[q][d] represents the derivative in coordinate direction $d$ at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1347,7 +1347,7 @@

    This function does the same as the other get_function_gradients(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    gradients[q] is a vector of gradients of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the $c$th vector component at the $q$th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction $d$ of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    gradients[q] is a vector of gradients of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the $c$th vector component at the $q$th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction $d$ of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3463 of file fe_values.cc.

    @@ -1495,11 +1495,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]hessiansThe Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]hessiansThe Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    hessians[q] will contain the Hessian of the field described by fe_function at the $q$th quadrature point. hessians[q][i][j] represents the $(i,j)$th component of the matrix of second derivatives at quadrature point $q$.
    +
    Postcondition
    hessians[q] will contain the Hessian of the field described by fe_function at the $q$th quadrature point. hessians[q][i][j] represents the $(i,j)$th component of the matrix of second derivatives at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1549,7 +1549,7 @@

    This function does the same as the other get_function_hessians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    hessians[q] is a vector of Hessians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the $c$th vector component at the $q$th quadrature point. Consequently, hessians[q][c][i][j] is the $(i,j)$th component of the matrix of second derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    hessians[q] is a vector of Hessians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the $c$th vector component at the $q$th quadrature point. Consequently, hessians[q][c][i][j] is the $(i,j)$th component of the matrix of second derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3576 of file fe_values.cc.

    @@ -1698,11 +1698,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]laplaciansThe Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
    [out]laplaciansThe Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
    -
    Postcondition
    laplacians[q] will contain the Laplacian of the field described by fe_function at the $q$th quadrature point.
    +
    Postcondition
    laplacians[q] will contain the Laplacian of the field described by fe_function at the $q$th quadrature point.
    For each component of the output vector, there holds laplacians[q]=trace(hessians[q]), where hessians would be the output of the get_function_hessians() function.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    @@ -1749,7 +1749,7 @@

    This function does the same as the other get_function_laplacians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    laplacians[q] is a vector of Laplacians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the $c$th vector component at the $q$th quadrature point.
    +
    Postcondition
    laplacians[q] is a vector of Laplacians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the $c$th vector component at the $q$th quadrature point.
    For each component of the output vector, there holds laplacians[q][c]=trace(hessians[q][c]), where hessians would be the output of the get_function_hessians() function.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1949,11 +1949,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]third_derivativesThe third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]third_derivativesThe third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    third_derivatives[q] will contain the third derivatives of the field described by fe_function at the $q$th quadrature point. third_derivatives[q][i][j][k] represents the $(i,j,k)$th component of the 3rd order tensor of third derivatives at quadrature point $q$.
    +
    Postcondition
    third_derivatives[q] will contain the third derivatives of the field described by fe_function at the $q$th quadrature point. third_derivatives[q][i][j][k] represents the $(i,j,k)$th component of the 3rd order tensor of third derivatives at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_3rd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2003,7 +2003,7 @@

    This function does the same as the other get_function_third_derivatives(), but applied to multi-component (vector- valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the $c$th vector component at the $q$th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the $(i,j,k)$th component of the tensor of third derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the $c$th vector component at the $q$th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the $(i,j,k)$th component of the tensor of third derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_3rd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3826 of file fe_values.cc.

    @@ -2360,7 +2360,7 @@

    Mapped quadrature weight. If this object refers to a volume evaluation (i.e. the derived class is of type FEValues), then this is the Jacobi determinant times the weight of the q_pointth unit quadrature point.

    For surface evaluations (i.e. classes FEFaceValues or FESubfaceValues), it is the mapped surface element times the weight of the quadrature point.

    -

    You can think of the quantity returned by this function as the volume or surface element $dx, ds$ in the integral that we implement here by quadrature.

    +

    You can think of the quantity returned by this function as the volume or surface element $dx, ds$ in the integral that we implement here by quadrature.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_JxW_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2417,7 +2417,7 @@
    -

    Return the Jacobian of the transformation at the specified quadrature point, i.e. $J_{ij}=dx_i/d\hat x_j$

    +

    Return the Jacobian of the transformation at the specified quadrature point, i.e. $J_{ij}=dx_i/d\hat x_j$

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2475,7 +2475,7 @@
    -

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijk}=dJ_{jk}/d\hat x_i$.

    +

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijk}=dJ_{jk}/d\hat x_i$.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2533,7 +2533,7 @@
    -

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. $G_{ijk}=dJ_{iJ}/d\hat x_K (J_{jJ})^{-1} (J_{kK})^{-1}$.

    +

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. $G_{ijk}=dJ_{iJ}/d\hat x_K (J_{jJ})^{-1} (J_{kK})^{-1}$.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_pushed_forward_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2591,7 +2591,7 @@
    -

    Return the third derivative of the transformation from unit to real cell, i.e. the second derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijkl}=\frac{d^2J_{ij}}{d\hat x_k d\hat x_l}$.

    +

    Return the third derivative of the transformation from unit to real cell, i.e. the second derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijkl}=\frac{d^2J_{ij}}{d\hat x_k d\hat x_l}$.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_2nd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceValues.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceValues.html 2023-08-09 23:38:40.050489336 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceValues.html 2023-08-09 23:38:40.050489336 +0000 @@ -523,9 +523,9 @@
  • If the q_index and mapping_index arguments to this function are explicitly specified (rather than leaving them at their default values), then these indices will be used to select which element of the hp::QCollection and hp::MappingCollection passed to the constructor should serve as the quadrature and mapping to be used.
  • If one of these arguments is left at its default value, then the function will need to choose a quadrature and/or mapping that is appropriate for the two finite element spaces used on the two cells adjacent to the current interface. As the first choice, if the quadrature or mapping collection we are considering has only one element, then that is clearly the one that should be used.
  • If the quadrature or mapping collection have multiple elements, then we need to dig further. For quadrature objects, we can compare whether the two quadrature objects that correspond to the active_fe_index values of the two adjacent cells are identical (i.e., have quadrature points at the same locations, and have the same weights). If this is so, then it does not matter which one of the two we take, and we choose one or the other.
  • -
  • If this has still not helped, we try to find out which of the two finite element spaces on the two adjacent cells is "larger" (say, if you had used $Q_2$ and $Q_4$ elements on the two adjacent cells, then the $Q_4$ element is the larger one); the determination of which space is "larger" is made using the hp::FECollection::find_dominated_fe() function, which is not necessarily intended for this kind of query, but yields a result that serves just fine for our purposes here. We then operate on the assumption that the quadrature object associated with the "larger" of the two spaces is the appropriate one to use for the face that separates these two spaces.
      -
    • If this function returns that one of the two elements in question is dominated by the other, then presumably it is "larger" one and we take the quadrature formula and mapping that corresponds to this "larger" element is. For example, for the $Q_2$ element mentioned above, one would generally use a QGauss(3) quadrature formula, whereas for the $Q_4$ element, one would use QGauss(5). To integrate jump and average terms on the interface between cells using these two elements, QGauss(5) is appropriate. Because, typically, people will order elements in the hp::FECollection in the same order as the quadrature and mapping objects in hp::QCollection and hp::MappingCollection, this function will use the index of the "larger" element in the hp::FECollection to also index into the hp::QCollection and hp::MappingCollection to retrieve quadrature and mapping objects appropriate for the current face.
    • -
    • There are cases where neither element dominates the other. For example, if one uses $Q_2\times Q_1$ and $Q_1\times Q_2$ elements on neighboring cells, neither of the two spaces dominates the other – or, in the context of the current function, neither space is "larger" than the other. In that case, there is no way for the current function to determine quadrature and mapping objects associated with the two elements are the appropriate ones. If that happens, you will get an error – and the only way to avoid the error is to explicitly specify for these interfaces which quadrature and mapping objects you want to use, by providing non-default values for the q_index and mapping_index arguments to this function.
    • +
    • If this has still not helped, we try to find out which of the two finite element spaces on the two adjacent cells is "larger" (say, if you had used $Q_2$ and $Q_4$ elements on the two adjacent cells, then the $Q_4$ element is the larger one); the determination of which space is "larger" is made using the hp::FECollection::find_dominated_fe() function, which is not necessarily intended for this kind of query, but yields a result that serves just fine for our purposes here. We then operate on the assumption that the quadrature object associated with the "larger" of the two spaces is the appropriate one to use for the face that separates these two spaces.
        +
      • If this function returns that one of the two elements in question is dominated by the other, then presumably it is "larger" one and we take the quadrature formula and mapping that corresponds to this "larger" element is. For example, for the $Q_2$ element mentioned above, one would generally use a QGauss(3) quadrature formula, whereas for the $Q_4$ element, one would use QGauss(5). To integrate jump and average terms on the interface between cells using these two elements, QGauss(5) is appropriate. Because, typically, people will order elements in the hp::FECollection in the same order as the quadrature and mapping objects in hp::QCollection and hp::MappingCollection, this function will use the index of the "larger" element in the hp::FECollection to also index into the hp::QCollection and hp::MappingCollection to retrieve quadrature and mapping objects appropriate for the current face.
      • +
      • There are cases where neither element dominates the other. For example, if one uses $Q_2\times Q_1$ and $Q_1\times Q_2$ elements on neighboring cells, neither of the two spaces dominates the other – or, in the context of the current function, neither space is "larger" than the other. In that case, there is no way for the current function to determine quadrature and mapping objects associated with the two elements are the appropriate ones. If that happens, you will get an error – and the only way to avoid the error is to explicitly specify for these interfaces which quadrature and mapping objects you want to use, by providing non-default values for the q_index and mapping_index arguments to this function.
    • @@ -865,7 +865,7 @@
  • Mapped quadrature weight. This value equals the mapped surface element times the weight of the quadrature point.

    -

    You can think of the quantity returned by this function as the surface element $ds$ in the integral that we implement here by quadrature.

    +

    You can think of the quantity returned by this function as the surface element $ds$ in the integral that we implement here by quadrature.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_JxW_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1151,9 +1151,9 @@
    -

    Return the jump $\jump{u}=u_{\text{cell0}} - u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    +

    Return the jump $\jump{u}=u_{\text{cell0}} - u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    Note that one can define the jump in different ways (the value "there" minus the value "here", or the other way around; both are used in the finite element literature). The definition here uses "value here minus value there", as seen from the first cell.

    -

    If this is a boundary face (at_boundary() returns true), then $\jump{u}=u_{\text{cell0}}$, that is "the value here (minus zero)".

    +

    If this is a boundary face (at_boundary() returns true), then $\jump{u}=u_{\text{cell0}}$, that is "the value here (minus zero)".

    Note
    The name of the function is supposed to be read as "the jump (singular) in the values (plural: one or two possible values) of the shape function (singular)".
    @@ -1225,9 +1225,9 @@
    -

    Return the jump in the gradient $\jump{\nabla u}=\nabla u_{\text{cell0}} -
-\nabla u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    -

    If this is a boundary face (at_boundary() returns true), then $\jump{\nabla u}=\nabla u_{\text{cell0}}$.

    +

    Return the jump in the gradient $\jump{\nabla u}=\nabla u_{\text{cell0}} -
+\nabla u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    +

    If this is a boundary face (at_boundary() returns true), then $\jump{\nabla u}=\nabla u_{\text{cell0}}$.

    Note
    The name of the function is supposed to be read as "the jump (singular) in the gradients (plural: one or two possible gradients) of the shape function (singular)".
    @@ -1299,9 +1299,9 @@
    -

    Return the jump in the Hessian $\jump{\nabla^2 u} = \nabla^2
-u_{\text{cell0}} - \nabla^2 u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    -

    If this is a boundary face (at_boundary() returns true), then $\jump{\nabla^2 u} = \nabla^2 u_{\text{cell0}}$.

    +

    Return the jump in the Hessian $\jump{\nabla^2 u} = \nabla^2
+u_{\text{cell0}} - \nabla^2 u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    +

    If this is a boundary face (at_boundary() returns true), then $\jump{\nabla^2 u} = \nabla^2 u_{\text{cell0}}$.

    Note
    The name of the function is supposed to be read as "the jump (singular) in the Hessians (plural: one or two possible values for the derivative) of the shape function (singular)".
    @@ -1373,9 +1373,9 @@
    -

    Return the jump in the third derivative $\jump{\nabla^3 u} = \nabla^3
-u_{\text{cell0}} - \nabla^3 u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    -

    If this is a boundary face (at_boundary() returns true), then $\jump{\nabla^3 u} = \nabla^3 u_{\text{cell0}}$.

    +

    Return the jump in the third derivative $\jump{\nabla^3 u} = \nabla^3
+u_{\text{cell0}} - \nabla^3 u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    +

    If this is a boundary face (at_boundary() returns true), then $\jump{\nabla^3 u} = \nabla^3 u_{\text{cell0}}$.

    Note
    The name of the function is supposed to be read as "the jump (singular) in the third derivatives (plural: one or two possible values for the derivative) of the shape function (singular)".
    @@ -1447,9 +1447,9 @@
    -

    Return the average $\average{u}=\frac{1}{2}u_{\text{cell0}} +
-\frac{1}{2}u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    -

    If this is a boundary face (at_boundary() returns true), then $\average{u}=u_{\text{cell0}}$.

    +

    Return the average $\average{u}=\frac{1}{2}u_{\text{cell0}} +
+\frac{1}{2}u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    +

    If this is a boundary face (at_boundary() returns true), then $\average{u}=u_{\text{cell0}}$.

    Note
    The name of the function is supposed to be read as "the average (singular) of the values (plural: one or two possible values) of the shape function (singular)".
    @@ -1521,9 +1521,9 @@
    -

    Return the average of the gradient $\average{\nabla u} = \frac{1}{2}\nabla
-u_{\text{cell0}} + \frac{1}{2} \nabla u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    -

    If this is a boundary face (at_boundary() returns true), then $\average{\nabla u}=\nabla u_{\text{cell0}}$.

    +

    Return the average of the gradient $\average{\nabla u} = \frac{1}{2}\nabla
+u_{\text{cell0}} + \frac{1}{2} \nabla u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    +

    If this is a boundary face (at_boundary() returns true), then $\average{\nabla u}=\nabla u_{\text{cell0}}$.

    Note
    The name of the function is supposed to be read as "the average (singular) of the gradients (plural: one or two possible values for the gradient) of the shape function (singular)".
    @@ -1595,10 +1595,10 @@
    -

    Return the average of the Hessian $\average{\nabla^2 u} =
+<p>Return the average of the Hessian <picture><source srcset=$\average{\nabla^2 u} =
 \frac{1}{2}\nabla^2 u_{\text{cell0}} + \frac{1}{2} \nabla^2
-u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    -

    If this is a boundary face (at_boundary() returns true), then $\average{\nabla^2 u}=\nabla^2 u_{\text{cell0}}$.

    +u_{\text{cell1}}$" src="form_1094.png"/> on the interface for the shape function interface_dof_index at the quadrature point q_point of component component.

    +

    If this is a boundary face (at_boundary() returns true), then $\average{\nabla^2 u}=\nabla^2 u_{\text{cell0}}$.

    Note
    The name of the function is supposed to be read as "the average (singular) of the Hessians (plural: one or two possible values for the second derivatives) of the shape function (singular)".
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceViews_1_1Scalar.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceViews_1_1Scalar.html 2023-08-09 23:38:40.094489666 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceViews_1_1Scalar.html 2023-08-09 23:38:40.094489666 +0000 @@ -477,7 +477,7 @@
    -

    Return the jump $\jump{u}=u_1 - u_2$ on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.

    +

    Return the jump $\jump{u}=u_1 - u_2$ on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.

    Note
    The name of the function is supposed to be read as "the jump (singular) in the values (plural: one or two possible values) of the shape function (singular)".
    @@ -539,7 +539,7 @@
    -

    Return the jump of the gradient $\jump{nabla u}$ on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.

    +

    Return the jump of the gradient $\jump{nabla u}$ on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.

    Note
    The name of the function is supposed to be read as "the jump (singular) in the gradients (plural: one or two possible gradients) of the shape function (singular)".
    @@ -601,8 +601,8 @@
    -

    Return the jump in the gradient $\jump{\nabla u}=\nabla u_{\text{cell0}}
-- \nabla u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.

    +

    Return the jump in the gradient $\jump{\nabla u}=\nabla u_{\text{cell0}}
+- \nabla u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.

    Note
    The name of the function is supposed to be read as "the jump (singular) in the Hessians (plural: one or two possible values for the second derivative) of the shape function (singular)".
    @@ -664,8 +664,8 @@
    -

    Return the jump in the third derivative $\jump{\nabla^3 u} = \nabla^3
-u_{\text{cell0}} - \nabla^3 u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.

    +

    Return the jump in the third derivative $\jump{\nabla^3 u} = \nabla^3
+u_{\text{cell0}} - \nabla^3 u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.

    Note
    The name of the function is supposed to be read as "the jump (singular) in the third derivatives (plural: one or two possible values for the third derivative) of the shape function (singular)".
    @@ -727,7 +727,7 @@
    -

    Return the average value $\average{u}=\frac{1}{2}(u_1 + u_2)$ on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.

    +

    Return the average value $\average{u}=\frac{1}{2}(u_1 + u_2)$ on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.

    Note
    The name of the function is supposed to be read as "the average (singular) of the values (plural: one or two possible values) of the shape function (singular)".
    @@ -819,7 +819,7 @@
    -

    Return the average of the gradient $\average{\nabla u}$ on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.

    +

    Return the average of the gradient $\average{\nabla u}$ on the interface for the shape function interface_dof_index in the quadrature point q_point of the component selected by this view.

    Note
    The name of the function is supposed to be read as "the average (singular) of the gradients (plural: one or two possible values of the derivative) of the shape function (singular)".
    @@ -881,9 +881,9 @@
    -

    Return the average of the Hessian $\average{\nabla^2 u} =
+<p>Return the average of the Hessian <picture><source srcset=$\average{\nabla^2 u} =
 \frac{1}{2}\nabla^2 u_{\text{cell0}} + \frac{1}{2} \nabla^2
-u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.

    +u_{\text{cell1}}$" src="form_1094.png"/> on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.

    Note
    The name of the function is supposed to be read as "the average (singular) in the Hessians (plural: one or two possible values of the second derivative) of the shape function (singular)".
    @@ -956,7 +956,7 @@

    Return the values of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.

    The argument here_or_there selects between the value on cell 0 (here, true) and cell 1 (there, false). You can also interpret it as "upstream" (true) and "downstream" (false) as defined by the direction of the normal vector in this quadrature point. If here_or_there is true, the values from the first cell of the interface is used.

    -

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1042,7 +1042,7 @@

    Return the jump in the values of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1108,7 +1108,7 @@

    Return the jump in the gradients of the selected scalar components of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1174,7 +1174,7 @@

    Return the jump in the Hessians of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1240,7 +1240,7 @@

    Return the jump in the third derivatives of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_third_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1306,7 +1306,7 @@

    Return the average of the values of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1372,7 +1372,7 @@

    Return the average of the gradients of the selected scalar components of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1438,7 +1438,7 @@

    Return the average of the Hessians of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceViews_1_1Vector.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceViews_1_1Vector.html 2023-08-09 23:38:40.134489963 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEInterfaceViews_1_1Vector.html 2023-08-09 23:38:40.134489963 +0000 @@ -475,7 +475,7 @@
    -

    Return the jump vector $[\mathbf{u}]=\mathbf{u_1} - \mathbf{u_2}$ on the interface for the shape function interface_dof_index in the quadrature point q_point.

    +

    Return the jump vector $[\mathbf{u}]=\mathbf{u_1} - \mathbf{u_2}$ on the interface for the shape function interface_dof_index in the quadrature point q_point.

    Note
    The name of the function is supposed to be read as "the jump (singular) in the values (plural: one or two possible values) of the shape function (singular)".
    @@ -537,8 +537,8 @@
    -

    Return the jump of the gradient (a tensor of rank 2) $\jump{\nabla
-\mathbf{u}}$ on the interface for the shape function interface_dof_index in the quadrature point q_point.

    +

    Return the jump of the gradient (a tensor of rank 2) $\jump{\nabla
+\mathbf{u}}$ on the interface for the shape function interface_dof_index in the quadrature point q_point.

    Note
    The name of the function is supposed to be read as "the jump (singular) in the gradients (plural: one or two possible gradients) of the shape function (singular)".
    @@ -600,8 +600,8 @@
    -

    Return the jump in the gradient $\jump{\nabla u}=\nabla u_{\text{cell0}}
-- \nabla u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.

    +

    Return the jump in the gradient $\jump{\nabla u}=\nabla u_{\text{cell0}}
+- \nabla u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.

    Note
    The name of the function is supposed to be read as "the jump (singular) in the Hessians (plural: one or two possible values for the second derivative) of the shape function (singular)".
    @@ -663,8 +663,8 @@
    -

    Return the jump in the third derivative $\jump{\nabla^3 u} = \nabla^3
-u_{\text{cell0}} - \nabla^3 u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.

    +

    Return the jump in the third derivative $\jump{\nabla^3 u} = \nabla^3
+u_{\text{cell0}} - \nabla^3 u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.

    Note
    The name of the function is supposed to be read as "the jump (singular) in the third derivatives (plural: one or two possible values for the third derivative) of the shape function (singular)".
    @@ -726,8 +726,8 @@
    -

    Return the average vector $\average{\mathbf{u}}=\frac{1}{2}(\mathbf{u_1}
-+ \mathbf{u_2})$ on the interface for the shape function interface_dof_index in the quadrature point q_point.

    +

    Return the average vector $\average{\mathbf{u}}=\frac{1}{2}(\mathbf{u_1}
++ \mathbf{u_2})$ on the interface for the shape function interface_dof_index in the quadrature point q_point.

    Note
    The name of the function is supposed to be read as "the average (singular) of the values (plural: one or two possible values) of the shape function (singular)".
    @@ -789,8 +789,8 @@
    -

    Return the average of the gradient (a tensor of rank 2) $\average{\nabla
-\mathbf{u}}$ on the interface for the shape function interface_dof_index in the quadrature point q_point.

    +

    Return the average of the gradient (a tensor of rank 2) $\average{\nabla
+\mathbf{u}}$ on the interface for the shape function interface_dof_index in the quadrature point q_point.

    Note
    The name of the function is supposed to be read as "the average (singular) of the gradients (plural: one or two possible values of the derivative) of the shape function (singular)".
    @@ -852,9 +852,9 @@
    -

    Return the average of the Hessian $\average{\nabla^2 u} =
+<p>Return the average of the Hessian <picture><source srcset=$\average{\nabla^2 u} =
 \frac{1}{2}\nabla^2 u_{\text{cell0}} + \frac{1}{2} \nabla^2
-u_{\text{cell1}}$ on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.

    +u_{\text{cell1}}$" src="form_1094.png"/> on the interface for the shape function interface_dof_index at the quadrature point q_point of the component selected by this view.

    Note
    The name of the function is supposed to be read as "the average (singular) in the Hessians (plural: one or two possible values of the second derivative) of the shape function (singular)".
    @@ -927,7 +927,7 @@

    Return the values of the selected vector component of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.

    The argument here_or_there selects between the value on cell 0 (here, true) and cell 1 (there, false). You can also interpret it as "upstream" (true) and "downstream" (false) as defined by the direction of the normal vector in this quadrature point. If here_or_there is true, the values from the first cell of the interface is used.

    -

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1013,7 +1013,7 @@

    Return the jump in the values of the selected vector component of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1079,7 +1079,7 @@

    Return the jump in the gradients of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1145,7 +1145,7 @@

    Return the jump in the Hessians of the selected vector component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1211,7 +1211,7 @@

    Return the jump in the third derivatives of the selected vector component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_third_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1277,7 +1277,7 @@

    Return the average of the values of the selected vector component of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1343,7 +1343,7 @@

    Return the average of the gradients of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell interface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1409,7 +1409,7 @@

    Return the average of the Hessians of the selected vector component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEInterfaceValues object was called.

    -

    The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESeries_1_1Fourier.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESeries_1_1Fourier.html 2023-08-09 23:38:40.162490172 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESeries_1_1Fourier.html 2023-08-09 23:38:40.162490172 +0000 @@ -198,25 +198,25 @@

    Detailed Description

    template<int dim, int spacedim = dim>
    -class FESeries::Fourier< dim, spacedim >

    A class to calculate expansion of a scalar FE (or a single component of vector-valued FE) field into Fourier series on a reference element. The exponential form of the Fourier series is based on completeness and Hermitian orthogonality of the set of exponential functions $ \phi_{\bf k}({\bf x}) = \exp(2 \pi i\, {\bf k} \cdot {\bf x})$. For example in 1d the L2-orthogonality condition reads

    -\[
+class FESeries::Fourier< dim, spacedim ></div><p>A class to calculate expansion of a scalar FE (or a single component of vector-valued FE) field into <a class=Fourier series on a reference element. The exponential form of the Fourier series is based on completeness and Hermitian orthogonality of the set of exponential functions $ \phi_{\bf k}({\bf x}) = \exp(2 \pi i\, {\bf k} \cdot {\bf x})$. For example in 1d the L2-orthogonality condition reads

    +\[
   \int_0^1 \phi_k(x) \phi_l^\ast(x) dx=\delta_{kl}.
-\] +\]" src="form_1176.png"/>

    -

    Note that $ \phi_{\bf k} = \phi_{-\bf k}^\ast $.

    +

    Note that $ \phi_{\bf k} = \phi_{-\bf k}^\ast $.

    The arbitrary scalar FE field on the reference element can be expanded in the complete orthogonal exponential basis as

    -\[
+<picture><source srcset=\[
    u({\bf x})
    = \sum_{\bf k} c_{\bf k} \phi_{\bf k}({\bf x}).
-\] +\]" src="form_1178.png"/>

    From the orthogonality property of the basis, it follows that

    -\[
+<picture><source srcset=\[
    c_{\bf k} =
    \int_{[0,1]^d} u({\bf x}) \phi_{\bf k}^\ast ({\bf x}) d{\bf x}\,.
-\] +\]" src="form_1179.png"/>

    -

    It is this complex-valued expansion coefficients, that are calculated by this class. Note that $ u({\bf x}) = \sum_i u_i N_i({\bf x})$, where $ N_i({\bf x}) $ are real-valued FiniteElement shape functions. Consequently $ c_{\bf k} \equiv c_{-\bf k}^\ast $ and we only need to compute $ c_{\bf k} $ for positive indices $ \bf k $ .

    +

    It is this complex-valued expansion coefficients, that are calculated by this class. Note that $ u({\bf x}) = \sum_i u_i N_i({\bf x})$, where $ N_i({\bf x}) $ are real-valued FiniteElement shape functions. Consequently $ c_{\bf k} \equiv c_{-\bf k}^\ast $ and we only need to compute $ c_{\bf k} $ for positive indices $ \bf k $ .

    Definition at line 90 of file fe_series.h.

    Member Typedef Documentation

    @@ -882,7 +882,7 @@
    -

    Angular frequencies $ 2 \pi {\bf k} $ .

    +

    Angular frequencies $ 2 \pi {\bf k} $ .

    Definition at line 196 of file fe_series.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESeries_1_1Legendre.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESeries_1_1Legendre.html 2023-08-09 23:38:40.190490382 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESeries_1_1Legendre.html 2023-08-09 23:38:40.190490382 +0000 @@ -195,39 +195,39 @@
    template<int dim, int spacedim = dim>
    class FESeries::Legendre< dim, spacedim >

    A class to calculate expansion of a scalar FE (or a single component of vector-valued FE) field into series of Legendre functions on a reference element.

    Legendre functions are solutions to Legendre's differential equation

    -\[
+<picture><source srcset=\[
    \frac{d}{dx}\left([1-x^2] \frac{d}{dx} P_n(x)\right) +
    n[n+1] P_n(x) = 0
-\] +\]" src="form_1185.png"/>

    and can be expressed using Rodrigues' formula

    -\[
+<picture><source srcset=\[
    P_n(x) = \frac{1}{2^n n!} \frac{d^n}{dx^n}[x^2-1]^n.
-\] +\]" src="form_1186.png"/>

    -

    These polynomials are orthogonal with respect to the $ L^2 $ inner product on the interval $ [-1;1] $

    -\[
+<p> These polynomials are orthogonal with respect to the <picture><source srcset=$ L^2 $ inner product on the interval $ [-1;1] $

    +\[
    \int_{-1}^1 P_m(x) P_n(x) = \frac{2}{2n + 1} \delta_{mn}
-\] +\]" src="form_1189.png"/>

    -

    and are complete. A family of $ L^2 $-orthogonal polynomials on $ [0;1] $ can be constructed via

    -\[
+<p> and are complete. A family of <picture><source srcset=$ L^2 $-orthogonal polynomials on $ [0;1] $ can be constructed via

    +\[
    \widetilde P_m = \sqrt{2} P_m(2x-1).
-\] +\]" src="form_1191.png"/>

    -

    An arbitrary scalar FE field on the reference element $ [0;1] $ can be expanded in the complete orthogonal basis as

    -\[
+<p>An arbitrary scalar FE field on the reference element <picture><source srcset=$ [0;1] $ can be expanded in the complete orthogonal basis as

    +\[
    u(x)
    = \sum_{m} c_m \widetilde P_{m}(x).
-\] +\]" src="form_1192.png"/>

    From the orthogonality property of the basis, it follows that

    -\[
+<picture><source srcset=\[
    c_m = \frac{2m+1}{2}
    \int_0^1 u(x) \widetilde P_m(x) dx .
-\] +\]" src="form_1193.png"/>

    -

    This class calculates coefficients $ c_{\bf k} $ using $ dim $-dimensional Legendre polynomials constructed from $ \widetilde P_m(x) $ using tensor product rule.

    +

    This class calculates coefficients $ c_{\bf k} $ using $ dim $-dimensional Legendre polynomials constructed from $ \widetilde P_m(x) $ using tensor product rule.

    Definition at line 260 of file fe_series.h.

    Member Typedef Documentation

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESubfaceValues.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESubfaceValues.html 2023-08-09 23:38:40.282491069 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESubfaceValues.html 2023-08-09 23:38:40.282491069 +0000 @@ -556,7 +556,7 @@
    -

    Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

    +

    Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

    @@ -1033,7 +1033,7 @@

    If the shape function is vector-valued, then this returns the only non- zero component. If the shape function has more than one non-zero component (i.e. it is not primitive), then throw an exception of type ExcShapeFunctionNotPrimitive. In that case, use the shape_value_component() function.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
    iNumber of the shape function $\varphi_i$ to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
    q_pointNumber of the quadrature point at which function is to be evaluated
    @@ -1083,7 +1083,7 @@

    Compute one vector component of the value of a shape function at a quadrature point. If the finite element is scalar, then only component zero is allowed and the return value equals that of the shape_value() function. If the finite element is vector valued but all shape functions are primitive (i.e. they are non-zero in only one component), then the value returned by shape_value() equals that of this function for exactly one component. This function is therefore only of greater interest if the shape function is not primitive, but then it is necessary since the other function cannot be used.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated.
    iNumber of the shape function $\varphi_i$ to be evaluated.
    q_pointNumber of the quadrature point at which function is to be evaluated.
    componentvector component to be evaluated.
    @@ -1131,7 +1131,7 @@

    The same holds for the arguments of this function as for the shape_value() function.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated.
    iNumber of the shape function $\varphi_i$ to be evaluated.
    q_pointNumber of the quadrature point at which function is to be evaluated.
    @@ -1388,17 +1388,17 @@
    -

    Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.

    +

    Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.

    If the current cell is not active (i.e., it has children), then the finite element function is, strictly speaking, defined by shape functions that live on these child cells. Rather than evaluating the shape functions on the child cells, with the quadrature points defined on the current cell, this function first interpolates the finite element function to shape functions defined on the current cell, and then evaluates this interpolated function.

    This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. To get values of multi-component elements, there is another get_function_values() below, returning a vector of vectors of results.

    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]valuesThe values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
    [out]valuesThe values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
    -
    Postcondition
    values[q] will contain the value of the field described by fe_function at the $q$th quadrature point.
    +
    Postcondition
    values[q] will contain the value of the field described by fe_function at the $q$th quadrature point.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1443,7 +1443,7 @@

    This function does the same as the other get_function_values(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    values[q] is a vector of values of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the $c$th vector component at the $q$th quadrature point.
    +
    Postcondition
    values[q] is a vector of values of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the $c$th vector component at the $q$th quadrature point.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3320 of file fe_values.cc.

    @@ -1651,16 +1651,16 @@
    -

    Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $\nabla u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.

    +

    Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $\nabla u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.

    This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. There is a corresponding function of the same name for vector-valued finite elements.

    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]gradientsThe gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]gradientsThe gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    gradients[q] will contain the gradient of the field described by fe_function at the $q$th quadrature point. gradients[q][d] represents the derivative in coordinate direction $d$ at quadrature point $q$.
    +
    Postcondition
    gradients[q] will contain the gradient of the field described by fe_function at the $q$th quadrature point. gradients[q][d] represents the derivative in coordinate direction $d$ at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1705,7 +1705,7 @@

    This function does the same as the other get_function_gradients(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    gradients[q] is a vector of gradients of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the $c$th vector component at the $q$th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction $d$ of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    gradients[q] is a vector of gradients of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the $c$th vector component at the $q$th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction $d$ of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3463 of file fe_values.cc.

    @@ -1853,11 +1853,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]hessiansThe Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]hessiansThe Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    hessians[q] will contain the Hessian of the field described by fe_function at the $q$th quadrature point. hessians[q][i][j] represents the $(i,j)$th component of the matrix of second derivatives at quadrature point $q$.
    +
    Postcondition
    hessians[q] will contain the Hessian of the field described by fe_function at the $q$th quadrature point. hessians[q][i][j] represents the $(i,j)$th component of the matrix of second derivatives at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1907,7 +1907,7 @@

    This function does the same as the other get_function_hessians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    hessians[q] is a vector of Hessians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the $c$th vector component at the $q$th quadrature point. Consequently, hessians[q][c][i][j] is the $(i,j)$th component of the matrix of second derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    hessians[q] is a vector of Hessians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the $c$th vector component at the $q$th quadrature point. Consequently, hessians[q][c][i][j] is the $(i,j)$th component of the matrix of second derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3576 of file fe_values.cc.

    @@ -2056,11 +2056,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]laplaciansThe Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
    [out]laplaciansThe Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
    -
    Postcondition
    laplacians[q] will contain the Laplacian of the field described by fe_function at the $q$th quadrature point.
    +
    Postcondition
    laplacians[q] will contain the Laplacian of the field described by fe_function at the $q$th quadrature point.
    For each component of the output vector, there holds laplacians[q]=trace(hessians[q]), where hessians would be the output of the get_function_hessians() function.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    @@ -2107,7 +2107,7 @@

    This function does the same as the other get_function_laplacians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    laplacians[q] is a vector of Laplacians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the $c$th vector component at the $q$th quadrature point.
    +
    Postcondition
    laplacians[q] is a vector of Laplacians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the $c$th vector component at the $q$th quadrature point.
    For each component of the output vector, there holds laplacians[q][c]=trace(hessians[q][c]), where hessians would be the output of the get_function_hessians() function.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2307,11 +2307,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]third_derivativesThe third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]third_derivativesThe third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    third_derivatives[q] will contain the third derivatives of the field described by fe_function at the $q$th quadrature point. third_derivatives[q][i][j][k] represents the $(i,j,k)$th component of the 3rd order tensor of third derivatives at quadrature point $q$.
    +
    Postcondition
    third_derivatives[q] will contain the third derivatives of the field described by fe_function at the $q$th quadrature point. third_derivatives[q][i][j][k] represents the $(i,j,k)$th component of the 3rd order tensor of third derivatives at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_3rd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2361,7 +2361,7 @@

    This function does the same as the other get_function_third_derivatives(), but applied to multi-component (vector- valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the $c$th vector component at the $q$th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the $(i,j,k)$th component of the tensor of third derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the $c$th vector component at the $q$th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the $(i,j,k)$th component of the tensor of third derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_3rd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3826 of file fe_values.cc.

    @@ -2718,7 +2718,7 @@

    Mapped quadrature weight. If this object refers to a volume evaluation (i.e. the derived class is of type FEValues), then this is the Jacobi determinant times the weight of the q_pointth unit quadrature point.

    For surface evaluations (i.e. classes FEFaceValues or FESubfaceValues), it is the mapped surface element times the weight of the quadrature point.

    -

    You can think of the quantity returned by this function as the volume or surface element $dx, ds$ in the integral that we implement here by quadrature.

    +

    You can think of the quantity returned by this function as the volume or surface element $dx, ds$ in the integral that we implement here by quadrature.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_JxW_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2775,7 +2775,7 @@
    -

    Return the Jacobian of the transformation at the specified quadrature point, i.e. $J_{ij}=dx_i/d\hat x_j$

    +

    Return the Jacobian of the transformation at the specified quadrature point, i.e. $J_{ij}=dx_i/d\hat x_j$

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2833,7 +2833,7 @@
    -

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijk}=dJ_{jk}/d\hat x_i$.

    +

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijk}=dJ_{jk}/d\hat x_i$.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2891,7 +2891,7 @@
    -

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. $G_{ijk}=dJ_{iJ}/d\hat x_K (J_{jJ})^{-1} (J_{kK})^{-1}$.

    +

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. $G_{ijk}=dJ_{iJ}/d\hat x_K (J_{jJ})^{-1} (J_{kK})^{-1}$.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_pushed_forward_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESystem.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESystem.html 2023-08-09 23:38:40.414492054 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFESystem.html 2023-08-09 23:38:40.414492054 +0000 @@ -499,31 +499,31 @@

    Detailed Description

    template<int dim, int spacedim = dim>
    -class FESystem< dim, spacedim >

    This class provides an interface to group several elements together into one, vector-valued element. As example, consider the Taylor-Hood element that is used for the solution of the Stokes and Navier-Stokes equations: There, the velocity (of which there are as many components as the dimension $d$ of the domain) is discretized with $Q_2$ elements and the pressure with $Q_1$ elements. Mathematically, the finite element space for the coupled problem is then often written as $V_h = Q_2^d \times Q_1$ where the exponentiation is understood to be the tensor product of spaces – i.e., in 2d, we have $V_h=Q_2\times Q_2\times Q_1$ – and tensor products lead to vectors where each component of the vector-valued function space corresponds to a scalar function in one of the $Q_2$ or $Q_1$ spaces. Using the FESystem class, this space is created using

    FESystem<dim> taylor_hood_fe (FE_Q<dim>(2)^dim, // velocity components
    +class FESystem< dim, spacedim >

    This class provides an interface to group several elements together into one, vector-valued element. As example, consider the Taylor-Hood element that is used for the solution of the Stokes and Navier-Stokes equations: There, the velocity (of which there are as many components as the dimension $d$ of the domain) is discretized with $Q_2$ elements and the pressure with $Q_1$ elements. Mathematically, the finite element space for the coupled problem is then often written as $V_h = Q_2^d \times Q_1$ where the exponentiation is understood to be the tensor product of spaces – i.e., in 2d, we have $V_h=Q_2\times Q_2\times Q_1$ – and tensor products lead to vectors where each component of the vector-valued function space corresponds to a scalar function in one of the $Q_2$ or $Q_1$ spaces. Using the FESystem class, this space is created using

    FESystem<dim> taylor_hood_fe (FE_Q<dim>(2)^dim, // velocity components
    FE_Q<dim>(1)); // pressure component
    Definition: fe_q.h:551
    -

    The creation of this element here corresponds to taking tensor-product powers of the $Q_2$ element in the first line of the list of arguments to the FESystem constructor, and then concatenation via another tensor product with the element in the second line. This kind of construction is used, for example, in the step-22 tutorial program.

    -

    Similarly, step-8 solves an elasticity equation where we need to solve for the displacement of a solid object. The displacement again has $d$ components if the domain is $d$-dimensional, and so the combined finite element is created using

    FESystem<dim> displacement_fe (FE_Q<dim>(1)^dim);
    -

    where now each (vector) component of the combined element corresponds to a $Q_1$ space.

    +

    The creation of this element here corresponds to taking tensor-product powers of the $Q_2$ element in the first line of the list of arguments to the FESystem constructor, and then concatenation via another tensor product with the element in the second line. This kind of construction is used, for example, in the step-22 tutorial program.

    +

    Similarly, step-8 solves an elasticity equation where we need to solve for the displacement of a solid object. The displacement again has $d$ components if the domain is $d$-dimensional, and so the combined finite element is created using

    FESystem<dim> displacement_fe (FE_Q<dim>(1)^dim);
    +

    where now each (vector) component of the combined element corresponds to a $Q_1$ space.

    To the outside world, FESystem objects look just like a usual finite element object, they just happen to be composed of several other finite elements that are possibly of different type. These "base elements" can themselves have multiple components and, in particular, could also be vector-valued – for example, if one of the base elements is an FESystem itself (see also below). An example is given in the documentation of namespace FETools::Compositing, when using the "tensor product" strategy.

    Vector valued elements are discussed in a number of tutorial programs, for example step-8, step-20, step-21, step-22, and in particular in the Handling vector valued problems module.

    Note
    The material presented here is also discussed in video lecture 19, video lecture 20. (All video lectures are also available here.)

    FESystem, components and blocks

    -

    An FESystem, except in the most trivial case, produces a vector-valued finite element with several components. The number of components n_components() corresponds to the dimension of the solution function in the PDE system, and correspondingly also to the number of equations your PDE system has. For example, the mixed Laplace system covered in step-20 has $d+1$ components in $d$ space dimensions: the scalar pressure and the $d$ components of the velocity vector. Similarly, the elasticity equation covered in step-8 has $d$ components in $d$ space dimensions. In general, the number of components of a FESystem element is the accumulated number of components of all base elements times their multiplicities. A bit more on components is also given in the glossary entry on components.

    +

    An FESystem, except in the most trivial case, produces a vector-valued finite element with several components. The number of components n_components() corresponds to the dimension of the solution function in the PDE system, and correspondingly also to the number of equations your PDE system has. For example, the mixed Laplace system covered in step-20 has $d+1$ components in $d$ space dimensions: the scalar pressure and the $d$ components of the velocity vector. Similarly, the elasticity equation covered in step-8 has $d$ components in $d$ space dimensions. In general, the number of components of a FESystem element is the accumulated number of components of all base elements times their multiplicities. A bit more on components is also given in the glossary entry on components.

    While the concept of components is important from the viewpoint of a partial differential equation, the finite element side looks a bit different Since not only FESystem, but also vector-valued elements like FE_RaviartThomas, have several components. The concept needed here is a block. Each block encompasses the set of degrees of freedom associated with a single base element of an FESystem, where base elements with multiplicities count multiple times. These blocks are usually addressed using the information in DoFHandler::block_info(). The number of blocks of a FESystem object is simply the sum of all multiplicities of base elements and is given by n_blocks().

    For example, the FESystem for the Taylor-Hood element for the three-dimensional Stokes problem can be built using the code

    const FE_Q<3> u(2);
    const FE_Q<3> p(1);
    FESystem<3> sys1(u,3, p,1);

    or more concisely via

    FESystem<3> sys1(FE_Q<3>(2),3,
    FE_Q<3>(1),1);
    -

    or even shorter (mimicking the mathematical notation that we are dealing with a $Q_2^3 \times Q_1$ element):

    FESystem<3> sys1(FE_Q<3>(2)^3,
    +

    or even shorter (mimicking the mathematical notation that we are dealing with a $Q_2^3 \times Q_1$ element):

    FESystem<3> sys1(FE_Q<3>(2)^3,
    FE_Q<3>(1));

    This example creates an FESystem sys1 with four components, three for the velocity components and one for the pressure, and also four blocks with the degrees of freedom of each of the velocity components and the pressure in a separate block each. The number of blocks is four since the first base element is repeated three times.

    On the other hand, a Taylor-Hood element can also be constructed using

    FESystem<3> U(u,3);
    FESystem<3> sys2(U, p);
    -

    The FESystem sys2 created here has the same four components, but the degrees of freedom are distributed into only two blocks. The first block has all velocity degrees of freedom from U, while the second block contains the pressure degrees of freedom. Note that while U itself has 3 blocks, the FESystem sys2 does not attempt to split U into its base elements but considers it a block of its own. By blocking all velocities into one system first as in sys2, we achieve the same block structure that would be generated if instead of using a $Q_2^3$ element for the velocities we had used vector-valued base elements, for instance like using a mixed discretization of Darcy's law using

    +

    The FESystem sys2 created here has the same four components, but the degrees of freedom are distributed into only two blocks. The first block has all velocity degrees of freedom from U, while the second block contains the pressure degrees of freedom. Note that while U itself has 3 blocks, the FESystem sys2 does not attempt to split U into its base elements but considers it a block of its own. By blocking all velocities into one system first as in sys2, we achieve the same block structure that would be generated if instead of using a $Q_2^3$ element for the velocities we had used vector-valued base elements, for instance like using a mixed discretization of Darcy's law using

    FE_DGQ<3> p(1);
    FESystem<3> sys3(u, p);
    @@ -4197,7 +4197,7 @@

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4305,7 +4305,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4464,7 +4464,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4523,9 +4523,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValues.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValues.html 2023-08-09 23:38:40.506492742 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValues.html 2023-08-09 23:38:40.506492742 +0000 @@ -538,7 +538,7 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

    +

    Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

    @@ -776,7 +776,7 @@

    If the shape function is vector-valued, then this returns the only non- zero component. If the shape function has more than one non-zero component (i.e. it is not primitive), then throw an exception of type ExcShapeFunctionNotPrimitive. In that case, use the shape_value_component() function.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
    iNumber of the shape function $\varphi_i$ to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
    q_pointNumber of the quadrature point at which function is to be evaluated
    @@ -826,7 +826,7 @@

    Compute one vector component of the value of a shape function at a quadrature point. If the finite element is scalar, then only component zero is allowed and the return value equals that of the shape_value() function. If the finite element is vector valued but all shape functions are primitive (i.e. they are non-zero in only one component), then the value returned by shape_value() equals that of this function for exactly one component. This function is therefore only of greater interest if the shape function is not primitive, but then it is necessary since the other function cannot be used.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated.
    iNumber of the shape function $\varphi_i$ to be evaluated.
    q_pointNumber of the quadrature point at which function is to be evaluated.
    componentvector component to be evaluated.
    @@ -874,7 +874,7 @@

    The same holds for the arguments of this function as for the shape_value() function.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated.
    iNumber of the shape function $\varphi_i$ to be evaluated.
    q_pointNumber of the quadrature point at which function is to be evaluated.
    @@ -1131,17 +1131,17 @@
    -

    Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.

    +

    Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.

    If the current cell is not active (i.e., it has children), then the finite element function is, strictly speaking, defined by shape functions that live on these child cells. Rather than evaluating the shape functions on the child cells, with the quadrature points defined on the current cell, this function first interpolates the finite element function to shape functions defined on the current cell, and then evaluates this interpolated function.

    This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. To get values of multi-component elements, there is another get_function_values() below, returning a vector of vectors of results.

    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]valuesThe values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
    [out]valuesThe values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
    -
    Postcondition
    values[q] will contain the value of the field described by fe_function at the $q$th quadrature point.
    +
    Postcondition
    values[q] will contain the value of the field described by fe_function at the $q$th quadrature point.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1186,7 +1186,7 @@

    This function does the same as the other get_function_values(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    values[q] is a vector of values of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the $c$th vector component at the $q$th quadrature point.
    +
    Postcondition
    values[q] is a vector of values of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the $c$th vector component at the $q$th quadrature point.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3320 of file fe_values.cc.

    @@ -1394,16 +1394,16 @@
    -

    Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $\nabla u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.

    +

    Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $\nabla u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.

    This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. There is a corresponding function of the same name for vector-valued finite elements.

    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]gradientsThe gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]gradientsThe gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    gradients[q] will contain the gradient of the field described by fe_function at the $q$th quadrature point. gradients[q][d] represents the derivative in coordinate direction $d$ at quadrature point $q$.
    +
    Postcondition
    gradients[q] will contain the gradient of the field described by fe_function at the $q$th quadrature point. gradients[q][d] represents the derivative in coordinate direction $d$ at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1448,7 +1448,7 @@

    This function does the same as the other get_function_gradients(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    gradients[q] is a vector of gradients of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the $c$th vector component at the $q$th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction $d$ of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    gradients[q] is a vector of gradients of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the $c$th vector component at the $q$th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction $d$ of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3463 of file fe_values.cc.

    @@ -1596,11 +1596,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]hessiansThe Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]hessiansThe Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    hessians[q] will contain the Hessian of the field described by fe_function at the $q$th quadrature point. hessians[q][i][j] represents the $(i,j)$th component of the matrix of second derivatives at quadrature point $q$.
    +
    Postcondition
    hessians[q] will contain the Hessian of the field described by fe_function at the $q$th quadrature point. hessians[q][i][j] represents the $(i,j)$th component of the matrix of second derivatives at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1650,7 +1650,7 @@

    This function does the same as the other get_function_hessians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    hessians[q] is a vector of Hessians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the $c$th vector component at the $q$th quadrature point. Consequently, hessians[q][c][i][j] is the $(i,j)$th component of the matrix of second derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    hessians[q] is a vector of Hessians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the $c$th vector component at the $q$th quadrature point. Consequently, hessians[q][c][i][j] is the $(i,j)$th component of the matrix of second derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3576 of file fe_values.cc.

    @@ -1799,11 +1799,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]laplaciansThe Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
    [out]laplaciansThe Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
    -
    Postcondition
    laplacians[q] will contain the Laplacian of the field described by fe_function at the $q$th quadrature point.
    +
    Postcondition
    laplacians[q] will contain the Laplacian of the field described by fe_function at the $q$th quadrature point.
    For each component of the output vector, there holds laplacians[q]=trace(hessians[q]), where hessians would be the output of the get_function_hessians() function.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    @@ -1850,7 +1850,7 @@

    This function does the same as the other get_function_laplacians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    laplacians[q] is a vector of Laplacians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the $c$th vector component at the $q$th quadrature point.
    +
    Postcondition
    laplacians[q] is a vector of Laplacians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the $c$th vector component at the $q$th quadrature point.
    For each component of the output vector, there holds laplacians[q][c]=trace(hessians[q][c]), where hessians would be the output of the get_function_hessians() function.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2050,11 +2050,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]third_derivativesThe third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]third_derivativesThe third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    third_derivatives[q] will contain the third derivatives of the field described by fe_function at the $q$th quadrature point. third_derivatives[q][i][j][k] represents the $(i,j,k)$th component of the 3rd order tensor of third derivatives at quadrature point $q$.
    +
    Postcondition
    third_derivatives[q] will contain the third derivatives of the field described by fe_function at the $q$th quadrature point. third_derivatives[q][i][j][k] represents the $(i,j,k)$th component of the 3rd order tensor of third derivatives at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_3rd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2104,7 +2104,7 @@

    This function does the same as the other get_function_third_derivatives(), but applied to multi-component (vector- valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the $c$th vector component at the $q$th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the $(i,j,k)$th component of the tensor of third derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the $c$th vector component at the $q$th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the $(i,j,k)$th component of the tensor of third derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_3rd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3826 of file fe_values.cc.

    @@ -2461,7 +2461,7 @@

    Mapped quadrature weight. If this object refers to a volume evaluation (i.e. the derived class is of type FEValues), then this is the Jacobi determinant times the weight of the q_pointth unit quadrature point.

    For surface evaluations (i.e. classes FEFaceValues or FESubfaceValues), it is the mapped surface element times the weight of the quadrature point.

    -

    You can think of the quantity returned by this function as the volume or surface element $dx, ds$ in the integral that we implement here by quadrature.

    +

    You can think of the quantity returned by this function as the volume or surface element $dx, ds$ in the integral that we implement here by quadrature.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_JxW_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2518,7 +2518,7 @@
    -

    Return the Jacobian of the transformation at the specified quadrature point, i.e. $J_{ij}=dx_i/d\hat x_j$

    +

    Return the Jacobian of the transformation at the specified quadrature point, i.e. $J_{ij}=dx_i/d\hat x_j$

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2576,7 +2576,7 @@
    -

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijk}=dJ_{jk}/d\hat x_i$.

    +

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijk}=dJ_{jk}/d\hat x_i$.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2634,7 +2634,7 @@
    -

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. $G_{ijk}=dJ_{iJ}/d\hat x_K (J_{jJ})^{-1} (J_{kK})^{-1}$.

    +

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. $G_{ijk}=dJ_{iJ}/d\hat x_K (J_{jJ})^{-1} (J_{kK})^{-1}$.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_pushed_forward_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesBase.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesBase.html 2023-08-09 23:38:40.590493368 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesBase.html 2023-08-09 23:38:40.590493368 +0000 @@ -627,7 +627,7 @@

    If the shape function is vector-valued, then this returns the only non- zero component. If the shape function has more than one non-zero component (i.e. it is not primitive), then throw an exception of type ExcShapeFunctionNotPrimitive. In that case, use the shape_value_component() function.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
    iNumber of the shape function $\varphi_i$ to be evaluated. Note that this number runs from zero to dofs_per_cell, even in the case of an FEFaceValues or FESubfaceValues object.
    q_pointNumber of the quadrature point at which function is to be evaluated
    @@ -669,7 +669,7 @@

    Compute one vector component of the value of a shape function at a quadrature point. If the finite element is scalar, then only component zero is allowed and the return value equals that of the shape_value() function. If the finite element is vector valued but all shape functions are primitive (i.e. they are non-zero in only one component), then the value returned by shape_value() equals that of this function for exactly one component. This function is therefore only of greater interest if the shape function is not primitive, but then it is necessary since the other function cannot be used.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated.
    iNumber of the shape function $\varphi_i$ to be evaluated.
    q_pointNumber of the quadrature point at which function is to be evaluated.
    componentvector component to be evaluated.
    @@ -709,7 +709,7 @@

    The same holds for the arguments of this function as for the shape_value() function.

    Parameters
    - +
    iNumber of the shape function $\varphi_i$ to be evaluated.
    iNumber of the shape function $\varphi_i$ to be evaluated.
    q_pointNumber of the quadrature point at which function is to be evaluated.
    @@ -918,17 +918,17 @@
    -

    Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.

    +

    Return the values of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and the related get_function_gradients() function is also used in step-15 along with numerous other tutorial programs.

    If the current cell is not active (i.e., it has children), then the finite element function is, strictly speaking, defined by shape functions that live on these child cells. Rather than evaluating the shape functions on the child cells, with the quadrature points defined on the current cell, this function first interpolates the finite element function to shape functions defined on the current cell, and then evaluates this interpolated function.

    This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. To get values of multi-component elements, there is another get_function_values() below, returning a vector of vectors of results.

    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]valuesThe values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
    [out]valuesThe values of the function specified by fe_function at the quadrature points of the current cell. The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the values of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the solution vector.
    -
    Postcondition
    values[q] will contain the value of the field described by fe_function at the $q$th quadrature point.
    +
    Postcondition
    values[q] will contain the value of the field described by fe_function at the $q$th quadrature point.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -965,7 +965,7 @@

    This function does the same as the other get_function_values(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    values[q] is a vector of values of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the $c$th vector component at the $q$th quadrature point.
    +
    Postcondition
    values[q] is a vector of values of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by values[q] equals the number of components of the finite element, i.e. values[q](c) returns the value of the $c$th vector component at the $q$th quadrature point.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3320 of file fe_values.cc.

    @@ -1141,16 +1141,16 @@
    -

    Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $\nabla u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.

    +

    Return the gradients of a finite element function at the quadrature points of the current cell, face, or subface (selected the last time the reinit() function was called). That is, if the first argument fe_function is a vector of nodal values of a finite element function $u_h(\mathbf x)$ defined on a DoFHandler object, then the output vector (the second argument, values) is the vector of values $\nabla u_h(\mathbf x_q^K)$ where $x_q^K$ are the quadrature points on the current cell $K$. This function is first discussed in the Results section of step-4, and it is also used in step-15 along with numerous other tutorial programs.

    This function may only be used if the finite element in use is a scalar one, i.e. has only one vector component. There is a corresponding function of the same name for vector-valued finite elements.

    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]gradientsThe gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]gradientsThe gradients of the function specified by fe_function at the quadrature points of the current cell. The gradients are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the gradients of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    gradients[q] will contain the gradient of the field described by fe_function at the $q$th quadrature point. gradients[q][d] represents the derivative in coordinate direction $d$ at quadrature point $q$.
    +
    Postcondition
    gradients[q] will contain the gradient of the field described by fe_function at the $q$th quadrature point. gradients[q][d] represents the derivative in coordinate direction $d$ at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1187,7 +1187,7 @@

    This function does the same as the other get_function_gradients(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    gradients[q] is a vector of gradients of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the $c$th vector component at the $q$th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction $d$ of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    gradients[q] is a vector of gradients of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by gradients[q] equals the number of components of the finite element, i.e. gradients[q][c] returns the gradient of the $c$th vector component at the $q$th quadrature point. Consequently, gradients[q][c][d] is the derivative in coordinate direction $d$ of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3463 of file fe_values.cc.

    @@ -1311,11 +1311,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]hessiansThe Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]hessiansThe Hessians of the function specified by fe_function at the quadrature points of the current cell. The Hessians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Hessians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    hessians[q] will contain the Hessian of the field described by fe_function at the $q$th quadrature point. hessians[q][i][j] represents the $(i,j)$th component of the matrix of second derivatives at quadrature point $q$.
    +
    Postcondition
    hessians[q] will contain the Hessian of the field described by fe_function at the $q$th quadrature point. hessians[q][i][j] represents the $(i,j)$th component of the matrix of second derivatives at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1357,7 +1357,7 @@

    This function does the same as the other get_function_hessians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    hessians[q] is a vector of Hessians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the $c$th vector component at the $q$th quadrature point. Consequently, hessians[q][c][i][j] is the $(i,j)$th component of the matrix of second derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    hessians[q] is a vector of Hessians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by hessians[q] equals the number of components of the finite element, i.e. hessians[q][c] returns the Hessian of the $c$th vector component at the $q$th quadrature point. Consequently, hessians[q][c][i][j] is the $(i,j)$th component of the matrix of second derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3576 of file fe_values.cc.

    @@ -1482,11 +1482,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]laplaciansThe Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
    [out]laplaciansThe Laplacians of the function specified by fe_function at the quadrature points of the current cell. The Laplacians are computed in real space (as opposed to on the unit cell). The object is assume to already have the correct size. The data type stored by this output vector must be what you get when you multiply the Laplacians of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument). This happens to be equal to the type of the elements of the input vector.
    -
    Postcondition
    laplacians[q] will contain the Laplacian of the field described by fe_function at the $q$th quadrature point.
    +
    Postcondition
    laplacians[q] will contain the Laplacian of the field described by fe_function at the $q$th quadrature point.
    For each component of the output vector, there holds laplacians[q]=trace(hessians[q]), where hessians would be the output of the get_function_hessians() function.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    @@ -1525,7 +1525,7 @@

    This function does the same as the other get_function_laplacians(), but applied to multi-component (vector-valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    laplacians[q] is a vector of Laplacians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the $c$th vector component at the $q$th quadrature point.
    +
    Postcondition
    laplacians[q] is a vector of Laplacians of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by laplacians[q] equals the number of components of the finite element, i.e. laplacians[q][c] returns the Laplacian of the $c$th vector component at the $q$th quadrature point.
    For each component of the output vector, there holds laplacians[q][c]=trace(hessians[q][c]), where hessians would be the output of the get_function_hessians() function.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1693,11 +1693,11 @@
    Parameters
    - +
    [in]fe_functionA vector of values that describes (globally) the finite element function that this function should evaluate at the quadrature points of the current cell.
    [out]third_derivativesThe third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    [out]third_derivativesThe third derivatives of the function specified by fe_function at the quadrature points of the current cell. The third derivatives are computed in real space (as opposed to on the unit cell). The object is assumed to already have the correct size. The data type stored by this output vector must be what you get when you multiply the third derivatives of shape function times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).
    -
    Postcondition
    third_derivatives[q] will contain the third derivatives of the field described by fe_function at the $q$th quadrature point. third_derivatives[q][i][j][k] represents the $(i,j,k)$th component of the 3rd order tensor of third derivatives at quadrature point $q$.
    +
    Postcondition
    third_derivatives[q] will contain the third derivatives of the field described by fe_function at the $q$th quadrature point. third_derivatives[q][i][j][k] represents the $(i,j,k)$th component of the 3rd order tensor of third derivatives at quadrature point $q$.
    Note
    The actual data type of the input vector may be either a Vector<T>, BlockVector<T>, or one of the PETSc or Trilinos vector wrapper classes. It represents a global vector of DoF values associated with the DoFHandler object with which this FEValues object was last initialized.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_3rd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -1739,7 +1739,7 @@

    This function does the same as the other get_function_third_derivatives(), but applied to multi-component (vector- valued) elements. The meaning of the arguments is as explained there.

    -
    Postcondition
    third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the $c$th vector component at the $q$th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the $(i,j,k)$th component of the tensor of third derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    +
    Postcondition
    third_derivatives[q] is a vector of third derivatives of the field described by fe_function at the $q$th quadrature point. The size of the vector accessed by third_derivatives[q] equals the number of components of the finite element, i.e. third_derivatives[q][c] returns the third derivative of the $c$th vector component at the $q$th quadrature point. Consequently, third_derivatives[q][c][i][j][k] is the $(i,j,k)$th component of the tensor of third derivatives of the $c$th vector component of the vector field at quadrature point $q$ of the current cell.
    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_3rd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 3826 of file fe_values.cc.

    @@ -2022,7 +2022,7 @@

    Mapped quadrature weight. If this object refers to a volume evaluation (i.e. the derived class is of type FEValues), then this is the Jacobi determinant times the weight of the q_pointth unit quadrature point.

    For surface evaluations (i.e. classes FEFaceValues or FESubfaceValues), it is the mapped surface element times the weight of the quadrature point.

    -

    You can think of the quantity returned by this function as the volume or surface element $dx, ds$ in the integral that we implement here by quadrature.

    +

    You can think of the quantity returned by this function as the volume or surface element $dx, ds$ in the integral that we implement here by quadrature.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_JxW_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2063,7 +2063,7 @@
    -

    Return the Jacobian of the transformation at the specified quadrature point, i.e. $J_{ij}=dx_i/d\hat x_j$

    +

    Return the Jacobian of the transformation at the specified quadrature point, i.e. $J_{ij}=dx_i/d\hat x_j$

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2105,7 +2105,7 @@
    -

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijk}=dJ_{jk}/d\hat x_i$.

    +

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijk}=dJ_{jk}/d\hat x_i$.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2147,7 +2147,7 @@
    -

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. $G_{ijk}=dJ_{iJ}/d\hat x_K (J_{jJ})^{-1} (J_{kK})^{-1}$.

    +

    Return the second derivative of the transformation from unit to real cell, i.e. the first derivative of the Jacobian, at the specified quadrature point, pushed forward to the real cell coordinates, i.e. $G_{ijk}=dJ_{iJ}/d\hat x_K (J_{jJ})^{-1} (J_{kK})^{-1}$.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_pushed_forward_grads flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -2189,7 +2189,7 @@
    -

    Return the third derivative of the transformation from unit to real cell, i.e. the second derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijkl}=\frac{d^2J_{ij}}{d\hat x_k d\hat x_l}$.

    +

    Return the third derivative of the transformation from unit to real cell, i.e. the second derivative of the Jacobian, at the specified quadrature point, i.e. $G_{ijkl}=\frac{d^2J_{ij}}{d\hat x_k d\hat x_l}$.

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_jacobian_2nd_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Scalar.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Scalar.html 2023-08-09 23:38:40.630493667 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Scalar.html 2023-08-09 23:38:40.630493667 +0000 @@ -734,7 +734,7 @@

    Return the values of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    This function is the equivalent of the FEValuesBase::get_function_values function but it only works on the selected scalar component.

    -

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 1545 of file fe_values.cc.

    @@ -819,7 +819,7 @@

    Return the gradients of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    This function is the equivalent of the FEValuesBase::get_function_gradients function but it only works on the selected scalar component.

    -

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 1600 of file fe_values.cc.

    @@ -890,7 +890,7 @@

    Return the Hessians of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    This function is the equivalent of the FEValuesBase::get_function_hessians function but it only works on the selected scalar component.

    -

    The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 1654 of file fe_values.cc.

    @@ -961,7 +961,7 @@

    Return the Laplacians of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called. The Laplacians are the trace of the Hessians.

    This function is the equivalent of the FEValuesBase::get_function_laplacians function but it only works on the selected scalar component.

    -

    The data type stored by the output vector must be what you get when you multiply the Laplacians of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the Laplacians of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 1708 of file fe_values.cc.

    @@ -1032,7 +1032,7 @@

    Return the third derivatives of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    This function is the equivalent of the FEValuesBase::get_function_third_derivatives function but it only works on the selected scalar component.

    -

    The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_third_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 1762 of file fe_values.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1SymmetricTensor_3_012_00_01dim_00_01spacedim_01_4.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1SymmetricTensor_3_012_00_01dim_00_01spacedim_01_4.html 2023-08-09 23:38:40.658493876 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1SymmetricTensor_3_012_00_01dim_00_01spacedim_01_4.html 2023-08-09 23:38:40.658493876 +0000 @@ -154,9 +154,9 @@

    Detailed Description

    template<int dim, int spacedim>
    class FEValuesViews::SymmetricTensor< 2, dim, spacedim >

    A class representing a view to a set of (dim*dim + dim)/2 components forming a symmetric second-order tensor from a vector-valued finite element. Views are discussed in the Handling vector valued problems module.

    -

    This class allows to query the value and divergence of (components of) shape functions and solutions representing symmetric tensors. The divergence of a symmetric tensor $S_{ij}, 0\le i,j<\text{dim}$ is defined as $d_i = \sum_j \frac{\partial S_{ij}}{\partial x_j}, 0\le
-i<\text{dim}$, which due to the symmetry of the tensor is also $d_i =
-\sum_j \frac{\partial S_{ji}}{\partial x_j}$. In other words, it due to the symmetry of $S$ it does not matter whether we apply the nabla operator by row or by column to get the divergence.

    +

    This class allows to query the value and divergence of (components of) shape functions and solutions representing symmetric tensors. The divergence of a symmetric tensor $S_{ij}, 0\le i,j<\text{dim}$ is defined as $d_i = \sum_j \frac{\partial S_{ij}}{\partial x_j}, 0\le
+i<\text{dim}$, which due to the symmetry of the tensor is also $d_i =
+\sum_j \frac{\partial S_{ji}}{\partial x_j}$. In other words, it due to the symmetry of $S$ it does not matter whether we apply the nabla operator by row or by column to get the divergence.

    You get an object of this type if you apply a FEValuesExtractors::SymmetricTensor to an FEValues, FEFaceValues or FESubfaceValues object.

    Definition at line 1477 of file fe_values.h.

    @@ -507,7 +507,7 @@

    Return the values of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    This function is the equivalent of the FEValuesBase::get_function_values function but it only works on the selected vector components.

    -

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 2263 of file fe_values.cc.

    @@ -593,7 +593,7 @@

    Return the divergence of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    There is no equivalent function such as FEValuesBase::get_function_divergences in the FEValues classes but the information can be obtained from FEValuesBase::get_function_gradients, of course.

    See the general discussion of this class for a definition of the divergence.

    -

    The data type stored by the output vector must be what you get when you multiply the divergences of shape functions (i.e., divergence_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the divergences of shape functions (i.e., divergence_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 2317 of file fe_values.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Tensor_3_012_00_01dim_00_01spacedim_01_4.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Tensor_3_012_00_01dim_00_01spacedim_01_4.html 2023-08-09 23:38:40.686494085 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Tensor_3_012_00_01dim_00_01spacedim_01_4.html 2023-08-09 23:38:40.686494085 +0000 @@ -167,8 +167,8 @@

    Detailed Description

    template<int dim, int spacedim>
    class FEValuesViews::Tensor< 2, dim, spacedim >

    A class representing a view to a set of dim*dim components forming a second-order tensor from a vector-valued finite element. Views are discussed in the Handling vector valued problems module.

    -

    This class allows to query the value, gradient and divergence of (components of) shape functions and solutions representing tensors. The divergence of a tensor $T_{ij},\, 0\le i,j<\text{dim}$ is defined as $d_i =
-\sum_j \frac{\partial T_{ij}}{\partial x_j}, \, 0\le i<\text{dim}$, whereas its gradient is $G_{ijk} = \frac{\partial T_{ij}}{\partial x_k}$.

    +

    This class allows to query the value, gradient and divergence of (components of) shape functions and solutions representing tensors. The divergence of a tensor $T_{ij},\, 0\le i,j<\text{dim}$ is defined as $d_i =
+\sum_j \frac{\partial T_{ij}}{\partial x_j}, \, 0\le i<\text{dim}$, whereas its gradient is $G_{ijk} = \frac{\partial T_{ij}}{\partial x_k}$.

    You get an object of this type if you apply a FEValuesExtractors::Tensor to an FEValues, FEFaceValues or FESubfaceValues object.

    Definition at line 1815 of file fe_values.h.

    @@ -619,7 +619,7 @@

    Return the values of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    This function is the equivalent of the FEValuesBase::get_function_values function but it only works on the selected vector components.

    -

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 2373 of file fe_values.cc.

    @@ -705,7 +705,7 @@

    Return the divergence of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    There is no equivalent function such as FEValuesBase::get_function_divergences in the FEValues classes but the information can be obtained from FEValuesBase::get_function_gradients, of course.

    See the general discussion of this class for a definition of the divergence.

    -

    The data type stored by the output vector must be what you get when you multiply the divergences of shape functions (i.e., divergence_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the divergences of shape functions (i.e., divergence_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 2427 of file fe_values.cc.

    @@ -776,7 +776,7 @@

    Return the gradient of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    See the general discussion of this class for a definition of the gradient.

    -

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 2482 of file fe_values.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Vector.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Vector.html 2023-08-09 23:38:40.730494415 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFEValuesViews_1_1Vector.html 2023-08-09 23:38:40.730494415 +0000 @@ -228,8 +228,8 @@
    template<int dim, int spacedim = dim>
    class FEValuesViews::Vector< dim, spacedim >

    A class representing a view to a set of spacedim components forming a vector part of a vector-valued finite element. Views are discussed in the Handling vector valued problems module.

    Note that in the current context, a vector is meant in the sense physics uses it: it has spacedim components that behave in specific ways under coordinate system transformations. Examples include velocity or displacement fields. This is opposed to how mathematics uses the word "vector" (and how we use this word in other contexts in the library, for example in the Vector class), where it really stands for a collection of numbers. An example of this latter use of the word could be the set of concentrations of chemical species in a flame; however, these are really just a collection of scalar variables, since they do not change if the coordinate system is rotated, unlike the components of a velocity vector, and consequently, this class should not be used for this context.

    -

    This class allows to query the value, gradient and divergence of (components of) shape functions and solutions representing vectors. The gradient of a vector $d_{k}, 0\le k<\text{dim}$ is defined as $S_{ij} =
-\frac{\partial d_{i}}{\partial x_j}, 0\le i,j<\text{dim}$.

    +

    This class allows to query the value, gradient and divergence of (components of) shape functions and solutions representing vectors. The gradient of a vector $d_{k}, 0\le k<\text{dim}$ is defined as $S_{ij} =
+\frac{\partial d_{i}}{\partial x_j}, 0\le i,j<\text{dim}$.

    You get an object of this type if you apply a FEValuesExtractors::Vector to an FEValues, FEFaceValues or FESubfaceValues object.

    Definition at line 675 of file fe_values.h.

    @@ -287,8 +287,8 @@

    An alias for the type of symmetrized gradients of the view this class represents. Here, for a set of dim components of the finite element, the symmetrized gradient is a SymmetricTensor<2,spacedim>.

    -

    The symmetric gradient of a vector field $\mathbf v$ is defined as $\varepsilon(\mathbf v)=\frac 12 (\nabla \mathbf v + \nabla \mathbf
-v^T)$.

    +

    The symmetric gradient of a vector field $\mathbf v$ is defined as $\varepsilon(\mathbf v)=\frac 12 (\nabla \mathbf v + \nabla \mathbf
+v^T)$.

    Definition at line 705 of file fe_values.h.

    @@ -827,8 +827,8 @@

    Return the symmetric gradient (a symmetric tensor of rank 2) of the vector component selected by this view, for the shape function and quadrature point selected by the arguments.

    -

    The symmetric gradient is defined as $\frac 12 [(\nabla \phi_i(x_q)) +
-(\nabla \phi_i(x_q))^T]$, where $\phi_i$ represents the dim components selected from the FEValuesBase object, and $x_q$ is the location of the $q$-th quadrature point.

    +

    The symmetric gradient is defined as $\frac 12 [(\nabla \phi_i(x_q)) +
+(\nabla \phi_i(x_q))^T]$, where $\phi_i$ represents the dim components selected from the FEValuesBase object, and $x_q$ is the location of the $q$-th quadrature point.

    Note
    The meaning of the arguments is as documented for the value() function.
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.
    @@ -893,16 +893,16 @@

    Return the vector curl of the vector components selected by this view, for the shape function and quadrature point selected by the arguments. For 1d this function does not make any sense. Thus it is not implemented for spacedim=1. In 2d the curl is defined as

    -\begin{equation*}
+<picture><source srcset=\begin{equation*}
 \operatorname{curl}(u) \dealcoloneq \frac{du_2}{dx} -\frac{du_1}{dy},
-\end{equation*} +\end{equation*}" src="form_1247.png"/>

    whereas in 3d it is given by

    -\begin{equation*}
+<picture><source srcset=\begin{equation*}
 \operatorname{curl}(u) \dealcoloneq \left( \begin{array}{c}
 \frac{du_3}{dy}-\frac{du_2}{dz}\\ \frac{du_1}{dz}-\frac{du_3}{dx}\\
 \frac{du_2}{dx}-\frac{du_1}{dy} \end{array} \right).
-\end{equation*} +\end{equation*}" src="form_1248.png"/>

    Note
    The meaning of the arguments is as documented for the value() function.
    @@ -1004,7 +1004,7 @@

    Return the values of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    This function is the equivalent of the FEValuesBase::get_function_values function but it only works on the selected vector components.

    -

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the values of shape functions (i.e., value_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_values flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 1818 of file fe_values.cc.

    @@ -1089,7 +1089,7 @@

    Return the gradients of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    This function is the equivalent of the FEValuesBase::get_function_gradients function but it only works on the selected vector components.

    -

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the gradients of shape functions (i.e., gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 1872 of file fe_values.cc.

    @@ -1159,10 +1159,10 @@

    Return the symmetrized gradients of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    -

    The symmetric gradient of a vector field $\mathbf v$ is defined as $\varepsilon(\mathbf v)=\frac 12 (\nabla \mathbf v + \nabla \mathbf
-v^T)$.

    +

    The symmetric gradient of a vector field $\mathbf v$ is defined as $\varepsilon(\mathbf v)=\frac 12 (\nabla \mathbf v + \nabla \mathbf
+v^T)$.

    Note
    There is no equivalent function such as FEValuesBase::get_function_symmetric_gradients in the FEValues classes but the information can be obtained from FEValuesBase::get_function_gradients, of course.
    -

    The data type stored by the output vector must be what you get when you multiply the symmetric gradients of shape functions (i.e., symmetric_gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the symmetric gradients of shape functions (i.e., symmetric_gradient_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 1926 of file fe_values.cc.

    @@ -1233,7 +1233,7 @@

    Return the divergence of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    There is no equivalent function such as FEValuesBase::get_function_divergences in the FEValues classes but the information can be obtained from FEValuesBase::get_function_gradients, of course.

    -

    The data type stored by the output vector must be what you get when you multiply the divergences of shape functions (i.e., divergence_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the divergences of shape functions (i.e., divergence_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 1982 of file fe_values.cc.

    @@ -1304,7 +1304,7 @@

    Return the curl of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    There is no equivalent function such as FEValuesBase::get_function_curls in the FEValues classes but the information can be obtained from FEValuesBase::get_function_gradients, of course.

    -

    The data type stored by the output vector must be what you get when you multiply the curls of shape functions (i.e., curl_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the curls of shape functions (i.e., curl_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_gradients flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 2037 of file fe_values.cc.

    @@ -1375,7 +1375,7 @@

    Return the Hessians of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    This function is the equivalent of the FEValuesBase::get_function_hessians function but it only works on the selected vector components.

    -

    The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the Hessians of shape functions (i.e., hessian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 2091 of file fe_values.cc.

    @@ -1446,7 +1446,7 @@

    Return the Laplacians of the selected vector components of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called. The Laplacians are the trace of the Hessians.

    This function is the equivalent of the FEValuesBase::get_function_laplacians function but it only works on the selected vector components.

    -

    The data type stored by the output vector must be what you get when you multiply the Laplacians of shape functions (i.e., laplacian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the Laplacians of shape functions (i.e., laplacian_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_hessians flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 2145 of file fe_values.cc.

    @@ -1517,7 +1517,7 @@

    Return the third derivatives of the selected scalar component of the finite element function characterized by fe_function at the quadrature points of the cell, face or subface selected the last time the reinit function of the FEValues object was called.

    This function is the equivalent of the FEValuesBase::get_function_third_derivatives function but it only works on the selected scalar component.

    -

    The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    +

    The data type stored by the output vector must be what you get when you multiply the third derivatives of shape functions (i.e., third_derivative_type) times the type used to store the values of the unknowns $U_j$ of your finite element vector $U$ (represented by the fe_function argument).

    Note
    For this function to work properly, the underlying FEValues, FEFaceValues, or FESubfaceValues object on which you call it must have computed the information you are requesting. To do so, the update_third_derivatives flag must be an element of the list of UpdateFlags that you passed to the constructor of this object. See The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues for more information.

    Definition at line 2207 of file fe_values.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__ABF.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__ABF.html 2023-08-09 23:38:40.858495370 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__ABF.html 2023-08-09 23:38:40.858495370 +0000 @@ -763,11 +763,11 @@
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    @@ -3037,7 +3037,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3758,7 +3758,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3866,7 +3866,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4126,7 +4126,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4185,9 +4185,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__BDM.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__BDM.html 2023-08-09 23:38:40.990496355 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__BDM.html 2023-08-09 23:38:40.994496385 +0000 @@ -730,11 +730,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    @@ -2980,7 +2980,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3701,7 +3701,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3809,7 +3809,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4069,7 +4069,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4128,9 +4128,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__BernardiRaugel.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__BernardiRaugel.html 2023-08-09 23:38:41.126497371 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__BernardiRaugel.html 2023-08-09 23:38:41.130497400 +0000 @@ -489,8 +489,8 @@

    Detailed Description

    template<int dim>
    class FE_BernardiRaugel< dim >

    The Bernardi-Raugel element.

    -

    This class implements the non-standard Bernardi-Raugel (BR) element that can be used as one part of a stable velocity/pressure pair for the Stokes equation. The BR element can be seen as either an enriched version of the $Q_1^d$ element with added bubble functions on each edge (in 2d) or face (in 3d), or as a reduced version of the $Q_2^d$ element. It addresses the fact that the $Q_1^d\times
-Q_0$ combination is not inf-sup stable (requiring a larger velocity space), and that the $Q_2^d\times Q_1$ combination is stable but sub-optimal since the velocity space is too large relative to the pressure space to provide additional accuracy commensurate with the cost of the large number of velocity unknowns.

    +

    This class implements the non-standard Bernardi-Raugel (BR) element that can be used as one part of a stable velocity/pressure pair for the Stokes equation. The BR element can be seen as either an enriched version of the $Q_1^d$ element with added bubble functions on each edge (in 2d) or face (in 3d), or as a reduced version of the $Q_2^d$ element. It addresses the fact that the $Q_1^d\times
+Q_0$ combination is not inf-sup stable (requiring a larger velocity space), and that the $Q_2^d\times Q_1$ combination is stable but sub-optimal since the velocity space is too large relative to the pressure space to provide additional accuracy commensurate with the cost of the large number of velocity unknowns.

    The element was introduced in the following paper:

    @article{BR85,
    author = {Christine Bernardi and Genevi{\`e}ve Raugel},
    title = {Analysis of some finite elements for the {S}tokes problem},
    @@ -505,7 +505,7 @@
    }

    Degrees of freedom

    The BR1 element has dim degrees of freedom on each vertex and 1 on each face. The shape functions are ordered by the $(Q_1)^d$ shape functions supported on each vertex, increasing according to vertex ordering on the element in GeometryInfo, then the bubble functions follow in the ordering given in PolynomialsBernardiRaugel.

    -

    This element only has 1 degree (degree $p=1$) because it yields an LBB stable pair BR1-P0 for Stokes problems which is lower degree than the Taylor-Hood element. The pair is sometimes referred to as an enriched P1-P0 element or a reduced P2-P0 element.

    +

    This element only has 1 degree (degree $p=1$) because it yields an LBB stable pair BR1-P0 for Stokes problems which is lower degree than the Taylor-Hood element. The pair is sometimes referred to as an enriched P1-P0 element or a reduced P2-P0 element.

    This element does not support hanging nodes or multigrid in the current implementation.

    Some numerical experiments have shown that this element may converge with first-order accuracy when using the BR1-Q0 pair for the mixed Laplace equation in step-20.

    @@ -637,7 +637,7 @@

    Constructor for the Bernardi-Raugel element of degree p. The only supported degree is 1.

      -
    • p: The degree of the element $p=1$ for $BR_1$.
    • +
    • p: The degree of the element $p=1$ for $BR_1$.

    Definition at line 44 of file fe_bernardi_raugel.cc.

    @@ -741,11 +741,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    @@ -2955,7 +2955,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3676,7 +3676,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3784,7 +3784,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4044,7 +4044,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4103,9 +4103,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Bernstein.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Bernstein.html 2023-08-09 23:38:41.254498326 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Bernstein.html 2023-08-09 23:38:41.254498326 +0000 @@ -2633,17 +2633,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -2687,21 +2687,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -3903,7 +3903,7 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4011,7 +4011,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4240,7 +4240,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4299,9 +4299,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -4346,11 +4346,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGBDM.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGBDM.html 2023-08-09 23:38:41.386499312 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGBDM.html 2023-08-09 23:38:41.390499342 +0000 @@ -2851,7 +2851,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3572,7 +3572,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3680,7 +3680,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3940,7 +3940,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -3999,9 +3999,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -4046,11 +4046,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGNedelec.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGNedelec.html 2023-08-09 23:38:41.518500298 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGNedelec.html 2023-08-09 23:38:41.518500298 +0000 @@ -2851,7 +2851,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3572,7 +3572,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3680,7 +3680,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3940,7 +3940,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -3999,9 +3999,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -4046,11 +4046,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGP.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGP.html 2023-08-09 23:38:41.650501283 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGP.html 2023-08-09 23:38:41.654501314 +0000 @@ -481,14 +481,14 @@
    This class is only partially implemented for the codimension one case (spacedim != dim ), since no passage of information between meshes of different refinement level is possible because the embedding and projection matrices are not computed in the class constructor.

    Transformation properties

    -

    It is worth noting that under a (bi-, tri-)linear mapping, the space described by this element does not contain $P(k)$, even if we use a basis of polynomials of degree $k$. Consequently, for example, on meshes with non-affine cells, a linear function can not be exactly represented by elements of type FE_DGP(1) or FE_DGPMonomial(1).

    +

    It is worth noting that under a (bi-, tri-)linear mapping, the space described by this element does not contain $P(k)$, even if we use a basis of polynomials of degree $k$. Consequently, for example, on meshes with non-affine cells, a linear function can not be exactly represented by elements of type FE_DGP(1) or FE_DGPMonomial(1).

    This can be understood by the following 2-d example: consider the cell with vertices at $(0,0),(1,0),(0,1),(s,s)$:

    -

    For this cell, a bilinear transformation $F$ produces the relations $x=\hat
-x+\hat x\hat y$ and $y=\hat y+\hat x\hat y$ that correlate reference coordinates $\hat x,\hat y$ and coordinates in real space $x,y$. Under this mapping, the constant function is clearly mapped onto itself, but the two other shape functions of the $P_1$ space, namely $\phi_1(\hat x,\hat
+<p>For this cell, a bilinear transformation <picture><source srcset=$F$ produces the relations $x=\hat
+x+\hat x\hat y$ and $y=\hat y+\hat x\hat y$ that correlate reference coordinates $\hat x,\hat y$ and coordinates in real space $x,y$. Under this mapping, the constant function is clearly mapped onto itself, but the two other shape functions of the $P_1$ space, namely $\phi_1(\hat x,\hat
 y)=\hat x$ and $\phi_2(\hat x,\hat y)=\hat y$ are mapped onto $\phi_1(x,y)=\frac{x-t}{t(s-1)},\phi_2(x,y)=t$ where $t=\frac{y}{s-x+sx+y-sy}$.

    -

    For the simple case that $s=1$, i.e. if the real cell is the unit square, the expressions can be simplified to $t=y$ and $\phi_1(x,y)=x,\phi_2(x,y)=y$. However, for all other cases, the functions $\phi_1(x,y),\phi_2(x,y)$ are not linear any more, and neither is any linear combination of them. Consequently, the linear functions are not within the range of the mapped $P_1$ polynomials.

    +

    For the simple case that $s=1$, i.e. if the real cell is the unit square, the expressions can be simplified to $t=y$ and $\phi_1(x,y)=x,\phi_2(x,y)=y$. However, for all other cases, the functions $\phi_1(x,y),\phi_2(x,y)$ are not linear any more, and neither is any linear combination of them. Consequently, the linear functions are not within the range of the mapped $P_1$ polynomials.

    Visualization of shape functions

    In 2d, the shape functions of this element look as follows.

    $P_0$ element

    @@ -504,7 +504,7 @@

    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
    -

    $P_1$ element

    +

    $P_1$ element

    - @@ -528,7 +528,7 @@

    -
    @@ -516,9 +516,9 @@

    $P_1$ element, shape function 0

    +

    $P_1$ element, shape function 0

    -

    $P_1$ element, shape function 1

    +

    $P_1$ element, shape function 1

    $P_1$ element, shape function 2

    +

    $P_1$ element, shape function 2

    @@ -2573,17 +2573,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -2627,21 +2627,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -3301,7 +3301,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -4022,7 +4022,7 @@

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4130,7 +4130,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4359,7 +4359,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4418,9 +4418,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -4465,11 +4465,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGPMonomial.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGPMonomial.html 2023-08-09 23:38:41.790502329 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGPMonomial.html 2023-08-09 23:38:41.790502329 +0000 @@ -491,14 +491,14 @@

    The basis functions for this element are chosen to be the monomials listed above. Note that this is the main difference to the FE_DGP class that uses a set of polynomials of complete degree p that form a Legendre basis on the unit square. Thus, there, the mass matrix is diagonal, if the grid cells are parallelograms. The basis here does not have this property; however, it is simpler to compute. On the other hand, this element has the additional disadvantage that the local cell matrices usually have a worse condition number than the ones originating from the FE_DGP element.

    This class is not implemented for the codimension one case (spacedim != dim).

    Transformation properties

    -

    It is worth noting that under a (bi-, tri-)linear mapping, the space described by this element does not contain $P(k)$, even if we use a basis of polynomials of degree $k$. Consequently, for example, on meshes with non-affine cells, a linear function can not be exactly represented by elements of type FE_DGP(1) or FE_DGPMonomial(1).

    +

    It is worth noting that under a (bi-, tri-)linear mapping, the space described by this element does not contain $P(k)$, even if we use a basis of polynomials of degree $k$. Consequently, for example, on meshes with non-affine cells, a linear function can not be exactly represented by elements of type FE_DGP(1) or FE_DGPMonomial(1).

    This can be understood by the following 2-d example: consider the cell with vertices at $(0,0),(1,0),(0,1),(s,s)$:

    -

    For this cell, a bilinear transformation $F$ produces the relations $x=\hat
-x+\hat x\hat y$ and $y=\hat y+\hat x\hat y$ that correlate reference coordinates $\hat x,\hat y$ and coordinates in real space $x,y$. Under this mapping, the constant function is clearly mapped onto itself, but the two other shape functions of the $P_1$ space, namely $\phi_1(\hat x,\hat
+<p>For this cell, a bilinear transformation <picture><source srcset=$F$ produces the relations $x=\hat
+x+\hat x\hat y$ and $y=\hat y+\hat x\hat y$ that correlate reference coordinates $\hat x,\hat y$ and coordinates in real space $x,y$. Under this mapping, the constant function is clearly mapped onto itself, but the two other shape functions of the $P_1$ space, namely $\phi_1(\hat x,\hat
 y)=\hat x$ and $\phi_2(\hat x,\hat y)=\hat y$ are mapped onto $\phi_1(x,y)=\frac{x-t}{t(s-1)},\phi_2(x,y)=t$ where $t=\frac{y}{s-x+sx+y-sy}$.

    -

    For the simple case that $s=1$, i.e. if the real cell is the unit square, the expressions can be simplified to $t=y$ and $\phi_1(x,y)=x,\phi_2(x,y)=y$. However, for all other cases, the functions $\phi_1(x,y),\phi_2(x,y)$ are not linear any more, and neither is any linear combination of them. Consequently, the linear functions are not within the range of the mapped $P_1$ polynomials.

    +

    For the simple case that $s=1$, i.e. if the real cell is the unit square, the expressions can be simplified to $t=y$ and $\phi_1(x,y)=x,\phi_2(x,y)=y$. However, for all other cases, the functions $\phi_1(x,y),\phi_2(x,y)$ are not linear any more, and neither is any linear combination of them. Consequently, the linear functions are not within the range of the mapped $P_1$ polynomials.

    Visualization of shape functions

    In 2d, the shape functions of this element look as follows.

    $P_0$ element

    @@ -514,7 +514,7 @@

    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
    -

    $P_1$ element

    +

    $P_1$ element

    - @@ -538,7 +538,7 @@

    -
    @@ -526,9 +526,9 @@

    $P_1$ element, shape function 0

    +

    $P_1$ element, shape function 0

    -

    $P_1$ element, shape function 1

    +

    $P_1$ element, shape function 1

    $P_1$ element, shape function 2

    +

    $P_1$ element, shape function 2

    @@ -2727,17 +2727,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -2781,21 +2781,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -3689,7 +3689,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -4410,7 +4410,7 @@

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4518,7 +4518,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4778,7 +4778,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4837,9 +4837,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -4884,11 +4884,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGPNonparametric.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGPNonparametric.html 2023-08-09 23:38:41.918503284 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGPNonparametric.html 2023-08-09 23:38:41.918503284 +0000 @@ -475,7 +475,7 @@
    template<int dim, int spacedim = dim>
    class FE_DGPNonparametric< dim, spacedim >

    Discontinuous finite elements evaluated at the mapped quadrature points.

    Warning: this class does not work properly, yet. Don't use it!

    -

    This finite element implements complete polynomial spaces, that is, $d$-dimensional polynomials of order $k$.

    +

    This finite element implements complete polynomial spaces, that is, $d$-dimensional polynomials of order $k$.

    The polynomials are not mapped. Therefore, they are constant, linear, quadratic, etc. on any grid cell.

    Since the polynomials are evaluated at the quadrature points of the actual grid cell, no grid transfer and interpolation matrices are available.

    The purpose of this class is experimental, therefore the implementation will remain incomplete.

    @@ -495,7 +495,7 @@

    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
    -

    $P_1$ element

    +

    $P_1$ element

    - @@ -519,7 +519,7 @@

    -
    @@ -507,9 +507,9 @@

    $P_1$ element, shape function 0

    +

    $P_1$ element, shape function 0

    -

    $P_1$ element, shape function 1

    +

    $P_1$ element, shape function 1

    $P_1$ element, shape function 2

    +

    $P_1$ element, shape function 2

    @@ -2753,7 +2753,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3474,7 +3474,7 @@

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3582,7 +3582,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3842,7 +3842,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -3901,9 +3901,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -3948,11 +3948,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQ.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQ.html 2023-08-09 23:38:42.042504210 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQ.html 2023-08-09 23:38:42.042504210 +0000 @@ -505,7 +505,7 @@ *

    with node 13 being placed in the interior of the hex.

    Note, however, that these are just the Lagrange interpolation points of the shape functions. Even though they may physically be on the boundary of the cell, they are logically in the interior since there are no continuity requirements for these shape functions across cell boundaries. While discontinuous, when restricted to a single cell the shape functions of this element are exactly the same as those of the FE_Q element where they are shown visually.

    Unit support point distribution and conditioning of interpolation

    -

    When constructing an FE_DGQ element at polynomial degrees one or two, equidistant support points at 0 and 1 (linear case) or 0, 0.5, and 1 (quadratic case) are used. The unit support or nodal points xi are those points where the jth Lagrange polynomial satisfies the $\delta_{ij}$ property, i.e., where one polynomial is one and all the others are zero. For higher polynomial degrees, the support points are non-equidistant by default, and chosen to be the support points of the (degree+1)-order Gauss-Lobatto quadrature rule. This point distribution yields well-conditioned Lagrange interpolation at arbitrary polynomial degrees. By contrast, polynomials based on equidistant points get increasingly ill-conditioned as the polynomial degree increases. In interpolation, this effect is known as the Runge phenomenon. For Galerkin methods, the Runge phenomenon is typically not visible in the solution quality but rather in the condition number of the associated system matrices. For example, the elemental mass matrix of equidistant points at degree 10 has condition number 2.6e6, whereas the condition number for Gauss-Lobatto points is around 400.

    +

    When constructing an FE_DGQ element at polynomial degrees one or two, equidistant support points at 0 and 1 (linear case) or 0, 0.5, and 1 (quadratic case) are used. The unit support or nodal points xi are those points where the jth Lagrange polynomial satisfies the $\delta_{ij}$ property, i.e., where one polynomial is one and all the others are zero. For higher polynomial degrees, the support points are non-equidistant by default, and chosen to be the support points of the (degree+1)-order Gauss-Lobatto quadrature rule. This point distribution yields well-conditioned Lagrange interpolation at arbitrary polynomial degrees. By contrast, polynomials based on equidistant points get increasingly ill-conditioned as the polynomial degree increases. In interpolation, this effect is known as the Runge phenomenon. For Galerkin methods, the Runge phenomenon is typically not visible in the solution quality but rather in the condition number of the associated system matrices. For example, the elemental mass matrix of equidistant points at degree 10 has condition number 2.6e6, whereas the condition number for Gauss-Lobatto points is around 400.

    The Gauss-Lobatto points in 1d include the end points 0 and +1 of the unit interval. The interior points are shifted towards the end points, which gives a denser point distribution close to the element boundary.

    Definition at line 112 of file fe_dgq.h.

    @@ -2547,17 +2547,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -2601,21 +2601,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -3168,7 +3168,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3889,7 +3889,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3997,7 +3997,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4226,7 +4226,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4285,9 +4285,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQArbitraryNodes.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQArbitraryNodes.html 2023-08-09 23:38:42.166505136 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQArbitraryNodes.html 2023-08-09 23:38:42.166505136 +0000 @@ -2475,17 +2475,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -2529,21 +2529,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -3096,7 +3096,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3817,7 +3817,7 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3925,7 +3925,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4154,7 +4154,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4213,9 +4213,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQHermite.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQHermite.html 2023-08-09 23:38:42.286506032 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQHermite.html 2023-08-09 23:38:42.286506032 +0000 @@ -2479,17 +2479,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -2533,21 +2533,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -3100,7 +3100,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3821,7 +3821,7 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3929,7 +3929,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4158,7 +4158,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4217,9 +4217,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQLegendre.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQLegendre.html 2023-08-09 23:38:42.410506958 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGQLegendre.html 2023-08-09 23:38:42.414506988 +0000 @@ -2477,17 +2477,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -2531,21 +2531,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -3098,7 +3098,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3819,7 +3819,7 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3927,7 +3927,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4156,7 +4156,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4215,9 +4215,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGRaviartThomas.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGRaviartThomas.html 2023-08-09 23:38:42.546507975 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGRaviartThomas.html 2023-08-09 23:38:42.546507975 +0000 @@ -2851,7 +2851,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3572,7 +3572,7 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3680,7 +3680,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3940,7 +3940,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -3999,9 +3999,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -4046,11 +4046,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGVector.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGVector.html 2023-08-09 23:38:42.678508959 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__DGVector.html 2023-08-09 23:38:42.678508959 +0000 @@ -2869,7 +2869,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3590,7 +3590,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3698,7 +3698,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3958,7 +3958,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4017,9 +4017,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -4064,11 +4064,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Enriched.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Enriched.html 2023-08-09 23:38:42.806509915 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Enriched.html 2023-08-09 23:38:42.810509945 +0000 @@ -483,12 +483,12 @@

    Detailed Description

    template<int dim, int spacedim = dim>
    class FE_Enriched< dim, spacedim >

    Implementation of a partition of unity finite element method (PUM) by Babuska and Melenk which enriches a standard finite element with an enrichment function multiplied with another (usually linear) finite element:

    -\[
+<picture><source srcset=\[
 U(\mathbf x) = \sum_i N_i(\mathbf x) U_i + \sum_j N_j(\mathbf x) \sum_k
-F_k(\mathbf x) U_{jk} \] +F_k(\mathbf x) U_{jk} \]" src="form_1077.png"/>

    -

    where $ N_i(\mathbf x) $ and $ N_j(\mathbf x) $ are the underlying finite elements (including the mapping from the isoparametric element to the real element); $ F_k(\mathbf x) $ are the scalar enrichment functions in real space (e.g. $ 1/r $, $ \exp(-r) $, etc); $ U_i $ and $
-U_{jk} $ are the standard and enriched DoFs. This allows to include in the finite element space a priori knowledge about the partial differential equation being solved which in turn improves the local approximation properties of the spaces. This can be useful for highly oscillatory solutions, problems with domain corners or on unbounded domains or sudden changes of boundary conditions. PUM method uses finite element spaces which satisfy the partition of unity property (e.g. FE_Q). Among other properties this makes the resulting space to reproduce enrichment functions exactly.

    +

    where $ N_i(\mathbf x) $ and $ N_j(\mathbf x) $ are the underlying finite elements (including the mapping from the isoparametric element to the real element); $ F_k(\mathbf x) $ are the scalar enrichment functions in real space (e.g. $ 1/r $, $ \exp(-r) $, etc); $ U_i $ and $
+U_{jk} $ are the standard and enriched DoFs. This allows to include in the finite element space a priori knowledge about the partial differential equation being solved which in turn improves the local approximation properties of the spaces. This can be useful for highly oscillatory solutions, problems with domain corners or on unbounded domains or sudden changes of boundary conditions. PUM method uses finite element spaces which satisfy the partition of unity property (e.g. FE_Q). Among other properties this makes the resulting space to reproduce enrichment functions exactly.

    The simplest constructor of this class takes two finite element objects and an enrichment function to be used. For example

    @@ -496,7 +496,7 @@
    Definition: fe_q.h:551

    In this case, standard DoFs are distributed by FE_Q<dim>(2), whereas enriched DoFs are coming from a single finite element FE_Q<dim>(1) used with a single enrichment function function. In this case, the total number of DoFs on the enriched element is the sum of DoFs from FE_Q<dim>(2) and FE_Q<dim>(1).

    -

    As an example of an enrichment function, consider $ \exp(-x) $, which leads to the following shape functions on the unit element:

    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
    +

    As an example of an enrichment function, consider $ \exp(-x) $, which leads to the following shape functions on the unit element:

    @@ -509,7 +509,7 @@
    1d element, base and enriched shape functions. enriched shape function corresponding to the central vertex.

    Note that evaluation of gradients (hessians) of the enriched shape functions or the finite element field requires evaluation of gradients (gradients and hessians) of the enrichment functions:

    -\begin{align*}
+<picture><source srcset=\begin{align*}
   U(\mathbf x)
     &= \sum_i N_i(\mathbf x) U_i
     + \sum_{j,k} N_j(\mathbf x) F_k(\mathbf x) U_{jk} \\
@@ -523,10 +523,10 @@
 F_k(\mathbf x) + \mathbf \nabla F_k(\mathbf x) \mathbf \nabla N_j(\mathbf x)
 + \mathbf \nabla N_j(\mathbf x) \mathbf \nabla F_k(\mathbf x) + N_j(\mathbf
 x) \mathbf \nabla \mathbf \nabla F_k(\mathbf x) \right] U_{jk}
-\end{align*} +\end{align*}" src="form_1086.png"/>

    Using enriched and non-enriched FEs together

    -

    In most applications it is beneficial to introduce enrichments only in some part of the domain (e.g. around a crack tip) and use standard FE (e.g. FE_Q) elsewhere. This can be achieved by using the hp-finite element framework in deal.II that allows for the use of different elements on different cells. To make the resulting space $C^0$ continuous, it is then necessary for the DoFHandler class and DoFTools::make_hanging_node_constraints() function to be able to figure out what to do at the interface between enriched and non-enriched cells. Specifically, we want the degrees of freedom corresponding to enriched shape functions to be zero at these interfaces. These classes and functions can not to do this automatically, but the effect can be achieved by using not just a regular FE_Q on cells without enrichment, but to wrap the FE_Q into an FE_Enriched object without actually enriching it. This can be done as follows:

    FE_Enriched<dim> fe_non_enriched(FE_Q<dim>(1));
    +

    In most applications it is beneficial to introduce enrichments only in some part of the domain (e.g. around a crack tip) and use standard FE (e.g. FE_Q) elsewhere. This can be achieved by using the hp-finite element framework in deal.II that allows for the use of different elements on different cells. To make the resulting space $C^0$ continuous, it is then necessary for the DoFHandler class and DoFTools::make_hanging_node_constraints() function to be able to figure out what to do at the interface between enriched and non-enriched cells. Specifically, we want the degrees of freedom corresponding to enriched shape functions to be zero at these interfaces. These classes and functions can not to do this automatically, but the effect can be achieved by using not just a regular FE_Q on cells without enrichment, but to wrap the FE_Q into an FE_Enriched object without actually enriching it. This can be done as follows:

    FE_Enriched<dim> fe_non_enriched(FE_Q<dim>(1));

    This constructor is equivalent to calling

    FE_Enriched<dim> fe_non_enriched(FE_Q<dim>(1),
    FE_Nothing<dim>(1,true),
    nullptr);
    @@ -2929,7 +2929,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3618,7 +3618,7 @@

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3726,7 +3726,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3986,7 +3986,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4045,9 +4045,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -4092,11 +4092,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceP.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceP.html 2023-08-09 23:38:42.934510871 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceP.html 2023-08-09 23:38:42.934510871 +0000 @@ -2936,7 +2936,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3657,7 +3657,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3765,7 +3765,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3994,7 +3994,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4053,9 +4053,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -4100,11 +4100,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceP_3_011_00_01spacedim_01_4.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceP_3_011_00_01spacedim_01_4.html 2023-08-09 23:38:43.054511768 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceP_3_011_00_01spacedim_01_4.html 2023-08-09 23:38:43.054511768 +0000 @@ -3140,7 +3140,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    @@ -3811,7 +3811,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3913,7 +3913,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4124,7 +4124,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4179,9 +4179,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -4224,11 +4224,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceQ.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceQ.html 2023-08-09 23:38:43.178512693 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceQ.html 2023-08-09 23:38:43.178512693 +0000 @@ -2987,7 +2987,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3708,7 +3708,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3816,7 +3816,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4045,7 +4045,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4104,9 +4104,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceQ_3_011_00_01spacedim_01_4.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceQ_3_011_00_01spacedim_01_4.html 2023-08-09 23:38:43.302513619 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__FaceQ_3_011_00_01spacedim_01_4.html 2023-08-09 23:38:43.302513619 +0000 @@ -2606,7 +2606,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    @@ -3277,7 +3277,7 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3379,7 +3379,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3590,7 +3590,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -3645,9 +3645,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -3690,11 +3690,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Nedelec.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Nedelec.html 2023-08-09 23:38:43.446514694 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Nedelec.html 2023-08-09 23:38:43.446514694 +0000 @@ -507,12 +507,12 @@

    Detailed Description

    template<int dim>
    class FE_Nedelec< dim >
    Warning
    Several aspects of the implementation are experimental. For the moment, it is safe to use the element on globally refined meshes with consistent orientation of faces. See the todo entries below for more detailed caveats.
    -

    Implementation of Nédélec elements. The Nédélec space is designed to solve problems in which the solution only lives in the space $H^\text{curl}=\{ {\mathbf u} \in L_2: \text{curl}\, {\mathbf u} \in L_2\}$, rather than in the more commonly used space $H^1=\{ u \in L_2: \nabla u \in L_2\}$. In other words, the solution must be a vector field whose curl is square integrable, but for which the gradient may not be square integrable. The typical application for this space (and these elements) is to the Maxwell equations and corresponding simplifications, such as the reduced version of the Maxwell equation that only involves the electric field $\mathbf E$ which has to satisfy the equation $\text{curl}\, \text{curl}\, {\mathbf E} = 0$ in the time independent case when no currents are present, or the equation $\text{curl}\,\text{curl}\,{\mathbf A} = 4\pi{\mathbf j}$ that the magnetic vector potential $\mathbf A$ has to satisfy in the time independent case.

    -

    The defining characteristic of functions in $H^\text{curl}$ is that they are in general discontinuous – but that if you draw a line in 2d (or a surface in 3d), then the tangential component(s) of the vector field must be continuous across the line (or surface) even though the normal component may not be. As a consequence, the Nédélec element is constructed in such a way that (i) it is vector-valued, (ii) the shape functions are discontinuous, but (iii) the tangential component(s) of the vector field represented by each shape function are continuous across the faces of cells.

    +

    Implementation of Nédélec elements. The Nédélec space is designed to solve problems in which the solution only lives in the space $H^\text{curl}=\{ {\mathbf u} \in L_2: \text{curl}\, {\mathbf u} \in L_2\}$, rather than in the more commonly used space $H^1=\{ u \in L_2: \nabla u \in L_2\}$. In other words, the solution must be a vector field whose curl is square integrable, but for which the gradient may not be square integrable. The typical application for this space (and these elements) is to the Maxwell equations and corresponding simplifications, such as the reduced version of the Maxwell equation that only involves the electric field $\mathbf E$ which has to satisfy the equation $\text{curl}\, \text{curl}\, {\mathbf E} = 0$ in the time independent case when no currents are present, or the equation $\text{curl}\,\text{curl}\,{\mathbf A} = 4\pi{\mathbf j}$ that the magnetic vector potential $\mathbf A$ has to satisfy in the time independent case.

    +

    The defining characteristic of functions in $H^\text{curl}$ is that they are in general discontinuous – but that if you draw a line in 2d (or a surface in 3d), then the tangential component(s) of the vector field must be continuous across the line (or surface) even though the normal component may not be. As a consequence, the Nédélec element is constructed in such a way that (i) it is vector-valued, (ii) the shape functions are discontinuous, but (iii) the tangential component(s) of the vector field represented by each shape function are continuous across the faces of cells.

    Other properties of the Nédélec element are that (i) it is not a primitive element ; (ii) the shape functions are defined so that certain integrals over the faces are either zero or one, rather than the common case of certain point values being either zero or one.

    We follow the commonly used – though confusing – definition of the "degree" of Nédélec elements. Specifically, the "degree" of the element denotes the polynomial degree of the largest complete polynomial subspace contained in the finite element space, even if the space may contain shape functions of higher polynomial degree. The lowest order element is consequently FE_Nedelec(0), i.e., the Raviart-Thomas element "of degree zero", even though the functions of this space are in general polynomials of degree one in each variable. This choice of "degree" implies that the approximation order of the function itself is degree+1, as with usual polynomial spaces. The numbering so chosen implies the sequence

    -\[
+<picture><source srcset=\[
   Q_{k+1}
   \stackrel{\text{grad}}{\rightarrow}
   \text{Nedelec}_k
@@ -520,7 +520,7 @@
   \text{RaviartThomas}_k
   \stackrel{\text{div}}{\rightarrow}
   DGQ_{k}
-\] +\]" src="form_1119.png"/>

    Note that this follows the convention of Brezzi and Raviart, though not the one used in the original paper by Nédélec.

    This class is not implemented for the codimension one case (spacedim != dim).

    @@ -1421,11 +1421,11 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    @@ -3801,7 +3801,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -4522,7 +4522,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4630,7 +4630,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4859,7 +4859,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4918,9 +4918,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__NedelecSZ.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__NedelecSZ.html 2023-08-09 23:38:43.566515591 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__NedelecSZ.html 2023-08-09 23:38:43.566515591 +0000 @@ -2489,7 +2489,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    @@ -3160,7 +3160,7 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3262,7 +3262,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3500,7 +3500,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -3555,9 +3555,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -3600,11 +3600,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__NedelecSZ_1_1InternalData.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__NedelecSZ_1_1InternalData.html 2023-08-09 23:38:43.594515799 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__NedelecSZ_1_1InternalData.html 2023-08-09 23:38:43.594515799 +0000 @@ -146,9 +146,9 @@ class FE_NedelecSZ< dim, spacedim >::InternalData

    Derived Internal data which is used to store cell-independent data. Note that due to the nature of this element, a number of useful pre-computed quantities are stored for the computation of cell-dependent shape functions.

    The main quantities which are stored are associated with edge and face parameterizations. These are:

    • -$\lambda_{i}$ - trilinear function, equal to one at the $i$-th vertex and zero at all other vertices.
    • +$\lambda_{i}$ - trilinear function, equal to one at the $i$-th vertex and zero at all other vertices.
    • -$\sigma_{i}$ - linear functional associated with the $i$-th vertex.
    • +$\sigma_{i}$ - linear functional associated with the $i$-th vertex.

    The definitions of these functionals, as well as the edge and face parameterizations and edge and face extension parameters, can be found on page 82 of Zaglmayr's thesis. The details of the definition of the globally-defined edge and face orientations can be found on page 67.

    @@ -279,9 +279,9 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Storage for all possible edge parameterization between vertices. These are required in the computation of edge- and face-based DoFs, which are cell-dependent.

    -

    The edge parameterization of an edge, E, starting at vertex i and ending at vertex $j$ is given by $\sigma_{E} = \sigma_{i} - \sigma{j}$.

    -

    sigma_imj_values[q][i][j] stores the value of the edge parameterization connected by vertices $i$ and $j$ at the q-th quadrature point.

    -

    Note that not all of the $i$ and $j$ combinations result in valid edges on the hexahedral cell, but they are computed in this fashion for use with non-standard edge and face orientations.

    +

    The edge parameterization of an edge, E, starting at vertex i and ending at vertex $j$ is given by $\sigma_{E} = \sigma_{i} - \sigma{j}$.

    +

    sigma_imj_values[q][i][j] stores the value of the edge parameterization connected by vertices $i$ and $j$ at the q-th quadrature point.

    +

    Note that not all of the $i$ and $j$ combinations result in valid edges on the hexahedral cell, but they are computed in this fashion for use with non-standard edge and face orientations.

    Definition at line 287 of file fe_nedelec_sz.h.

    @@ -301,8 +301,8 @@

    Storage for gradients of all possible edge parameterizations between vertices. These are required in the computation of edge- and face-based DoFs, which are cell-dependent. Note that the components of the gradient are constant.

    -

    The edge parameterization of an edge, $E$, starting at vertex $i$ and ending at vertex $j$ is given by $\sigma_{E} = \sigma_{i} - \sigma{j}$.

    -

    sigma_imj_grads[i][j][d] stores the gradient of the edge parameterization connected by vertices $i$ and $j$ in component $d$.

    +

    The edge parameterization of an edge, $E$, starting at vertex $i$ and ending at vertex $j$ is given by $\sigma_{E} = \sigma_{i} - \sigma{j}$.

    +

    sigma_imj_grads[i][j][d] stores the gradient of the edge parameterization connected by vertices $i$ and $j$ in component $d$.

    Note that the gradient of the edge parameterization is constant on an edge, so we do not need to store it at every quadrature point.

    Definition at line 304 of file fe_nedelec_sz.h.

    @@ -365,10 +365,10 @@

    Storage for edge extension parameters at quadrature points. These are stored for the 12 edges such that the global vertex numbering would follow the order defined by the "standard" deal.II cell.

    -

    The edge extension parameter of an edge, $E$, starting at vertex $i$ and ending at vertex $j$ is given by $\lambda_{E} = \lambda_{i} +
-\lambda_{j}$.

    -

    Note that under this definition, the values of $\lambda_{E}$ do not change with the orientation of the edge.

    -

    edge_lambda_values[m][q] stores the edge extension parameter value at the $q$-th quadrature point on edge $m$.

    +

    The edge extension parameter of an edge, $E$, starting at vertex $i$ and ending at vertex $j$ is given by $\lambda_{E} = \lambda_{i} +
+\lambda_{j}$.

    +

    Note that under this definition, the values of $\lambda_{E}$ do not change with the orientation of the edge.

    +

    edge_lambda_values[m][q] stores the edge extension parameter value at the $q$-th quadrature point on edge $m$.

    Definition at line 347 of file fe_nedelec_sz.h.

    @@ -388,7 +388,7 @@

    Storage for gradients of edge extension parameters in 2d. In this case they are constant. These are stored for the 12 edges such that the global vertex numbering* would follow the order defined by the "standard" deal.II cell.

    -

    edge_lambda_grads_2d[m][d] stores the gradient of the edge extension parameter for component $d$ on edge $m$.

    +

    edge_lambda_grads_2d[m][d] stores the gradient of the edge extension parameter for component $d$ on edge $m$.

    Definition at line 358 of file fe_nedelec_sz.h.

    @@ -408,7 +408,7 @@

    Storage for gradients of edge extension parameters in 3d. In this case they are non-constant. These are stored for the 12 edges such that the global vertex numbering* would follow the order defined by the "standard" deal.II cell.

    -

    edge_lambda_grads_3d[m][q][d] stores the gradient of the edge extension parameter for component $d$ at the $q$-th quadrature point on edge m.

    +

    edge_lambda_grads_3d[m][q][d] stores the gradient of the edge extension parameter for component $d$ at the $q$-th quadrature point on edge m.

    Definition at line 369 of file fe_nedelec_sz.h.

    @@ -428,7 +428,7 @@

    Storage for 2nd derivatives of edge extension parameters in 3d, which are constant across the cell. These are stored for the 12 edges such that the global vertex numbering* would follow the order defined by the "standard" deal.II cell.

    -

    edge_lambda_gradgrads_3d[m][d1][d2] stores the 2nd derivatives of the edge extension parameters with respect to components d1 and d2 on edge $m$.

    +

    edge_lambda_gradgrads_3d[m][d1][d2] stores the 2nd derivatives of the edge extension parameters with respect to components d1 and d2 on edge $m$.

    Definition at line 381 of file fe_nedelec_sz.h.

    @@ -448,10 +448,10 @@

    Storage for the face extension parameters. These are stored for the 6 faces such that the global vertex numbering would follow the order defined by the "standard" deal.II cell.

    -

    The face extension parameter of a face, F, defined by the vertices v1, v2, v3, v4 is given by $\lambda_{F} = \lambda_{v1} + \lambda_{v2} + \lambda_{v3} +
-\lambda_{v4}$.

    -

    Note that under this definition, the values of $\lambda_{F}$ do not change with the orientation of the face.

    -

    face_lambda_values[m][q] stores the face extension parameter value at the $q$-th quadrature point on face $m$.

    +

    The face extension parameter of a face, F, defined by the vertices v1, v2, v3, v4 is given by $\lambda_{F} = \lambda_{v1} + \lambda_{v2} + \lambda_{v3} +
+\lambda_{v4}$.

    +

    Note that under this definition, the values of $\lambda_{F}$ do not change with the orientation of the face.

    +

    face_lambda_values[m][q] stores the face extension parameter value at the $q$-th quadrature point on face $m$.

    Definition at line 399 of file fe_nedelec_sz.h.

    @@ -471,7 +471,7 @@

    Storage for gradients of face extension parameters. These are stored for the 6 faces such that the global vertex numbering would follow the order defined by the "standard" deal.II cell.

    -

    face_lambda_grads[m][d] stores the gradient of the face extension parameters for component $d$ on face $m$.

    +

    face_lambda_grads[m][d] stores the gradient of the face extension parameters for component $d$ on face $m$.

    Definition at line 409 of file fe_nedelec_sz.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Nothing.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Nothing.html 2023-08-09 23:38:43.714516695 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Nothing.html 2023-08-09 23:38:43.714516695 +0000 @@ -465,7 +465,7 @@ class FE_Nothing< dim, spacedim >

    Definition of a finite element space with zero degrees of freedom and that, consequently, can only represent a single function: the zero function.

    This class is useful (in the context of an hp-method) to represent empty cells in the triangulation on which no degrees of freedom should be allocated, or to describe a field that is extended by zero to a part of the domain where we don't need it. Thus a triangulation may be divided into two regions: an active region where normal elements are used, and an inactive region where FE_Nothing elements are used. The DoFHandler will therefore assign no degrees of freedom to the FE_Nothing cells, and this subregion is therefore implicitly deleted from the computation. step-10 and step-46 show use cases for this element. An interesting application for this element is also presented in the paper [Cangiani2012].

    FE_Nothing as seen as a function space

    -

    Finite elements are often best interpreted as forming a function space, i.e., a set of functions that form a vector space. One can indeed interpret FE_Nothing in this light: It corresponds to the function space $V_h=\{0\}$, i.e., the set of functions that are zero everywhere. (The constructor can take an argument that, if greater than one, extends the space to one of vector-valued functions with more than one component, with all components equal to zero everywhere.) Indeed, this is a vector space since every linear combination of elements in the vector space is also an element in the vector space, as is every multiple of the single element zero. It is obvious that the function space has no degrees of freedom, thus the name of the class.

    +

    Finite elements are often best interpreted as forming a function space, i.e., a set of functions that form a vector space. One can indeed interpret FE_Nothing in this light: It corresponds to the function space $V_h=\{0\}$, i.e., the set of functions that are zero everywhere. (The constructor can take an argument that, if greater than one, extends the space to one of vector-valued functions with more than one component, with all components equal to zero everywhere.) Indeed, this is a vector space since every linear combination of elements in the vector space is also an element in the vector space, as is every multiple of the single element zero. It is obvious that the function space has no degrees of freedom, thus the name of the class.

    FE_Nothing in combination with other elements

    In situations such as those of step-46, one uses FE_Nothing on cells where one is not interested in a solution variable. For example, in fluid structure interaction problems, the fluid velocity is only defined on cells inside the fluid part of the domain. One then uses FE_Nothing on cells in the solid part of the domain to describe the finite element space for the velocity. In other words, the velocity lives everywhere conceptually, but it is identically zero in those parts of the domain where it is not of interest and doesn't use up any degrees of freedom there.

    The question is what happens at the interface between areas where one is interested in the solution (and uses a "normal" finite element) and where one is not interested (and uses FE_Nothing): Should the solution at that interface be zero – i.e., we consider a "continuous" finite element field that happens to be zero in that area where FE_Nothing is used – or is there no requirement for continuity at the interface. In the deal.II language, this is encoded by what the function FiniteElement::compare_for_domination() returns: If the FE_Nothing "dominates", then the solution must be zero at the interface; if it does not, then there is no requirement and one can think of FE_Nothing as a function space that is in general discontinuous (i.e., there is no requirement for any kind of continuity at cell interfaces) but on every cell equal to zero.

    @@ -633,7 +633,7 @@ - +
    [in]typeSpecifies the reference-cell type.
    [in]n_componentsDenotes the number of vector components to give this finite element. The default is one.
    [in]dominateDecides whether FE_Nothing will dominate any other FE in compare_for_domination() (with the default being false). Therefore at interfaces where, for example, a $Q_1$ meets an FE_Nothing, we will force the traces of the two functions to be the same. Because the FE_Nothing encodes a space that is zero everywhere, this means that the $Q_1$ field will be forced to become zero at this interface. See also the discussion in the general documentation of this class.
    [in]dominateDecides whether FE_Nothing will dominate any other FE in compare_for_domination() (with the default being false). Therefore at interfaces where, for example, a $Q_1$ meets an FE_Nothing, we will force the traces of the two functions to be the same. Because the FE_Nothing encodes a space that is zero everywhere, this means that the $Q_1$ field will be forced to become zero at this interface. See also the discussion in the general documentation of this class.
    @@ -2499,7 +2499,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3220,7 +3220,7 @@

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3328,7 +3328,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3557,7 +3557,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -3616,9 +3616,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -3663,11 +3663,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__P1NC.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__P1NC.html 2023-08-09 23:38:43.834517591 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__P1NC.html 2023-08-09 23:38:43.838517621 +0000 @@ -471,14 +471,14 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Detailed Description

    Implementation of the scalar version of the P1 nonconforming finite element, a piecewise linear element on quadrilaterals in 2d. This implementation is only for 2d cells in a 2d space (i.e., codimension 0).

    -

    Unlike the usual continuous, $H^1$ conforming finite elements, the P1 nonconforming element does not enforce continuity across edges. However, it requires the continuity in an integral sense: any function in the space should have the same integral values on two sides of the common edge shared by two adjacent elements.

    -

    Thus, each function in the nonconforming element space can be discontinuous, and consequently not included in $H^1_0$, just like the basis functions in Discontinuous Galerkin (DG) finite element spaces. On the other hand, basis functions in DG spaces are completely discontinuous across edges without any relation between the values from both sides. This is a reason why usual weak formulations for DG schemes contain additional penalty terms for jump across edges to control discontinuity. However, nonconforming elements usually do not need additional terms in their weak formulations because their integrals along edges are the same from both sides, i.e., there is some level of continuity.

    +

    Unlike the usual continuous, $H^1$ conforming finite elements, the P1 nonconforming element does not enforce continuity across edges. However, it requires the continuity in an integral sense: any function in the space should have the same integral values on two sides of the common edge shared by two adjacent elements.

    +

    Thus, each function in the nonconforming element space can be discontinuous, and consequently not included in $H^1_0$, just like the basis functions in Discontinuous Galerkin (DG) finite element spaces. On the other hand, basis functions in DG spaces are completely discontinuous across edges without any relation between the values from both sides. This is a reason why usual weak formulations for DG schemes contain additional penalty terms for jump across edges to control discontinuity. However, nonconforming elements usually do not need additional terms in their weak formulations because their integrals along edges are the same from both sides, i.e., there is some level of continuity.

    Dice Rule

    Since any function in the P1 nonconforming space is piecewise linear on each element, the function value at the midpoint of each edge is same as the mean value on the edge. Thus the continuity of the integral value across each edge is equivalent to the continuity of the midpoint value of each edge in this case.

    Thus for the P1 nonconforming element, the function values at midpoints on edges of a cell are important. The first attempt to define (local) degrees of freedom (DoFs) on a quadrilateral is by using midpoint values of a function.

    However, these 4 functionals are not linearly independent because a linear function on 2d is uniquely determined by only 3 independent values. A simple observation reads that any linear function on a quadrilateral should satisfy the 'dice rule': the sum of two function values at the midpoints of the edge pair on opposite sides of a cell is equal to the sum of those at the midpoints of the other edge pair. This is called the 'dice rule' because the number of points on opposite sides of a dice always adds up to the same number as well (in the case of dice, to seven).

    -

    In formulas, the dice rule is written as $\phi(m_0) + \phi(m_1) = \phi(m_2) +
-  \phi(m_3)$ for all $\phi$ in the function space where $m_j$ is the midpoint of the edge $e_j$. Here, we assume the standard numbering convention for edges used in deal.II and described in class GeometryInfo.

    +

    In formulas, the dice rule is written as $\phi(m_0) + \phi(m_1) = \phi(m_2) +
+  \phi(m_3)$ for all $\phi$ in the function space where $m_j$ is the midpoint of the edge $e_j$. Here, we assume the standard numbering convention for edges used in deal.II and described in class GeometryInfo.

    Conversely if 4 values at midpoints satisfying the dice rule are given, then there always exists the unique linear function which coincides with 4 midpoints values.

    Due to the dice rule, three values at any three midpoints can determine the last value at the last midpoint. It means that the number of independent local functionals on a cell is 3, and this is also the dimension of the linear polynomial space on a cell in 2d.

    Shape functions

    @@ -494,11 +494,11 @@ * | | * | | * 0---------|---------1 -*

    For each vertex $v_j$ of given cell, there are two edges of which $v_j$ is one of end points. Consider a linear function such that it has value 0.5 at the midpoints of two adjacent edges, and 0.0 at the two midpoints of the other edges. Note that the set of these values satisfies the dice rule which is described above. We denote such a function associated with vertex $v_j$ by $\phi_j$. Then the set of 4 shape functions is a partition of unity on a cell: $\sum_{j=0}^{3} \phi_j = 1$. (This is easy to see: at each edge midpoint, the sum of the four function adds up to one because two functions have value 0.5 and the other value 0.0. Because the function is globally linear, the only function that can have value 1 at four points must also be globally equal to one.)

    -

    The following figures represent $\phi_j$ for $j=0,\cdots,3$ with their midpoint values:

    +*

    For each vertex $v_j$ of given cell, there are two edges of which $v_j$ is one of end points. Consider a linear function such that it has value 0.5 at the midpoints of two adjacent edges, and 0.0 at the two midpoints of the other edges. Note that the set of these values satisfies the dice rule which is described above. We denote such a function associated with vertex $v_j$ by $\phi_j$. Then the set of 4 shape functions is a partition of unity on a cell: $\sum_{j=0}^{3} \phi_j = 1$. (This is easy to see: at each edge midpoint, the sum of the four function adds up to one because two functions have value 0.5 and the other value 0.0. Because the function is globally linear, the only function that can have value 1 at four points must also be globally equal to one.)

    +

    The following figures represent $\phi_j$ for $j=0,\cdots,3$ with their midpoint values:

    • -

      shape function $\phi_0$:

      *  +--------0.0--------+
      +

      shape function $\phi_0$:

      *  +--------0.0--------+
       *  |                   |
       *  |                   |
       *  |                   |
      @@ -512,7 +512,7 @@
       *  

    • -

      shape function $\phi_1$:

      *  +--------0.0--------+
      +

      shape function $\phi_1$:

      *  +--------0.0--------+
       *  |                   |
       *  |                   |
       *  |                   |
      @@ -526,7 +526,7 @@
       *  

    • -

      shape function $\phi_2$:

      *  +--------0.5--------+
      +

      shape function $\phi_2$:

      *  +--------0.5--------+
       *  |                   |
       *  |                   |
       *  |                   |
      @@ -540,7 +540,7 @@
       *  

    • -

      shape function $\phi_3$:

      *  +--------0.5--------+
      +

      shape function $\phi_3$:

      *  +--------0.5--------+
       *  |                   |
       *  |                   |
       *  |                   |
      @@ -560,8 +560,8 @@
       

      Degrees of freedom

      We next have to consider the global basis functions for the element because the system of equations which we ultimately have to solve is for a global system, not local. The global basis functions associated with a node are defined by a cell-wise composition of local shape functions associated with the node on each element.

      There is a theoretical result about the linear independence of the global basis functions depending on the type of the boundary condition we consider.

      -

      When homogeneous Dirichlet boundary conditions are given, the global basis functions associated with interior nodes are linearly independent. Then, the number of DoFs is equal to the number of interior nodes, and consequently the same as the number of DoFs for the standard bilinear $Q_1$ finite element.

      -

      When Neumann boundary conditions are given, the global basis functions associated with all nodes (including boundary nodes) are actually not linearly independent. There exists one redundancy. Thus in this case, the number of DoFs is equal to the number of all nodes minus 1. This is, again as for the regular $Q_1$ element.

      +

      When homogeneous Dirichlet boundary conditions are given, the global basis functions associated with interior nodes are linearly independent. Then, the number of DoFs is equal to the number of interior nodes, and consequently the same as the number of DoFs for the standard bilinear $Q_1$ finite element.

      +

      When Neumann boundary conditions are given, the global basis functions associated with all nodes (including boundary nodes) are actually not linearly independent. There exists one redundancy. Thus in this case, the number of DoFs is equal to the number of all nodes minus 1. This is, again as for the regular $Q_1$ element.

      Unit support points

      For a smooth function, we construct a piecewise linear function which belongs to the element space by using its nodal values as DoF values.

      Note that for the P1 nonconforming element, two nodal values of a smooth function and its interpolant do not coincide in general, in contrast to ordinary Lagrange finite elements. Of course, it is meaningless to refer 'nodal value' because the element space has nonconformity. But it is also true even though the single global basis function associated with a node is considered the unique 'nodal value' at the node. For instance, consider the basis function associated with a node. Consider two lines representing the level sets for value 0.5 and 0, respectively, by connecting two midpoints. Then we cut the quad into two sub-triangles by the diagonal which is placed along those two lines. It gives another level set for value 0.25 which coincides with the cutting diagonal. Therefore these three level sets are all parallel in the quad and it gives the value 0.75 at the base node, not value 1. This is true whether the quadrilateral is a rectangle, parallelogram, or any other shape.

      @@ -871,8 +871,8 @@
    -

    Return the coefficients of 4 local linear shape functions $\phi_j(x,y) = a
-x + b y + c$ on given cell. For each local shape function, the array consists of three coefficients is in order of a,b and c.

    +

    Return the coefficients of 4 local linear shape functions $\phi_j(x,y) = a
+x + b y + c$ on given cell. For each local shape function, the array consists of three coefficients is in order of a,b and c.

    Definition at line 89 of file fe_p1nc.cc.

    @@ -2544,7 +2544,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    @@ -3215,7 +3215,7 @@

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3317,7 +3317,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3555,7 +3555,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -3610,9 +3610,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -3655,11 +3655,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Poly.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Poly.html 2023-08-09 23:38:43.970518607 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Poly.html 2023-08-09 23:38:43.970518607 +0000 @@ -1545,17 +1545,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -1599,21 +1599,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -2641,7 +2641,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3362,7 +3362,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3470,7 +3470,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3730,7 +3730,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -3789,9 +3789,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -3836,11 +3836,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PolyFace.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PolyFace.html 2023-08-09 23:38:44.102519592 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PolyFace.html 2023-08-09 23:38:44.102519592 +0000 @@ -2517,7 +2517,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3238,7 +3238,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3346,7 +3346,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3606,7 +3606,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -3665,9 +3665,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -3712,11 +3712,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PolyTensor.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PolyTensor.html 2023-08-09 23:38:44.238520608 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PolyTensor.html 2023-08-09 23:38:44.238520608 +0000 @@ -492,12 +492,12 @@

    Similarly, in many cases, node functionals depend on the shape of the mesh cell, since they evaluate normal or tangential components on the faces. In order to allow for a set of transformations, the variable mapping_kind has been introduced. It needs be set in the constructor of a derived class.

    Any derived class must decide on the polynomial space to use. This polynomial space should be implemented simply as a set of vector valued polynomials like PolynomialsBDM and PolynomialsRaviartThomas. In order to facilitate this implementation, which basis the polynomial space chooses is not of importance to the current class – as described next, this class handles the transformation from the basis chosen by the polynomial space template argument to the basis we want to use for finite element computations internally.

    Determining the correct basis

    -

    In most cases, the basis used by the class that describes the polynomial space, $\{\tilde\varphi_j(\hat{\mathbf x})\}$, does not match the one we want to use for the finite element description, $\{\varphi_j(\hat{\mathbf x})\}$. Rather, we need to express the finite element shape functions as a linear combination of the basis provided by the polynomial space:

    -\begin{align*}
+<p>In most cases, the basis used by the class that describes the polynomial space, <picture><source srcset=$\{\tilde\varphi_j(\hat{\mathbf x})\}$, does not match the one we want to use for the finite element description, $\{\varphi_j(\hat{\mathbf x})\}$. Rather, we need to express the finite element shape functions as a linear combination of the basis provided by the polynomial space:

    +\begin{align*}
   \varphi_j = \sum_k c_{jk} \tilde\varphi_j.
-\end{align*} +\end{align*}" src="form_1149.png"/>

    -

    These expansion coefficients $c_{jk}$ are typically computed in the constructors of derived classes. To facilitate this, this class at first (unless told otherwise, see below), assumes that the shape functions should be exactly the ones provided by the polynomial space. In the constructor of the derived class, one then typically has code of the form

    // Now compute the inverse node matrix, generating the correct
    +

    These expansion coefficients $c_{jk}$ are typically computed in the constructors of derived classes. To facilitate this, this class at first (unless told otherwise, see below), assumes that the shape functions should be exactly the ones provided by the polynomial space. In the constructor of the derived class, one then typically has code of the form

    // Now compute the inverse node matrix, generating the correct
    // basis functions from the raw ones. For a discussion of what
    // exactly happens here, see FETools::compute_node_matrix.
    @@ -510,7 +510,7 @@
    void invert(const FullMatrix< number2 > &M)
    FullMatrix< double > compute_node_matrix(const FiniteElement< dim, spacedim > &fe)
    -

    The FETools::compute_node_matrix() function explains in more detail what exactly it computes, and how; in any case, the result is that inverse_node_matrix now contains the expansion coefficients $c_{jk}$, and the fact that this block of code now sets the matrix to a non-zero size indicates to the functions of the current class that it should from then on use the expanded basis, $\{\varphi_j(\hat{\mathbf x})\}$, and no longer the original, "raw" basis $\{\tilde\varphi_j(\hat{\mathbf x})\}$ when asked for values or derivatives of shape functions.

    +

    The FETools::compute_node_matrix() function explains in more detail what exactly it computes, and how; in any case, the result is that inverse_node_matrix now contains the expansion coefficients $c_{jk}$, and the fact that this block of code now sets the matrix to a non-zero size indicates to the functions of the current class that it should from then on use the expanded basis, $\{\varphi_j(\hat{\mathbf x})\}$, and no longer the original, "raw" basis $\{\tilde\varphi_j(\hat{\mathbf x})\}$ when asked for values or derivatives of shape functions.

    In order for this scheme to work, it is important to ensure that the size of the inverse_node_matrix be zero at the time when FETools::compute_node_matrix() is called; thus, the call to this function cannot be inlined into the last line – the result of the call really does need to be stored in the temporary object M.

    Setting the transformation

    In most cases, vector valued basis functions must be transformed when mapped from the reference cell to the actual grid cell. These transformations can be selected from the set MappingKind and stored in mapping_kind. Therefore, each constructor should contain a line like:

    @@ -2543,7 +2543,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3264,7 +3264,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3372,7 +3372,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3632,7 +3632,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -3691,9 +3691,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -3738,11 +3738,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidDGP.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidDGP.html 2023-08-09 23:38:44.366521563 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidDGP.html 2023-08-09 23:38:44.366521563 +0000 @@ -469,7 +469,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Detailed Description

    template<int dim, int spacedim = dim>
    -class FE_PyramidDGP< dim, spacedim >

    Implementation of a scalar Lagrange finite element on a pyramid that yields the finite element space of discontinuous, piecewise polynomials of degree $k$.

    +class FE_PyramidDGP< dim, spacedim >

    Implementation of a scalar Lagrange finite element on a pyramid that yields the finite element space of discontinuous, piecewise polynomials of degree $k$.

    Note
    Currently, only linear polynomials (degree=1) are implemented. See also the documentation of ScalarLagrangePolynomialPyramid.

    Also see Simplex support.

    @@ -703,11 +703,11 @@

    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    @@ -1951,17 +1951,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -2005,21 +2005,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -2985,7 +2985,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3706,7 +3706,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3814,7 +3814,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4074,7 +4074,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4133,9 +4133,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidP.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidP.html 2023-08-09 23:38:44.494522519 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidP.html 2023-08-09 23:38:44.494522519 +0000 @@ -469,7 +469,7 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).

    Detailed Description

    template<int dim, int spacedim = dim>
    -class FE_PyramidP< dim, spacedim >

    Implementation of a scalar Lagrange finite element on a pyramid that yields the finite element space of continuous, piecewise polynomials of degree $k$.

    +class FE_PyramidP< dim, spacedim >

    Implementation of a scalar Lagrange finite element on a pyramid that yields the finite element space of continuous, piecewise polynomials of degree $k$.

    Note
    Currently, only linear polynomials (degree=1) are implemented. See also the documentation of ScalarLagrangePolynomialPyramid.

    Also see Simplex support.

    @@ -858,11 +858,11 @@

    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    @@ -2106,17 +2106,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -2160,21 +2160,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -3001,7 +3001,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3722,7 +3722,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3830,7 +3830,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4090,7 +4090,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4149,9 +4149,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidPoly.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidPoly.html 2023-08-09 23:38:44.622523475 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__PyramidPoly.html 2023-08-09 23:38:44.622523475 +0000 @@ -657,11 +657,11 @@

    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    @@ -1905,17 +1905,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -1959,21 +1959,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -3001,7 +3001,7 @@
    Returns
    The index of this degree of freedom within the set of degrees of freedom on the entire cell. The returned value will be between zero and dofs_per_cell.
    -
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.
    +
    Note
    This function exists in this class because that is where it was first implemented. However, it can't really work in the most general case without knowing what element we have. The reason is that when a face is flipped or rotated, we also need to know whether we need to swap the degrees of freedom on this face, or whether they are immune from this. For this, consider the situation of a $Q_3$ element in 2d. If face_flip is true, then we need to consider the two degrees of freedom on the edge in reverse order. On the other hand, if the element were a $Q_1^2$, then because the two degrees of freedom on this edge belong to different vector components, they should not be considered in reverse order. What all of this shows is that the function can't work if there are more than one degree of freedom per line or quad, and that in these cases the function will throw an exception pointing out that this functionality will need to be provided by a derived class that knows what degrees of freedom actually represent.

    Reimplemented in FE_Q_Base< dim, spacedim >, FE_Q_Base< dim, dim >, FE_Q_Base< dim, spacedim >, FESystem< dim, spacedim >, FESystem< dim, dim >, and FESystem< dim, spacedim >.

    @@ -3722,7 +3722,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -3830,7 +3830,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4090,7 +4090,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4149,9 +4149,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q.html 2023-08-09 23:38:44.758524491 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q.html 2023-08-09 23:38:44.758524491 +0000 @@ -483,7 +483,7 @@

    The constructor creates a TensorProductPolynomials object that includes the tensor product of LagrangeEquidistant polynomials of degree p. This TensorProductPolynomials object provides all values and derivatives of the shape functions. In case a quadrature rule is given, the constructor creates a TensorProductPolynomials object that includes the tensor product of Lagrange polynomials with the support points from points.

    Furthermore the constructor fills the interface_constraints, the prolongation (embedding) and the restriction matrices. These are implemented only up to a certain degree and may not be available for very high polynomial degree.

    Unit support point distribution and conditioning of interpolation

    -

    When constructing an FE_Q element at polynomial degrees one or two, equidistant support points at 0 and 1 (linear case) or 0, 0.5, and 1 (quadratic case) are used. The unit support or nodal points xi are those points where the jth Lagrange polynomial satisfies the $\delta_{ij}$ property, i.e., where one polynomial is one and all the others are zero. For higher polynomial degrees, the support points are non-equidistant by default, and chosen to be the support points of the (degree+1)-order Gauss-Lobatto quadrature rule. This point distribution yields well-conditioned Lagrange interpolation at arbitrary polynomial degrees. By contrast, polynomials based on equidistant points get increasingly ill-conditioned as the polynomial degree increases. In interpolation, this effect is known as the Runge phenomenon. For Galerkin methods, the Runge phenomenon is typically not visible in the solution quality but rather in the condition number of the associated system matrices. For example, the elemental mass matrix of equidistant points at degree 10 has condition number 2.6e6, whereas the condition number for Gauss-Lobatto points is around 400.

    +

    When constructing an FE_Q element at polynomial degrees one or two, equidistant support points at 0 and 1 (linear case) or 0, 0.5, and 1 (quadratic case) are used. The unit support or nodal points xi are those points where the jth Lagrange polynomial satisfies the $\delta_{ij}$ property, i.e., where one polynomial is one and all the others are zero. For higher polynomial degrees, the support points are non-equidistant by default, and chosen to be the support points of the (degree+1)-order Gauss-Lobatto quadrature rule. This point distribution yields well-conditioned Lagrange interpolation at arbitrary polynomial degrees. By contrast, polynomials based on equidistant points get increasingly ill-conditioned as the polynomial degree increases. In interpolation, this effect is known as the Runge phenomenon. For Galerkin methods, the Runge phenomenon is typically not visible in the solution quality but rather in the condition number of the associated system matrices. For example, the elemental mass matrix of equidistant points at degree 10 has condition number 2.6e6, whereas the condition number for Gauss-Lobatto points is around 400.

    The Gauss-Lobatto points in 1d include the end points 0 and +1 of the unit interval. The interior points are shifted towards the end points, which gives a denser point distribution close to the element boundary.

    If combined with Gauss-Lobatto quadrature, FE_Q based on the default support points gives diagonal mass matrices. This case is demonstrated in step-48. However, this element can be combined with arbitrary quadrature rules through the usual FEValues approach, including full Gauss quadrature. In the general case, the mass matrix is non-diagonal.

    Numbering of the degrees of freedom (DoFs)

    @@ -544,9 +544,9 @@ - @@ -559,9 +559,9 @@ - +
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).

    $Q_1$ element, shape function 0

    +

    $Q_1$ element, shape function 0

    -

    $Q_1$ element, shape function 1

    +

    $Q_1$ element, shape function 1

    $Q_1$ element, shape function 2

    +

    $Q_1$ element, shape function 2

    -
    $Q_1$ element, shape function 3
    $Q_1$ element, shape function 3

    Q2 elements

      @@ -669,9 +669,9 @@
    -

    $Q_2$ element, shape function 0

    +

    $Q_2$ element, shape function 0

    -

    $Q_2$ element, shape function 1

    +

    $Q_2$ element, shape function 1

    @@ -684,9 +684,9 @@ -

    $Q_2$ element, shape function 2

    +

    $Q_2$ element, shape function 2

    -

    $Q_2$ element, shape function 3

    +

    $Q_2$ element, shape function 3

    @@ -699,9 +699,9 @@ -

    $Q_2$ element, shape function 4

    +

    $Q_2$ element, shape function 4

    -

    $Q_2$ element, shape function 5

    +

    $Q_2$ element, shape function 5

    @@ -714,9 +714,9 @@ -

    $Q_2$ element, shape function 6

    +

    $Q_2$ element, shape function 6

    -

    $Q_2$ element, shape function 7

    +

    $Q_2$ element, shape function 7

    @@ -726,7 +726,7 @@

    -

    $Q_2$ element, shape function 8

    +

    $Q_2$ element, shape function 8

    @@ -895,9 +895,9 @@ -

    $Q_4$ element, shape function 0

    +

    $Q_4$ element, shape function 0

    -

    $Q_4$ element, shape function 1

    +

    $Q_4$ element, shape function 1

    @@ -910,9 +910,9 @@ -

    $Q_4$ element, shape function 2

    +

    $Q_4$ element, shape function 2

    -

    $Q_4$ element, shape function 3

    +

    $Q_4$ element, shape function 3

    @@ -925,9 +925,9 @@ -

    $Q_4$ element, shape function 4

    +

    $Q_4$ element, shape function 4

    -

    $Q_4$ element, shape function 5

    +

    $Q_4$ element, shape function 5

    @@ -940,9 +940,9 @@ -

    $Q_4$ element, shape function 6

    +

    $Q_4$ element, shape function 6

    -

    $Q_4$ element, shape function 7

    +

    $Q_4$ element, shape function 7

    @@ -955,9 +955,9 @@ -

    $Q_4$ element, shape function 8

    +

    $Q_4$ element, shape function 8

    -

    $Q_4$ element, shape function 9

    +

    $Q_4$ element, shape function 9

    @@ -970,9 +970,9 @@ -

    $Q_4$ element, shape function 10

    +

    $Q_4$ element, shape function 10

    -

    $Q_4$ element, shape function 11

    +

    $Q_4$ element, shape function 11

    @@ -985,9 +985,9 @@ -

    $Q_4$ element, shape function 12

    +

    $Q_4$ element, shape function 12

    -

    $Q_4$ element, shape function 13

    +

    $Q_4$ element, shape function 13

    @@ -1000,9 +1000,9 @@ -

    $Q_4$ element, shape function 14

    +

    $Q_4$ element, shape function 14

    -

    $Q_4$ element, shape function 15

    +

    $Q_4$ element, shape function 15

    @@ -1015,9 +1015,9 @@ -

    $Q_4$ element, shape function 16

    +

    $Q_4$ element, shape function 16

    -

    $Q_4$ element, shape function 17

    +

    $Q_4$ element, shape function 17

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Base.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Base.html 2023-08-09 23:38:44.886525446 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Base.html 2023-08-09 23:38:44.890525476 +0000 @@ -2523,17 +2523,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -2577,21 +2577,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -3895,7 +3895,7 @@

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4003,7 +4003,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4232,7 +4232,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4291,9 +4291,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    @@ -4338,11 +4338,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Bubbles.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Bubbles.html 2023-08-09 23:38:45.018526432 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Bubbles.html 2023-08-09 23:38:45.022526462 +0000 @@ -484,17 +484,17 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Detailed Description

    template<int dim, int spacedim = dim>
    -class FE_Q_Bubbles< dim, spacedim >

    Implementation of a scalar Lagrange finite element $Q_p^+$ that yields the finite element space of continuous, piecewise polynomials of degree p in each coordinate direction plus some (non-normalized) bubble enrichment space spanned by the additional shape function $\varphi_j(\mathbf x)
+class FE_Q_Bubbles< dim, spacedim ></div><p>Implementation of a scalar Lagrange finite element <picture><source srcset=$Q_p^+$ that yields the finite element space of continuous, piecewise polynomials of degree p in each coordinate direction plus some (non-normalized) bubble enrichment space spanned by the additional shape function $\varphi_j(\mathbf x)
 = 2^{p-1}\left(x_j-\frac 12\right)^{p-1}
-\left[\prod_{i=0}^{dim-1}(x_i(1-x_i))\right]$. for $j=0,\ldots,dim-1$. If $p$ is one, then the first factor disappears and one receives the usual bubble function centered at the mid-point of the cell. Because these last shape functions have polynomial degree is $p+1$, the overall polynomial degree of the shape functions in the space described by this class is $p+1$.

    +\left[\prod_{i=0}^{dim-1}(x_i(1-x_i))\right]$" src="form_1157.png"/>. for $j=0,\ldots,dim-1$. If $p$ is one, then the first factor disappears and one receives the usual bubble function centered at the mid-point of the cell. Because these last shape functions have polynomial degree is $p+1$, the overall polynomial degree of the shape functions in the space described by this class is $p+1$.

    This class is realized using tensor product polynomials based on equidistant or given support points, in the same way as one can provide support points to the FE_Q class's constructors.

    For more information about the spacedim template parameter check the documentation of the FiniteElement class, or the one of Triangulation.

    -

    Due to the fact that the enrichments are small almost everywhere for large $p$, the condition number for the mass and stiffness matrix quickly increaseses with increasing $p$. Below you see a comparison with FE_Q(QGaussLobatto(p+1)) for dim=1.

    +

    Due to the fact that the enrichments are small almost everywhere for large $p$, the condition number for the mass and stiffness matrix quickly increaseses with increasing $p$. Below you see a comparison with FE_Q(QGaussLobatto(p+1)) for dim=1.

    -

    Therefore, this element should be used with care for $p>3$.

    +

    Therefore, this element should be used with care for $p>3$.

    Implementation

    The constructor creates a TensorProductPolynomials object that includes the tensor product of LagrangeEquidistant polynomials of degree p plus the bubble enrichments. This TensorProductPolynomialsBubbles object provides all values and derivatives of the shape functions. In case a quadrature rule is given, the constructor creates a TensorProductPolynomialsBubbles object that includes the tensor product of Lagrange polynomials with the support points from points and the bubble enrichments as defined above.

    Furthermore the constructor fills the interface_constrains, the prolongation (embedding) and the restriction matrices.

    @@ -720,11 +720,11 @@
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    @@ -2759,17 +2759,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -2813,21 +2813,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -4029,7 +4029,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4137,7 +4137,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4366,7 +4366,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4425,9 +4425,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__DG0.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__DG0.html 2023-08-09 23:38:45.150527418 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__DG0.html 2023-08-09 23:38:45.150527418 +0000 @@ -891,11 +891,11 @@
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).
    -

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
-$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    -

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    -

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    -

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    +

    Given the values of a function $f(\mathbf x)$ at the (generalized) support points of the reference cell, this function then computes what the nodal values of the element are, i.e., $\Psi_i[f]$, where $\Psi_i$ are the node functionals of the element (see also Node values or node functionals). The values $\Psi_i[f]$ are then the expansion coefficients for the shape functions of the finite element function that interpolates the given function $f(x)$, i.e., $ f_h(\mathbf x) = \sum_i \Psi_i[f] \varphi_i(\mathbf x)
+$ is the finite element interpolant of $f$ with the current element. The operation described here is used, for example, in the FETools::compute_node_matrix() function.

    +

    In more detail, let us assume that the generalized support points (see this glossary entry ) of the current element are $\hat{\mathbf x}_i$ and that the node functionals associated with the current element are $\Psi_i[\cdot]$. Then, the fact that the element is based on generalized support points, implies that if we apply $\Psi_i$ to a (possibly vector-valued) finite element function $\varphi$, the result must have the form $\Psi_i[\varphi] = f_i(\varphi(\hat{\mathbf x}_i))$ – in other words, the value of the node functional $\Psi_i$ applied to $\varphi$ only depends on the values of $\varphi$ at $\hat{\mathbf x}_i$ and not on values anywhere else, or integrals of $\varphi$, or any other kind of information.

    +

    The exact form of $f_i$ depends on the element. For example, for scalar Lagrange elements, we have that in fact $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)$. If you combine multiple scalar Lagrange elements via an FESystem object, then $\Psi_i[\varphi] = \varphi(\hat{\mathbf x}_i)_{c(i)}$ where $c(i)$ is the result of the FiniteElement::system_to_component_index() function's return value's first component. In these two cases, $f_i$ is therefore simply the identity (in the scalar case) or a function that selects a particular vector component of its argument. On the other hand, for Raviart-Thomas elements, one would have that $f_i(\mathbf y) = \mathbf y \cdot \mathbf n_i$ where $\mathbf n_i$ is the normal vector of the face at which the shape function is defined.

    +

    Given all of this, what this function does is the following: If you input a list of values of a function $\varphi$ at all generalized support points (where each value is in fact a vector of values with as many components as the element has), then this function returns a vector of values obtained by applying the node functionals to these values. In other words, if you pass in $\{\varphi(\hat{\mathbf x}_i)\}_{i=0}^{N-1}$ then you will get out a vector $\{\Psi[\varphi]\}_{i=0}^{N-1}$ where $N$ equals dofs_per_cell.

    Parameters
    @@ -2907,17 +2907,17 @@

    Correct the shape Hessians by subtracting the terms corresponding to the Jacobian pushed forward gradient.

    Before the correction, the Hessians would be given by

    -\[
+<picture><source srcset=\[
 D_{ijk} = \frac{d^2\phi_i}{d \hat x_J d \hat x_K} (J_{jJ})^{-1}
 (J_{kK})^{-1},
-\] +\]" src="form_1140.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct Hessians would be given by

    +\[
 \frac{d^2 \phi_i}{d x_j d x_k} = D_{ijk} - H_{mjk} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1142.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative.

    @@ -2961,21 +2961,21 @@

    Correct the shape third derivatives by subtracting the terms corresponding to the Jacobian pushed forward gradient and second derivative.

    Before the correction, the third derivatives would be given by

    -\[
+<picture><source srcset=\[
 D_{ijkl} = \frac{d^3\phi_i}{d \hat x_J d \hat x_K d \hat x_L} (J_{jJ})^{-1}
 (J_{kK})^{-1} (J_{lL})^{-1},
-\] +\]" src="form_1144.png"/>

    -

    where $J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    -\[
+<p> where <picture><source srcset=$J_{iI}=\frac{d x_i}{d \hat x_I}$. After the correction, the correct third derivative would be given by

    +\[
 \frac{d^3\phi_i}{d x_j d x_k d x_l} = D_{ijkl} - H_{mjl} \frac{d^2
 \phi_i}{d x_k d x_m}
 - H_{mkl} \frac{d^2 \phi_i}{d x_j d x_m} - H_{mjk} \frac{d^2 \phi_i}{d x_l
 d x_m}
 - K_{mjkl} \frac{d \phi_i}{d x_m},
-\] +\]" src="form_1145.png"/>

    -

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    +

    where $H_{ijk}$ is the Jacobian pushed-forward derivative and $K_{ijkl}$ is the Jacobian pushed-forward second derivative.

    @@ -4177,7 +4177,7 @@
    [in]support_point_valuesAn array of size dofs_per_cell (which equals the number of points the get_generalized_support_points() function will return) where each element is a vector with as many entries as the element has vector components. This array should contain the values of a function at the generalized support points of the current element.

    Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

    -
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4285,7 +4285,7 @@
    scalarAn object that represents a single scalar vector component of this finite element.

    Given a component mask (see this glossary entry), produce a block mask (see this glossary entry) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

    -
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    +
    Note
    This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
    Parameters
    @@ -4514,7 +4514,7 @@
    component_maskThe mask that selects individual components of the finite element

    Return a vector of generalized support points.

    -
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.
    +
    Note
    The vector returned by this function is always a minimal set of unique support points. This is in contrast to the behavior of get_unit_support_points() that returns a repeated list of unit support points for an FESystem of numerous (Lagrangian) base elements. As a consequence, it is possible to have fewer generalized support points than degrees of freedom in the element. An example is the element FESystem<dim>(FE_Q<dim>(1), 2), which has two copies of the $Q_1$ element. In 2d, each copy has 4 degrees of freedom, and each copy has its support points in the four vertices of the cell. While the get_support_points() function would return a vector of size 8 in which each of the vertices is listed twice, this function strips out the duplicates and returns a vector of length 4 in which each vertex is listed only once. This is possible because the purpose of this function is to return a list of points so that it is possible to interpolate an arbitrary function onto the finite element space, and this is possible by knowing the two components of the function in question at the four vertices of the cell – it is not necessary to ask for this information twice at each vertex.

    See the glossary entry on generalized support points for more information.

    @@ -4573,9 +4573,9 @@

    For a given degree of freedom, return whether it is logically associated with a vertex, line, quad or hex.

    -

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    -

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    -

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    +

    For instance, for continuous finite elements this coincides with the lowest dimensional object the support point of the degree of freedom lies on. To give an example, for $Q_1$ elements in 3d, every degree of freedom is defined by a shape function that we get by interpolating using support points that lie on the vertices of the cell. The support of these points of course extends to all edges connected to this vertex, as well as the adjacent faces and the cell interior, but we say that logically the degree of freedom is associated with the vertex as this is the lowest- dimensional object it is associated with. Likewise, for $Q_2$ elements in 3d, the degrees of freedom with support points at edge midpoints would yield a value of GeometryPrimitive::line from this function, whereas those on the centers of faces in 3d would return GeometryPrimitive::quad.

    +

    To make this more formal, the kind of object returned by this function represents the object so that the support of the shape function corresponding to the degree of freedom, (i.e., that part of the domain where the function "lives") is the union of all of the cells sharing this object. To return to the example above, for $Q_2$ in 3d, the shape function with support point at an edge midpoint has support on all cells that share the edge and not only the cells that share the adjacent faces, and consequently the function will return GeometryPrimitive::line.

    +

    On the other hand, for discontinuous elements of type $DGQ_2$, a degree of freedom associated with an interpolation polynomial that has its support point physically located at a line bounding a cell, but is nonzero only on one cell. Consequently, it is logically associated with the interior of that cell (i.e., with a GeometryPrimitive::quad in 2d and a GeometryPrimitive::hex in 3d).

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Hierarchical.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Hierarchical.html 2023-08-09 23:38:45.298528523 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classFE__Q__Hierarchical.html 2023-08-09 23:38:45.298528523 +0000 @@ -519,7 +519,7 @@

    Numbering of the degrees of freedom (DoFs)

    The original ordering of the shape functions represented by the TensorProductPolynomials is a tensor product numbering. However, the shape functions on a cell are renumbered beginning with the shape functions whose support points are at the vertices, then on the line, on the quads, and finally (for 3d) on the hexes. To be explicit, these numberings are listed in the following:

    Q1 elements

    -

    The $Q_1^H$ element is of polynomial degree one and, consequently, is exactly the same as the $Q_1$ element in class FE_Q. In particular, the shape function are defined in the exact same way:

    +

    The $Q_1^H$ element is of polynomial degree one and, consequently, is exactly the same as the $Q_1$ element in class FE_Q. In particular, the shape function are defined in the exact same way:

    • 1d case:

      *      0-------1
      @@ -575,9 +575,9 @@
       
          
       
    - @@ -590,9 +590,9 @@ - +
    [in]cell_dof_indexThe index of a shape function or degree of freedom. This index must be in the range [0,dofs_per_cell).

    $Q_1^H$ element, shape function 0

    +

    $Q_1^H$ element, shape function 0

    -

    $Q_1^H$ element, shape function 1

    +

    $Q_1^H$ element, shape function 1

    $Q_1^H$ element, shape function 2

    +

    $Q_1^H$ element, shape function 2

    -
    $Q_1^H$ element, shape function 3
    $Q_1^H$ element, shape function 3

    Q2 elements

      @@ -700,9 +700,9 @@
    -

    $Q_2^H$ element, shape function 0

    +

    $Q_2^H$ element, shape function 0

    -

    $Q_2^H$ element, shape function 1

    +

    $Q_2^H$ element, shape function 1

    @@ -715,9 +715,9 @@ -

    $Q_2^H$ element, shape function 2

    +

    $Q_2^H$ element, shape function 2

    -

    $Q_2^H$ element, shape function 3

    +

    $Q_2^H$ element, shape function 3

    @@ -730,9 +730,9 @@ -

    $Q_2^H$ element, shape function 4

    +

    $Q_2^H$ element, shape function 4

    -

    $Q_2^H$ element, shape function 5

    +

    $Q_2^H$ element, shape function 5

    @@ -745,9 +745,9 @@ -

    $Q_2^H$ element, shape function 6

    +

    $Q_2^H$ element, shape function 6

    -

    $Q_2^H$ element, shape function 7

    +

    $Q_2^H$ element, shape function 7

    @@ -757,7 +757,7 @@

    -

    $Q_2^H$ element, shape function 8

    +

    $Q_2^H$ element, shape function 8

    @@ -788,9 +788,9 @@ -

    $Q_3^H$ element, shape function 0

    +

    $Q_3^H$ element, shape function 0

    -

    $Q_3^H$ element, shape function 1

    +

    $Q_3^H$ element, shape function 1

    @@ -803,9 +803,9 @@ -

    $Q_3^H$ element, shape function 2

    +

    $Q_3^H$ element, shape function 2

    -

    $Q_3^H$ element, shape function 3

    +

    $Q_3^H$ element, shape function 3

    @@ -818,9 +818,9 @@ -

    $Q_3^H$ element, shape function 4

    +

    $Q_3^H$ element, shape function 4

    -

    $Q_3^H$ element, shape function 5

    +

    $Q_3^H$ element, shape function 5

    @@ -833,9 +833,9 @@ -

    $Q_3^H$ element, shape function 6

    +

    $Q_3^H$ element, shape function 6

    -

    $Q_3^H$ element, shape function 7

    +

    $Q_3^H$ element, shape function 7

    @@ -848,9 +848,9 @@ -

    $Q_3^H$ element, shape function 8

    +

    $Q_3^H$ element, shape function 8

    -

    $Q_3^H$ element, shape function 9

    +

    $Q_3^H$ element, shape function 9

    @@ -863,9 +863,9 @@ -

    $Q_3^H$ element, shape function 10

    +

    $Q_3^H$ element, shape function 10

    -

    $Q_3^H$ element, shape function 11

    +

    $Q_3^H$ element, shape function 11

    @@ -878,9 +878,9 @@ -

    $Q_3^H$ element, shape function 12

    +

    $Q_3^H$ element, shape function 12

    -

    $Q_3^H$ element, shape function 13

    +

    $Q_3^H$ element, shape function 13

    @@ -893,9 +893,9 @@ -

    $Q_3^H$ element, shape function 14

    +

    $Q_3^H$ element, shape function 14

    -$Q_3^H$ element, shape function 15 +$Q_3^H$ element, shape function 15

    Q4 elements

    -

    By default, this class assumes that all components are differential, and that you want to solve a standard ode. In this case, the initial component type is set to use_y_diff, so that the y_dot at time t=initial_time is computed by solving the nonlinear problem $F(y_dot,
-y(t0), t0) = 0$ in the variable y_dot.

    +

    By default, this class assumes that all components are differential, and that you want to solve a standard ode. In this case, the initial component type is set to use_y_diff, so that the y_dot at time t=initial_time is computed by solving the nonlinear problem $F(y_dot,
+y(t0), t0) = 0$ in the variable y_dot.

    Notice that a Newton solver is used for this computation. The Newton solver parameters can be tweaked by acting on ic_alpha and ic_max_iter.

    If you reset the solver at some point, you may want to select a different computation for the initial conditions after reset. Say, for example, that you have refined a grid, and after transferring the solution to the new grid, the initial conditions are no longer consistent. Then you can choose how these are made consistent, using the same three options that you used for the initial conditions in reset_type.

    Parameters
    @@ -631,7 +631,7 @@
    -

    Compute residual. Return $F(t, y, \dot y)$.

    +

    Compute residual. Return $F(t, y, \dot y)$.

    Note
    This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, IDA can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.

    Definition at line 662 of file ida.h.

    @@ -653,13 +653,13 @@

    Compute Jacobian. This function is called by IDA any time a Jacobian update is required. The user should compute the Jacobian (or update all the variables that allow the application of the Jacobian). This function is called by IDA once, before any call to solve_jacobian_system() or solve_with_jacobian().

    The Jacobian $J$ should be a (possibly inexact) computation of

    -\[
+<picture><source srcset=\[
   J=\dfrac{\partial G}{\partial y} = \dfrac{\partial F}{\partial y} +
  \alpha \dfrac{\partial F}{\partial \dot y}.
-\] +\]" src="form_2636.png"/>

    If the user uses a matrix based computation of the Jacobian, then this is the right place where an assembly routine should be called to assemble both a matrix and a preconditioner for the Jacobian system. Subsequent calls (possibly more than one) to solve_jacobian_system() or solve_with_jacobian() can assume that this function has been called at least once.

    -

    Notice that no assumption is made by this interface on what the user should do in this function. IDA only assumes that after a call to setup_jacobian() it is possible to call solve_jacobian_system() or solve_with_jacobian() to obtain a solution $x$ to the system $J x = b$.

    +

    Notice that no assumption is made by this interface on what the user should do in this function. IDA only assumes that after a call to setup_jacobian() it is possible to call solve_jacobian_system() or solve_with_jacobian() to obtain a solution $x$ to the system $J x = b$.

    Note
    This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, IDA can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.

    Definition at line 701 of file ida.h.

    @@ -681,12 +681,12 @@

    Solve the Jacobian linear system. This function will be called by IDA (possibly several times) after setup_jacobian() has been called at least once. IDA tries to do its best to call setup_jacobian() the minimum amount of times. If convergence can be achieved without updating the Jacobian, then IDA does not call setup_jacobian() again. If, on the contrary, internal IDA convergence tests fail, then IDA calls again setup_jacobian() with updated vectors and coefficients so that successive calls to solve_jacobian_systems() lead to better convergence in the Newton process.

    The jacobian $J$ should be (an approximation of) the system Jacobian

    -\[
+<picture><source srcset=\[
   J=\dfrac{\partial G}{\partial y} = \dfrac{\partial F}{\partial y} +
  \alpha \dfrac{\partial F}{\partial \dot y}.
-\] +\]" src="form_2636.png"/>

    -

    A call to this function should store in dst the result of $J^{-1}$ applied to src, i.e., J*dst = src. It is the users responsibility to set up proper solvers and preconditioners inside this function.

    +

    A call to this function should store in dst the result of $J^{-1}$ applied to src, i.e., J*dst = src. It is the users responsibility to set up proper solvers and preconditioners inside this function.

    Note
    This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, IDA can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.
    Deprecated:
    Use solve_with_jacobian() instead which also uses a numerical tolerance.
    @@ -709,21 +709,21 @@

    Solve the Jacobian linear system up to a specified tolerance. This function will be called by IDA (possibly several times) after setup_jacobian() has been called at least once. IDA tries to do its best to call setup_jacobian() the minimum number of times. If convergence can be achieved without updating the Jacobian, then IDA does not call setup_jacobian() again. If, on the contrary, internal IDA convergence tests fail, then IDA calls again setup_jacobian() with updated vectors and coefficients so that successive calls to solve_with_jacobian() lead to better convergence in the Newton process.

    The Jacobian $J$ should be (an approximation of) the system Jacobian

    -\[
+<picture><source srcset=\[
   J=\dfrac{\partial G}{\partial y} = \dfrac{\partial F}{\partial y} +
  \alpha \dfrac{\partial F}{\partial \dot y}.
-\] +\]" src="form_2636.png"/>

    Arguments to the function are:

    Parameters
    - +
    [in]rhsThe system right hand side to solve for.
    [out]dstThe solution of $J^{-1} * src$.
    [out]dstThe solution of $J^{-1} * src$.
    [in]toleranceThe tolerance with which to solve the linear system of equations.
    -

    A call to this function should store in dst the result of $J^{-1}$ applied to src, i.e., the solution of the linear system J*dst = src. It is the user's responsibility to set up proper solvers and preconditioners either inside this function, or already within the setup_jacobian() function. (The latter is, for example, what the step-77 program does: All expensive operations happen in setup_jacobian(), given that that function is called far less often than the current one.)

    +

    A call to this function should store in dst the result of $J^{-1}$ applied to src, i.e., the solution of the linear system J*dst = src. It is the user's responsibility to set up proper solvers and preconditioners either inside this function, or already within the setup_jacobian() function. (The latter is, for example, what the step-77 program does: All expensive operations happen in setup_jacobian(), given that that function is called far less often than the current one.)

    Note
    This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, IDA can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.

    Definition at line 781 of file ida.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1IDA_1_1AdditionalData.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1IDA_1_1AdditionalData.html 2023-08-09 23:38:52.746584137 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1IDA_1_1AdditionalData.html 2023-08-09 23:38:52.746584137 +0000 @@ -567,8 +567,8 @@

    Type of correction for initial conditions.

    -

    If you do not provide consistent initial conditions, (i.e., conditions for which $F(y_dot(0), y(0), 0) = 0$), you can ask SUNDIALS to compute initial conditions for you by using the ic_type parameter at construction time.

    -

    Notice that you could in principle use this capabilities to solve for steady state problems by setting y_dot to zero, and asking to compute $y(0)$ that satisfies $F(0, y(0), 0) = 0$, however the nonlinear solver used inside IDA may not be robust enough for complex problems with several millions unknowns.

    +

    If you do not provide consistent initial conditions, (i.e., conditions for which $F(y_dot(0), y(0), 0) = 0$), you can ask SUNDIALS to compute initial conditions for you by using the ic_type parameter at construction time.

    +

    Notice that you could in principle use this capabilities to solve for steady state problems by setting y_dot to zero, and asking to compute $y(0)$ that satisfies $F(0, y(0), 0) = 0$, however the nonlinear solver used inside IDA may not be robust enough for complex problems with several millions unknowns.

    Definition at line 523 of file ida.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1KINSOL.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1KINSOL.html 2023-08-09 23:38:52.778584376 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSUNDIALS_1_1KINSOL.html 2023-08-09 23:38:52.778584376 +0000 @@ -174,48 +174,48 @@

    Detailed Description

    template<typename VectorType = Vector<double>>
    class SUNDIALS::KINSOL< VectorType >

    Interface to SUNDIALS' nonlinear solver (KINSOL).

    -

    KINSOL is a solver for nonlinear algebraic systems in residual form $F(u)
-= 0$ or fixed point form $G(u) = u$, where $u$ is a vector which we will assume to be in ${\mathbb R}^n$ or ${\mathbb C}^n$, but that may also have a block structure and may be distributed in parallel computations; the functions $F$ and $G$ satisfy $F,G:{\mathbb R}^N \to{\mathbb R}^N$ or $F,G:{\mathbb C}^N \to{\mathbb C}^N$. It includes a Newton-Krylov solver as well as Picard and fixed point solvers, both of which can be accelerated with Anderson acceleration. KINSOL is based on the previous Fortran package NKSOL of Brown and Saad. An example of using KINSOL can be found in the step-77 tutorial program.

    +

    KINSOL is a solver for nonlinear algebraic systems in residual form $F(u)
+= 0$ or fixed point form $G(u) = u$, where $u$ is a vector which we will assume to be in ${\mathbb R}^n$ or ${\mathbb C}^n$, but that may also have a block structure and may be distributed in parallel computations; the functions $F$ and $G$ satisfy $F,G:{\mathbb R}^N \to{\mathbb R}^N$ or $F,G:{\mathbb C}^N \to{\mathbb C}^N$. It includes a Newton-Krylov solver as well as Picard and fixed point solvers, both of which can be accelerated with Anderson acceleration. KINSOL is based on the previous Fortran package NKSOL of Brown and Saad. An example of using KINSOL can be found in the step-77 tutorial program.

    KINSOL's Newton solver employs the inexact Newton method. As this solver is intended mainly for large systems, the user is required to provide their own solver function.

    At the highest level, KINSOL implements the following iteration scheme:

      -
    • set $u_0$ = an initial guess
    • -
    • For $n = 0, 1, 2, \ldots$ until convergence do:
        -
      • Solve $J(u_n)\delta_n = -F(u_n)$
      • -
      • Set $u_{n+1} = u_n + \lambda \delta_n, 0 < \lambda \leq 1$
      • +
      • set $u_0$ = an initial guess
      • +
      • For $n = 0, 1, 2, \ldots$ until convergence do:
          +
        • Solve $J(u_n)\delta_n = -F(u_n)$
        • +
        • Set $u_{n+1} = u_n + \lambda \delta_n, 0 < \lambda \leq 1$
        • Test for convergence
      -

      Here, $u_n$ is the $n$-th iterate to $u$, and $J(u) = \nabla_u F(u)$ is the system Jacobian. At each stage in the iteration process, a scalar multiple of the step $\delta_n$, is added to $u_n$ to produce a new iterate, $u_{n+1}$. A test for convergence is made before the iteration continues.

      +

      Here, $u_n$ is the $n$-th iterate to $u$, and $J(u) = \nabla_u F(u)$ is the system Jacobian. At each stage in the iteration process, a scalar multiple of the step $\delta_n$, is added to $u_n$ to produce a new iterate, $u_{n+1}$. A test for convergence is made before the iteration continues.

      Unless specified otherwise by the user, KINSOL strives to update Jacobian information as infrequently as possible to balance the high costs of matrix operations against other costs. Specifically, these updates occur when:

      • the problem is initialized,
      • -
      • $\|\lambda \delta_{n-1} \|_{D_u,\infty} \geq 1.5$ (inexact Newton only, see below for a definition of $\| \cdot \|_{D_u,\infty}$)
      • +
      • $\|\lambda \delta_{n-1} \|_{D_u,\infty} \geq 1.5$ (inexact Newton only, see below for a definition of $\| \cdot \|_{D_u,\infty}$)
      • a specified number of nonlinear iterations have passed since the last update,
      • the linear solver failed recoverably with outdated Jacobian information,
      • the global strategy failed with outdated Jacobian information, or
      • -
      • $\|\lambda \delta_{n} \|_{D_u,\infty} \leq $ tolerance with outdated Jacobian information.
      • +
      • $\|\lambda \delta_{n} \|_{D_u,\infty} \leq $ tolerance with outdated Jacobian information.

      KINSOL allows changes to the above strategy through optional solver inputs. The user can disable the initial Jacobian information evaluation or change the default value of the number of nonlinear iterations after which a Jacobian information update is enforced.

      -

      To address the case of ill-conditioned nonlinear systems, KINSOL allows prescribing scaling factors both for the solution vector and for the residual vector. For scaling to be used, the user may supply the function get_solution_scaling(), that returns values $D_u$, which are diagonal elements of the scaling matrix such that $D_u u_n$ has all components roughly the same magnitude when $u_n$ is close to a solution, and get_function_scaling(), that supply values $D_F$, which are diagonal scaling matrix elements such that $D_F F$ has all components roughly the same magnitude when $u_n$ is not too close to a solution.

      +

      To address the case of ill-conditioned nonlinear systems, KINSOL allows prescribing scaling factors both for the solution vector and for the residual vector. For scaling to be used, the user may supply the function get_solution_scaling(), that returns values $D_u$, which are diagonal elements of the scaling matrix such that $D_u u_n$ has all components roughly the same magnitude when $u_n$ is close to a solution, and get_function_scaling(), that supply values $D_F$, which are diagonal scaling matrix elements such that $D_F F$ has all components roughly the same magnitude when $u_n$ is not too close to a solution.

      When scaling values are provided for the solution vector, these values are automatically incorporated into the calculation of the perturbations used for the default difference quotient approximations for Jacobian information if the user does not supply a Jacobian solver through the solve_with_jacobian() function.

      -

      Two methods of applying a computed step $\delta_n$ to the previously computed solution vector are implemented. The first and simplest is the standard Newton strategy which applies the update with a constant $\lambda$ always set to 1. The other method is a global strategy, which attempts to use the direction implied by $\delta_n$ in the most efficient way for furthering convergence of the nonlinear problem. This technique is implemented in the second strategy, called Linesearch. This option employs both the $\alpha$ and $\beta$ conditions of the Goldstein-Armijo linesearch algorithm given in [DennisSchnabel96] , where $\lambda$ is chosen to guarantee a sufficient decrease in $F$ relative to the step length as well as a minimum step length relative to the initial rate of decrease of $F$. One property of the algorithm is that the full Newton step tends to be taken close to the solution.

      +

      Two methods of applying a computed step $\delta_n$ to the previously computed solution vector are implemented. The first and simplest is the standard Newton strategy which applies the update with a constant $\lambda$ always set to 1. The other method is a global strategy, which attempts to use the direction implied by $\delta_n$ in the most efficient way for furthering convergence of the nonlinear problem. This technique is implemented in the second strategy, called Linesearch. This option employs both the $\alpha$ and $\beta$ conditions of the Goldstein-Armijo linesearch algorithm given in [DennisSchnabel96] , where $\lambda$ is chosen to guarantee a sufficient decrease in $F$ relative to the step length as well as a minimum step length relative to the initial rate of decrease of $F$. One property of the algorithm is that the full Newton step tends to be taken close to the solution.

      The basic fixed-point iteration scheme implemented in KINSOL is given by:

        -
      • Set $u_0 =$ an initial guess
      • -
      • For $n = 0, 1, 2, \dots$ until convergence do:
          -
        • Set $u_{n+1} = G(u_n)$
        • +
        • Set $u_0 =$ an initial guess
        • +
        • For $n = 0, 1, 2, \dots$ until convergence do:
            +
          • Set $u_{n+1} = G(u_n)$
          • Test for convergence
        -

        At each stage in the iteration process, function $G$ is applied to the current iterate to produce a new iterate, $u_{n+1}$. A test for convergence is made before the iteration continues.

        -

        For Picard iteration, as implemented in KINSOL, we consider a special form of the nonlinear function $F$, such that $F(u) = Lu - N(u)$, where $L$ is a constant nonsingular matrix and $N$ is (in general) nonlinear.

        -

        Then the fixed-point function $G$ is defined as $G(u) = u - L^{-1}F(u)$. Within each iteration, the Picard step is computed then added to $u_n$ to produce the new iterate. Next, the nonlinear residual function is evaluated at the new iterate, and convergence is checked. The Picard and fixed point methods can be significantly accelerated using Anderson's acceleration method.

        +

        At each stage in the iteration process, function $G$ is applied to the current iterate to produce a new iterate, $u_{n+1}$. A test for convergence is made before the iteration continues.

        +

        For Picard iteration, as implemented in KINSOL, we consider a special form of the nonlinear function $F$, such that $F(u) = Lu - N(u)$, where $L$ is a constant nonsingular matrix and $N$ is (in general) nonlinear.

        +

        Then the fixed-point function $G$ is defined as $G(u) = u - L^{-1}F(u)$. Within each iteration, the Picard step is computed then added to $u_n$ to produce the new iterate. Next, the nonlinear residual function is evaluated at the new iterate, and convergence is checked. The Picard and fixed point methods can be significantly accelerated using Anderson's acceleration method.

        The user has to provide the implementation of the following std::functions:

        • reinit_vector; and only one of
        • residual; or
        • iteration_function;
        -

        Specifying residual() allows the user to use Newton and Picard strategies (i.e., $F(u)=0$ will be solved), while specifying iteration_function(), a fixed point iteration will be used (i.e., $G(u)=u$ will be solved). An error will be thrown if iteration_function() is set for Picard or Newton.

        +

        Specifying residual() allows the user to use Newton and Picard strategies (i.e., $F(u)=0$ will be solved), while specifying iteration_function(), a fixed point iteration will be used (i.e., $G(u)=u$ will be solved). An error will be thrown if iteration_function() is set for Picard or Newton.

        If the use of a Newton or Picard method is desired, then the user should also supply

        • solve_jacobian_system or solve_with_jacobian; and optionally
        • setup_jacobian;
        • @@ -440,13 +440,13 @@

    A function object that users may supply and that is intended to prepare the linear solver for subsequent calls to solve_with_jacobian().

    The job of setup_jacobian() is to prepare the linear solver for subsequent calls to solve_with_jacobian(), in the solution of linear systems $Ax = b$. The exact nature of this system depends on the SolutionStrategy that has been selected.

    -

    In the cases strategy = SolutionStrategy::newton or SolutionStrategy::linesearch, $A$ is the Jacobian $J = \partial
-F/\partial u$. If strategy = SolutionStrategy::picard, $A$ is the approximate Jacobian matrix $L$. If strategy = SolutionStrategy::fixed_point, then linear systems do not arise, and this function is never called.

    +

    In the cases strategy = SolutionStrategy::newton or SolutionStrategy::linesearch, $A$ is the Jacobian $J = \partial
+F/\partial u$. If strategy = SolutionStrategy::picard, $A$ is the approximate Jacobian matrix $L$. If strategy = SolutionStrategy::fixed_point, then linear systems do not arise, and this function is never called.

    The setup_jacobian() function may call a user-supplied function, or a function within the linear solver module, to compute Jacobian-related data that is required by the linear solver. It may also preprocess that data as needed for solve_with_jacobian(), which may involve calling a generic function (such as for LU factorization) or, more generally, build preconditioners from the assembled Jacobian. In any case, the data so generated may then be used whenever a linear system is solved.

    The point of this function is that setup_jacobian() function is not called at every Newton iteration, but only as frequently as the solver determines that it is appropriate to perform the setup task. In this way, Jacobian-related data generated by setup_jacobian() is expected to be used over a number of Newton iterations. KINSOL determines itself when it is beneficial to regenerate the Jacobian and associated information (such as preconditioners computed for the Jacobian), thereby saving the effort to regenerate the Jacobian matrix and a preconditioner for it whenever possible.

    Parameters
    - +
    current_uCurrent value of $u$
    current_uCurrent value of $u$
    current_fCurrent value of $F(u)$ or $G(u)$
    @@ -473,14 +473,14 @@
    Deprecated:
    Versions of SUNDIALS after 4.0 no longer provide all of the information necessary for this callback (see below). Use the solve_with_jacobian callback described below.

    A function object that users may supply and that is intended to solve a linear system with the Jacobian matrix. This function will be called by KINSOL (possibly several times) after setup_jacobian() has been called at least once. KINSOL tries to do its best to call setup_jacobian() the minimum number of times. If convergence can be achieved without updating the Jacobian, then KINSOL does not call setup_jacobian() again. If, on the contrary, internal KINSOL convergence tests fail, then KINSOL calls setup_jacobian() again with updated vectors and coefficients so that successive calls to solve_jacobian_system() lead to better convergence in the Newton process.

    If you do not specify a solve_jacobian_system or solve_with_jacobian function, then only a fixed point iteration strategy can be used. Notice that this may not converge, or may converge very slowly.

    -

    A call to this function should store in dst the result of $J^{-1}$ applied to rhs, i.e., $J \cdot dst = rhs$. It is the user's responsibility to set up proper solvers and preconditioners inside this function (or in the setup_jacobian callback above).

    +

    A call to this function should store in dst the result of $J^{-1}$ applied to rhs, i.e., $J \cdot dst = rhs$. It is the user's responsibility to set up proper solvers and preconditioners inside this function (or in the setup_jacobian callback above).

    Arguments to the function are:

    Parameters
    - - + + - +
    [in]ycurThe current $y$ vector for the current KINSOL internal step. In the documentation above, this $y$ vector is generally denoted by $u$.
    [in]fcurThe current value of the implicit right-hand side at ycur, $f_I (t_n, ypred)$.
    [in]ycurThe current $y$ vector for the current KINSOL internal step. In the documentation above, this $y$ vector is generally denoted by $u$.
    [in]fcurThe current value of the implicit right-hand side at ycur, $f_I (t_n, ypred)$.
    [in]rhsThe system right hand side to solve for
    [out]dstThe solution of $J^{-1} * src$
    [out]dstThe solution of $J^{-1} * src$
    @@ -511,12 +511,12 @@

    A function object that users may supply and that is intended to solve a linear system with the Jacobian matrix. This function will be called by KINSOL (possibly several times) after setup_jacobian() has been called at least once. KINSOL tries to do its best to call setup_jacobian() the minimum number of times. If convergence can be achieved without updating the Jacobian, then KINSOL does not call setup_jacobian() again. If, on the contrary, internal KINSOL convergence tests fail, then KINSOL calls setup_jacobian() again with updated vectors and coefficients so that successive calls to solve_with_jacobian() lead to better convergence in the Newton process.

    If you do not specify a solve_with_jacobian function, then only a fixed point iteration strategy can be used. Notice that this may not converge, or may converge very slowly.

    -

    A call to this function should store in dst the result of $J^{-1}$ applied to rhs, i.e., $J \cdot dst = rhs$. It is the user's responsibility to set up proper solvers and preconditioners inside this function (or in the setup_jacobian callback above). The function attached to this callback is also provided with a tolerance to the linear solver, indicating that it is not necessary to solve the linear system with the Jacobian matrix exactly, but only to a tolerance that KINSOL will adapt over time.

    +

    A call to this function should store in dst the result of $J^{-1}$ applied to rhs, i.e., $J \cdot dst = rhs$. It is the user's responsibility to set up proper solvers and preconditioners inside this function (or in the setup_jacobian callback above). The function attached to this callback is also provided with a tolerance to the linear solver, indicating that it is not necessary to solve the linear system with the Jacobian matrix exactly, but only to a tolerance that KINSOL will adapt over time.

    Arguments to the function are:

    Parameters
    - +
    [in]rhsThe system right hand side to solve for.
    [out]dstThe solution of $J^{-1} * src$.
    [out]dstThe solution of $J^{-1} * src$.
    [in]toleranceThe tolerance with which to solve the linear system of equations.
    @@ -541,7 +541,7 @@

    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#href_anchor".

    +

    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#href_anchor".

    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.

    Note
    This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, KINSOL can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.
    @@ -563,7 +563,7 @@

    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 function evaluation away from the solution. The implementation of this function is optional, and it is used only if implemented.

    -

    The point of this function and the scaling vector it returns is similar to the one discussed above for get_solution_scaling, except that it is for a vector that scales the components of the function $F(U)$, rather than the components of $U$, when computing norms. As above, if no function is provided, then this is equivalent to using a scaling vector whose components are all equal to one.

    +

    The point of this function and the scaling vector it returns is similar to the one discussed above for get_solution_scaling, except that it is for a vector that scales the components of the function $F(U)$, rather than the components of $U$, when computing norms. As above, if no function is provided, then this is equivalent to using a scaling vector whose components are all equal to one.

    Note
    This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. In particular, KINSOL can deal with "recoverable" errors in some circumstances, so callbacks can throw exceptions of type RecoverableUserCallbackError.

    Definition at line 691 of file kinsol.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classScaLAPACKMatrix.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classScaLAPACKMatrix.html 2023-08-09 23:38:52.854584944 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classScaLAPACKMatrix.html 2023-08-09 23:38:52.854584944 +0000 @@ -358,15 +358,15 @@

    Detailed Description

    template<typename NumberType>
    class ScaLAPACKMatrix< NumberType >

    A wrapper class around ScaLAPACK parallel dense linear algebra.

    -

    ScaLAPACK assumes that matrices are distributed according to the block-cyclic decomposition scheme. An $M$ by $N$ matrix is first decomposed into $\lceil M / MB \rceil$ by $\lceil N / NB \rceil$ blocks which are then uniformly distributed across the 2d process grid with $p q \le Np$ processes, where $p,q$ are grid dimensions and $Np$ is the total number of processes. The parameters MB and NB are referred to as row and column block size and determine the granularity of the block-cyclic distribution.

    -

    In the following the block-cyclic distribution of a $10 \times 9$ matrix onto a $3\times 3$ Cartesian process grid with block sizes $\text{MB}=\text{NB}=2$ is displayed.

    +

    ScaLAPACK assumes that matrices are distributed according to the block-cyclic decomposition scheme. An $M$ by $N$ matrix is first decomposed into $\lceil M / MB \rceil$ by $\lceil N / NB \rceil$ blocks which are then uniformly distributed across the 2d process grid with $p q \le Np$ processes, where $p,q$ are grid dimensions and $Np$ is the total number of processes. The parameters MB and NB are referred to as row and column block size and determine the granularity of the block-cyclic distribution.

    +

    In the following the block-cyclic distribution of a $10 \times 9$ matrix onto a $3\times 3$ Cartesian process grid with block sizes $\text{MB}=\text{NB}=2$ is displayed.

    Block-Cyclic Distribution
    -

    Note that the odd number of columns of the local matrices owned by the processes P2, P5 and P8 accounts for $N=9$ not being an integral multiple of $\text{NB}=2$.

    +

    Note that the odd number of columns of the local matrices owned by the processes P2, P5 and P8 accounts for $N=9$ not being an integral multiple of $\text{NB}=2$.

    The choice of the block sizes is a compromise between a sufficiently large size for efficient local/serial BLAS, but one that is also small enough to achieve good parallel load balance.

    Below we show a strong scaling example of ScaLAPACKMatrix::invert() on up to 5 nodes each composed of two Intel Xeon 2660v2 IvyBridge sockets 2.20GHz, 10 cores/socket. Calculations are performed on square processor grids 1x1, 2x2, 3x3, 4x4, 5x5, 6x6, 7x7, 8x8, 9x9, 10x10.

    @@ -621,7 +621,7 @@

    Constructor for a rectangular matrix with n_rows and n_cols and distributed using the grid process_grid.

    -

    The parameters row_block_size and column_block_size are the block sizes used for the block-cyclic distribution of the matrix. In general, it is recommended to use powers of $2$, e.g. $16,32,64, \dots$.

    +

    The parameters row_block_size and column_block_size are the block sizes used for the block-cyclic distribution of the matrix. In general, it is recommended to use powers of $2$, e.g. $16,32,64, \dots$.

    Definition at line 81 of file scalapack.cc.

    @@ -666,7 +666,7 @@

    Constructor for a square matrix of size size, and distributed using the process grid in process_grid.

    -

    The parameter block_size is used for the block-cyclic distribution of the matrix. An identical block size is used for the rows and columns of the matrix. In general, it is recommended to use powers of $2$, e.g. $16,32,64, \dots$.

    +

    The parameter block_size is used for the block-cyclic distribution of the matrix. An identical block size is used for the rows and columns of the matrix. In general, it is recommended to use powers of $2$, e.g. $16,32,64, \dots$.

    Definition at line 106 of file scalapack.cc.

    @@ -711,7 +711,7 @@

    Constructor for a general rectangular matrix that is read from the file filename and distributed using the grid process_grid.

    Loads the matrix from file filename using HDF5. In case that deal.II was built without HDF5 a call to this function will cause an exception to be thrown.

    -

    The parameters row_block_size and column_block_size are the block sizes used for the block-cyclic distribution of the matrix. In general, it is recommended to use powers of $2$, e.g. $16,32,64, \dots$.

    +

    The parameters row_block_size and column_block_size are the block sizes used for the block-cyclic distribution of the matrix. In general, it is recommended to use powers of $2$, e.g. $16,32,64, \dots$.

    Definition at line 122 of file scalapack.cc.

    @@ -797,7 +797,7 @@

    Initialize the rectangular matrix with n_rows and n_cols and distributed using the grid process_grid.

    -

    The parameters row_block_size and column_block_size are the block sizes used for the block-cyclic distribution of the matrix. In general, it is recommended to use powers of $2$, e.g. $16,32,64, \dots$.

    +

    The parameters row_block_size and column_block_size are the block sizes used for the block-cyclic distribution of the matrix. In general, it is recommended to use powers of $2$, e.g. $16,32,64, \dots$.

    Definition at line 217 of file scalapack.cc.

    @@ -842,7 +842,7 @@

    Initialize the square matrix of size size and distributed using the grid process_grid.

    -

    The parameter block_size is used for the block-cyclic distribution of the matrix. An identical block size is used for the rows and columns of the matrix. In general, it is recommended to use powers of $2$, e.g. $16,32,64, \dots$.

    +

    The parameter block_size is used for the block-cyclic distribution of the matrix. An identical block size is used for the rows and columns of the matrix. In general, it is recommended to use powers of $2$, e.g. $16,32,64, \dots$.

    Definition at line 291 of file scalapack.cc.

    @@ -1105,9 +1105,9 @@
    -

    Transposing assignment: $\mathbf{A} = \mathbf{B}^T$

    -

    The matrices $\mathbf{A}$ and $\mathbf{B}$ must have the same process grid.

    -

    The following alignment conditions have to be fulfilled: $MB_A=NB_B$ and $NB_A=MB_B$.

    +

    Transposing assignment: $\mathbf{A} = \mathbf{B}^T$

    +

    The matrices $\mathbf{A}$ and $\mathbf{B}$ must have the same process grid.

    +

    The following alignment conditions have to be fulfilled: $MB_A=NB_B$ and $NB_A=MB_B$.

    Definition at line 981 of file scalapack.cc.

    @@ -1155,13 +1155,13 @@ transpose_B Block Sizes Operation -false $MB_A=MB_B$
    - $NB_A=NB_B$ $\mathbf{A} = a \mathbf{A} + b \mathbf{B}$ +false $MB_A=MB_B$
    + $NB_A=NB_B$ $\mathbf{A} = a \mathbf{A} + b \mathbf{B}$ -true $MB_A=NB_B$
    - $NB_A=MB_B$ $\mathbf{A} = a \mathbf{A} + b \mathbf{B}^T$ +true $MB_A=NB_B$
    + $NB_A=MB_B$ $\mathbf{A} = a \mathbf{A} + b \mathbf{B}^T$ -

    The matrices $\mathbf{A}$ and $\mathbf{B}$ must have the same process grid.

    +

    The matrices $\mathbf{A}$ and $\mathbf{B}$ must have the same process grid.

    Definition at line 991 of file scalapack.cc.

    @@ -1192,9 +1192,9 @@
    -

    Matrix-addition: $\mathbf{A} = \mathbf{A} + b\, \mathbf{B}$

    -

    The matrices $\mathbf{A}$ and $\mathbf{B}$ must have the same process grid.

    -

    The following alignment conditions have to be fulfilled: $MB_A=MB_B$ and $NB_A=NB_B$.

    +

    Matrix-addition: $\mathbf{A} = \mathbf{A} + b\, \mathbf{B}$

    +

    The matrices $\mathbf{A}$ and $\mathbf{B}$ must have the same process grid.

    +

    The following alignment conditions have to be fulfilled: $MB_A=MB_B$ and $NB_A=NB_B$.

    Definition at line 1047 of file scalapack.cc.

    @@ -1225,9 +1225,9 @@
    -

    Matrix-addition: $\mathbf{A} = \mathbf{A} + b\, \mathbf{B}^T$

    -

    The matrices $\mathbf{A}$ and $\mathbf{B}$ must have the same process grid.

    -

    The following alignment conditions have to be fulfilled: $MB_A=NB_B$ and $NB_A=MB_B$.

    +

    Matrix-addition: $\mathbf{A} = \mathbf{A} + b\, \mathbf{B}^T$

    +

    The matrices $\mathbf{A}$ and $\mathbf{B}$ must have the same process grid.

    +

    The following alignment conditions have to be fulfilled: $MB_A=NB_B$ and $NB_A=MB_B$.

    Definition at line 1057 of file scalapack.cc.

    @@ -1285,24 +1285,24 @@ transpose_A transpose_B Block Sizes Operation -false false $MB_A=MB_C$
    - $NB_A=MB_B$
    - $NB_B=NB_C$ $\mathbf{C} = b \mathbf{A} \cdot \mathbf{B} + c \mathbf{C}$ +false false $MB_A=MB_C$
    + $NB_A=MB_B$
    + $NB_B=NB_C$ $\mathbf{C} = b \mathbf{A} \cdot \mathbf{B} + c \mathbf{C}$ -false true $MB_A=MB_C$
    - $NB_A=NB_B$
    - $MB_B=NB_C$ $\mathbf{C} = b \mathbf{A} \cdot \mathbf{B}^T + c \mathbf{C}$ +false true $MB_A=MB_C$
    + $NB_A=NB_B$
    + $MB_B=NB_C$ $\mathbf{C} = b \mathbf{A} \cdot \mathbf{B}^T + c \mathbf{C}$ -true false $MB_A=MB_B$
    - $NB_A=MB_C$
    - $NB_B=NB_C$ $\mathbf{C} = b \mathbf{A}^T \cdot \mathbf{B} + c \mathbf{C}$ +true false $MB_A=MB_B$
    + $NB_A=MB_C$
    + $NB_B=NB_C$ $\mathbf{C} = b \mathbf{A}^T \cdot \mathbf{B} + c \mathbf{C}$ -true true $MB_A=NB_B$
    - $NB_A=MB_C$
    - $MB_B=NB_C$ $\mathbf{C} = b \mathbf{A}^T \cdot \mathbf{B}^T + c \mathbf{C}$ +true true $MB_A=NB_B$
    + $NB_A=MB_C$
    + $MB_B=NB_C$ $\mathbf{C} = b \mathbf{A}^T \cdot \mathbf{B}^T + c \mathbf{C}$ -

    It is assumed that $\mathbf{A}$ and $\mathbf{B}$ have compatible sizes and that $\mathbf{C}$ already has the right size.

    -

    The matrices $\mathbf{A}$, $\mathbf{B}$ and $\mathbf{C}$ must have the same process grid.

    +

    It is assumed that $\mathbf{A}$ and $\mathbf{B}$ have compatible sizes and that $\mathbf{C}$ already has the right size.

    +

    The matrices $\mathbf{A}$, $\mathbf{B}$ and $\mathbf{C}$ must have the same process grid.

    Definition at line 1067 of file scalapack.cc.

    @@ -1339,11 +1339,11 @@

    Matrix-matrix-multiplication.

    -

    The optional parameter adding determines whether the result is stored in $\mathbf{C}$ or added to $\mathbf{C}$.

    -

    if (adding) $\mathbf{C} = \mathbf{C} + \mathbf{A} \cdot \mathbf{B}$

    -

    else $\mathbf{C} = \mathbf{A} \cdot \mathbf{B}$

    -

    It is assumed that $\mathbf{A}$ and $\mathbf{B}$ have compatible sizes and that $\mathbf{C}$ already has the right size.

    -

    The following alignment conditions have to be fulfilled: $MB_A=MB_C$, $NB_A=MB_B$ and $NB_B=NB_C$.

    +

    The optional parameter adding determines whether the result is stored in $\mathbf{C}$ or added to $\mathbf{C}$.

    +

    if (adding) $\mathbf{C} = \mathbf{C} + \mathbf{A} \cdot \mathbf{B}$

    +

    else $\mathbf{C} = \mathbf{A} \cdot \mathbf{B}$

    +

    It is assumed that $\mathbf{A}$ and $\mathbf{B}$ have compatible sizes and that $\mathbf{C}$ already has the right size.

    +

    The following alignment conditions have to be fulfilled: $MB_A=MB_C$, $NB_A=MB_B$ and $NB_B=NB_C$.

    Definition at line 1184 of file scalapack.cc.

    @@ -1379,12 +1379,12 @@
    -

    Matrix-matrix-multiplication using transpose of $\mathbf{A}$.

    -

    The optional parameter adding determines whether the result is stored in $\mathbf{C}$ or added to $\mathbf{C}$.

    -

    if (adding) $\mathbf{C} = \mathbf{C} + \mathbf{A}^T \cdot \mathbf{B}$

    -

    else $\mathbf{C} = \mathbf{A}^T \cdot \mathbf{B}$

    -

    It is assumed that $\mathbf{A}$ and $\mathbf{B}$ have compatible sizes and that $\mathbf{C}$ already has the right size.

    -

    The following alignment conditions have to be fulfilled: $MB_A=MB_B$, $NB_A=MB_C$ and $NB_B=NB_C$.

    +

    Matrix-matrix-multiplication using transpose of $\mathbf{A}$.

    +

    The optional parameter adding determines whether the result is stored in $\mathbf{C}$ or added to $\mathbf{C}$.

    +

    if (adding) $\mathbf{C} = \mathbf{C} + \mathbf{A}^T \cdot \mathbf{B}$

    +

    else $\mathbf{C} = \mathbf{A}^T \cdot \mathbf{B}$

    +

    It is assumed that $\mathbf{A}$ and $\mathbf{B}$ have compatible sizes and that $\mathbf{C}$ already has the right size.

    +

    The following alignment conditions have to be fulfilled: $MB_A=MB_B$, $NB_A=MB_C$ and $NB_B=NB_C$.

    Definition at line 1198 of file scalapack.cc.

    @@ -1420,12 +1420,12 @@ /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classScalarFunctionFromFunctionObject.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classScalarFunctionFromFunctionObject.html 2023-08-09 23:38:52.898585273 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classScalarFunctionFromFunctionObject.html 2023-08-09 23:38:52.898585273 +0000 @@ -257,7 +257,7 @@
    Vector<double> solution_1d;
    Definition: vector.h:109
    -

    We will denote this solution function described by this DoFHandler and vector object by $u_h(x)$ where $x$ is a vector with just one component, and consequently is not shown in boldface. Then assume that we want this $u_h(x)$ to be used as a boundary condition for a 2d problem at the line $y=0$. Let's say that this line corresponds to boundary indicator 123. If we say that the 2d problem is associated with

    DoFHandler<2> dof_handler_2d;
    +

    We will denote this solution function described by this DoFHandler and vector object by $u_h(x)$ where $x$ is a vector with just one component, and consequently is not shown in boldface. Then assume that we want this $u_h(x)$ to be used as a boundary condition for a 2d problem at the line $y=0$. Let's say that this line corresponds to boundary indicator 123. If we say that the 2d problem is associated with

    DoFHandler<2> dof_handler_2d;

    then in order to evaluate the boundary conditions for this 2d problem, we would want to call VectorTools::interpolate_boundary_values() via

    AffineConstraints<double> boundary_values_2d;
    123,
    @@ -265,7 +265,7 @@
    boundary_values_2d);
    void interpolate_boundary_values(const Mapping< dim, spacedim > &mapping, const DoFHandler< dim, spacedim > &dof, const std::map< types::boundary_id, const Function< spacedim, number > * > &function_map, std::map< types::global_dof_index, number > &boundary_values, const ComponentMask &component_mask=ComponentMask())
    -

    The question here is what to use as the Function object that can be passed as third argument. It needs to be a Function<2> object, i.e., it receives a 2d input point and is supposed to return the value at that point. What we want it to do is to just take the $x$ component of the input point and evaluate the 1d solution at that point, knowing that at the boundary with indicator 123, the $y$ component of the input point must be zero. This all can be achieved via the following function object:

    The question here is what to use as the Function object that can be passed as third argument. It needs to be a Function<2> object, i.e., it receives a 2d input point and is supposed to return the value at that point. What we want it to do is to just take the $x$ component of the input point and evaluate the 1d solution at that point, knowing that at the boundary with indicator 123, the $y$ component of the input point must be zero. This all can be achieved via the following function object:

    solution_1d_as_function_object (dof_handler_1d, solution_1d);
    auto boundary_evaluator
    = [&] (const Point<2> &p)
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolutionTransfer.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolutionTransfer.html 2023-08-09 23:38:52.926585482 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolutionTransfer.html 2023-08-09 23:38:52.926585482 +0000 @@ -278,7 +278,7 @@

    Interaction with hanging nodes

    -

    This class does its best to represent on the new mesh the finite element function that existed on the old mesh, but this may lead to situations where the function on the new mesh is no longer conforming at hanging nodes. To this end, consider a situation of a twice refined mesh that started with a single square cell (i.e., we now have 16 cells). Consider also that we coarsen 4 of the cells back to the first refinement level. In this case, we end up with a mesh that will look as follows if we were to use a $Q_1$ element:

    +

    This class does its best to represent on the new mesh the finite element function that existed on the old mesh, but this may lead to situations where the function on the new mesh is no longer conforming at hanging nodes. To this end, consider a situation of a twice refined mesh that started with a single square cell (i.e., we now have 16 cells). Consider also that we coarsen 4 of the cells back to the first refinement level. In this case, we end up with a mesh that will look as follows if we were to use a $Q_1$ element:

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverBFGS.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverBFGS.html 2023-08-09 23:38:52.950585661 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverBFGS.html 2023-08-09 23:38:52.950585661 +0000 @@ -211,7 +211,7 @@ \rho^{(k)} &\dealcoloneq \frac{1}{y^{(k)} \cdot s^{(k)}} \end{align*}" src="form_2417.png"/>

    -

    for a symmetric positive definite $H$. Limited memory variant is implemented via the two-loop recursion.

    +

    for a symmetric positive definite $H$. Limited memory variant is implemented via the two-loop recursion.

    Definition at line 58 of file solver_bfgs.h.

    Member Typedef Documentation

    @@ -372,8 +372,8 @@ \]" src="form_2418.png"/>

    starting from initial state x.

    -

    The function compute takes two arguments indicating the values of $x$ and of the gradient $g=\nabla f(\mathbf x)=\frac{\partial f}{\partial
-\mathbf x}$. When called, it needs to update the gradient $g$ at the given location $x$ and return the value of the function being minimized, i.e., $f(\mathbf x)$.

    +

    The function compute takes two arguments indicating the values of $x$ and of the gradient $g=\nabla f(\mathbf x)=\frac{\partial f}{\partial
+\mathbf x}$. When called, it needs to update the gradient $g$ at the given location $x$ and return the value of the function being minimized, i.e., $f(\mathbf x)$.

    @@ -395,7 +395,7 @@

    Connect a slot to perform a custom line-search.

    -

    Given the value of function f, the current value of unknown x, the gradient g and the search direction p, return the size $\alpha$ of the step $x \leftarrow x + \alpha p$, and update x, g and f accordingly.

    +

    Given the value of function f, the current value of unknown x, the gradient g and the search direction p, return the size $\alpha$ of the step $x \leftarrow x + \alpha p$, and update x, g and f accordingly.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverCG.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverCG.html 2023-08-09 23:38:52.982585900 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverCG.html 2023-08-09 23:38:52.982585900 +0000 @@ -477,7 +477,7 @@
    -

    Solve the linear system $Ax=b$ for x.

    +

    Solve the linear system $Ax=b$ for x.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFGMRES.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFGMRES.html 2023-08-09 23:38:53.006586079 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFGMRES.html 2023-08-09 23:38:53.006586079 +0000 @@ -364,7 +364,7 @@
    -

    Solve the linear system $Ax=b$ for x.

    +

    Solve the linear system $Ax=b$ for x.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFIRE.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFIRE.html 2023-08-09 23:38:53.034586289 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFIRE.html 2023-08-09 23:38:53.034586289 +0000 @@ -195,10 +195,10 @@

    Detailed Description

    template<typename VectorType = Vector<double>>
    -class SolverFIRE< VectorType >

    FIRE (Fast Inertial Relaxation Engine) for minimization of (potentially non-linear) objective function $E(\mathbf x)$, $\mathbf x$ is a vector of $n$ variables ( $n$ is the number of variables of the objective function). Like all other solver classes, it can work on any kind of vector and matrix as long as they satisfy certain requirements (for the requirements on matrices and vectors in order to work with this class, see the documentation of the Solver base class). The type of the solution vector must be passed as template argument, and defaults to Vector<double>.

    +class SolverFIRE< VectorType >

    FIRE (Fast Inertial Relaxation Engine) for minimization of (potentially non-linear) objective function $E(\mathbf x)$, $\mathbf x$ is a vector of $n$ variables ( $n$ is the number of variables of the objective function). Like all other solver classes, it can work on any kind of vector and matrix as long as they satisfy certain requirements (for the requirements on matrices and vectors in order to work with this class, see the documentation of the Solver base class). The type of the solution vector must be passed as template argument, and defaults to Vector<double>.

    FIRE is a damped dynamics method described in Structural Relaxation Made Simple by Bitzek et al. 2006, typically used to find stable equilibrium configurations of atomistic systems in computational material science. Starting from a given initial configuration of the atomistic system, the algorithm relies on inertia to obtain (nearest) configuration with least potential energy.

    Notation:

    -

    Given initial values for $\Delta t$, $\alpha = \alpha_0$, $\epsilon$, $\mathbf x = \mathbf x_0$ and $\mathbf v= \mathbf 0$ along with a given mass matrix $\mathbf M$, FIRE algorithm is as follows,

      +

      Given initial values for $\Delta t$, $\alpha = \alpha_0$, $\epsilon$, $\mathbf x = \mathbf x_0$ and $\mathbf v= \mathbf 0$ along with a given mass matrix $\mathbf M$, FIRE algorithm is as follows,

      1. Calculate $\mathbf g = \nabla E(\mathbf x)$ and check for convergence ( $\mathbf g \cdot \mathbf g < \epsilon^2 $).
      2. -
      3. Update $\mathbf x$ and $V$ using simple (forward) Euler integration step,
        +
      4. Update $\mathbf x$ and $V$ using simple (forward) Euler integration step,
        $\mathbf x = \mathbf x + \Delta t \mathbf v$,
        $\mathbf v = \mathbf v + \Delta t \mathbf M^{-1} \cdot \mathbf g$.
      5. Calculate $p = \mathbf g \cdot \mathbf v$.
      6. Set $\mathbf v = (1-\alpha) \mathbf v
                   + \alpha \frac{|\mathbf v|}{|\mathbf g|} \mathbf g$.
      7. -
      8. If $p<0$ and number of steps since $p$ was last negative is larger than certain value, then increase time step $\Delta t$ and decrease $\alpha$.
      9. +
      10. If $p<0$ and number of steps since $p$ was last negative is larger than certain value, then increase time step $\Delta t$ and decrease $\alpha$.
      11. If $p>0$, then decrease the time step, freeze the system i.e., $\mathbf v = \mathbf 0$ and reset $\alpha = \alpha_0$.
      12. Return to 1.
      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFlexibleCG.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFlexibleCG.html 2023-08-09 23:38:53.062586498 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverFlexibleCG.html 2023-08-09 23:38:53.062586498 +0000 @@ -417,7 +417,7 @@
      -

      Solve the linear system $Ax=b$ for x.

      +

      Solve the linear system $Ax=b$ for x.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverGMRES.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverGMRES.html 2023-08-09 23:38:53.098586767 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverGMRES.html 2023-08-09 23:38:53.098586767 +0000 @@ -446,7 +446,7 @@
      -

      Solve the linear system $Ax=b$ for x.

      +

      Solve the linear system $Ax=b$ for x.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverMinRes.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverMinRes.html 2023-08-09 23:38:53.122586945 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverMinRes.html 2023-08-09 23:38:53.122586945 +0000 @@ -403,7 +403,7 @@
      -

      Solve the linear system $Ax=b$ for x.

      +

      Solve the linear system $Ax=b$ for x.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverQMRS.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverQMRS.html 2023-08-09 23:38:53.150587154 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverQMRS.html 2023-08-09 23:38:53.150587154 +0000 @@ -374,7 +374,7 @@
      -

      Solve the linear system $Ax=b$ for x.

      +

      Solve the linear system $Ax=b$ for x.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverRichardson.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverRichardson.html 2023-08-09 23:38:53.174587334 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSolverRichardson.html 2023-08-09 23:38:53.174587334 +0000 @@ -404,7 +404,7 @@
      -

      Solve the linear system $Ax=b$ for x.

      +

      Solve the linear system $Ax=b$ for x.

      @@ -448,7 +448,7 @@
      -

      Solve $A^Tx=b$ for $x$.

      +

      Solve $A^Tx=b$ for $x$.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseDirectUMFPACK.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseDirectUMFPACK.html 2023-08-09 23:38:53.206587573 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseDirectUMFPACK.html 2023-08-09 23:38:53.206587573 +0000 @@ -617,8 +617,8 @@

      The solution will be returned in place of the right hand side vector.

      Parameters
      - - + +
      [in,out]rhs_and_solutionA vector that contains the right hand side $b$ of a linear system $Ax=b$ upon calling this function, and that contains the solution $x$ of the linear system after calling this function.
      [in]transposeIf set to true, this function solves the linear $A^T x = b$ instead of $Ax=b$.
      [in,out]rhs_and_solutionA vector that contains the right hand side $b$ of a linear system $Ax=b$ upon calling this function, and that contains the solution $x$ of the linear system after calling this function.
      [in]transposeIf set to true, this function solves the linear $A^T x = b$ instead of $Ax=b$.
      @@ -652,7 +652,7 @@

      Like the previous function, but for a complex-valued right hand side and solution vector.

      -

      If the matrix that was previously factorized had complex-valued entries, then the rhs_and_solution vector will, upon return from this function, simply contain the solution of the linear system $Ax=b$. If the matrix was real-valued, then this is also true, but the solution will simply be computed by applying the factorized $A^{-1}$ to both the real and imaginary parts of the right hand side vector.

      +

      If the matrix that was previously factorized had complex-valued entries, then the rhs_and_solution vector will, upon return from this function, simply contain the solution of the linear system $Ax=b$. If the matrix was real-valued, then this is also true, but the solution will simply be computed by applying the factorized $A^{-1}$ to both the real and imaginary parts of the right hand side vector.

      Definition at line 418 of file sparse_direct.cc.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseILU.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseILU.html 2023-08-09 23:38:53.274588080 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseILU.html 2023-08-09 23:38:53.274588080 +0000 @@ -2086,7 +2086,7 @@
      -

      Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, $A = \frac 12(A+A^T)$.

      +

      Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, $A = \frac 12(A+A^T)$.

      This operation assumes that the underlying sparsity pattern represents a symmetric object. If this is not the case, then the result of this operation will not be a symmetric matrix, since it only explicitly symmetrizes by looping over the lower left triangular part for efficiency reasons; if there are entries in the upper right triangle, then these elements are missed in the symmetrization. Symmetrization of the sparsity pattern can be obtain by SparsityPattern::symmetrize().

      @@ -2381,7 +2381,7 @@
      -

      Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e. $\left(v,Mv\right)$. This is useful, e.g. in the finite element context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

      +

      Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e. $\left(v,Mv\right)$. This is useful, e.g. in the finite element context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

      Obviously, the matrix needs to be quadratic for this operation, and for the result to actually be a norm it also needs to be either real symmetric or complex hermitian.

      The underlying template types of both this matrix and the given vector should either both be real or complex-valued, but not mixed, for this function to make sense.

      Note
      If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
      @@ -2423,7 +2423,7 @@
      -

      Compute the matrix scalar product $\left(u,Mv\right)$.

      +

      Compute the matrix scalar product $\left(u,Mv\right)$.

      Note
      If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
      @@ -2518,7 +2518,7 @@

      Perform the matrix-matrix multiplication C = A * B, or, if an optional vector argument is given, C = A * diag(V) * B, where diag(V) defines a diagonal matrix with the vector entries.

      This function assumes that the calling matrix A and the argument B have compatible sizes. By default, the output matrix C will be resized appropriately.

      -

      By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product $AB$ can be stored in $C$. This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.

      +

      By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product $AB$ can be stored in $C$. This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.

      When setting rebuild_sparsity_pattern to true (i.e., leaving it at the default value), it is important to realize that the matrix C passed as first argument still has to be initialized with a sparsity pattern (either at the time of creation of the SparseMatrix object, or via the SparseMatrix::reinit() function). This is because we could create a sparsity pattern inside the current function, and then associate C with it, but there would be no way to transfer ownership of this sparsity pattern to anyone once the current function finishes. Consequently, the function requires that C be already associated with a sparsity pattern object, and this object is then reset to fit the product of A and B.

      As a consequence of this, however, it is also important to realize that the sparsity pattern of C is modified and that this would render invalid all other SparseMatrix objects that happen to also use that sparsity pattern object.

      @@ -2598,8 +2598,8 @@
      -

      Return the $l_1$-norm of the matrix, that is $|M|_1=\max_{\mathrm{all\
-columns\ }j}\sum_{\mathrm{all\ rows\ } i} |M_{ij}|$, (max. sum of columns). This is the natural matrix norm that is compatible to the $l_1$-norm for vectors, i.e. $|Mv|_1\leq |M|_1 |v|_1$. (cf. Haemmerlin- Hoffmann: Numerische Mathematik)

      +

      Return the $l_1$-norm of the matrix, that is $|M|_1=\max_{\mathrm{all\
+columns\ }j}\sum_{\mathrm{all\ rows\ } i} |M_{ij}|$, (max. sum of columns). This is the natural matrix norm that is compatible to the $l_1$-norm for vectors, i.e. $|Mv|_1\leq |M|_1 |v|_1$. (cf. Haemmerlin- Hoffmann: Numerische Mathematik)

      @@ -2627,8 +2627,8 @@
      -

      Return the $l_\infty$-norm of the matrix, that is $|M|_\infty=\max_{\mathrm{all\ rows\ }i}\sum_{\mathrm{all\ columns\ }j}
-|M_{ij}|$, (max. sum of rows). This is the natural matrix norm that is compatible to the $l_\infty$-norm of vectors, i.e. $|Mv|_\infty \leq
+<p>Return the <picture><source srcset=$l_\infty$-norm of the matrix, that is $|M|_\infty=\max_{\mathrm{all\ rows\ }i}\sum_{\mathrm{all\ columns\ }j}
+|M_{ij}|$, (max. sum of rows). This is the natural matrix norm that is compatible to the $l_\infty$-norm of vectors, i.e. $|Mv|_\infty \leq
 |M|_\infty |v|_\infty$. (cf. Haemmerlin-Hoffmann: Numerische Mathematik)

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseLUDecomposition.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseLUDecomposition.html 2023-08-09 23:38:53.342588588 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseLUDecomposition.html 2023-08-09 23:38:53.346588618 +0000 @@ -1854,7 +1854,7 @@
      -

      Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, $A = \frac 12(A+A^T)$.

      +

      Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, $A = \frac 12(A+A^T)$.

      This operation assumes that the underlying sparsity pattern represents a symmetric object. If this is not the case, then the result of this operation will not be a symmetric matrix, since it only explicitly symmetrizes by looping over the lower left triangular part for efficiency reasons; if there are entries in the upper right triangle, then these elements are missed in the symmetrization. Symmetrization of the sparsity pattern can be obtain by SparsityPattern::symmetrize().

      @@ -2252,7 +2252,7 @@
      -

      Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e. $\left(v,Mv\right)$. This is useful, e.g. in the finite element context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

      +

      Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e. $\left(v,Mv\right)$. This is useful, e.g. in the finite element context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

      Obviously, the matrix needs to be quadratic for this operation, and for the result to actually be a norm it also needs to be either real symmetric or complex hermitian.

      The underlying template types of both this matrix and the given vector should either both be real or complex-valued, but not mixed, for this function to make sense.

      Note
      If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
      @@ -2294,7 +2294,7 @@
      -

      Compute the matrix scalar product $\left(u,Mv\right)$.

      +

      Compute the matrix scalar product $\left(u,Mv\right)$.

      Note
      If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
      @@ -2389,7 +2389,7 @@

      Perform the matrix-matrix multiplication C = A * B, or, if an optional vector argument is given, C = A * diag(V) * B, where diag(V) defines a diagonal matrix with the vector entries.

      This function assumes that the calling matrix A and the argument B have compatible sizes. By default, the output matrix C will be resized appropriately.

      -

      By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product $AB$ can be stored in $C$. This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.

      +

      By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product $AB$ can be stored in $C$. This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.

      When setting rebuild_sparsity_pattern to true (i.e., leaving it at the default value), it is important to realize that the matrix C passed as first argument still has to be initialized with a sparsity pattern (either at the time of creation of the SparseMatrix object, or via the SparseMatrix::reinit() function). This is because we could create a sparsity pattern inside the current function, and then associate C with it, but there would be no way to transfer ownership of this sparsity pattern to anyone once the current function finishes. Consequently, the function requires that C be already associated with a sparsity pattern object, and this object is then reset to fit the product of A and B.

      As a consequence of this, however, it is also important to realize that the sparsity pattern of C is modified and that this would render invalid all other SparseMatrix objects that happen to also use that sparsity pattern object.

      @@ -2469,8 +2469,8 @@
      -

      Return the $l_1$-norm of the matrix, that is $|M|_1=\max_{\mathrm{all\
-columns\ }j}\sum_{\mathrm{all\ rows\ } i} |M_{ij}|$, (max. sum of columns). This is the natural matrix norm that is compatible to the $l_1$-norm for vectors, i.e. $|Mv|_1\leq |M|_1 |v|_1$. (cf. Haemmerlin- Hoffmann: Numerische Mathematik)

      +

      Return the $l_1$-norm of the matrix, that is $|M|_1=\max_{\mathrm{all\
+columns\ }j}\sum_{\mathrm{all\ rows\ } i} |M_{ij}|$, (max. sum of columns). This is the natural matrix norm that is compatible to the $l_1$-norm for vectors, i.e. $|Mv|_1\leq |M|_1 |v|_1$. (cf. Haemmerlin- Hoffmann: Numerische Mathematik)

      @@ -2498,8 +2498,8 @@
      -

      Return the $l_\infty$-norm of the matrix, that is $|M|_\infty=\max_{\mathrm{all\ rows\ }i}\sum_{\mathrm{all\ columns\ }j}
-|M_{ij}|$, (max. sum of rows). This is the natural matrix norm that is compatible to the $l_\infty$-norm of vectors, i.e. $|Mv|_\infty \leq
+<p>Return the <picture><source srcset=$l_\infty$-norm of the matrix, that is $|M|_\infty=\max_{\mathrm{all\ rows\ }i}\sum_{\mathrm{all\ columns\ }j}
+|M_{ij}|$, (max. sum of rows). This is the natural matrix norm that is compatible to the $l_\infty$-norm of vectors, i.e. $|Mv|_\infty \leq
 |M|_\infty |v|_\infty$. (cf. Haemmerlin-Hoffmann: Numerische Mathematik)

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMIC.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMIC.html 2023-08-09 23:38:53.414589126 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMIC.html 2023-08-09 23:38:53.418589156 +0000 @@ -425,8 +425,8 @@
      template<typename number>
      class SparseMIC< number >

      Implementation of the Modified Incomplete Cholesky (MIC(0)) preconditioner for symmetric matrices. This class conforms to the state and usage specification in SparseLUDecomposition.

      The decomposition

      -

      Let a symmetric, positive-definite, sparse matrix $A$ be in the form $A = D
-- L - L^T$, where $D$ is the diagonal part of $A$ and $-L$ is a strictly lower triangular matrix. The MIC(0) decomposition of the matrix $A$ is defined by $B = (X-L)X^{-1}(X-L^T)$, where $X$ is a diagonal matrix defined by the condition $\text{rowsum}(A) = \text{rowsum}(B)$.

      +

      Let a symmetric, positive-definite, sparse matrix $A$ be in the form $A = D
+- L - L^T$, where $D$ is the diagonal part of $A$ and $-L$ is a strictly lower triangular matrix. The MIC(0) decomposition of the matrix $A$ is defined by $B = (X-L)X^{-1}(X-L^T)$, where $X$ is a diagonal matrix defined by the condition $\text{rowsum}(A) = \text{rowsum}(B)$.

      Definition at line 46 of file sparse_mic.h.

      Member Typedef Documentation

      @@ -2152,7 +2152,7 @@
      -

      Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, $A = \frac 12(A+A^T)$.

      +

      Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, $A = \frac 12(A+A^T)$.

      This operation assumes that the underlying sparsity pattern represents a symmetric object. If this is not the case, then the result of this operation will not be a symmetric matrix, since it only explicitly symmetrizes by looping over the lower left triangular part for efficiency reasons; if there are entries in the upper right triangle, then these elements are missed in the symmetrization. Symmetrization of the sparsity pattern can be obtain by SparsityPattern::symmetrize().

      @@ -2447,7 +2447,7 @@
      -

      Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e. $\left(v,Mv\right)$. This is useful, e.g. in the finite element context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

      +

      Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e. $\left(v,Mv\right)$. This is useful, e.g. in the finite element context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

      Obviously, the matrix needs to be quadratic for this operation, and for the result to actually be a norm it also needs to be either real symmetric or complex hermitian.

      The underlying template types of both this matrix and the given vector should either both be real or complex-valued, but not mixed, for this function to make sense.

      Note
      If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
      @@ -2489,7 +2489,7 @@
      -

      Compute the matrix scalar product $\left(u,Mv\right)$.

      +

      Compute the matrix scalar product $\left(u,Mv\right)$.

      Note
      If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
      @@ -2584,7 +2584,7 @@

      Perform the matrix-matrix multiplication C = A * B, or, if an optional vector argument is given, C = A * diag(V) * B, where diag(V) defines a diagonal matrix with the vector entries.

      This function assumes that the calling matrix A and the argument B have compatible sizes. By default, the output matrix C will be resized appropriately.

      -

      By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product $AB$ can be stored in $C$. This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.

      +

      By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product $AB$ can be stored in $C$. This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.

      When setting rebuild_sparsity_pattern to true (i.e., leaving it at the default value), it is important to realize that the matrix C passed as first argument still has to be initialized with a sparsity pattern (either at the time of creation of the SparseMatrix object, or via the SparseMatrix::reinit() function). This is because we could create a sparsity pattern inside the current function, and then associate C with it, but there would be no way to transfer ownership of this sparsity pattern to anyone once the current function finishes. Consequently, the function requires that C be already associated with a sparsity pattern object, and this object is then reset to fit the product of A and B.

      As a consequence of this, however, it is also important to realize that the sparsity pattern of C is modified and that this would render invalid all other SparseMatrix objects that happen to also use that sparsity pattern object.

      @@ -2664,8 +2664,8 @@
      -

      Return the $l_1$-norm of the matrix, that is $|M|_1=\max_{\mathrm{all\
-columns\ }j}\sum_{\mathrm{all\ rows\ } i} |M_{ij}|$, (max. sum of columns). This is the natural matrix norm that is compatible to the $l_1$-norm for vectors, i.e. $|Mv|_1\leq |M|_1 |v|_1$. (cf. Haemmerlin- Hoffmann: Numerische Mathematik)

      +

      Return the $l_1$-norm of the matrix, that is $|M|_1=\max_{\mathrm{all\
+columns\ }j}\sum_{\mathrm{all\ rows\ } i} |M_{ij}|$, (max. sum of columns). This is the natural matrix norm that is compatible to the $l_1$-norm for vectors, i.e. $|Mv|_1\leq |M|_1 |v|_1$. (cf. Haemmerlin- Hoffmann: Numerische Mathematik)

      @@ -2693,8 +2693,8 @@
      -

      Return the $l_\infty$-norm of the matrix, that is $|M|_\infty=\max_{\mathrm{all\ rows\ }i}\sum_{\mathrm{all\ columns\ }j}
-|M_{ij}|$, (max. sum of rows). This is the natural matrix norm that is compatible to the $l_\infty$-norm of vectors, i.e. $|Mv|_\infty \leq
+<p>Return the <picture><source srcset=$l_\infty$-norm of the matrix, that is $|M|_\infty=\max_{\mathrm{all\ rows\ }i}\sum_{\mathrm{all\ columns\ }j}
+|M_{ij}|$, (max. sum of rows). This is the natural matrix norm that is compatible to the $l_\infty$-norm of vectors, i.e. $|Mv|_\infty \leq
 |M|_\infty |v|_\infty$. (cf. Haemmerlin-Hoffmann: Numerische Mathematik)

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrix.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrix.html 2023-08-09 23:38:53.482589634 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrix.html 2023-08-09 23:38:53.482589634 +0000 @@ -1561,7 +1561,7 @@
      -

      Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, $A = \frac 12(A+A^T)$.

      +

      Symmetrize the matrix by forming the mean value between the existing matrix and its transpose, $A = \frac 12(A+A^T)$.

      This operation assumes that the underlying sparsity pattern represents a symmetric object. If this is not the case, then the result of this operation will not be a symmetric matrix, since it only explicitly symmetrizes by looping over the lower left triangular part for efficiency reasons; if there are entries in the upper right triangle, then these elements are missed in the symmetrization. Symmetrization of the sparsity pattern can be obtain by SparsityPattern::symmetrize().

      @@ -1997,7 +1997,7 @@
      -

      Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e. $\left(v,Mv\right)$. This is useful, e.g. in the finite element context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

      +

      Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e. $\left(v,Mv\right)$. This is useful, e.g. in the finite element context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

      Obviously, the matrix needs to be quadratic for this operation, and for the result to actually be a norm it also needs to be either real symmetric or complex hermitian.

      The underlying template types of both this matrix and the given vector should either both be real or complex-valued, but not mixed, for this function to make sense.

      Note
      If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
      @@ -2031,7 +2031,7 @@
      -

      Compute the matrix scalar product $\left(u,Mv\right)$.

      +

      Compute the matrix scalar product $\left(u,Mv\right)$.

      Note
      If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile).
      @@ -2110,7 +2110,7 @@

      Perform the matrix-matrix multiplication C = A * B, or, if an optional vector argument is given, C = A * diag(V) * B, where diag(V) defines a diagonal matrix with the vector entries.

      This function assumes that the calling matrix A and the argument B have compatible sizes. By default, the output matrix C will be resized appropriately.

      -

      By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product $AB$ can be stored in $C$. This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.

      +

      By default, i.e., if the optional argument rebuild_sparsity_pattern is true, the sparsity pattern of the matrix C will be changed to ensure that all entries that result from the product $AB$ can be stored in $C$. This is an expensive operation, and if there is a way to predict the sparsity pattern up front, you should probably build it yourself before calling this function with false as last argument. In this case, the rebuilding of the sparsity pattern is bypassed.

      When setting rebuild_sparsity_pattern to true (i.e., leaving it at the default value), it is important to realize that the matrix C passed as first argument still has to be initialized with a sparsity pattern (either at the time of creation of the SparseMatrix object, or via the SparseMatrix::reinit() function). This is because we could create a sparsity pattern inside the current function, and then associate C with it, but there would be no way to transfer ownership of this sparsity pattern to anyone once the current function finishes. Consequently, the function requires that C be already associated with a sparsity pattern object, and this object is then reset to fit the product of A and B.

      As a consequence of this, however, it is also important to realize that the sparsity pattern of C is modified and that this would render invalid all other SparseMatrix objects that happen to also use that sparsity pattern object.

      @@ -2174,8 +2174,8 @@
      -

      Return the $l_1$-norm of the matrix, that is $|M|_1=\max_{\mathrm{all\
-columns\ }j}\sum_{\mathrm{all\ rows\ } i} |M_{ij}|$, (max. sum of columns). This is the natural matrix norm that is compatible to the $l_1$-norm for vectors, i.e. $|Mv|_1\leq |M|_1 |v|_1$. (cf. Haemmerlin- Hoffmann: Numerische Mathematik)

      +

      Return the $l_1$-norm of the matrix, that is $|M|_1=\max_{\mathrm{all\
+columns\ }j}\sum_{\mathrm{all\ rows\ } i} |M_{ij}|$, (max. sum of columns). This is the natural matrix norm that is compatible to the $l_1$-norm for vectors, i.e. $|Mv|_1\leq |M|_1 |v|_1$. (cf. Haemmerlin- Hoffmann: Numerische Mathematik)

      @@ -2195,8 +2195,8 @@
      -

      Return the $l_\infty$-norm of the matrix, that is $|M|_\infty=\max_{\mathrm{all\ rows\ }i}\sum_{\mathrm{all\ columns\ }j}
-|M_{ij}|$, (max. sum of rows). This is the natural matrix norm that is compatible to the $l_\infty$-norm of vectors, i.e. $|Mv|_\infty \leq
+<p>Return the <picture><source srcset=$l_\infty$-norm of the matrix, that is $|M|_\infty=\max_{\mathrm{all\ rows\ }i}\sum_{\mathrm{all\ columns\ }j}
+|M_{ij}|$, (max. sum of rows). This is the natural matrix norm that is compatible to the $l_\infty$-norm of vectors, i.e. $|Mv|_\infty \leq
 |M|_\infty |v|_\infty$. (cf. Haemmerlin-Hoffmann: Numerische Mathematik)

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrixEZ.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrixEZ.html 2023-08-09 23:38:53.530589992 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrixEZ.html 2023-08-09 23:38:53.530589992 +0000 @@ -1345,7 +1345,7 @@
      -

      Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix.

      +

      Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix.

      @@ -1376,7 +1376,7 @@
      -

      Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult but takes the transposed matrix.

      +

      Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult but takes the transposed matrix.

      @@ -1407,7 +1407,7 @@
      -

      Adding Matrix-vector multiplication. Add $M*src$ on $dst$ with $M$ being this matrix.

      +

      Adding Matrix-vector multiplication. Add $M*src$ on $dst$ with $M$ being this matrix.

      @@ -1438,7 +1438,7 @@
      -

      Adding Matrix-vector multiplication. Add $M^T*src$ to $dst$ with $M$ being this matrix. This function does the same as vmult_add but takes the transposed matrix.

      +

      Adding Matrix-vector multiplication. Add $M^T*src$ to $dst$ with $M$ being this matrix. This function does the same as vmult_add but takes the transposed matrix.

      @@ -1575,7 +1575,7 @@
      -

      Apply SOR preconditioning matrix to src. The result of this method is $dst = (om D - L)^{-1} src$.

      +

      Apply SOR preconditioning matrix to src. The result of this method is $dst = (om D - L)^{-1} src$.

      @@ -1612,7 +1612,7 @@
      -

      Apply transpose SOR preconditioning matrix to src. The result of this method is $dst = (om D - U)^{-1} src$.

      +

      Apply transpose SOR preconditioning matrix to src. The result of this method is $dst = (om D - U)^{-1} src$.

      @@ -1657,7 +1657,7 @@
      -

      Add the matrix A conjugated by B, that is, $B A B^T$ to this object. If the parameter transpose is true, compute $B^T A B$.

      +

      Add the matrix A conjugated by B, that is, $B A B^T$ to this object. If the parameter transpose is true, compute $B^T A B$.

      This function requires that B has a const_iterator traversing all matrix entries and that A has a function el(i,j) for access to a specific entry.

      Definition at line 1461 of file sparse_matrix_ez.h.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrixIterators_1_1Iterator.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrixIterators_1_1Iterator.html 2023-08-09 23:38:53.550590142 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparseMatrixIterators_1_1Iterator.html 2023-08-09 23:38:53.550590142 +0000 @@ -141,7 +141,7 @@

      The typical use for these iterators is to iterate over the elements of a sparse matrix or over the elements of individual rows. Note that there is no guarantee that the elements of a row are actually traversed in an order in which columns monotonically increase. See the documentation of the SparsityPattern class for more information.

      The first template argument denotes the underlying numeric type, the second the constness of the matrix.

      Since there is a specialization of this class for Constness=false, this class is for iterators to constant matrices.

      -
      Note
      This class operates directly on the internal data structures of the SparsityPattern and SparseMatrix classes. As a consequence, some operations are cheap and some are not. In particular, it is cheap to access the column index and the value of an entry pointed to. On the other hand, it is expensive to access the row index (this requires $O(\log(N))$ operations for a matrix with $N$ row). As a consequence, when you design algorithms that use these iterators, it is common practice to not loop over all elements of a sparse matrix at once, but to have an outer loop over all rows and within this loop iterate over the elements of this row. This way, you only ever need to dereference the iterator to obtain the column indices and values whereas the (expensive) lookup of the row index can be avoided by using the loop index instead.
      +
      Note
      This class operates directly on the internal data structures of the SparsityPattern and SparseMatrix classes. As a consequence, some operations are cheap and some are not. In particular, it is cheap to access the column index and the value of an entry pointed to. On the other hand, it is expensive to access the row index (this requires $O(\log(N))$ operations for a matrix with $N$ row). As a consequence, when you design algorithms that use these iterators, it is common practice to not loop over all elements of a sparse matrix at once, but to have an outer loop over all rows and within this loop iterate over the elements of this row. This way, you only ever need to dereference the iterator to obtain the column indices and values whereas the (expensive) lookup of the row index can be avoided by using the loop index instead.

      Definition at line 347 of file sparse_matrix.h.

      Member Typedef Documentation

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparsityPattern.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparsityPattern.html 2023-08-09 23:38:53.598590500 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparsityPattern.html 2023-08-09 23:38:53.598590500 +0000 @@ -1282,7 +1282,7 @@
      -

      Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of $|i-j|$ for which the index pair $(i,j)$ represents a nonzero entry of the matrix. Consequently, the maximum bandwidth a $n\times m$ matrix can have is $\max\{n-1,m-1\}$, a diagonal matrix has bandwidth 0, and there are at most $2*q+1$ entries per row if the bandwidth is $q$. The returned quantity is sometimes called "half +

      Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of $|i-j|$ for which the index pair $(i,j)$ represents a nonzero entry of the matrix. Consequently, the maximum bandwidth a $n\times m$ matrix can have is $\max\{n-1,m-1\}$, a diagonal matrix has bandwidth 0, and there are at most $2*q+1$ entries per row if the bandwidth is $q$. The returned quantity is sometimes called "half bandwidth" in the literature.

      Definition at line 674 of file sparsity_pattern.cc.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparsityPatternIterators_1_1Iterator.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparsityPatternIterators_1_1Iterator.html 2023-08-09 23:38:53.626590709 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSparsityPatternIterators_1_1Iterator.html 2023-08-09 23:38:53.626590709 +0000 @@ -158,7 +158,7 @@

      Detailed Description

      An iterator class for walking over the elements of a sparsity pattern.

      The typical use for these iterators is to iterate over the elements of a sparsity pattern (or, since they also serve as the basis for iterating over the elements of an associated matrix, over the elements of a sparse matrix), or over the elements of individual rows. There is no guarantee that the elements of a row are actually traversed in an order in which column numbers monotonically increase. See the documentation of the SparsityPattern class for more information.

      -
      Note
      This class operates directly on the internal data structures of the SparsityPattern class. As a consequence, some operations are cheap and some are not. In particular, it is cheap to access the column index of the sparsity pattern entry pointed to. On the other hand, it is expensive to access the row index (this requires $O(\log(N))$ operations for a matrix with $N$ row). As a consequence, when you design algorithms that use these iterators, it is common practice to not loop over all elements of a sparsity pattern at once, but to have an outer loop over all rows and within this loop iterate over the elements of this row. This way, you only ever need to dereference the iterator to obtain the column indices whereas the (expensive) lookup of the row index can be avoided by using the loop index instead.
      +
      Note
      This class operates directly on the internal data structures of the SparsityPattern class. As a consequence, some operations are cheap and some are not. In particular, it is cheap to access the column index of the sparsity pattern entry pointed to. On the other hand, it is expensive to access the row index (this requires $O(\log(N))$ operations for a matrix with $N$ row). As a consequence, when you design algorithms that use these iterators, it is common practice to not loop over all elements of a sparsity pattern at once, but to have an outer loop over all rows and within this loop iterate over the elements of this row. This way, you only ever need to dereference the iterator to obtain the column indices whereas the (expensive) lookup of the row index can be avoided by using the loop index instead.

      Definition at line 280 of file sparsity_pattern.h.

      Member Typedef Documentation

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSphericalManifold.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSphericalManifold.html 2023-08-09 23:38:53.670591037 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSphericalManifold.html 2023-08-09 23:38:53.670591037 +0000 @@ -217,20 +217,20 @@ class SphericalManifold< dim, spacedim >

      Manifold description for a spherical space coordinate system.

      You can use this Manifold object to describe any sphere, circle, hypersphere or hyperdisc in two or three dimensions. This manifold can be used as a co-dimension one manifold descriptor of a spherical surface embedded in a higher dimensional space, or as a co-dimension zero manifold descriptor for a body with positive volume, provided that the center of the spherical space is excluded from the domain. An example for the use of this function would be in the description of a hyper-shell or hyper-ball geometry, for example after creating a coarse mesh using GridGenerator::hyper_ball(). (However, it is worth mentioning that generating a good mesh for a disk or ball is complicated and requires addition steps. See the "Possibilities for extensions" section of step-6 for an extensive discussion of how one would construct such meshes and what one needs to do for it.)

      The two template arguments match the meaning of the two template arguments in Triangulation<dim, spacedim>, however this Manifold can be used to describe both thin and thick objects, and the behavior is identical when dim <= spacedim, i.e., the functionality of SphericalManifold<2,3> is identical to SphericalManifold<3,3>.

      -

      While PolarManifold reflects the usual notion of polar coordinates, it may not be suitable for domains that contain either the north or south poles. Consider for instance the pair of points $x_1=(1,\pi/3,0)$ and $x_2=(1,\pi/3,\pi)$ in polar coordinates (lying on the surface of a sphere with radius one, on a parallel at height $\pi/3$). In this case connecting the points with a straight line in polar coordinates would take the long road around the globe, without passing through the north pole.

      +

      While PolarManifold reflects the usual notion of polar coordinates, it may not be suitable for domains that contain either the north or south poles. Consider for instance the pair of points $x_1=(1,\pi/3,0)$ and $x_2=(1,\pi/3,\pi)$ in polar coordinates (lying on the surface of a sphere with radius one, on a parallel at height $\pi/3$). In this case connecting the points with a straight line in polar coordinates would take the long road around the globe, without passing through the north pole.

      These two points would be connected (using a PolarManifold) by the curve

      -\begin{align*}
+<picture><source srcset=\begin{align*}
   s: [0,1]  & \rightarrow &  \mathbb S^3 \\
           t & \mapsto     &  (1,\pi/3,0) + (0,0,t\pi)
-\end{align*} +\end{align*}" src="form_1449.png"/>

      This curve is not a geodesic on the sphere, and it is not how we would connect those two points. A better curve, would be the one passing through the North pole:

      -\[
+<picture><source srcset=\[
  s(t) = x_1 \cos(\alpha(t)) + \kappa \times x_1 \sin(\alpha(t)) +
  \kappa ( \kappa \cdot x_1) (1-\cos(\alpha(t))).
-\] +\]" src="form_1450.png"/>

      -

      where $\kappa = \frac{x_1 \times x_2}{\Vert x_1 \times x_2 \Vert}$ and $\alpha(t) = t \cdot \arccos(x_1 \cdot x_2)$ for $t\in[0,1]$. Indeed, this is a geodesic, and it is the natural choice when connecting points on the surface of the sphere. In the examples above, the PolarManifold class implements the first way of connecting two points on the surface of a sphere, while SphericalManifold implements the second way, i.e., this Manifold connects points using geodesics. If more than two points are involved through a SphericalManifold::get_new_points() call, a so-called spherical average is used where the final point minimizes the weighted distance to all other points via geodesics.

      +

      where $\kappa = \frac{x_1 \times x_2}{\Vert x_1 \times x_2 \Vert}$ and $\alpha(t) = t \cdot \arccos(x_1 \cdot x_2)$ for $t\in[0,1]$. Indeed, this is a geodesic, and it is the natural choice when connecting points on the surface of the sphere. In the examples above, the PolarManifold class implements the first way of connecting two points on the surface of a sphere, while SphericalManifold implements the second way, i.e., this Manifold connects points using geodesics. If more than two points are involved through a SphericalManifold::get_new_points() call, a so-called spherical average is used where the final point minimizes the weighted distance to all other points via geodesics.

      In particular, this class implements a Manifold that joins any two points in space by first projecting them onto the surface of a sphere with unit radius, then connecting them with a geodesic, and finally rescaling the final radius so that the resulting one is the weighted average of the starting radii. This Manifold is identical to PolarManifold in dimension two, while for dimension three it returns points that are more uniformly distributed on the sphere, and it is invariant with respect to rotations of the coordinate system, therefore avoiding the problems that PolarManifold has at the poles. Notice, in particular, that computing tangent vectors at the poles with a PolarManifold is not well defined, while it is perfectly fine with this class.

      For mathematical reasons, it is impossible to construct a unique map of a sphere using only geodesic curves, and therefore, using this class with MappingManifold is discouraged. If you use this Manifold to describe the geometry of a sphere, you should use MappingQ as the underlying mapping, and not MappingManifold.

      This Manifold can be used only on geometries where a ball with finite radius is removed from the center. Indeed, the center is a singular point for this manifold, and if you try to connect two points across the center, they would travel on spherical coordinates, avoiding the center.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSymmetricTensor.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSymmetricTensor.html 2023-08-09 23:38:53.738591545 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classSymmetricTensor.html 2023-08-09 23:38:53.738591545 +0000 @@ -299,7 +299,7 @@ std::ostream &&#href_anchor"memTemplItemRight" valign="bottom">operator<< (std::ostream &out, const SymmetricTensor< 4, dim, Number > &t) &#href_anchor"details" id="details">

      Detailed Description

      template<int rank_, int dim, typename Number>
      -class SymmetricTensor< rank_, dim, Number >

      Provide a class that stores symmetric tensors of rank 2,4,... efficiently, i.e. only store those off-diagonal elements of the full tensor that are not redundant. For example, for symmetric $2\times 2$ tensors, this would be the elements 11, 22, and 12, while the element 21 is equal to the 12 element. Within this documentation, second order symmetric tensors are denoted as bold-faced upper-case Latin letters such as $\mathbf A, \mathbf B, \dots$ or bold-faced Greek letters such as $\boldsymbol{\varepsilon}$, $\boldsymbol{\sigma}$. The Cartesian coordinates of a second-order tensor such as $\mathbf A$ are represented as $A_{ij}$ where $i,j$ are indices ranging from 0 to dim-1.

      +class SymmetricTensor< rank_, dim, Number >

      Provide a class that stores symmetric tensors of rank 2,4,... efficiently, i.e. only store those off-diagonal elements of the full tensor that are not redundant. For example, for symmetric $2\times 2$ tensors, this would be the elements 11, 22, and 12, while the element 21 is equal to the 12 element. Within this documentation, second order symmetric tensors are denoted as bold-faced upper-case Latin letters such as $\mathbf A, \mathbf B, \dots$ or bold-faced Greek letters such as $\boldsymbol{\varepsilon}$, $\boldsymbol{\sigma}$. The Cartesian coordinates of a second-order tensor such as $\mathbf A$ are represented as $A_{ij}$ where $i,j$ are indices ranging from 0 to dim-1.

      Using this class for symmetric tensors of rank 2 has advantages over matrices in many cases since the dimension is known to the compiler as well as the location of the data. It is therefore possible to produce far more efficient code than for matrices with runtime-dependent dimension. It is also more efficient than using the more general Tensor class, since fewer elements are stored, and the class automatically makes sure that the tensor represents a symmetric object.

      For tensors of higher rank, the savings in storage are even higher. For example for the $3 \times 3 \times 3 \times 3$ tensors of rank 4, only 36 instead of the full 81 entries have to be stored. These rank 4 tensors are denoted by blackboard-style upper-case Latin letters such as $\mathbb A$ with components $\mathcal{A}_{ijkl}$.

      While the definition of a symmetric rank-2 tensor is obvious, tensors of rank 4 are considered symmetric if they are operators mapping symmetric rank-2 tensors onto symmetric rank-2 tensors. This so-called minor symmetry of the rank 4 tensor requires that for every set of four indices $i, j, k, l$, the identity $\mathcal{C}_{ijkl} = \mathcal{C}_{jikl} =
@@ -625,7 +625,7 @@
   </tr>
 </table>
 </div><div class= -

      This operator assigns a scalar to a tensor. To avoid confusion with what exactly it means to assign a scalar value to a tensor, zero is the only value allowed for d, allowing the intuitive notation $\mathbf A = 0$ to reset all elements of the tensor to zero.

      +

      This operator assigns a scalar to a tensor. To avoid confusion with what exactly it means to assign a scalar value to a tensor, zero is the only value allowed for d, allowing the intuitive notation $\mathbf A = 0$ to reset all elements of the tensor to zero.

      @@ -887,8 +887,8 @@
      -

      Double contraction product between the present symmetric tensor and a tensor of rank 2. For example, if the present object is the symmetric rank-2 tensor $\mathbf{A}$ and it is multiplied by another symmetric rank-2 tensor $\mathbf{B}$, then the result is the scalar-product double contraction $\mathbf A : \mathbf B = \sum_{i,j} A_{ij} B_{ij}$. In this case, the return value evaluates to a single scalar. While it is possible to define other scalar products (and associated induced norms), this one seems to be the most appropriate one.

      -

      If the present object is a rank-4 tensor such as $\mathbb A$, then the result is a rank-2 tensor $\mathbf C = \mathbb A : \mathbf B$, i.e., the operation contracts over the last two indices of the present object and the indices of the argument, and the result is a tensor of rank 2 ( $C_{ij} = \sum_{k,l} \mathcal{A}_{ijkl} B_{kl}$).

      +

      Double contraction product between the present symmetric tensor and a tensor of rank 2. For example, if the present object is the symmetric rank-2 tensor $\mathbf{A}$ and it is multiplied by another symmetric rank-2 tensor $\mathbf{B}$, then the result is the scalar-product double contraction $\mathbf A : \mathbf B = \sum_{i,j} A_{ij} B_{ij}$. In this case, the return value evaluates to a single scalar. While it is possible to define other scalar products (and associated induced norms), this one seems to be the most appropriate one.

      +

      If the present object is a rank-4 tensor such as $\mathbb A$, then the result is a rank-2 tensor $\mathbf C = \mathbb A : \mathbf B$, i.e., the operation contracts over the last two indices of the present object and the indices of the argument, and the result is a tensor of rank 2 ( $C_{ij} = \sum_{k,l} \mathcal{A}_{ijkl} B_{kl}$).

      Note that the multiplication operator for symmetric tensors is defined to be a double contraction over two indices, while it is defined as a single contraction over only one index for regular Tensor objects. For symmetric tensors it therefore acts in a way that is commonly denoted by a "colon multiplication" in the mathematical literature (the two dots of the colon suggesting that it is a contraction over two indices), which corresponds to a scalar product between tensors.

      It is worth pointing out that this definition of operator* between symmetric tensors is different to how the (in general non-symmetric) Tensor class defines operator*, namely as the single-contraction product over the last index of the first operand and the first index of the second operand. For the double contraction of Tensor objects, you will need to use the double_contract() function.

      To maintain at least a modicum of resemblance between the interfaces of Tensor and SymmetricTensor, there are also global functions double_contract() for symmetric tensors that then do the same work as this operator. However, rather than returning the result as a return value, they write it into the first argument to the function in the same way as the corresponding functions for the Tensor class do things.

      @@ -1232,7 +1232,7 @@
      -

      The opposite of the previous function: given an index $i$ in the unrolled form of the tensor, return what set of indices $(k,l)$ (for rank-2 tensors) or $(k,l,m,n)$ (for rank-4 tensors) corresponds to it.

      +

      The opposite of the previous function: given an index $i$ in the unrolled form of the tensor, return what set of indices $(k,l)$ (for rank-2 tensors) or $(k,l,m,n)$ (for rank-4 tensors) corresponds to it.

      @@ -1960,7 +1960,7 @@ \left[ (\text{tr} \mathbf A)^2 - \text{tr} (\mathbf{A}^2) \right]$" src="form_809.png"/>.

      For the kind of arguments to this function, i.e., a symmetric rank-2 tensor of size 2, the result is (counting indices starting at one) $I_2(\mathbf A) = II(\mathbf A) = \frac 12
   \left[ (A_{11} + A_{22})^2 - (A_{11}^2+2 A_{12}^2+ A_{22}^2) \right]
-  = A_{11} A_{22} - A_{12}^2$. As expected, for the $2\times 2$ symmetric tensors this function handles, this equals the determinant of the tensor. (This is so because for $2\times 2$ symmetric tensors, there really are only two invariants, so the second and third invariant are the same; the determinant is the third invariant.)

      + = A_{11} A_{22} - A_{12}^2$" src="form_810.png"/>. As expected, for the $2\times 2$ symmetric tensors this function handles, this equals the determinant of the tensor. (This is so because for $2\times 2$ symmetric tensors, there really are only two invariants, so the second and third invariant are the same; the determinant is the third invariant.)

      Definition at line 2917 of file symmetric_tensor.h.

      @@ -2049,8 +2049,8 @@
      -

      Return the eigenvalues of a symmetric $2\times 2$ tensor. The array of eigenvalues is sorted in descending order.

      -

      For $2\times 2$ tensors, the eigenvalues of tensor $\mathbf T$ are the roots of the characteristic polynomial $0 = \lambda^2
+<p>Return the eigenvalues of a symmetric <picture><source srcset=$2\times 2$ tensor. The array of eigenvalues is sorted in descending order.

      +

      For $2\times 2$ tensors, the eigenvalues of tensor $\mathbf T$ are the roots of the characteristic polynomial $0 = \lambda^2
 - \lambda\;\text{tr}\mathbf{T} + \det \mathbf{T}$ as given by $\lambda_1, \lambda_2 = \frac{1}{2} \left[ \text{tr} \mathbf{T} \pm
 \sqrt{(\text{tr} \mathbf{T})^2 - 4 \det \mathbf{T}} \right]$.

      Warning
      The algorithm employed here determines the eigenvalues by computing the roots of the characteristic polynomial. In the case that there exists a common root (the eigenvalues are equal), the computation is subject to round-off errors of order $\sqrt{\epsilon}$. As an alternative, the eigenvectors() function provides a more robust, but costly, method to compute the eigenvalues of a symmetric tensor.
      @@ -2081,8 +2081,8 @@
      -

      Return the eigenvalues of a symmetric $3\times 3$ tensor. The array of eigenvalues is sorted in descending order.

      -

      For $3\times 3$ tensors, the eigenvalues of tensor $\mathbf T$ are the roots of the characteristic polynomial $0 = \lambda^3 - \lambda^2\;\text{tr}\mathbf T
+<p>Return the eigenvalues of a symmetric <picture><source srcset=$3\times 3$ tensor. The array of eigenvalues is sorted in descending order.

      +

      For $3\times 3$ tensors, the eigenvalues of tensor $\mathbf T$ are the roots of the characteristic polynomial $0 = \lambda^3 - \lambda^2\;\text{tr}\mathbf T
 - \frac{1}{2} \lambda
 \left[\text{tr}(\mathbf{T}^2) - (\text{tr}\mathbf T)^2\right] -
 \det \mathbf T$.

      @@ -2662,7 +2662,7 @@
      -

      Compute the scalar product $\mathbf A: \mathbf B=\sum_{i,j} A_{ij}B_{ij}$ between two tensors $\mathbf A, \mathbf B$ of rank 2. In the current case where both arguments are symmetric tensors, this is equivalent to calling the expression A*B which uses SymmetricTensor::operator*().

      +

      Compute the scalar product $\mathbf A: \mathbf B=\sum_{i,j} A_{ij}B_{ij}$ between two tensors $\mathbf A, \mathbf B$ of rank 2. In the current case where both arguments are symmetric tensors, this is equivalent to calling the expression A*B which uses SymmetricTensor::operator*().

      Definition at line 3737 of file symmetric_tensor.h.

      @@ -2701,7 +2701,7 @@
      -

      Compute the scalar product $\mathbf A: \mathbf B=\sum_{i,j} A_{ij}B_{ij}$ between two tensors $\mathbf A, \mathbf B$ of rank 2. We don't use operator* for this operation since the product between two tensors is usually assumed to be the contraction over the last index of the first tensor and the first index of the second tensor. For example, if B is a Tensor, calling A*B (instead of scalar_product(A,B)) provides $(\mathbf A \cdot\mathbf B)_{ij}=\sum_k A_{ik}B_{kj}$.

      +

      Compute the scalar product $\mathbf A: \mathbf B=\sum_{i,j} A_{ij}B_{ij}$ between two tensors $\mathbf A, \mathbf B$ of rank 2. We don't use operator* for this operation since the product between two tensors is usually assumed to be the contraction over the last index of the first tensor and the first index of the second tensor. For example, if B is a Tensor, calling A*B (instead of scalar_product(A,B)) provides $(\mathbf A \cdot\mathbf B)_{ij}=\sum_k A_{ik}B_{kj}$.

      Definition at line 3759 of file symmetric_tensor.h.

      @@ -2740,7 +2740,7 @@
      -

      Compute the scalar product $\mathbf A:\mathbf B=\sum_{i,j} A_{ij}B_{ij}$ between two tensors $\mathbf A, \mathbf B$ of rank 2. We don't use operator* for this operation since the product between two tensors is usually assumed to be the contraction over the last index of the first tensor and the first index of the second tensor. For example, if A is a Tensor, calling A*B (instead of scalar_product(A,B)) provides $(\mathbf A \cdot\mathbf B)_{ij}=\sum_k A_{ik}B_{kj}$.

      +

      Compute the scalar product $\mathbf A:\mathbf B=\sum_{i,j} A_{ij}B_{ij}$ between two tensors $\mathbf A, \mathbf B$ of rank 2. We don't use operator* for this operation since the product between two tensors is usually assumed to be the contraction over the last index of the first tensor and the first index of the second tensor. For example, if A is a Tensor, calling A*B (instead of scalar_product(A,B)) provides $(\mathbf A \cdot\mathbf B)_{ij}=\sum_k A_{ik}B_{kj}$.

      Definition at line 3786 of file symmetric_tensor.h.

      @@ -3127,13 +3127,13 @@
      -

      The dot product (single contraction) for tensors: Return a tensor of rank $(\text{rank}_1 + \text{rank}_2 - 2)$ that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:

      -\[
+<p>The dot product (single contraction) for tensors: Return a tensor of rank <picture><source srcset=$(\text{rank}_1 + \text{rank}_2 - 2)$ that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:

      +\[
   \text{result}_{i_1,\ldots,i_{r1},j_1,\ldots,j_{r2}}
   = \sum_{k}
     \text{left}_{i_1,\ldots,i_{r1}, k}
     \text{right}_{k, j_1,\ldots,j_{r2}}
-\] +\]" src="form_827.png"/>

      Note
      As one operand is a Tensor, the multiplication operator only performs a contraction over a single pair of indices. This is in contrast to the multiplication operator for SymmetricTensor, which does the double contraction.
      @@ -3174,13 +3174,13 @@
      -

      The dot product (single contraction) for tensors: Return a tensor of rank $(\text{rank}_1 + \text{rank}_2 - 2)$ that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:

      -\[
+<p>The dot product (single contraction) for tensors: Return a tensor of rank <picture><source srcset=$(\text{rank}_1 + \text{rank}_2 - 2)$ that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:

      +\[
   \text{result}_{i_1,\ldots,i_{r1},j_1,\ldots,j_{r2}}
   = \sum_{k}
     \text{left}_{i_1,\ldots,i_{r1}, k}
     \text{right}_{k, j_1,\ldots,j_{r2}}
-\] +\]" src="form_827.png"/>

      Note
      As one operand is a Tensor, the multiplication operator only performs a contraction over a single pair of indices. This is in contrast to the multiplication operator for SymmetricTensor, which does the double contraction.
      @@ -3346,7 +3346,7 @@
      n_independent_components
      -

      An integer denoting the number of independent components that fully describe a symmetric tensor. In $d$ space dimensions, this number equals $\frac 12 (d^2+d)$ for symmetric tensors of rank 2.

      +

      An integer denoting the number of independent components that fully describe a symmetric tensor. In $d$ space dimensions, this number equals $\frac 12 (d^2+d)$ for symmetric tensors of rank 2.

      Definition at line 743 of file symmetric_tensor.h.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTableBase.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTableBase.html 2023-08-09 23:38:53.778591844 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTableBase.html 2023-08-09 23:38:53.778591844 +0000 @@ -231,7 +231,7 @@

      In some way, this class is similar to the Tensor class, in that it templatizes on the number of dimensions. However, there are two major differences. The first is that the Tensor class stores only numeric values (as doubles), while the Table class stores arbitrary objects. The second is that the Tensor class has fixed sizes in each dimension, also given as a template argument, while this class can handle arbitrary and different sizes in each dimension.

      This has two consequences. First, since the size is not known at compile time, it has to do explicit memory allocation. Second, the layout of individual elements is not known at compile time, so access is slower than for the Tensor class where the number of elements are their location is known at compile time and the compiler can optimize with this knowledge (for example when unrolling loops). On the other hand, this class is of course more flexible, for example when you want a two-dimensional table with the number of rows equal to the number of degrees of freedom on a cell, and the number of columns equal to the number of quadrature points. Both numbers may only be known at run-time, so a flexible table is needed here. Furthermore, you may want to store, say, the gradients of shape functions, so the data type is not a single scalar value, but a tensor itself.

      Dealing with large data sets

      -

      The Table classes (derived from this class) are frequently used to store large data tables. A modest example is given in step-53 where we store a $380 \times 220$ table of geographic elevation data for a region of Africa, and this data requires about 670 kB if memory; however, tables that store three- or more-dimensional data (say, information about the density, pressure, and temperature in the earth interior on a regular grid of (latitude, longitude, depth) points) can easily run into hundreds of megabytes or more. These tables are then often provided to classes such as InterpolatedTensorProductGridData or InterpolatedUniformGridData.

      +

      The Table classes (derived from this class) are frequently used to store large data tables. A modest example is given in step-53 where we store a $380 \times 220$ table of geographic elevation data for a region of Africa, and this data requires about 670 kB if memory; however, tables that store three- or more-dimensional data (say, information about the density, pressure, and temperature in the earth interior on a regular grid of (latitude, longitude, depth) points) can easily run into hundreds of megabytes or more. These tables are then often provided to classes such as InterpolatedTensorProductGridData or InterpolatedUniformGridData.

      If you need to load such tables on single-processor (or multi-threaded) jobs, then there is nothing you can do about the size of these tables: The table just has to fit into memory. But, if your program is parallelized via MPI, then a typical first implementation would create a table object on every process and fill it on every MPI process by reading the data from a file. This is inefficient from two perspectives:

      • You will have a lot of processes that are all trying to read from the same file at the same time.
      • In most cases, the data stored on every process is the same, and while every process needs to be able to read from a table, it is not necessary that every process stores its own table: All MPI processes that happen to be located on the same machine might as well store only one copy and make it available to each other via shared memory; in this model, only one MPI process per machine needs to store the data, and all other processes could then access it.
      • /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTableHandler.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTableHandler.html 2023-08-09 23:38:53.806592053 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTableHandler.html 2023-08-09 23:38:53.806592053 +0000 @@ -199,7 +199,7 @@

        Two (or more) columns may be merged into a "supercolumn" by twice (or multiple) calling add_column_to_supercolumn(), see there. Additionally there is a function to set for each column the precision of the output of numbers, and there are several functions to prescribe the format and the captions the columns are written with in tex mode.

        A detailed explanation of this class is also given in the step-13 tutorial program.

        Example

        -

        This is a simple example demonstrating the usage of this class. The first column includes the numbers $i=1 \dots n$, the second $1^2 \dots n^2$, the third $\sqrt{1}\dots\sqrt{n}$, where the second and third columns are merged into one supercolumn with the superkey squares and roots. Additionally the first column is aligned to the right (the default was centered) and the precision of the square roots are set to be 6 (instead of 4 as default).

        +

        This is a simple example demonstrating the usage of this class. The first column includes the numbers $i=1 \dots n$, the second $1^2 \dots n^2$, the third $\sqrt{1}\dots\sqrt{n}$, where the second and third columns are merged into one supercolumn with the superkey squares and roots. Additionally the first column is aligned to the right (the default was centered) and the precision of the square roots are set to be 6 (instead of 4 as default).

        for (unsigned int i = 1; i <= n; ++i)
        {
        @@ -230,9 +230,9 @@

        When generating output, TableHandler expects that all columns have the exact same number of elements in it so that the result is in fact a table. This assumes that in each of the iterations (time steps, nonlinear iterations, etc) you fill every single column. On the other hand, this may not always be what you want to do. For example, it could be that the function that computes the nonlinear residual is only called every few time steps; or, a function computing statistics of the mesh is only called whenever the mesh is in fact refined. In these cases, the add_value() function will be called less often for some columns and the column would therefore have fewer elements; furthermore, these elements would not be aligned with the rows that contain the other data elements that were produced during this iteration. An entirely different scenario is that the table is filled and at a later time we use the data in there to compute the elements of other rows; the ConvergenceTable class does something like this.

        To support both scenarios, the TableHandler class has a property called auto-fill mode. By default, auto-fill mode is off, but it can be enabled by calling set_auto_fill_mode(). If auto-fill mode is enabled we use the following algorithm:

          -
        • When calling add_value(key, value), we count the number of elements in the column corresponding to key. Let's call this number $m$.
        • -
        • We also determine the maximal number of elements in the other columns; call it $n$.
        • -
        • If $m < n-1$ then we add $n-m-1$ copies of the object T() to this column. Here, T is the data type of the given value. For example, if T is a numeric type, then T() is the number zero; if T is std::string, then T() is the empty string "".
        • +
        • When calling add_value(key, value), we count the number of elements in the column corresponding to key. Let's call this number $m$.
        • +
        • We also determine the maximal number of elements in the other columns; call it $n$.
        • +
        • If $m < n-1$ then we add $n-m-1$ copies of the object T() to this column. Here, T is the data type of the given value. For example, if T is a numeric type, then T() is the number zero; if T is std::string, then T() is the empty string "".
        • Add the given value to this column.

        Padding the column with default elements makes sure that after the addition the column has as many entries as the longest other column. In other words, if we have skipped previous invocations of add_value() for a given key, then the padding will enter default values into this column.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensor.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensor.html 2023-08-09 23:38:53.850592381 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensor.html 2023-08-09 23:38:53.850592381 +0000 @@ -265,13 +265,13 @@ class Tensor< rank_, dim, Number >

        A general tensor class with an arbitrary rank, i.e. with an arbitrary number of indices. The Tensor class provides an indexing operator and a bit of infrastructure, but most functionality is recursively handed down to tensors of rank 1 or put into external templated functions, e.g. the contract family.

        The rank of a tensor specifies which types of physical quantities it can represent:

        • -A rank-0 tensor is a scalar that can store quantities such as temperature or pressure. These scalar quantities are shown in this documentation as simple lower-case Latin letters e.g. $a, b, c, \dots$.
        • +A rank-0 tensor is a scalar that can store quantities such as temperature or pressure. These scalar quantities are shown in this documentation as simple lower-case Latin letters e.g. $a, b, c, \dots$.
        • -A rank-1 tensor is a vector with dim components and it can represent vector quantities such as velocity, displacement, electric field, etc. They can also describe the gradient of a scalar field. The notation used for rank-1 tensors is bold-faced lower-case Latin letters e.g. $\mathbf a, \mathbf b, \mathbf c, \dots$. The components of a rank-1 tensor such as $\mathbf a$ are represented as $a_i$ where $i$ is an index between 0 and dim-1.
        • +A rank-1 tensor is a vector with dim components and it can represent vector quantities such as velocity, displacement, electric field, etc. They can also describe the gradient of a scalar field. The notation used for rank-1 tensors is bold-faced lower-case Latin letters e.g. $\mathbf a, \mathbf b, \mathbf c, \dots$. The components of a rank-1 tensor such as $\mathbf a$ are represented as $a_i$ where $i$ is an index between 0 and dim-1.
        • -A rank-2 tensor is a linear operator that can transform a vector into another vector. These tensors are similar to matrices with $\text{dim} \times \text{dim}$ components. There is a related class SymmetricTensor<2,dim> for tensors of rank 2 whose elements are symmetric. Rank-2 tensors are usually denoted by bold-faced upper-case Latin letters such as $\mathbf A, \mathbf B, \dots$ or bold-faced Greek letters for example $\boldsymbol{\varepsilon}, \boldsymbol{\sigma}$. The components of a rank 2 tensor such as $\mathbf A$ are shown with two indices $(i,j)$ as $A_{ij}$. These tensors usually describe the gradients of vector fields (deformation gradient, velocity gradient, etc.) or Hessians of scalar fields. Additionally, mechanical stress tensors are rank-2 tensors that map the unit normal vectors of internal surfaces into local traction (force per unit area) vectors.
        • +A rank-2 tensor is a linear operator that can transform a vector into another vector. These tensors are similar to matrices with $\text{dim} \times \text{dim}$ components. There is a related class SymmetricTensor<2,dim> for tensors of rank 2 whose elements are symmetric. Rank-2 tensors are usually denoted by bold-faced upper-case Latin letters such as $\mathbf A, \mathbf B, \dots$ or bold-faced Greek letters for example $\boldsymbol{\varepsilon}, \boldsymbol{\sigma}$. The components of a rank 2 tensor such as $\mathbf A$ are shown with two indices $(i,j)$ as $A_{ij}$. These tensors usually describe the gradients of vector fields (deformation gradient, velocity gradient, etc.) or Hessians of scalar fields. Additionally, mechanical stress tensors are rank-2 tensors that map the unit normal vectors of internal surfaces into local traction (force per unit area) vectors.
        • -Tensors with ranks higher than 2 are similarly defined in a consistent manner. They have $\text{dim}^{\text{rank}}$ components and the number of indices required to identify a component equals rank. For rank-4 tensors, a symmetric variant called SymmetricTensor<4,dim> exists.
        • +Tensors with ranks higher than 2 are similarly defined in a consistent manner. They have $\text{dim}^{\text{rank}}$ components and the number of indices required to identify a component equals rank. For rank-4 tensors, a symmetric variant called SymmetricTensor<4,dim> exists.

        Using this tensor class for objects of rank 2 has advantages over matrices in many cases since the dimension is known to the compiler as well as the location of the data. It is therefore possible to produce far more efficient code than for matrices with runtime-dependent dimension. It also makes the code easier to read because of the semantic difference between a tensor (an object that relates to a coordinate system and has transformation properties with regard to coordinate rotations and transforms) and matrices (which we consider as operators on arbitrary vector spaces related to linear algebra things).

        Template Parameters
        @@ -1222,7 +1222,7 @@
        -

        Return an unrolled index in the range $[0,\text{dim}^{\text{rank}}-1]$ for the element of the tensor indexed by the argument to the function.

        +

        Return an unrolled index in the range $[0,\text{dim}^{\text{rank}}-1]$ for the element of the tensor indexed by the argument to the function.

        @@ -1250,7 +1250,7 @@
        -

        Opposite of component_to_unrolled_index: For an index in the range $[0, \text{dim}^{\text{rank}}-1]$, return which set of indices it would correspond to.

        +

        Opposite of component_to_unrolled_index: For an index in the range $[0, \text{dim}^{\text{rank}}-1]$, return which set of indices it would correspond to.

        @@ -2068,11 +2068,11 @@

        Entrywise multiplication of two tensor objects of general rank.

        This multiplication is also called "Hadamard-product" (c.f. https://en.wikipedia.org/wiki/Hadamard_product_(matrices)), and generates a new tensor of size <rank, dim>:

        -\[
+<picture><source srcset=\[
   \text{result}_{i, j}
   = \text{left}_{i, j}\circ
     \text{right}_{i, j}
-\] +\]" src="form_857.png"/>

        Template Parameters
        @@ -2111,17 +2111,17 @@
        -

        The dot product (single contraction) for tensors. This function return a tensor of rank $(\text{rank}_1 + \text{rank}_2 - 2)$ that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:

        -\[
+<p>The dot product (single contraction) for tensors. This function return a tensor of rank <picture><source srcset=$(\text{rank}_1 + \text{rank}_2 - 2)$ that is the contraction of the last index of a tensor src1 of rank rank_1 with the first index of a tensor src2 of rank rank_2:

        +\[
   \text{result}_{i_1,\ldots,i_{r1},j_1,\ldots,j_{r2}}
   = \sum_{k}
     \text{left}_{i_1,\ldots,i_{r1}, k}
     \text{right}_{k, j_1,\ldots,j_{r2}}
-\] +\]" src="form_827.png"/>

        Note
        For the Tensor class, the multiplication operator only performs a contraction over a single pair of indices. This is in contrast to the multiplication operator for SymmetricTensor, for which the corresponding operator*() performs a double contraction. The origin of the difference in how operator*() is implemented between Tensor and SymmetricTensor is that for the former, the product between two Tensor objects of same rank and dimension results in another Tensor object – that it, operator*() corresponds to the multiplicative group action within the group of tensors. On the other hand, there is no corresponding multiplicative group action with the set of symmetric tensors because, in general, the product of two symmetric tensors is a nonsymmetric tensor. As a consequence, for a mathematician, it is clear that operator*() for symmetric tensors must have a different meaning: namely the dot or scalar product that maps two symmetric tensors of rank 2 to a scalar. This corresponds to the double-dot (colon) operator whose meaning is then extended to the product of any two even-ranked symmetric tensors.
        -In case the contraction yields a tensor of rank 0, that is, if rank_1==rank_2==1, then a scalar number is returned as an unwrapped number type. Return the $l_1$ norm of the given rank-2 tensor, where $\|\mathbf T\|_1 = \max_j \sum_i |T_{ij}|$ (maximum of the sums over columns).
        +In case the contraction yields a tensor of rank 0, that is, if rank_1==rank_2==1, then a scalar number is returned as an unwrapped number type. Return the $l_1$ norm of the given rank-2 tensor, where $\|\mathbf T\|_1 = \max_j \sum_i |T_{ij}|$ (maximum of the sums over columns).

        Definition at line 3035 of file tensor.h.

        @@ -2151,7 +2151,7 @@
        -

        Return the $l_\infty$ norm of the given rank-2 tensor, where $\|\mathbf T\|_\infty = \max_i \sum_j |T_{ij}|$ (maximum of the sums over rows).

        +

        Return the $l_\infty$ norm of the given rank-2 tensor, where $\|\mathbf T\|_\infty = \max_i \sum_j |T_{ij}|$ (maximum of the sums over rows).

        Definition at line 3061 of file tensor.h.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductManifold.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductManifold.html 2023-08-09 23:38:53.894592710 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductManifold.html 2023-08-09 23:38:53.894592710 +0000 @@ -231,7 +231,7 @@

        Detailed Description

        template<int dim, int dim_A, int spacedim_A, int chartdim_A, int dim_B, int spacedim_B, int chartdim_B>
        class TensorProductManifold< dim, dim_A, spacedim_A, chartdim_A, dim_B, spacedim_B, chartdim_B >

        Tensor product manifold of two ChartManifolds.

        -

        This manifold will combine the ChartManifolds A and B given in the constructor to form a new ChartManifold by building the tensor product $A\otimes B$. The first spacedim_A dimensions in the real space and the first chartdim_A dimensions of the chart will be given by manifold A, while the remaining coordinates are given by B. The manifold is to be used by a Triangulation<dim, space_dim_A+space_dim_B>.

        +

        This manifold will combine the ChartManifolds A and B given in the constructor to form a new ChartManifold by building the tensor product $A\otimes B$. The first spacedim_A dimensions in the real space and the first chartdim_A dimensions of the chart will be given by manifold A, while the remaining coordinates are given by B. The manifold is to be used by a Triangulation<dim, space_dim_A+space_dim_B>.

        An example usage would be the combination of a SphericalManifold with space dimension 2 and a FlatManifold with space dimension 1 to form a cylindrical manifold.

        pull_back(), push_forward(), and push_forward_gradient() are implemented by splitting the input argument into inputs for A and B according to the given dimensions and applying the corresponding operations before concatenating the result.

        Note
        The dimension arguments dim_A and dim_B are not used.
        @@ -648,24 +648,24 @@
        -

        Return a vector that, at $\mathbf x_1$, is tangential to the geodesic that connects two points $\mathbf x_1,\mathbf x_2$. See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.

        -

        For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are $\xi_1=F^{-1}(\mathbf x_1), \xi_2=F^{-1}(\mathbf x_2)$, then the geodesic in preimage (the chartdim-dimensional Euclidean) space is

        -\begin{align*}
+<p>Return a vector that, at <picture><source srcset=$\mathbf x_1$, is tangential to the geodesic that connects two points $\mathbf x_1,\mathbf x_2$. See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.

        +

        For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are $\xi_1=F^{-1}(\mathbf x_1), \xi_2=F^{-1}(\mathbf x_2)$, then the geodesic in preimage (the chartdim-dimensional Euclidean) space is

        +\begin{align*}
   \zeta(t) &= \xi_1 +  t (\xi_2-\xi_1)
  \\          &= F^{-1}(\mathbf x_1) + t\left[F^{-1}(\mathbf x_2)
                                             -F^{-1}(\mathbf x_1)\right]
-\end{align*} +\end{align*}" src="form_1440.png"/>

        In image space, i.e., in the space in which we operate, this leads to the curve

        -\begin{align*}
+<picture><source srcset=\begin{align*}
   \mathbf s(t) &= F(\zeta(t))
  \\          &= F(\xi_1 +  t (\xi_2-\xi_1))
  \\          &= F\left(F^{-1}(\mathbf x_1) + t\left[F^{-1}(\mathbf x_2)
                                     -F^{-1}(\mathbf x_1)\right]\right).
-\end{align*} +\end{align*}" src="form_1441.png"/>

        -

        What the current function is supposed to return is $\mathbf s'(0)$. By the chain rule, this is equal to

        -\begin{align*}
+<p> What the current function is supposed to return is <picture><source srcset=$\mathbf s'(0)$. By the chain rule, this is equal to

        +\begin{align*}
   \mathbf s'(0) &=
     \frac{d}{dt}\left. F\left(F^{-1}(\mathbf x_1)
                        + t\left[F^{-1}(\mathbf x_2)
@@ -674,11 +674,11 @@
 \\ &= \nabla_\xi F\left(F^{-1}(\mathbf x_1)\right)
                    \left[F^{-1}(\mathbf x_2)
                                 -F^{-1}(\mathbf x_1)\right].
-\end{align*} +\end{align*}" src="form_1442.png"/>

        This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.

        -

        Thus, the computation of tangent vectors also requires the implementation of derivatives $\nabla_\xi F(\xi)$ of the push-forward mapping. Here, $F^{-1}(\mathbf x_2)-F^{-1}(\mathbf x_1)$ is a chartdim-dimensional vector, and $\nabla_\xi F\left(F^{-1}(\mathbf
-x_1)\right) = \nabla_\xi F\left(\xi_1\right)$ is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.

        +

        Thus, the computation of tangent vectors also requires the implementation of derivatives $\nabla_\xi F(\xi)$ of the push-forward mapping. Here, $F^{-1}(\mathbf x_2)-F^{-1}(\mathbf x_1)$ is a chartdim-dimensional vector, and $\nabla_\xi F\left(F^{-1}(\mathbf
+x_1)\right) = \nabla_\xi F\left(\xi_1\right)$ is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.

        Parameters
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductMatrixSymmetricSum.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductMatrixSymmetricSum.html 2023-08-09 23:38:53.918592889 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductMatrixSymmetricSum.html 2023-08-09 23:38:53.918592889 +0000 @@ -159,20 +159,20 @@ M_1 \otimes A_0 \end{align*}" src="form_1936.png"/>

        -

        in 3d. The typical application setting is a discretization of the Laplacian $L$ on a Cartesian (axis-aligned) geometry, where it can be exactly represented by the Kronecker or tensor product of a 1d mass matrix $M$ and a 1d Laplace matrix $A$ in each tensor direction (due to symmetry $M$ and $A$ are the same in each dimension). The dimension of the resulting class is the product of the one-dimensional matrices.

        -

        This class implements two basic operations, namely the usual multiplication by a vector and the inverse. For both operations, fast tensorial techniques can be applied that implement the operator evaluation in $\text{size}(M)^{d+1}$ arithmetic operations, considerably less than $\text{size}(M)^{2d}$ for the naive forward transformation and $\text{size}(M)^{3d}$ for setting up the inverse of $L$.

        -

        Interestingly, the exact inverse of the matrix $L$ can be found through tensor products due to 1964's work by Lynch et al. [Lynch1964],

        +

        in 3d. The typical application setting is a discretization of the Laplacian $L$ on a Cartesian (axis-aligned) geometry, where it can be exactly represented by the Kronecker or tensor product of a 1d mass matrix $M$ and a 1d Laplace matrix $A$ in each tensor direction (due to symmetry $M$ and $A$ are the same in each dimension). The dimension of the resulting class is the product of the one-dimensional matrices.

        +

        This class implements two basic operations, namely the usual multiplication by a vector and the inverse. For both operations, fast tensorial techniques can be applied that implement the operator evaluation in $\text{size}(M)^{d+1}$ arithmetic operations, considerably less than $\text{size}(M)^{2d}$ for the naive forward transformation and $\text{size}(M)^{3d}$ for setting up the inverse of $L$.

        +

        Interestingly, the exact inverse of the matrix $L$ can be found through tensor products due to 1964's work by Lynch et al. [Lynch1964],

        \begin{align*}
 L^{-1} &= S_1 \otimes S_0 (\Lambda_1 \otimes I + I \otimes \Lambda_0)^{-1}
 S_1^\mathrm T \otimes S_0^\mathrm T,
 \end{align*}

        -

        where $S_d$ is the matrix of eigenvectors to the generalized eigenvalue problem in the given tensor direction $d$:

        +

        where $S_d$ is the matrix of eigenvectors to the generalized eigenvalue problem in the given tensor direction $d$:

        \begin{align*}
 A_d s  &= \lambda M_d s, d = 0, \quad \ldots,\mathrm{dim},
 \end{align*}

        -

        and $\Lambda_d$ is the diagonal matrix representing the generalized eigenvalues $\lambda$. Note that the vectors $s$ are such that they simultaneously diagonalize $A_d$ and $M_d$, i.e. $S_d^{\mathrm T} A_d S_d =
+<p> and <picture><source srcset=$\Lambda_d$ is the diagonal matrix representing the generalized eigenvalues $\lambda$. Note that the vectors $s$ are such that they simultaneously diagonalize $A_d$ and $M_d$, i.e. $S_d^{\mathrm T} A_d S_d =
 \Lambda_d$ and $S_d^{\mathrm T} M_d S_d = I$. This method of matrix inversion is called fast diagonalization method.

        This class requires LAPACK support.

        Note
        This class allows for two modes of usage. The first is a use case with run time constants for the matrix dimensions that is achieved by setting the optional template parameter n_rows_1d to -1. The second mode of usage that is faster allows to set the template parameter as a compile time constant, giving significantly faster code in particular for small sizes of the matrix.
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductPolynomialsBubbles.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductPolynomialsBubbles.html 2023-08-09 23:38:53.946593098 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTensorProductPolynomialsBubbles.html 2023-08-09 23:38:53.946593098 +0000 @@ -156,9 +156,9 @@
        x1The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.

        Detailed Description

        template<int dim>
        -class TensorProductPolynomialsBubbles< dim >

        A class that represents a space of tensor product polynomials, augmented by $dim$ (non-normalized) bubble functions of form $\varphi_j(\mathbf x)
+class TensorProductPolynomialsBubbles< dim ></div><p>A class that represents a space of tensor product polynomials, augmented by <picture><source srcset=$dim$ (non-normalized) bubble functions of form $\varphi_j(\mathbf x)
 = 2^{\text{degree}-1}\left(x_j-frac 12\right)^{\text{degree}-1}
-\left[\prod_{i=0}^{dim-1}(x_i(1-x_i))\right]$ for $j=0,\ldots,dim-1$. If degree is one, then the first factor disappears and one receives the usual bubble function centered at the mid-point of the cell.

        +\left[\prod_{i=0}^{dim-1}(x_i(1-x_i))\right]$" src="form_877.png"/> for $j=0,\ldots,dim-1$. If degree is one, then the first factor disappears and one receives the usual bubble function centered at the mid-point of the cell.

        This class inherits most of its functionality from TensorProductPolynomials. The bubble enrichments are added for the last index.

        Definition at line 53 of file tensor_product_polynomials_bubbles.h.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTorusManifold.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTorusManifold.html 2023-08-09 23:38:53.982593367 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTorusManifold.html 2023-08-09 23:38:53.986593397 +0000 @@ -230,7 +230,7 @@

        Detailed Description

        template<int dim>
        -class TorusManifold< dim >

        Manifold description for the surface of a Torus in three dimensions. The Torus is assumed to be in the x-z plane. The reference coordinate system is given by the angle $phi$ around the y axis, the angle $theta$ around the centerline of the torus, and the distance to the centerline $w$ (between 0 and 1).

        +class TorusManifold< dim >

        Manifold description for the surface of a Torus in three dimensions. The Torus is assumed to be in the x-z plane. The reference coordinate system is given by the angle $phi$ around the y axis, the angle $theta$ around the centerline of the torus, and the distance to the centerline $w$ (between 0 and 1).

        This class was developed to be used in conjunction with GridGenerator::torus.

        Definition at line 787 of file manifold_lib.h.

        @@ -670,7 +670,7 @@
        -

        Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function $F$ that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size $\text{spacedim}\times\text{chartdim}$.

        +

        Given a point in the chartdim dimensional Euclidean space, this method returns the derivatives of the function $F$ that maps from the chartdim-dimensional to the spacedim-dimensional space. In other words, it is a matrix of size $\text{spacedim}\times\text{chartdim}$.

        This function is used in the computations required by the get_tangent_vector() function. Since not all users of the Manifold class interface will require calling that function, the current function is implemented but will trigger an exception whenever called. This allows derived classes to avoid implementing the push_forward_gradient function if this functionality is not needed in the user program.

        Refer to the general documentation of this class for more information.

        @@ -709,24 +709,24 @@
        -

        Return a vector that, at $\mathbf x_1$, is tangential to the geodesic that connects two points $\mathbf x_1,\mathbf x_2$. See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.

        -

        For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are $\xi_1=F^{-1}(\mathbf x_1), \xi_2=F^{-1}(\mathbf x_2)$, then the geodesic in preimage (the chartdim-dimensional Euclidean) space is

        -\begin{align*}
+<p>Return a vector that, at <picture><source srcset=$\mathbf x_1$, is tangential to the geodesic that connects two points $\mathbf x_1,\mathbf x_2$. See the documentation of the Manifold class and of Manifold::get_tangent_vector() for a more detailed description.

        +

        For the current class, we assume that this geodesic is the image under the push_forward() operation of a straight line of the pre-images of x1 and x2 (where pre-images are computed by pulling back the locations x1 and x2). In other words, if these preimages are $\xi_1=F^{-1}(\mathbf x_1), \xi_2=F^{-1}(\mathbf x_2)$, then the geodesic in preimage (the chartdim-dimensional Euclidean) space is

        +\begin{align*}
   \zeta(t) &= \xi_1 +  t (\xi_2-\xi_1)
  \\          &= F^{-1}(\mathbf x_1) + t\left[F^{-1}(\mathbf x_2)
                                             -F^{-1}(\mathbf x_1)\right]
-\end{align*} +\end{align*}" src="form_1440.png"/>

        In image space, i.e., in the space in which we operate, this leads to the curve

        -\begin{align*}
+<picture><source srcset=\begin{align*}
   \mathbf s(t) &= F(\zeta(t))
  \\          &= F(\xi_1 +  t (\xi_2-\xi_1))
  \\          &= F\left(F^{-1}(\mathbf x_1) + t\left[F^{-1}(\mathbf x_2)
                                     -F^{-1}(\mathbf x_1)\right]\right).
-\end{align*} +\end{align*}" src="form_1441.png"/>

        -

        What the current function is supposed to return is $\mathbf s'(0)$. By the chain rule, this is equal to

        -\begin{align*}
+<p> What the current function is supposed to return is <picture><source srcset=$\mathbf s'(0)$. By the chain rule, this is equal to

        +\begin{align*}
   \mathbf s'(0) &=
     \frac{d}{dt}\left. F\left(F^{-1}(\mathbf x_1)
                        + t\left[F^{-1}(\mathbf x_2)
@@ -735,11 +735,11 @@
 \\ &= \nabla_\xi F\left(F^{-1}(\mathbf x_1)\right)
                    \left[F^{-1}(\mathbf x_2)
                                 -F^{-1}(\mathbf x_1)\right].
-\end{align*} +\end{align*}" src="form_1442.png"/>

        This formula may then have to be slightly modified by considering any periodicity that was assumed in the call to the constructor.

        -

        Thus, the computation of tangent vectors also requires the implementation of derivatives $\nabla_\xi F(\xi)$ of the push-forward mapping. Here, $F^{-1}(\mathbf x_2)-F^{-1}(\mathbf x_1)$ is a chartdim-dimensional vector, and $\nabla_\xi F\left(F^{-1}(\mathbf
-x_1)\right) = \nabla_\xi F\left(\xi_1\right)$ is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.

        +

        Thus, the computation of tangent vectors also requires the implementation of derivatives $\nabla_\xi F(\xi)$ of the push-forward mapping. Here, $F^{-1}(\mathbf x_2)-F^{-1}(\mathbf x_1)$ is a chartdim-dimensional vector, and $\nabla_\xi F\left(F^{-1}(\mathbf
+x_1)\right) = \nabla_\xi F\left(\xi_1\right)$ is a spacedim-times-chartdim-dimensional matrix. Consequently, and as desired, the operation results in a spacedim-dimensional vector.

        Parameters
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTransfiniteInterpolationManifold.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTransfiniteInterpolationManifold.html 2023-08-09 23:38:54.030593726 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTransfiniteInterpolationManifold.html 2023-08-09 23:38:54.030593726 +0000 @@ -218,16 +218,16 @@

        Detailed Description

        template<int dim, int spacedim = dim>
        class TransfiniteInterpolationManifold< dim, spacedim >

        A mapping class that extends curved boundary descriptions into the interior of the computational domain. The outer curved boundary description is assumed to be given by another manifold (e.g. a polar manifold on a circle). The mechanism to extend the boundary information is a so-called transfinite interpolation. The use of this class is discussed extensively in step-65.

        -

        The formula for extending such a description in 2d is, for example, described on Wikipedia. Given a point $(u,v)$ on the chart, the image of this point in real space is given by

        -\begin{align*}
+<p>The formula for extending such a description in 2d is, for example, described on <a href=Wikipedia. Given a point $(u,v)$ on the chart, the image of this point in real space is given by

        +\begin{align*}
 \mathbf S(u,v) &= (1-v)\mathbf c_0(u)+v \mathbf c_1(u) + (1-u)\mathbf c_2(v)
 + u \mathbf c_3(v) \\
 &\quad - \left[(1-u)(1-v) \mathbf x_0 + u(1-v) \mathbf x_1 + (1-u)v \mathbf
 x_2 + uv \mathbf x_3 \right]
-\end{align*} +\end{align*}" src="form_1461.png"/>

        -

        where $\bf x_0, \bf x_1, \bf x_2, \bf x_3$ denote the four bounding vertices bounding the image space and $\bf c_0, \bf c_1, \bf c_2, \bf c_3$ are the four curves describing the lines of the cell. If a curved manifold is attached to any of these lines, the evaluation is done according to Manifold::get_new_point() with the two end points of the line and appropriate weight. In 3d, the generalization of this formula is implemented, creating a weighted sum of the vertices (positive contribution), the lines (negative), and the faces (positive contribution).

        -

        This manifold is usually attached to a coarse mesh and then places new points as a combination of the descriptions on the boundaries, weighted appropriately according to the position of the point in the original chart coordinates $(u,v)$. This manifold should be preferred over setting only a curved manifold on the boundary of a mesh in most situations as it yields more uniform mesh distributions as the mesh is refined because it switches from a curved description to a straight description over all children of the initial coarse cell this manifold was attached to. This way, the curved nature of the manifold that is originally contained in one coarse mesh layer will be applied to more than one fine mesh layer once the mesh gets refined. Note that the mechanisms of TransfiniteInterpolationManifold are also built into the MappingQ class when only a surface of a cell is subject to a curved description, ensuring that even the default case without this manifold gets optimal convergence rates when applying curved boundary descriptions.

        +

        where $\bf x_0, \bf x_1, \bf x_2, \bf x_3$ denote the four bounding vertices bounding the image space and $\bf c_0, \bf c_1, \bf c_2, \bf c_3$ are the four curves describing the lines of the cell. If a curved manifold is attached to any of these lines, the evaluation is done according to Manifold::get_new_point() with the two end points of the line and appropriate weight. In 3d, the generalization of this formula is implemented, creating a weighted sum of the vertices (positive contribution), the lines (negative), and the faces (positive contribution).

        +

        This manifold is usually attached to a coarse mesh and then places new points as a combination of the descriptions on the boundaries, weighted appropriately according to the position of the point in the original chart coordinates $(u,v)$. This manifold should be preferred over setting only a curved manifold on the boundary of a mesh in most situations as it yields more uniform mesh distributions as the mesh is refined because it switches from a curved description to a straight description over all children of the initial coarse cell this manifold was attached to. This way, the curved nature of the manifold that is originally contained in one coarse mesh layer will be applied to more than one fine mesh layer once the mesh gets refined. Note that the mechanisms of TransfiniteInterpolationManifold are also built into the MappingQ class when only a surface of a cell is subject to a curved description, ensuring that even the default case without this manifold gets optimal convergence rates when applying curved boundary descriptions.

        If no curved boundaries surround a coarse cell, this class reduces to a flat manifold description.

        To give an example of using this class, the following code attaches a transfinite manifold to a circle:

        PolarManifold<dim> polar_manifold;
        @@ -1210,11 +1210,11 @@
        x1The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.
        -

        Return a vector that, at $\mathbf x_1$, is tangential to the geodesic that connects two points $\mathbf x_1,\mathbf x_2$. The geodesic is the shortest line between these two points, where "shortest" is defined via a metric specific to a particular implementation of this class in a derived class. For example, in the case of a FlatManifold, the shortest line between two points is just the straight line, and in this case the tangent vector is just the difference $\mathbf d=\mathbf
-x_2-\mathbf x_1$. On the other hand, for a manifold that describes a surface embedded in a higher dimensional space (e.g., the surface of a sphere), then the tangent vector is tangential to the surface, and consequently may point in a different direction than the straight line that connects the two points.

        -

        While tangent vectors are often normalized to unit length, the vectors returned by this function are normalized as described in the introduction of this class. Specifically, if $\mathbf s(t)$ traces out the geodesic between the two points where $\mathbf x_1 = \mathbf s(0)$ and $\mathbf x_2 = \mathbf s(1)$, then the returned vector must equal $\mathbf s'(0)$. In other words, the norm of the returned vector also encodes, in some sense, the length of the geodesic because a curve $\mathbf s(t)$ must move "faster" if the two points it connects between arguments $t=0$ and $t=1$ are farther apart.

        -

        The default implementation of this function approximates $\mathbf s'(0) \approx \frac{\mathbf s(\epsilon)-\mathbf x_1}{\epsilon}$ for a small value of $\epsilon$, and the evaluation of $\mathbf
-s(\epsilon)$ is done by calling get_new_point(). If possible, derived classes should override this function by an implementation of the exact derivative.

        +

        Return a vector that, at $\mathbf x_1$, is tangential to the geodesic that connects two points $\mathbf x_1,\mathbf x_2$. The geodesic is the shortest line between these two points, where "shortest" is defined via a metric specific to a particular implementation of this class in a derived class. For example, in the case of a FlatManifold, the shortest line between two points is just the straight line, and in this case the tangent vector is just the difference $\mathbf d=\mathbf
+x_2-\mathbf x_1$. On the other hand, for a manifold that describes a surface embedded in a higher dimensional space (e.g., the surface of a sphere), then the tangent vector is tangential to the surface, and consequently may point in a different direction than the straight line that connects the two points.

        +

        While tangent vectors are often normalized to unit length, the vectors returned by this function are normalized as described in the introduction of this class. Specifically, if $\mathbf s(t)$ traces out the geodesic between the two points where $\mathbf x_1 = \mathbf s(0)$ and $\mathbf x_2 = \mathbf s(1)$, then the returned vector must equal $\mathbf s'(0)$. In other words, the norm of the returned vector also encodes, in some sense, the length of the geodesic because a curve $\mathbf s(t)$ must move "faster" if the two points it connects between arguments $t=0$ and $t=1$ are farther apart.

        +

        The default implementation of this function approximates $\mathbf s'(0) \approx \frac{\mathbf s(\epsilon)-\mathbf x_1}{\epsilon}$ for a small value of $\epsilon$, and the evaluation of $\mathbf
+s(\epsilon)$ is done by calling get_new_point(). If possible, derived classes should override this function by an implementation of the exact derivative.

        Parameters
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor.html 2023-08-09 23:38:54.090594174 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor.html 2023-08-09 23:38:54.094594204 +0000 @@ -325,7 +325,7 @@
        x1The first point that describes the geodesic, and the one at which the "direction" is to be evaluated.

        Detailed Description

        template<int structdim, int dim, int spacedim>
        -class TriaAccessor< structdim, dim, spacedim >

        A class that provides access to objects in a triangulation such as its vertices, sub-objects, children, geometric information, etc. This class represents objects of dimension structdim (i.e. 1 for lines, 2 for quads, 3 for hexes) in a triangulation of dimensionality dim (i.e. 1 for a triangulation of lines, 2 for a triangulation of quads, and 3 for a triangulation of hexes) that is embedded in a space of dimensionality spacedim (for spacedim==dim the triangulation represents a domain in $R^{dim}$, for spacedim>dim the triangulation is of a manifold embedded in a higher dimensional space).

        +class TriaAccessor< structdim, dim, spacedim >

        A class that provides access to objects in a triangulation such as its vertices, sub-objects, children, geometric information, etc. This class represents objects of dimension structdim (i.e. 1 for lines, 2 for quads, 3 for hexes) in a triangulation of dimensionality dim (i.e. 1 for a triangulation of lines, 2 for a triangulation of quads, and 3 for a triangulation of hexes) that is embedded in a space of dimensionality spacedim (for spacedim==dim the triangulation represents a domain in $R^{dim}$, for spacedim>dim the triangulation is of a manifold embedded in a higher dimensional space).

        There is a specialization of this class for the case where structdim equals zero, i.e., for vertices of a triangulation.

        Definition at line 757 of file tria_accessor.h.

        @@ -1715,8 +1715,8 @@
        -

        This function computes a fast approximate transformation from the real to the unit cell by inversion of an affine approximation of the $d$-linear function from the reference $d$-dimensional cell.

        -

        The affine approximation of the unit to real cell mapping is found by a least squares fit of an affine function to the $2^d$ vertices of the present object. For any valid mesh cell whose geometry is not degenerate, this operation results in a unique affine mapping. Thus, this function will return a finite result for all given input points, even in cases where the actual transformation by an actual bi-/trilinear or higher order mapping might be singular. Besides only approximating the mapping from the vertex points, this function also ignores the attached manifold descriptions. The result is only exact in case the transformation from the unit to the real cell is indeed affine, such as in one dimension or for Cartesian and affine (parallelogram) meshes in 2d/3d.

        +

        This function computes a fast approximate transformation from the real to the unit cell by inversion of an affine approximation of the $d$-linear function from the reference $d$-dimensional cell.

        +

        The affine approximation of the unit to real cell mapping is found by a least squares fit of an affine function to the $2^d$ vertices of the present object. For any valid mesh cell whose geometry is not degenerate, this operation results in a unique affine mapping. Thus, this function will return a finite result for all given input points, even in cases where the actual transformation by an actual bi-/trilinear or higher order mapping might be singular. Besides only approximating the mapping from the vertex points, this function also ignores the attached manifold descriptions. The result is only exact in case the transformation from the unit to the real cell is indeed affine, such as in one dimension or for Cartesian and affine (parallelogram) meshes in 2d/3d.

        For exact transformations to the unit cell, use Mapping::transform_real_to_unit_cell().

        Note
        If dim<spacedim we first project p onto the plane.
        @@ -1749,7 +1749,7 @@
        -

        Center of the object. The center of an object is defined to be the average of the locations of the vertices, which is also where a $Q_1$ mapping would map the center of the reference cell. However, you can also ask this function to instead return the average of the vertices as computed by the underlying Manifold object associated with the current object, by setting to true the optional parameter respect_manifold. Manifolds would then typically pull back the coordinates of the vertices to a reference domain (not necessarily the reference cell), compute the average there, and then push forward the coordinates of the averaged point to the physical space again; the resulting point is guaranteed to lie within the manifold, even if the manifold is curved.

        +

        Center of the object. The center of an object is defined to be the average of the locations of the vertices, which is also where a $Q_1$ mapping would map the center of the reference cell. However, you can also ask this function to instead return the average of the vertices as computed by the underlying Manifold object associated with the current object, by setting to true the optional parameter respect_manifold. Manifolds would then typically pull back the coordinates of the vertices to a reference domain (not necessarily the reference cell), compute the average there, and then push forward the coordinates of the averaged point to the physical space again; the resulting point is guaranteed to lie within the manifold, even if the manifold is curved.

        When the object uses a different manifold description as its surrounding, like when part of the bounding objects of this TriaAccessor use a non-flat manifold description but the object itself is flat, the result given by the TriaAccessor::center() function may not be accurate enough, even when parameter respect_manifold is set to true. If you find this to be case, than you can further refine the computation of the center by setting to true the second additional parameter interpolate_from_surrounding. This computes the location of the center by a so-called transfinite interpolation from the center of all the bounding objects. For a 2d object, it puts a weight of 1/2 on each of the four surrounding lines and a weight -1/4 on the four vertices. This corresponds to a linear interpolation between the descriptions of the four faces, subtracting the contribution of the vertices that is added twice when coming through both lines adjacent to the vertex. In 3d, the weights for faces are 1/2, the weights for lines are -1/4, and the weights for vertices are 1/8. For further information, also confer to the TransfiniteInterpolationManifold class that is able to not only apply this beneficial description to a single cell but all children of a coarse cell.

        Definition at line 1787 of file tria_accessor.cc.

        @@ -1769,17 +1769,17 @@
        -

        Return the barycenter (also called centroid) of the object. The barycenter for an object $K$ of dimension $d$ in $D$ space dimensions is given by the $D$-dimensional vector $\mathbf x_K$ defined by

        -\[
+<p>Return the barycenter (also called centroid) of the object. The barycenter for an object <picture><source srcset=$K$ of dimension $d$ in $D$ space dimensions is given by the $D$-dimensional vector $\mathbf x_K$ defined by

        +\[
   \mathbf x_K = \frac{1}{|K|} \int_K \mathbf x \; \textrm{d}x
-\] +\]" src="form_1482.png"/>

        where the measure of the object is given by

        -\[
+<picture><source srcset=\[
   |K| = \int_K \mathbf 1 \; \textrm{d}x.
-\] +\]" src="form_1483.png"/>

        -

        This function assumes that $K$ is mapped by a $d$-linear function from the reference $d$-dimensional cell. Then the integrals above can be pulled back to the reference cell and evaluated exactly (if through lengthy and, compared to the center() function, expensive computations).

        +

        This function assumes that $K$ is mapped by a $d$-linear function from the reference $d$-dimensional cell. Then the integrals above can be pulled back to the reference cell and evaluated exactly (if through lengthy and, compared to the center() function, expensive computations).

        Definition at line 1597 of file tria_accessor.cc.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor_3_010_00_011_00_01spacedim_01_4.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor_3_010_00_011_00_01spacedim_01_4.html 2023-08-09 23:38:54.138594532 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor_3_010_00_011_00_01spacedim_01_4.html 2023-08-09 23:38:54.138594532 +0000 @@ -279,7 +279,7 @@ &#href_anchor"memitem:a34cceffc302e3c23552635478b9fc983">static unsigned int&#href_anchor"memItemRight" valign="bottom">quad_index (const unsigned int i) &#href_anchor"details" id="details">

        Detailed Description

        template<int spacedim>
        -class TriaAccessor< 0, 1, spacedim >

        This class is a specialization of TriaAccessor<structdim, dim, spacedim> for the case that structdim is zero and dim is one. This class represents vertices in a one-dimensional triangulation that is embedded in a space of dimensionality spacedim (for spacedim==dim==1 the triangulation represents a domain in ${\mathbb R}^\text{dim}$, for spacedim>dim==1 the triangulation is of a manifold embedded in a higher dimensional space).

        +class TriaAccessor< 0, 1, spacedim >

        This class is a specialization of TriaAccessor<structdim, dim, spacedim> for the case that structdim is zero and dim is one. This class represents vertices in a one-dimensional triangulation that is embedded in a space of dimensionality spacedim (for spacedim==dim==1 the triangulation represents a domain in ${\mathbb R}^\text{dim}$, for spacedim>dim==1 the triangulation is of a manifold embedded in a higher dimensional space).

        The current specialization of the TriaAccessor<0,dim,spacedim> class for vertices of a one-dimensional triangulation exists since in the dim == 1 case vertices are also faces.

        Definition at line 2328 of file tria_accessor.h.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor_3_010_00_01dim_00_01spacedim_01_4.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor_3_010_00_01dim_00_01spacedim_01_4.html 2023-08-09 23:38:54.174594801 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriaAccessor_3_010_00_01dim_00_01spacedim_01_4.html 2023-08-09 23:38:54.174594801 +0000 @@ -229,7 +229,7 @@ &#href_anchor"memitem:abda88195917e4d56f80eab016f21bde3">static unsigned int&#href_anchor"memItemRight" valign="bottom">quad_index (const unsigned int i) &#href_anchor"details" id="details">

        Detailed Description

        template<int dim, int spacedim>
        -class TriaAccessor< 0, dim, spacedim >

        This class is a specialization of TriaAccessor<structdim, dim, spacedim> for the case that structdim is zero. This class represents vertices in a triangulation of dimensionality dim (i.e. 1 for a triangulation of lines, 2 for a triangulation of quads, and 3 for a triangulation of hexes) that is embedded in a space of dimensionality spacedim (for spacedim==dim the triangulation represents a domain in ${\mathbb R}^\text{dim}$, for spacedim>dim the triangulation is of a manifold embedded in a higher dimensional space).

        +class TriaAccessor< 0, dim, spacedim >

        This class is a specialization of TriaAccessor<structdim, dim, spacedim> for the case that structdim is zero. This class represents vertices in a triangulation of dimensionality dim (i.e. 1 for a triangulation of lines, 2 for a triangulation of quads, and 3 for a triangulation of hexes) that is embedded in a space of dimensionality spacedim (for spacedim==dim the triangulation represents a domain in ${\mathbb R}^\text{dim}$, for spacedim>dim the triangulation is of a manifold embedded in a higher dimensional space).

        There is a further specialization of this class for the case that dim equals one, i.e., for vertices of a one-dimensional triangulation, since in that case vertices are also faces.

        Definition at line 1910 of file tria_accessor.h.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriangulation.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriangulation.html 2023-08-09 23:38:54.298595727 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTriangulation.html 2023-08-09 23:38:54.302595757 +0000 @@ -1951,7 +1951,7 @@
        -

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        +

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.

        Note
        This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
        @@ -4715,7 +4715,7 @@
        -

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        +

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        Note
        The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1BlockSparseMatrix.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1BlockSparseMatrix.html 2023-08-09 23:38:54.366596234 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1BlockSparseMatrix.html 2023-08-09 23:38:54.366596234 +0000 @@ -1042,7 +1042,7 @@
        -

        Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix. The vector types can be block vectors or non-block vectors (only if the matrix has only one row or column, respectively), and need to define TrilinosWrappers::SparseMatrix::vmult.

        +

        Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix. The vector types can be block vectors or non-block vectors (only if the matrix has only one row or column, respectively), and need to define TrilinosWrappers::SparseMatrix::vmult.

        Definition at line 444 of file trilinos_block_sparse_matrix.h.

        @@ -1082,7 +1082,7 @@
        -

        Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult() but takes the transposed matrix.

        +

        Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult() but takes the transposed matrix.

        Definition at line 457 of file trilinos_block_sparse_matrix.h.

        @@ -2184,7 +2184,7 @@
        -

        Adding Matrix-vector multiplication. Add $M*src$ on $dst$ with $M$ being this matrix.

        +

        Adding Matrix-vector multiplication. Add $M*src$ on $dst$ with $M$ being this matrix.

        @@ -2309,7 +2309,7 @@
        -

        Compute the matrix scalar product $\left(u,Mv\right)$.

        +

        Compute the matrix scalar product $\left(u,Mv\right)$.

        @@ -2740,7 +2740,7 @@
        -

        Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix.

        +

        Matrix-vector multiplication: let $dst = M*src$ with $M$ being this matrix.

        Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.

        @@ -2888,7 +2888,7 @@
        -

        Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult() but takes the transposed matrix.

        +

        Matrix-vector multiplication: let $dst = M^T*src$ with $M$ being this matrix. This function does the same as vmult() but takes the transposed matrix.

        Due to problems with deriving template arguments between the block and non-block versions of the vmult/Tvmult functions, the actual functions are implemented in derived classes, with implementations forwarding the calls to the implementations provided here under a unique name for which template arguments can be derived by the compiler.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1BlockVector.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1BlockVector.html 2023-08-09 23:38:54.422596654 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1BlockVector.html 2023-08-09 23:38:54.422596654 +0000 @@ -1781,7 +1781,7 @@
        -

        Return the square of the $l_2$-norm.

        +

        Return the square of the $l_2$-norm.

        @@ -1833,7 +1833,7 @@
        -

        Return the $l_1$-norm of the vector, i.e. the sum of the absolute values.

        +

        Return the $l_1$-norm of the vector, i.e. the sum of the absolute values.

        @@ -1859,7 +1859,7 @@
        -

        Return the $l_2$-norm of the vector, i.e. the square root of the sum of the squares of the elements.

        +

        Return the $l_2$-norm of the vector, i.e. the square root of the sum of the squares of the elements.

        @@ -1885,7 +1885,7 @@
        -

        Return the maximum absolute value of the elements of this vector, which is the $l_\infty$-norm of a vector.

        +

        Return the maximum absolute value of the elements of this vector, which is the $l_\infty$-norm of a vector.

        @@ -2204,7 +2204,7 @@
        -

        $U(0-DIM)+=s$. Addition of s to all components. Note that s is a scalar and not a vector.

        +

        $U(0-DIM)+=s$. Addition of s to all components. Note that s is a scalar and not a vector.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1Vector.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1Vector.html 2023-08-09 23:38:54.482597101 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1MPI_1_1Vector.html 2023-08-09 23:38:54.482597101 +0000 @@ -1301,8 +1301,8 @@
        -

        Return a pair of indices indicating which elements of this vector are stored locally. The first number is the index of the first element stored, the second the index of the one past the last one that is stored locally. If this is a sequential vector, then the result will be the pair (0,N), otherwise it will be a pair (i,i+n), where n=local_size() and i is the first element of the vector stored on this processor, corresponding to the half open interval $[i,i+n)$

        -
        Note
        The description above is true most of the time, but not always. In particular, Trilinos vectors need not store contiguous ranges of elements such as $[i,i+n)$. Rather, it can store vectors where the elements are distributed in an arbitrary way across all processors and each processor simply stores a particular subset, not necessarily contiguous. In this case, this function clearly makes no sense since it could, at best, return a range that includes all elements that are stored locally. Thus, the function only succeeds if the locally stored range is indeed contiguous. It will trigger an assertion if the local portion of the vector is not contiguous.
        +

        Return a pair of indices indicating which elements of this vector are stored locally. The first number is the index of the first element stored, the second the index of the one past the last one that is stored locally. If this is a sequential vector, then the result will be the pair (0,N), otherwise it will be a pair (i,i+n), where n=local_size() and i is the first element of the vector stored on this processor, corresponding to the half open interval $[i,i+n)$

        +
        Note
        The description above is true most of the time, but not always. In particular, Trilinos vectors need not store contiguous ranges of elements such as $[i,i+n)$. Rather, it can store vectors where the elements are distributed in an arbitrary way across all processors and each processor simply stores a particular subset, not necessarily contiguous. In this case, this function clearly makes no sense since it could, at best, return a range that includes all elements that are stored locally. Thus, the function only succeeds if the locally stored range is indeed contiguous. It will trigger an assertion if the local portion of the vector is not contiguous.
        @@ -1414,7 +1414,7 @@
        -

        Return the square of the $l_2$-norm.

        +

        Return the square of the $l_2$-norm.

        @@ -1486,7 +1486,7 @@
        -

        $l_1$-norm of the vector. The sum of the absolute values.

        +

        $l_1$-norm of the vector. The sum of the absolute values.

        @@ -1504,7 +1504,7 @@
        -

        $l_2$-norm of the vector. The square root of the sum of the squares of the elements.

        +

        $l_2$-norm of the vector. The square root of the sum of the squares of the elements.

        @@ -1523,7 +1523,7 @@
        -

        $l_p$-norm of the vector. The pth root of the sum of the pth powers of the absolute values of the elements.

        +

        $l_p$-norm of the vector. The pth root of the sum of the pth powers of the absolute values of the elements.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1NOXSolver.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1NOXSolver.html 2023-08-09 23:38:54.506597280 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1NOXSolver.html 2023-08-09 23:38:54.506597280 +0000 @@ -376,7 +376,7 @@
        -

        A user function that applies the Jacobian $\nabla_u F(u)$ to x and writes the result in y. The Jacobian to be used (i.e., more precisely: the linearization point $u$ above) is the one computed when the setup_jacobian function was last called.

        +

        A user function that applies the Jacobian $\nabla_u F(u)$ to x and writes the result in y. The Jacobian to be used (i.e., more precisely: the linearization point $u$ above) is the one computed when the setup_jacobian function was last called.

        Note
        This function is optional and is used in the case of certain configurations. For instance, this function is required if the polynomial line search (NOX::LineSearch::Polynomial) is chosen, whereas for the full step case (NOX::LineSearch::FullStep) it won't be called.
        This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. NOX can not deal with "recoverable" errors, so if a callback throws an exception of type RecoverableUserCallbackError, then this exception is treated like any other exception.
        @@ -398,7 +398,7 @@
        -

        A user function that applies the inverse of the Jacobian $[\nabla_u F(u)]^{-1}$ to y and writes the result in x. The parameter tolerance specifies the error reduction if an iterative solver is used in applying the inverse matrix. The Jacobian to be used (i.e., more precisely: the linearization point $u$ above) is the one computed when the setup_jacobian function was last called.

        +

        A user function that applies the inverse of the Jacobian $[\nabla_u F(u)]^{-1}$ to y and writes the result in x. The parameter tolerance specifies the error reduction if an iterative solver is used in applying the inverse matrix. The Jacobian to be used (i.e., more precisely: the linearization point $u$ above) is the one computed when the setup_jacobian function was last called.

        Note
        This function is optional and is used in the case of certain configurations.
        This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. NOX can not deal with "recoverable" errors, so if a callback throws an exception of type RecoverableUserCallbackError, then this exception is treated like any other exception.
        @@ -420,7 +420,7 @@
        -

        A user function that applies the inverse of the Jacobian $[\nabla_u F(u)]^{-1}$ to y, writes the result in x and returns the number of linear iterations the linear solver needed. The parameter tolerance species the error reduction if an iterative solver is used. The Jacobian to be used (i.e., more precisely: the linearization point $u$ above) is the one computed when the setup_jacobian function was last called.

        +

        A user function that applies the inverse of the Jacobian $[\nabla_u F(u)]^{-1}$ to y, writes the result in x and returns the number of linear iterations the linear solver needed. The parameter tolerance species the error reduction if an iterative solver is used. The Jacobian to be used (i.e., more precisely: the linearization point $u$ above) is the one computed when the setup_jacobian function was last called.

        Note
        This function is used if solve_with_jacobian is not provided. Its return value is compared again AdditionalFlags::threshold_n_linear_iterations; if it is larger, the preconditioner will be built before the next linear system is solved. The use of this approach is predicated on the idea that one can keep using a preconditioner built earlier as long as it is a good preconditioner for the matrix currently in use – where "good" is defined as leading to a number of iterations to solve linear systems less than the threshold given by the current variable.
        This variable represents a user provided callback. See there for a description of how to deal with errors and other requirements and conventions. NOX can not deal with "recoverable" errors, so if a callback throws an exception of type RecoverableUserCallbackError, then this exception is treated like any other exception.
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1SparseMatrix.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1SparseMatrix.html 2023-08-09 23:38:54.574597788 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1SparseMatrix.html 2023-08-09 23:38:54.574597788 +0000 @@ -2401,7 +2401,7 @@
        -

        Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e., $\left(v,Mv\right)$. This is useful, e.g. in the finite element context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

        +

        Return the square of the norm of the vector $v$ with respect to the norm induced by this matrix, i.e., $\left(v,Mv\right)$. This is useful, e.g. in the finite element context, where the $L_2$ norm of a function equals the matrix norm with respect to the mass matrix of the vector representing the nodal values of the finite element function.

        Obviously, the matrix needs to be quadratic for this operation.

        The implementation of this function is not as efficient as the one in the SparseMatrix class used in deal.II (i.e. the original one, not the Trilinos wrapper class) since Trilinos doesn't support this operation and needs a temporary vector.

        The vector has to be initialized with the same IndexSet the matrix was initialized with.

        @@ -2434,7 +2434,7 @@
        -

        Compute the matrix scalar product $\left(u,Mv\right)$.

        +

        Compute the matrix scalar product $\left(u,Mv\right)$.

        The implementation of this function is not as efficient as the one in the SparseMatrix class used in deal.II (i.e. the original one, not the Trilinos wrapper class) since Trilinos doesn't support this operation and needs a temporary vector.

        The vector u has to be initialized with the same IndexSet that was used for the row indices of the matrix and the vector v has to be initialized with the same IndexSet that was used for the column indices of the matrix.

        In case of a localized Vector, this function will only work when running on one processor, since the matrix object is inherently distributed. Otherwise, an exception will be thrown.

        @@ -2551,10 +2551,10 @@
        -

        Return the l1-norm of the matrix, that is $|M|_1=
+<p>Return the <em>l</em><sub>1</sub>-norm of the matrix, that is <picture><source srcset=$|M|_1=
 \max_{\mathrm{all\ columns\ } j} \sum_{\mathrm{all\ rows\ } i}
-|M_{ij}|$, (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. $|Mv|_1 \leq |M|_1
-|v|_1$. (cf. Haemmerlin-Hoffmann: Numerische Mathematik)

        +|M_{ij}|$" src="form_1959.png"/>, (max. sum of columns). This is the natural matrix norm that is compatible to the l1-norm for vectors, i.e. $|Mv|_1 \leq |M|_1
+|v|_1$. (cf. Haemmerlin-Hoffmann: Numerische Mathematik)

        Definition at line 1911 of file trilinos_sparse_matrix.cc.

        @@ -2574,8 +2574,8 @@
        -

        Return the linfty-norm of the matrix, that is $|M|_\infty=\max_{\mathrm{all\ rows\ } i}\sum_{\mathrm{all\ columns\ }
-j} |M_{ij}|$, (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. $|Mv|_\infty \leq
+<p>Return the linfty-norm of the matrix, that is  <picture><source srcset=$|M|_\infty=\max_{\mathrm{all\ rows\ } i}\sum_{\mathrm{all\ columns\ }
+j} |M_{ij}|$, (max. sum of rows). This is the natural matrix norm that is compatible to the linfty-norm of vectors, i.e. $|Mv|_\infty \leq
 |M|_\infty |v|_\infty$. (cf. Haemmerlin-Hoffmann: Numerische Mathematik)

        Definition at line 1920 of file trilinos_sparse_matrix.cc.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1SparsityPattern.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1SparsityPattern.html 2023-08-09 23:38:54.622598146 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classTrilinosWrappers_1_1SparsityPattern.html 2023-08-09 23:38:54.622598146 +0000 @@ -461,7 +461,7 @@
        -

        Generate a sparsity pattern that is completely stored locally, having $m$ rows and $n$ columns. The resulting matrix will be completely stored locally, too.

        +

        Generate a sparsity pattern that is completely stored locally, having $m$ rows and $n$ columns. The resulting matrix will be completely stored locally, too.

        It is possible to specify the number of columns entries per row using the optional n_entries_per_row argument. However, this value does not need to be accurate or even given at all, since one does usually not have this kind of information before building the sparsity pattern (the usual case when the function DoFTools::make_sparsity_pattern() is called). The entries are allocated dynamically in a similar manner as for the deal.II DynamicSparsityPattern classes. However, a good estimate will reduce the setup time of the sparsity pattern.

        Definition at line 100 of file trilinos_sparsity_pattern.cc.

        @@ -499,7 +499,7 @@
        -

        Generate a sparsity pattern that is completely stored locally, having $m$ rows and $n$ columns. The resulting matrix will be completely stored locally, too.

        +

        Generate a sparsity pattern that is completely stored locally, having $m$ rows and $n$ columns. The resulting matrix will be completely stored locally, too.

        The vector n_entries_per_row specifies the number of entries in each row (an information usually not available, though).

        Definition at line 109 of file trilinos_sparsity_pattern.cc.

        @@ -809,7 +809,7 @@
        -

        Initialize a sparsity pattern that is completely stored locally, having $m$ rows and $n$ columns. The resulting matrix will be completely stored locally.

        +

        Initialize a sparsity pattern that is completely stored locally, having $m$ rows and $n$ columns. The resulting matrix will be completely stored locally.

        The number of columns entries per row is specified as the maximum number of entries argument. This does not need to be an accurate number since the entries are allocated dynamically in a similar manner as for the deal.II DynamicSparsityPattern classes, but a good estimate will reduce the setup time of the sparsity pattern.

        Definition at line 214 of file trilinos_sparsity_pattern.cc.

        @@ -847,7 +847,7 @@
        -

        Initialize a sparsity pattern that is completely stored locally, having $m$ rows and $n$ columns. The resulting matrix will be completely stored locally.

        +

        Initialize a sparsity pattern that is completely stored locally, having $m$ rows and $n$ columns. The resulting matrix will be completely stored locally.

        The vector n_entries_per_row specifies the number of entries in each row.

        Definition at line 227 of file trilinos_sparsity_pattern.cc.

        @@ -1399,7 +1399,7 @@
        -

        Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of $|i-j|$ for which the index pair $(i,j)$ represents a nonzero entry of the matrix. Consequently, the maximum bandwidth a $n\times m$ matrix can have is $\max\{n-1,m-1\}$.

        +

        Compute the bandwidth of the matrix represented by this structure. The bandwidth is the maximum of $|i-j|$ for which the index pair $(i,j)$ represents a nonzero entry of the matrix. Consequently, the maximum bandwidth a $n\times m$ matrix can have is $\max\{n-1,m-1\}$.

        Definition at line 896 of file trilinos_sparsity_pattern.cc.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classUtilities_1_1MPI_1_1Partitioner.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classUtilities_1_1MPI_1_1Partitioner.html 2023-08-09 23:38:54.662598445 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classUtilities_1_1MPI_1_1Partitioner.html 2023-08-09 23:38:54.662598445 +0000 @@ -321,7 +321,7 @@

        Constructor that takes the number of locally-owned degrees of freedom local_size and the number of ghost degrees of freedom ghost_size.

        -

        The local index range is translated to global indices in an ascending and one-to-one fashion, i.e., the indices of process $p$ sit exactly between the indices of the processes $p-1$ and $p+1$, respectively.

        +

        The local index range is translated to global indices in an ascending and one-to-one fashion, i.e., the indices of process $p$ sit exactly between the indices of the processes $p-1$ and $p+1$, respectively.

        Note
        Setting the ghost_size variable to an appropriate value provides memory space for the ghost data in a vector's memory allocation as and allows access to it via local_element(). However, the associated global indices must be handled externally in this case.
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classUtilities_1_1MPI_1_1ProcessGrid.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classUtilities_1_1MPI_1_1ProcessGrid.html 2023-08-09 23:38:54.686598624 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classUtilities_1_1MPI_1_1ProcessGrid.html 2023-08-09 23:38:54.686598624 +0000 @@ -239,7 +239,7 @@

        Constructor for a process grid for a given mpi_communicator. In this case the process grid is heuristically chosen based on the dimensions and block-cyclic distribution of a target matrix provided in n_rows_matrix, n_columns_matrix, row_block_size and column_block_size.

        -

        The maximum number of MPI cores one can utilize is $\min\{\frac{M}{MB}\frac{N}{NB}, Np\}$, where $M,N$ are the matrix dimension and $MB,NB$ are the block sizes and $Np$ is the number of processes in the mpi_communicator. This function then creates a 2d processor grid assuming the ratio between number of process row $p$ and columns $q$ to be equal the ratio between matrix dimensions $M$ and $N$.

        +

        The maximum number of MPI cores one can utilize is $\min\{\frac{M}{MB}\frac{N}{NB}, Np\}$, where $M,N$ are the matrix dimension and $MB,NB$ are the block sizes and $Np$ is the number of processes in the mpi_communicator. This function then creates a 2d processor grid assuming the ratio between number of process row $p$ and columns $q$ to be equal the ratio between matrix dimensions $M$ and $N$.

        For example, a square matrix $640x640$ with the block size $32$ and the mpi_communicator with 11 cores will result in the $3x3$ process grid.

        Definition at line 209 of file process_grid.cc.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classVector.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classVector.html 2023-08-09 23:38:54.738599013 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classVector.html 2023-08-09 23:38:54.738599013 +0000 @@ -1309,7 +1309,7 @@
        -

        Return the square of the $l_2$-norm.

        +

        Return the square of the $l_2$-norm.

        Note
        If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile). The algorithm uses pairwise summation with the same order of summation in every run, which gives fully repeatable results from one run to another.
        @@ -1351,7 +1351,7 @@
        -

        $l_1$-norm of the vector. The sum of the absolute values.

        +

        $l_1$-norm of the vector. The sum of the absolute values.

        Note
        If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile). The algorithm uses pairwise summation with the same order of summation in every run, which gives fully repeatable results from one run to another.
        @@ -1372,7 +1372,7 @@
        -

        $l_2$-norm of the vector. The square root of the sum of the squares of the elements.

        +

        $l_2$-norm of the vector. The square root of the sum of the squares of the elements.

        Note
        If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile). The algorithm uses pairwise summation with the same order of summation in every run, which gives fully repeatable results from one run to another.
        @@ -1394,7 +1394,7 @@
        -

        $l_p$-norm of the vector. The pth root of the sum of the pth powers of the absolute values of the elements.

        +

        $l_p$-norm of the vector. The pth root of the sum of the pth powers of the absolute values of the elements.

        Note
        If deal.II is configured with threads, this operation will run multi-threaded by splitting the work into smaller chunks (assuming there is enough work to make this worthwhile). The algorithm uses pairwise summation with the same order of summation in every run, which gives fully repeatable results from one run to another.
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FECollection.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FECollection.html 2023-08-09 23:38:54.786599371 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FECollection.html 2023-08-09 23:38:54.786599371 +0000 @@ -1348,7 +1348,7 @@

        Return a block mask with as many elements as this object has blocks and of which exactly the one component is true that corresponds to the given argument. See the glossary for more information.

        -
        Note
        This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
        +
        Note
        This function will only succeed if the scalar referenced by the argument encompasses a complete block. In other words, if, for example, you pass an extractor for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single scalar object you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
        This function is the equivalent of FiniteElement::component_mask() with the same arguments. It verifies that it gets the same result from every one of the elements that are stored in this FECollection. If this is not the case, it throws an exception.
        Parameters
        @@ -1444,7 +1444,7 @@

        Given a component mask (see this glossary entry ), produce a block mask (see this glossary entry ) that represents the blocks that correspond to the components selected in the input argument. This is essentially a conversion operator from ComponentMask to BlockMask.

        -
        Note
        This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
        +
        Note
        This function will only succeed if the components referenced by the argument encompasses complete blocks. In other words, if, for example, you pass an component mask for the single $x$ velocity and this object represents an FE_RaviartThomas object, then the single component you selected is part of a larger block and consequently there is no block mask that would represent it. The function will then produce an exception.
        This function is the equivalent of FiniteElement::component_mask() with the same arguments. It verifies that it gets the same result from every one of the elements that are stored in this FECollection. If this is not the case, it throws an exception.
        Parameters
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEFaceValues.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEFaceValues.html 2023-08-09 23:38:54.822599640 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEFaceValues.html 2023-08-09 23:38:54.822599640 +0000 @@ -388,7 +388,7 @@
        -

        Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

        +

        Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

        Definition at line 398 of file fe_values.cc.

        @@ -479,7 +479,7 @@

        After the call, you can get an FEFaceValues object using the get_present_fe_values() function that corresponds to the present cell. For this FEFaceValues object, we use the additional arguments described below to determine which finite element, mapping, and quadrature formula to use. They are order in such a way that the arguments one may want to change most frequently come first. The rules for these arguments are as follows:

        If the fe_index argument to this function is left at its default value, then we use that finite element within the hp::FECollection passed to the constructor of this class with index given by cell->active_fe_index(). Consequently, the hp::FECollection argument given to this object should really be the same as that used in the construction of the DoFHandler associated with the present cell. On the other hand, if a value is given for this argument, it overrides the choice of cell->active_fe_index(). (This may or may not be very useful: If you are using a specific finite element on the current cell, why would you want to reinit() an object of the current type with a different finite element?)

        If the q_index argument is left at its default value, then we use that quadrature formula within the hp::QCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. In this case, there should be a corresponding quadrature formula for each finite element in the hp::FECollection. As a special case, if the quadrature collection contains only a single element (a frequent case if one wants to use the same quadrature object for all finite elements in an hp-discretization, even if that may not be the most efficient), then this single quadrature is used unless a different value for this argument is specified. On the other hand, if a value is given for this argument, it overrides the choice of cell->active_fe_index() or the choice for the single quadrature.

        -

        If the mapping_index argument is left at its default value, then we use that mapping object within the hp::MappingCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. As above, if the mapping collection contains only a single element (a frequent case if one wants to use a $Q_1$ mapping for all finite elements in an hp-discretization), then this single mapping is used unless a different value for this argument is specified.

        +

        If the mapping_index argument is left at its default value, then we use that mapping object within the hp::MappingCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. As above, if the mapping collection contains only a single element (a frequent case if one wants to use a $Q_1$ mapping for all finite elements in an hp-discretization), then this single mapping is used unless a different value for this argument is specified.

        Definition at line 424 of file fe_values.cc.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FESubfaceValues.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FESubfaceValues.html 2023-08-09 23:38:54.842599790 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FESubfaceValues.html 2023-08-09 23:38:54.842599790 +0000 @@ -195,7 +195,7 @@
        -

        Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

        +

        Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

        Definition at line 550 of file fe_values.cc.

        @@ -252,7 +252,7 @@

        Reinitialize the object for the given cell, face, and subface.

        After the call, you can get an FESubfaceValues object using the get_present_fe_values() function that corresponds to the present cell. For this FESubfaceValues object, we use the additional arguments described below to determine which finite element, mapping, and quadrature formula to use. They are order in such a way that the arguments one may want to change most frequently come first. The rules for these arguments are as follows:

        If the q_index argument is left at its default value, then we use that quadrature formula within the hp::QCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. In this case, there should be a corresponding quadrature formula for each finite element in the hp::FECollection. As a special case, if the quadrature collection contains only a single element (a frequent case if one wants to use the same quadrature object for all finite elements in an hp-discretization, even if that may not be the most efficient), then this single quadrature is used unless a different value for this argument is specified. On the other hand, if a value is given for this argument, it overrides the choice of cell->active_fe_index() or the choice for the single quadrature.

        -

        If the mapping_index argument is left at its default value, then we use that mapping object within the hp::MappingCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. As above, if the mapping collection contains only a single element (a frequent case if one wants to use a $Q_1$ mapping for all finite elements in an hp-discretization), then this single mapping is used unless a different value for this argument is specified.

        +

        If the mapping_index argument is left at its default value, then we use that mapping object within the hp::MappingCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. As above, if the mapping collection contains only a single element (a frequent case if one wants to use a $Q_1$ mapping for all finite elements in an hp-discretization), then this single mapping is used unless a different value for this argument is specified.

        Definition at line 564 of file fe_values.cc.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEValues.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEValues.html 2023-08-09 23:38:54.874600029 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEValues.html 2023-08-09 23:38:54.874600029 +0000 @@ -348,7 +348,7 @@
        -

        Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

        +

        Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

        Definition at line 281 of file fe_values.cc.

        @@ -396,7 +396,7 @@

        After the call, you can get an FEValues object using the get_present_fe_values() function that corresponds to the present cell. For this FEValues object, we use the additional arguments described below to determine which finite element, mapping, and quadrature formula to use. They are order in such a way that the arguments one may want to change most frequently come first. The rules for these arguments are as follows:

        If the fe_index argument to this function is left at its default value, then we use that finite element within the hp::FECollection passed to the constructor of this class with index given by cell->active_fe_index(). Consequently, the hp::FECollection argument given to this object should really be the same as that used in the construction of the DoFHandler associated with the present cell. On the other hand, if a value is given for this argument, it overrides the choice of cell->active_fe_index().

        If the q_index argument is left at its default value, then we use that quadrature formula within the hp::QCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. In this case, there should be a corresponding quadrature formula for each finite element in the hp::FECollection. As a special case, if the quadrature collection contains only a single element (a frequent case if one wants to use the same quadrature object for all finite elements in an hp-discretization, even if that may not be the most efficient), then this single quadrature is used unless a different value for this argument is specified. On the other hand, if a value is given for this argument, it overrides the choice of cell->active_fe_index() or the choice for the single quadrature.

        -

        If the mapping_index argument is left at its default value, then we use that mapping object within the hp::MappingCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. As above, if the mapping collection contains only a single element (a frequent case if one wants to use a $Q_1$ mapping for all finite elements in an hp-discretization), then this single mapping is used unless a different value for this argument is specified.

        +

        If the mapping_index argument is left at its default value, then we use that mapping object within the hp::MappingCollection passed to the constructor of this class with index given by cell->active_fe_index(), i.e. the same index as that of the finite element. As above, if the mapping collection contains only a single element (a frequent case if one wants to use a $Q_1$ mapping for all finite elements in an hp-discretization), then this single mapping is used unless a different value for this argument is specified.

        Definition at line 294 of file fe_values.cc.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEValuesBase.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEValuesBase.html 2023-08-09 23:38:54.906600268 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classhp_1_1FEValuesBase.html 2023-08-09 23:38:54.906600268 +0000 @@ -380,7 +380,7 @@
        -

        Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

        +

        Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

        Definition at line 107 of file fe_values.cc.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1MappingQImplementation_1_1InverseQuadraticApproximation.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1MappingQImplementation_1_1InverseQuadraticApproximation.html 2023-08-09 23:38:54.926600416 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1MappingQImplementation_1_1InverseQuadraticApproximation.html 2023-08-09 23:38:54.926600416 +0000 @@ -174,7 +174,7 @@
        Parameters
        - +
        real_support_pointsThe position of the mapping support points in real space, queried by MappingQ::compute_mapping_support_points().
        unit_support_pointsThe location of the support points in reference coordinates $[0, 1]^d$ that map to the mapping support points in real space by a polynomial map.
        unit_support_pointsThe location of the support points in reference coordinates $[0, 1]^d$ that map to the mapping support points in real space by a polynomial map.
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html 2023-08-09 23:38:54.946600565 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html 2023-08-09 23:38:54.946600565 +0000 @@ -254,7 +254,7 @@
        -

        Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

        +

        Constructor. This constructor is equivalent to the other one except that it makes the object use a $Q_1$ mapping (i.e., an object of type MappingQ(1)) implicitly.

        Definition at line 210 of file mapping_data_on_the_fly.h.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1TriangulationImplementation_1_1TriaLevel.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1TriangulationImplementation_1_1TriaLevel.html 2023-08-09 23:38:54.970600745 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classinternal_1_1TriangulationImplementation_1_1TriaLevel.html 2023-08-09 23:38:54.970600745 +0000 @@ -379,7 +379,7 @@
        -

        Levels and indices of the neighbors of the cells. Convention is, that the neighbors of the cell with index i are stored in the fields following $i*(2*real\_space\_dimension)$, e.g. in one spatial dimension, the neighbors of cell 0 are stored in neighbors[0] and neighbors[1], the neighbors of cell 1 are stored in neighbors[2] and neighbors[3], and so on.

        +

        Levels and indices of the neighbors of the cells. Convention is, that the neighbors of the cell with index i are stored in the fields following $i*(2*real\_space\_dimension)$, e.g. in one spatial dimension, the neighbors of cell 0 are stored in neighbors[0] and neighbors[1], the neighbors of cell 1 are stored in neighbors[2] and neighbors[3], and so on.

        In neighbors, neighbors[i].first is the level, while neighbors[i].second is the index of the neighbor.

        If a neighbor does not exist (cell is at the boundary), level=index=-1 is set.

        Conventions: The ith neighbor of a cell is the one which shares the ith face (Line in 2d, Quad in 3d) of this cell.

        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1DistributedTriangulationBase.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1DistributedTriangulationBase.html 2023-08-09 23:38:55.106601760 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1DistributedTriangulationBase.html 2023-08-09 23:38:55.106601760 +0000 @@ -2022,7 +2022,7 @@

        When vertices have been moved locally, for example using code like

        cell->vertex(0) = new_location;

        then this function can be used to update the location of vertices between MPI processes.

        -

        All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor $i$ move those vertices that are adjacent to cells whose owners include processor $i$ but no other processor $j$ with $j<i$; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.

        +

        All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor $i$ move those vertices that are adjacent to cells whose owners include processor $i$ but no other processor $j$ with $j<i$; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.

        Note
        It only makes sense to move vertices that are either located on locally owned cells or on cells in the ghost layer. This is because you can be sure that these vertices indeed exist on the finest mesh aggregated over all processors, whereas vertices on artificial cells but not at least in the ghost layer may or may not exist on the globally finest mesh. Consequently, the vertex_locally_moved argument may not contain vertices that aren't at least on ghost cells.
        This function moves vertices in such a way that on every processor, the vertices of every locally owned and ghost cell is consistent with the corresponding location of these cells on other processors. On the other hand, the locations of artificial cells will in general be wrong since artificial cells may or may not exist on other processors and consequently it is not possible to determine their location in any way. This is not usually a problem since one never does anything on artificial cells. However, it may lead to problems if the mesh with moved vertices is refined in a later step. If that's what you want to do, the right way to do it is to save the offset applied to every vertex, call this function, and before refining or coarsening the mesh apply the opposite offset and call this function again.
        @@ -2432,7 +2432,7 @@
        -

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        +

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.

        Note
        This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
        @@ -6701,7 +6701,7 @@
        -

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        +

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        Note
        The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1TriangulationBase.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1TriangulationBase.html 2023-08-09 23:38:55.238602746 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1TriangulationBase.html 2023-08-09 23:38:55.238602746 +0000 @@ -1547,7 +1547,7 @@

        When vertices have been moved locally, for example using code like

        cell->vertex(0) = new_location;

        then this function can be used to update the location of vertices between MPI processes.

        -

        All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor $i$ move those vertices that are adjacent to cells whose owners include processor $i$ but no other processor $j$ with $j<i$; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.

        +

        All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor $i$ move those vertices that are adjacent to cells whose owners include processor $i$ but no other processor $j$ with $j<i$; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.

        Note
        It only makes sense to move vertices that are either located on locally owned cells or on cells in the ghost layer. This is because you can be sure that these vertices indeed exist on the finest mesh aggregated over all processors, whereas vertices on artificial cells but not at least in the ghost layer may or may not exist on the globally finest mesh. Consequently, the vertex_locally_moved argument may not contain vertices that aren't at least on ghost cells.
        This function moves vertices in such a way that on every processor, the vertices of every locally owned and ghost cell is consistent with the corresponding location of these cells on other processors. On the other hand, the locations of artificial cells will in general be wrong since artificial cells may or may not exist on other processors and consequently it is not possible to determine their location in any way. This is not usually a problem since one never does anything on artificial cells. However, it may lead to problems if the mesh with moved vertices is refined in a later step. If that's what you want to do, the right way to do it is to save the offset applied to every vertex, call this function, and before refining or coarsening the mesh apply the opposite offset and call this function again.
        @@ -2024,7 +2024,7 @@
        -

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        +

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.

        Note
        This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
        @@ -6324,7 +6324,7 @@
        -

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        +

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        Note
        The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation.html 2023-08-09 23:38:55.394603912 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation.html 2023-08-09 23:38:55.394603912 +0000 @@ -1925,7 +1925,7 @@
        -

        Return a permutation vector for the order the coarse cells are handed off to p4est. For example the value of the $i$th element in this vector is the index of the deal.II coarse cell (counting from begin(0)) that corresponds to the $i$th tree managed by p4est.

        +

        Return a permutation vector for the order the coarse cells are handed off to p4est. For example the value of the $i$th element in this vector is the index of the deal.II coarse cell (counting from begin(0)) that corresponds to the $i$th tree managed by p4est.

        Definition at line 3609 of file tria.cc.

        @@ -3027,7 +3027,7 @@

        When vertices have been moved locally, for example using code like

        cell->vertex(0) = new_location;

        then this function can be used to update the location of vertices between MPI processes.

        -

        All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor $i$ move those vertices that are adjacent to cells whose owners include processor $i$ but no other processor $j$ with $j<i$; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.

        +

        All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor $i$ move those vertices that are adjacent to cells whose owners include processor $i$ but no other processor $j$ with $j<i$; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.

        Note
        It only makes sense to move vertices that are either located on locally owned cells or on cells in the ghost layer. This is because you can be sure that these vertices indeed exist on the finest mesh aggregated over all processors, whereas vertices on artificial cells but not at least in the ghost layer may or may not exist on the globally finest mesh. Consequently, the vertex_locally_moved argument may not contain vertices that aren't at least on ghost cells.
        This function moves vertices in such a way that on every processor, the vertices of every locally owned and ghost cell is consistent with the corresponding location of these cells on other processors. On the other hand, the locations of artificial cells will in general be wrong since artificial cells may or may not exist on other processors and consequently it is not possible to determine their location in any way. This is not usually a problem since one never does anything on artificial cells. However, it may lead to problems if the mesh with moved vertices is refined in a later step. If that's what you want to do, the right way to do it is to save the offset applied to every vertex, call this function, and before refining or coarsening the mesh apply the opposite offset and call this function again.
        @@ -3344,7 +3344,7 @@
        -

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        +

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.

        Note
        This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
        @@ -7377,7 +7377,7 @@
        -

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        +

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        Note
        The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation_3_011_00_01spacedim_01_4.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation_3_011_00_01spacedim_01_4.html 2023-08-09 23:38:55.538604986 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation_3_011_00_01spacedim_01_4.html 2023-08-09 23:38:55.538604986 +0000 @@ -2364,7 +2364,7 @@

        When vertices have been moved locally, for example using code like

        cell->vertex(0) = new_location;

        then this function can be used to update the location of vertices between MPI processes.

        -

        All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor $i$ move those vertices that are adjacent to cells whose owners include processor $i$ but no other processor $j$ with $j<i$; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.

        +

        All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor $i$ move those vertices that are adjacent to cells whose owners include processor $i$ but no other processor $j$ with $j<i$; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.

        Note
        It only makes sense to move vertices that are either located on locally owned cells or on cells in the ghost layer. This is because you can be sure that these vertices indeed exist on the finest mesh aggregated over all processors, whereas vertices on artificial cells but not at least in the ghost layer may or may not exist on the globally finest mesh. Consequently, the vertex_locally_moved argument may not contain vertices that aren't at least on ghost cells.
        This function moves vertices in such a way that on every processor, the vertices of every locally owned and ghost cell is consistent with the corresponding location of these cells on other processors. On the other hand, the locations of artificial cells will in general be wrong since artificial cells may or may not exist on other processors and consequently it is not possible to determine their location in any way. This is not usually a problem since one never does anything on artificial cells. However, it may lead to problems if the mesh with moved vertices is refined in a later step. If that's what you want to do, the right way to do it is to save the offset applied to every vertex, call this function, and before refining or coarsening the mesh apply the opposite offset and call this function again.
        @@ -2773,7 +2773,7 @@
        -

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        +

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.

        Note
        This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
        @@ -6961,7 +6961,7 @@
        -

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        +

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        Note
        The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1fullydistributed_1_1Triangulation.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1fullydistributed_1_1Triangulation.html 2023-08-09 23:38:55.686606092 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1fullydistributed_1_1Triangulation.html 2023-08-09 23:38:55.686606092 +0000 @@ -2539,7 +2539,7 @@

        When vertices have been moved locally, for example using code like

        cell->vertex(0) = new_location;

        then this function can be used to update the location of vertices between MPI processes.

        -

        All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor $i$ move those vertices that are adjacent to cells whose owners include processor $i$ but no other processor $j$ with $j<i$; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.

        +

        All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor $i$ move those vertices that are adjacent to cells whose owners include processor $i$ but no other processor $j$ with $j<i$; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.

        Note
        It only makes sense to move vertices that are either located on locally owned cells or on cells in the ghost layer. This is because you can be sure that these vertices indeed exist on the finest mesh aggregated over all processors, whereas vertices on artificial cells but not at least in the ghost layer may or may not exist on the globally finest mesh. Consequently, the vertex_locally_moved argument may not contain vertices that aren't at least on ghost cells.
        This function moves vertices in such a way that on every processor, the vertices of every locally owned and ghost cell is consistent with the corresponding location of these cells on other processors. On the other hand, the locations of artificial cells will in general be wrong since artificial cells may or may not exist on other processors and consequently it is not possible to determine their location in any way. This is not usually a problem since one never does anything on artificial cells. However, it may lead to problems if the mesh with moved vertices is refined in a later step. If that's what you want to do, the right way to do it is to save the offset applied to every vertex, call this function, and before refining or coarsening the mesh apply the opposite offset and call this function again.
        @@ -2880,7 +2880,7 @@
        -

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        +

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.

        Note
        This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
        @@ -6913,7 +6913,7 @@
        -

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        +

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        Note
        The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1shared_1_1Triangulation.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1shared_1_1Triangulation.html 2023-08-09 23:38:55.822607107 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/classparallel_1_1shared_1_1Triangulation.html 2023-08-09 23:38:55.822607107 +0000 @@ -1987,7 +1987,7 @@

        When vertices have been moved locally, for example using code like

        cell->vertex(0) = new_location;

        then this function can be used to update the location of vertices between MPI processes.

        -

        All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor $i$ move those vertices that are adjacent to cells whose owners include processor $i$ but no other processor $j$ with $j<i$; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.

        +

        All the vertices that have been moved and might be in the ghost layer of a process have to be reported in the vertex_locally_moved argument. This ensures that that part of the information that has to be send between processes is actually sent. Additionally, it is quite important that vertices on the boundary between processes are reported on exactly one process (e.g. the one with the highest id). Otherwise we could expect undesirable results if multiple processes move a vertex differently. A typical strategy is to let processor $i$ move those vertices that are adjacent to cells whose owners include processor $i$ but no other processor $j$ with $j<i$; in other words, for vertices at the boundary of a subdomain, the processor with the lowest subdomain id "owns" a vertex.

        Note
        It only makes sense to move vertices that are either located on locally owned cells or on cells in the ghost layer. This is because you can be sure that these vertices indeed exist on the finest mesh aggregated over all processors, whereas vertices on artificial cells but not at least in the ghost layer may or may not exist on the globally finest mesh. Consequently, the vertex_locally_moved argument may not contain vertices that aren't at least on ghost cells.
        This function moves vertices in such a way that on every processor, the vertices of every locally owned and ghost cell is consistent with the corresponding location of these cells on other processors. On the other hand, the locations of artificial cells will in general be wrong since artificial cells may or may not exist on other processors and consequently it is not possible to determine their location in any way. This is not usually a problem since one never does anything on artificial cells. However, it may lead to problems if the mesh with moved vertices is refined in a later step. If that's what you want to do, the right way to do it is to save the offset applied to every vertex, call this function, and before refining or coarsening the mesh apply the opposite offset and call this function again.
        @@ -2335,7 +2335,7 @@
        -

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        +

        Refine all cells times times. In other words, in each one of the times iterations, loop over all cells and refine each cell uniformly into $2^\text{dim}$ children. In practice, this function repeats the following operations times times: call set_all_refine_flags() followed by execute_coarsening_and_refinement(). The end result is that the number of cells increases by a factor of $(2^\text{dim})^\text{times}=2^{\text{dim} \times \text{times}}$.

        The execute_coarsening_and_refinement() function called in this loop may throw an exception if it creates cells that are distorted (see its documentation for an explanation). This exception will be propagated through this function if that happens, and you may not get the actual number of refinement steps in that case.

        Note
        This function triggers the pre- and post-refinement signals before and after doing each individual refinement cycle (i.e. more than once if times > 1) . See the section on signals in the general documentation of this class.
        @@ -6555,7 +6555,7 @@
        -

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        +

        Iterator to the first quad, used or not, on the given level. If a level has no quads, a past-the-end iterator is returned. If quads are no cells, i.e. for $dim>2$ no level argument must be given.

        Note
        The given level argument needs to correspond to a level of the triangulation, i.e., should be less than the value returned by n_levels(). On the other hand, for parallel computations using a parallel::distributed::Triangulation object, it is often convenient to write loops over the cells of all levels of the global mesh, even if the local portion of the triangulation does not actually have cells at one of the higher levels. In those cases, the level argument is accepted if it is less than what the n_global_levels() function returns. If the given level is between the values returned by n_levels() and n_global_levels(), then no cells exist in the local portion of the triangulation at this level, and the function simply returns what end() would return.
        /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/deprecated.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/deprecated.html 2023-08-09 23:38:55.854607346 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/deprecated.html 2023-08-09 23:38:55.854607346 +0000 @@ -103,10 +103,10 @@
        Use numbers::invalid_fe_index instead.
        Member DoFHandler< dim, spacedim >::set_active_fe_indices (const std::vector< unsigned int > &active_fe_indices)
        Use set_active_fe_indices() with the types::fe_index datatype.
        -
        Member DoFTools::extract_boundary_dofs (const DoFHandler< dim, spacedim > &dof_handler, const ComponentMask &component_mask, IndexSet &selected_dofs, const std::set< types::boundary_id > &boundary_ids={})
        -
        Use the previous function instead.
        Member DoFTools::extract_boundary_dofs (const DoFHandler< dim, spacedim > &dof_handler, const ComponentMask &component_mask, std::vector< bool > &selected_dofs, const std::set< types::boundary_id > &boundary_ids={})
        This function will not work for DoFHandler objects that are built on a parallel::distributed::Triangulation object. The reasons is that the output argument selected_dofs has to have a length equal to all global degrees of freedom. Consequently, this does not scale to very large problems, and this is also why the function is deprecated. If you need the functionality of this function for parallel triangulations, then you need to use the other DoFTools::extract_boundary_dofs() function that returns its information via an IndexSet object.
        +
        Member DoFTools::extract_boundary_dofs (const DoFHandler< dim, spacedim > &dof_handler, const ComponentMask &component_mask, IndexSet &selected_dofs, const std::set< types::boundary_id > &boundary_ids={})
        +
        Use the previous function instead.
        Member DoFTools::extract_locally_active_dofs (const DoFHandler< dim, spacedim > &dof_handler, IndexSet &dof_set)
        Use the previous function instead.
        Member DoFTools::extract_locally_active_level_dofs (const DoFHandler< dim, spacedim > &dof_handler, IndexSet &dof_set, const unsigned int level)
        @@ -117,20 +117,20 @@
        Use the previous function instead.
        Member DoFTools::get_active_fe_indices (const DoFHandler< dim, spacedim > &dof_handler, std::vector< unsigned int > &active_fe_indices)
        Use DoFHandler::get_active_fe_indices() that returns the result vector.
        -
        Member DoFTools::map_dofs_to_support_points (const Mapping< dim, spacedim > &mapping, const DoFHandler< dim, spacedim > &dof_handler, std::map< types::global_dof_index, Point< spacedim > > &support_points, const ComponentMask &mask=ComponentMask())
        -
        Use the function that returns the std::map instead.
        Member DoFTools::map_dofs_to_support_points (const hp::MappingCollection< dim, spacedim > &mapping, const DoFHandler< dim, spacedim > &dof_handler, std::map< types::global_dof_index, Point< spacedim > > &support_points, const ComponentMask &mask=ComponentMask())
        Use the function that returns the std::map instead.
        -
        Member FEEvaluation< dim, fe_degree, n_q_points_1d, n_components_, Number, VectorizedArrayType >::evaluate (const VectorizedArrayType *values_array, const bool evaluate_values, const bool evaluate_gradients, const bool evaluate_hessians=false)
        -
        use evaluate() with the EvaluationFlags argument.
        +
        Member DoFTools::map_dofs_to_support_points (const Mapping< dim, spacedim > &mapping, const DoFHandler< dim, spacedim > &dof_handler, std::map< types::global_dof_index, Point< spacedim > > &support_points, const ComponentMask &mask=ComponentMask())
        +
        Use the function that returns the std::map instead.
        Member FEEvaluation< dim, fe_degree, n_q_points_1d, n_components_, Number, VectorizedArrayType >::evaluate (const bool evaluate_values, const bool evaluate_gradients, const bool evaluate_hessians=false)
        use evaluate() with the EvaluationFlags argument.
        +
        Member FEEvaluation< dim, fe_degree, n_q_points_1d, n_components_, Number, VectorizedArrayType >::evaluate (const VectorizedArrayType *values_array, const bool evaluate_values, const bool evaluate_gradients, const bool evaluate_hessians=false)
        +
        use evaluate() with the EvaluationFlags argument.
        Member FEEvaluation< dim, fe_degree, n_q_points_1d, n_components_, Number, VectorizedArrayType >::gather_evaluate (const VectorType &input_vector, const bool evaluate_values, const bool evaluate_gradients, const bool evaluate_hessians=false)
        Please use the gather_evaluate() function with the EvaluationFlags argument.
        -
        Member FEEvaluation< dim, fe_degree, n_q_points_1d, n_components_, Number, VectorizedArrayType >::integrate (const bool integrate_values, const bool integrate_gradients, VectorizedArrayType *values_array)
        -
        Please use the integrate() function with the EvaluationFlags argument.
        Member FEEvaluation< dim, fe_degree, n_q_points_1d, n_components_, Number, VectorizedArrayType >::integrate (const bool integrate_values, const bool integrate_gradients)
        Please use the integrate() function with the EvaluationFlags argument.
        +
        Member FEEvaluation< dim, fe_degree, n_q_points_1d, n_components_, Number, VectorizedArrayType >::integrate (const bool integrate_values, const bool integrate_gradients, VectorizedArrayType *values_array)
        +
        Please use the integrate() function with the EvaluationFlags argument.
        Member FEEvaluation< dim, fe_degree, n_q_points_1d, n_components_, Number, VectorizedArrayType >::integrate_scatter (const bool integrate_values, const bool integrate_gradients, VectorType &output_vector)
        Please use the integrate_scatter() function with the EvaluationFlags argument.
        Member FEFaceEvaluation< dim, fe_degree, n_q_points_1d, n_components_, Number, VectorizedArrayType >::evaluate (const bool evaluate_values, const bool evaluate_gradients)
        @@ -190,13 +190,13 @@
        Member FEInterfaceViews::Vector< dim, spacedim >::jump_hessian (const unsigned int interface_dof_index, const unsigned int q_point) const
        Use the average_of_hessians() function instead.
        Class FEValuesViews::Scalar< dim, spacedim >::OutputType< Number >
        -
        Use the types defined in the surrounding class instead.
        +
        Use the types defined in the surrounding class instead.
        Class FEValuesViews::SymmetricTensor< 2, dim, spacedim >::OutputType< Number >
        -
        Use the types defined in the surrounding class instead.
        +
        Use the types defined in the surrounding class instead.
        Class FEValuesViews::Tensor< 2, dim, spacedim >::OutputType< Number >
        -
        Use the types defined in the surrounding class instead.
        -
        Class FEValuesViews::Vector< dim, spacedim >::OutputType< Number >
        Use the types defined in the surrounding class instead.
        +
        Class FEValuesViews::Vector< dim, spacedim >::OutputType< Number >
        +
        Use the types defined in the surrounding class instead.
        Member FiniteElement< dim, spacedim >::fill_fe_face_values (const typename Triangulation< dim, spacedim >::cell_iterator &cell, const unsigned int face_no, const Quadrature< dim - 1 > &quadrature, const Mapping< dim, spacedim > &mapping, const typename Mapping< dim, spacedim >::InternalDataBase &mapping_internal, const internal::FEValuesImplementation::MappingRelatedData< dim, spacedim > &mapping_data, const InternalDataBase &fe_internal, internal::FEValuesImplementation::FiniteElementRelatedData< dim, spacedim > &output_data) const
        Use the version taking a hp::QCollection argument.
        Member FiniteElement< dim, spacedim >::get_face_data (const UpdateFlags update_flags, const Mapping< dim, spacedim > &mapping, const Quadrature< dim - 1 > &quadrature, internal::FEValuesImplementation::FiniteElementRelatedData< dim, spacedim > &output_data) const
        @@ -221,20 +221,20 @@
        Use import_elements() instead.
        Member LinearAlgebra::distributed::BlockVector< Number >::zero_out_ghosts () const
        Use zero_out_ghost_values() instead.
        -
        Member LinearAlgebra::distributed::Vector< Number, MemorySpace >::import (const Vector< Number, MemorySpace2 > &src, VectorOperation::values operation)
        -
        Use import_elements() instead.
        Member LinearAlgebra::distributed::Vector< Number, MemorySpace >::import (const LinearAlgebra::ReadWriteVector< Number > &V, VectorOperation::values operation, std::shared_ptr< const Utilities::MPI::CommunicationPatternBase > communication_pattern={}) override
        Use import_elements() instead.
        +
        Member LinearAlgebra::distributed::Vector< Number, MemorySpace >::import (const Vector< Number, MemorySpace2 > &src, VectorOperation::values operation)
        +
        Use import_elements() instead.
        Member LinearAlgebra::distributed::Vector< Number, MemorySpace >::local_size () const
        Use locally_owned_size() instead.
        Member LinearAlgebra::distributed::Vector< Number, MemorySpace >::zero_out_ghosts () const
        Use zero_out_ghost_values() instead.
        Member LinearAlgebra::EpetraWrappers::Vector::import (const ReadWriteVector< double > &V, VectorOperation::values operation, std::shared_ptr< const Utilities::MPI::CommunicationPatternBase > communication_pattern={}) override
        Use import_elements() instead.
        -
        Member LinearAlgebra::ReadWriteVector< Number >::import (const ::Vector< Number > &V, VectorOperation::values operation, const std::shared_ptr< const Utilities::MPI::CommunicationPatternBase > &communication_pattern={})
        -
        Use import_elements() instead.
        Member LinearAlgebra::ReadWriteVector< Number >::import (const LinearAlgebra::Vector< Number > &V, VectorOperation::values operation, const std::shared_ptr< const Utilities::MPI::CommunicationPatternBase > &communication_pattern={})
        Use import_elements() instead.
        +
        Member LinearAlgebra::ReadWriteVector< Number >::import (const ::Vector< Number > &V, VectorOperation::values operation, const std::shared_ptr< const Utilities::MPI::CommunicationPatternBase > &communication_pattern={})
        +
        Use import_elements() instead.
        Member LinearAlgebra::ReadWriteVector< Number >::import (const distributed::Vector< Number, MemorySpace > &V, VectorOperation::values operation, const std::shared_ptr< const Utilities::MPI::CommunicationPatternBase > &communication_pattern={})
        Use import_elements() instead.
        Member LinearAlgebra::ReadWriteVector< Number >::import (const PETScWrappers::MPI::Vector &V, VectorOperation::values operation, const std::shared_ptr< const Utilities::MPI::CommunicationPatternBase > &communication_pattern={})
        @@ -255,18 +255,18 @@
        Use import_elements() instead.
        Member LinearAlgebra::VectorSpaceVector< Number >::import (const ReadWriteVector< Number > &V, VectorOperation::values operation, std::shared_ptr< const Utilities::MPI::CommunicationPatternBase > communication_pattern={})=0
        Use import_elements() instead.
        +
        Member make_array_view (Tensor< rank, dim, Number > &tensor)
        +
        This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        Member make_array_view (SymmetricTensor< rank, dim, Number > &tensor)
        This function suggests that the elements of a SymmetricTensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        Member make_array_view (const SymmetricTensor< rank, dim, Number > &tensor)
        This function suggests that the elements of a SymmetricTensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        Member make_array_view (const Tensor< rank, dim, Number > &tensor)
        This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        -
        Member make_array_view (Tensor< rank, dim, Number > &tensor)
        -
        This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        Member Mapping< dim, spacedim >::fill_fe_face_values (const typename Triangulation< dim, spacedim >::cell_iterator &cell, const unsigned int face_no, const Quadrature< dim - 1 > &quadrature, const typename Mapping< dim, spacedim >::InternalDataBase &internal_data, internal::FEValuesImplementation::MappingRelatedData< dim, spacedim > &output_data) const
        -
        Use the version taking a hp::QCollection argument.
        +
        Use the version taking a hp::QCollection argument.
        Member Mapping< dim, spacedim >::get_face_data (const UpdateFlags update_flags, const Quadrature< dim - 1 > &quadrature) const
        -
        Use the version taking a hp::QCollection argument.
        +
        Use the version taking a hp::QCollection argument.
        Member MappingQCache< dim, spacedim >::initialize (const Triangulation< dim, spacedim > &triangulation, const MappingQ< dim, spacedim > &mapping)
        Use initialize() version above instead.
        Member parallel::distributed::Triangulation< dim, spacedim >::load (const std::string &filename, const bool autopartition) override
        @@ -337,10 +337,10 @@
        Use solve_with_jacobian() instead which also uses a numerical tolerance.
        Member SUNDIALS::KINSOL< VectorType >::solve_jacobian_system
        Versions of SUNDIALS after 4.0 no longer provide all of the information necessary for this callback (see below). Use the solve_with_jacobian callback described below.
        -
        Member SymmetricTensor< rank_, dim, Number >::begin_raw () const
        -
        This function suggests that the elements of a SymmetricTensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        Member SymmetricTensor< rank_, dim, Number >::begin_raw ()
        This function suggests that the elements of a SymmetricTensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        +
        Member SymmetricTensor< rank_, dim, Number >::begin_raw () const
        +
        This function suggests that the elements of a SymmetricTensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        Member SymmetricTensor< rank_, dim, Number >::end_raw () const
        This function suggests that the elements of a SymmetricTensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        Member SymmetricTensor< rank_, dim, Number >::end_raw ()
        @@ -349,22 +349,22 @@
        This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        Member Tensor< 0, dim, Number >::begin_raw ()
        This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        -
        Member Tensor< 0, dim, Number >::end_raw () const
        -
        This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        Member Tensor< 0, dim, Number >::end_raw ()
        This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        +
        Member Tensor< 0, dim, Number >::end_raw () const
        +
        This function suggests that the elements of a Tensor object are stored as a contiguous array, but this is not in fact true and one should not pretend that this so. As a consequence, this function is deprecated.
        Member Tensor< rank_, dim, Number >::unroll (Vector< OtherNumber > &result) const
        Use the more general function that takes a pair of iterators instead.
        -
        Member Threads::new_thread (RT(C::*fun_ptr)(Args...), std_cxx20::type_identity_t< C > &c, std_cxx20::type_identity_t< Args >... args)
        -
        Use std::thread or std::jthread instead.
        Member Threads::new_thread (RT(C::*fun_ptr)(Args...) const, std_cxx20::type_identity_t< const C > &c, std_cxx20::type_identity_t< Args >... args)
        Use std::thread or std::jthread instead.
        -
        Member Threads::new_thread (RT(*fun_ptr)(Args...), std_cxx20::type_identity_t< Args >... args)
        -
        Use std::thread or std::jthread instead.
        -
        Member Threads::new_thread (FunctionObjectType function_object) -> Thread< decltype(function_object())>
        -
        Use std::thread or std::jthread instead.
        +
        Member Threads::new_thread (RT(C::*fun_ptr)(Args...), std_cxx20::type_identity_t< C > &c, std_cxx20::type_identity_t< Args >... args)
        +
        Use std::thread or std::jthread instead.
        Member Threads::new_thread (const std::function< RT()> &function)
        Use std::thread or std::jthread instead.
        +
        Member Threads::new_thread (FunctionObjectType function_object) -> Thread< decltype(function_object())>
        +
        Use std::thread or std::jthread instead.
        +
        Member Threads::new_thread (RT(*fun_ptr)(Args...), std_cxx20::type_identity_t< Args >... args)
        +
        Use std::thread or std::jthread instead.
        Class Threads::Thread< RT >
        Use std::thread or std::jthread instead.
        Class Threads::ThreadGroup< RT >
        @@ -374,9 +374,9 @@
        Member TriaAccessor< 0, dim, spacedim >::number_of_children ()
        Use n_active_descendants() instead.
        Member TriaAccessor< structdim, dim, spacedim >::number_of_children () const
        -
        Use n_active_descendants() instead.
        +
        Use n_active_descendants() instead.
        Member Triangulation< dim, spacedim >::Signals::cell_weight
        -
        Use the weight signal instead which omits the base weight. You can invoke the old behavior by connecting a function to the signal that returns the base weight as follows. This function should be added in addition to the one that actually computes the weight.
        +
        Use the weight signal instead which omits the base weight. You can invoke the old behavior by connecting a function to the signal that returns the base weight as follows. This function should be added in addition to the one that actually computes the weight.
        Member TrilinosWrappers::MPI::Vector::import (const LinearAlgebra::ReadWriteVector< double > &rwv, const VectorOperation::values operation)
        Use import_elements() instead.
        Member TrilinosWrappers::MPI::Vector::local_size () const
        @@ -399,12 +399,12 @@
        Use the more clearly named function locally_owned_size() instead.
        Member XDMFEntry::get_xdmf_content (const unsigned int indent_level, const ReferenceCell &reference_cell) const
        Use the other function instead.
        -
        Member XDMFEntry::XDMFEntry (const std::string &mesh_filename, const std::string &solution_filename, const double time, const std::uint64_t nodes, const std::uint64_t cells, const unsigned int dim, const unsigned int spacedim)
        -
        Use the constructor that additionally takes a ReferenceCell.
        +
        Member XDMFEntry::XDMFEntry (const std::string &filename, const double time, const std::uint64_t nodes, const std::uint64_t cells, const unsigned int dim)
        +
        Use the constructor that additionally takes a ReferenceCell.
        Member XDMFEntry::XDMFEntry (const std::string &mesh_filename, const std::string &solution_filename, const double time, const std::uint64_t nodes, const std::uint64_t cells, const unsigned int dim)
        Use the constructor that additionally takes a ReferenceCell.
        -
        Member XDMFEntry::XDMFEntry (const std::string &filename, const double time, const std::uint64_t nodes, const std::uint64_t cells, const unsigned int dim)
        -
        Use the constructor that additionally takes a ReferenceCell.
        +
        Member XDMFEntry::XDMFEntry (const std::string &mesh_filename, const std::string &solution_filename, const double time, const std::uint64_t nodes, const std::uint64_t cells, const unsigned int dim, const unsigned int spacedim)
        +
        Use the constructor that additionally takes a ReferenceCell.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/derivative__form_8h.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/derivative__form_8h.html 2023-08-09 23:38:55.874607495 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/derivative__form_8h.html 2023-08-09 23:38:55.874607495 +0000 @@ -152,21 +152,21 @@
    -

    One of the uses of DerivativeForm is to apply it as a linear transformation. This function returns $\nabla \mathbf F(\mathbf x) \Delta \mathbf x$, which approximates the change in $\mathbf F(\mathbf x)$ when $\mathbf x$ is changed by the amount $\Delta \mathbf x$

    -\[
+<p>One of the uses of <a class=DerivativeForm is to apply it as a linear transformation. This function returns $\nabla \mathbf F(\mathbf x) \Delta \mathbf x$, which approximates the change in $\mathbf F(\mathbf x)$ when $\mathbf x$ is changed by the amount $\Delta \mathbf x$

    +\[
   \nabla \mathbf F(\mathbf x) \; \Delta \mathbf x
   \approx
   \mathbf F(\mathbf x + \Delta \mathbf x) - \mathbf F(\mathbf x).
-\] +\]" src="form_396.png"/>

    The transformation corresponds to

    -\[
+<picture><source srcset=\[
   [\text{result}]_{i_1,\dots,i_k} = i\sum_{j}
   \left[\nabla \mathbf F(\mathbf x)\right]_{i_1,\dots,i_k, j}
   \Delta x_j
-\] +\]" src="form_397.png"/>

    -

    in index notation and corresponds to $[\Delta \mathbf x] [\nabla \mathbf F(\mathbf x)]^T$ in matrix notation.

    +

    in index notation and corresponds to $[\Delta \mathbf x] [\nabla \mathbf F(\mathbf x)]^T$ in matrix notation.

    Definition at line 454 of file derivative_form.h.

    @@ -205,7 +205,7 @@
    -

    Similar to the previous apply_transformation(). Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to $\mathrm{D\_X} \, \mathrm{grad\_F}^T$ in matrix notation.

    +

    Similar to the previous apply_transformation(). Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to $\mathrm{D\_X} \, \mathrm{grad\_F}^T$ in matrix notation.

    Definition at line 479 of file derivative_form.h.

    @@ -244,7 +244,7 @@
    -

    Similar to the previous apply_transformation(), specialized for the case dim == spacedim where we can return a rank-2 tensor instead of the more general DerivativeForm. Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to $\mathrm{D\_X} \, \mathrm{grad\_F}^T$ in matrix notation.

    +

    Similar to the previous apply_transformation(), specialized for the case dim == spacedim where we can return a rank-2 tensor instead of the more general DerivativeForm. Each row of the result corresponds to one of the rows of D_X transformed by grad_F, equivalent to $\mathrm{D\_X} \, \mathrm{grad\_F}^T$ in matrix notation.

    Definition at line 505 of file derivative_form.h.

    @@ -322,7 +322,7 @@
    -

    Similar to the previous apply_transformation(). In matrix notation, it computes $DF2 \, DF1^{T}$. Moreover, the result of this operation $\mathbf A$ can be interpreted as a metric tensor in ${\mathbb R}^\text{spacedim}$ which corresponds to the Euclidean metric tensor in ${\mathbb R}^\text{dim}$. For every pair of vectors $\mathbf u, \mathbf v \in {\mathbb R}^\text{spacedim}$, we have:

    +

    Similar to the previous apply_transformation(). In matrix notation, it computes $DF2 \, DF1^{T}$. Moreover, the result of this operation $\mathbf A$ can be interpreted as a metric tensor in ${\mathbb R}^\text{spacedim}$ which corresponds to the Euclidean metric tensor in ${\mathbb R}^\text{dim}$. For every pair of vectors $\mathbf u, \mathbf v \in {\mathbb R}^\text{spacedim}$, we have:

    \[
   \mathbf u \cdot \mathbf A \mathbf v =
   \text{DF2}^{-1}(\mathbf u) \cdot \text{DF1}^{-1}(\mathbf v)
/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__CPP11.html differs (HTML document, ASCII text, with very long lines)
--- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__CPP11.html	2023-08-09 23:38:55.910607765 +0000
+++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__CPP11.html	2023-08-09 23:38:55.910607765 +0000
@@ -175,7 +175,7 @@
 </div><!-- fragment --><p> The macro <a class=DEAL_II_CONSTEXPR expands to constexpr if the compiler supports enough constexpr features (such as loops). If the compiler does not then this macro expands to nothing.

    Functions declared as constexpr can be evaluated at compile time. Hence code like

    constexpr double det_A = determinant(A);
    DEAL_II_HOST constexpr Number determinant(const SymmetricTensor< 2, dim, Number > &)
    -

    assuming A is declared with the constexpr specifier, will typically result in compile-time constants. This example shows the performance gains of using constexpr because here we performed an operation with $O(\text{dim}^3)$ complexity during compile time, avoiding any runtime cost.

    +

    assuming A is declared with the constexpr specifier, will typically result in compile-time constants. This example shows the performance gains of using constexpr because here we performed an operation with $O(\text{dim}^3)$ complexity during compile time, avoiding any runtime cost.

    Function Documentation

    ◆ new_thread()

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__Concepts.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__Concepts.html 2023-08-09 23:38:55.926607883 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__Concepts.html 2023-08-09 23:38:55.926607883 +0000 @@ -174,7 +174,7 @@
    template <typename VectorType>
    virtual void Tstep(VectorType &u, const VectorType &v) const =0;
    };
    -

    where these two member functions perform one step (or the transpose of such a step) of the smoothing scheme. In other words, the operations performed by these functions are $u = u - P^{-1} (A u - v)$ and $u = u - P^{-T} (A u - v)$.

    +

    where these two member functions perform one step (or the transpose of such a step) of the smoothing scheme. In other words, the operations performed by these functions are $u = u - P^{-1} (A u - v)$ and $u = u - P^{-T} (A u - v)$.

    SparsityPatternType
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__LAOperators.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__LAOperators.html 2023-08-09 23:38:56.246610273 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__LAOperators.html 2023-08-09 23:38:56.246610273 +0000 @@ -323,7 +323,7 @@
    std::function<void(Domain &, const Range &)> Tvmult;
    std::function<void(Domain &, const Range &)> Tvmult_add;

    Thus, such an object can be used as a matrix object in all iterative solver classes, either as a matrix object, or as preconditioner.

    -

    The big advantage of the LinearOperator class is that it provides syntactic sugar for complex matrix-vector operations. As an example consider the operation $(A+k\,B)\,C$, where $A$, $B$ and $C$ denote (possibly different) SparseMatrix objects. In order to construct a LinearOperator op that performs above computation when applied on a vector, one can write:

    #href_anchor"code" href="linear__operator__tools_8h.html">deal.II/lac/linear_operator_tools.h>
    +

    The big advantage of the LinearOperator class is that it provides syntactic sugar for complex matrix-vector operations. As an example consider the operation $(A+k\,B)\,C$, where $A$, $B$ and $C$ denote (possibly different) SparseMatrix objects. In order to construct a LinearOperator op that performs above computation when applied on a vector, one can write:

    #href_anchor"code" href="linear__operator__tools_8h.html">deal.II/lac/linear_operator_tools.h>
    double k;
    @@ -375,7 +375,7 @@
    result += b;
    result -= c;
    result += d;
    -

    that avoids any intermediate storage. As a second example (involving a LinearOperator object) consider the computation of a residual $b-Ax$:

    +

    that avoids any intermediate storage. As a second example (involving a LinearOperator object) consider the computation of a residual $b-Ax$:

    ::SparseMatrix<double> A;
    ::Vector<double> b, x;
    // ..
    @@ -623,8 +623,8 @@
    -

    Addition of two linear operators first_op and second_op given by $(\mathrm{first\_op}+\mathrm{second\_op})x \dealcoloneq \mathrm{first\_op}(x)
-+ \mathrm{second\_op}(x)$

    +

    Addition of two linear operators first_op and second_op given by $(\mathrm{first\_op}+\mathrm{second\_op})x \dealcoloneq \mathrm{first\_op}(x)
++ \mathrm{second\_op}(x)$

    Definition at line 390 of file linear_operator.h.

    @@ -655,8 +655,8 @@
    -

    Subtraction of two linear operators first_op and second_op given by $(\mathrm{first\_op}-\mathrm{second\_op})x \dealcoloneq \mathrm{first\_op}(x)
-- \mathrm{second\_op}(x)$

    +

    Subtraction of two linear operators first_op and second_op given by $(\mathrm{first\_op}-\mathrm{second\_op})x \dealcoloneq \mathrm{first\_op}(x)
+- \mathrm{second\_op}(x)$

    Definition at line 449 of file linear_operator.h.

    @@ -756,8 +756,8 @@
    -

    Composition of two linear operators first_op and second_op given by $(\mathrm{first\_op}*\mathrm{second\_op})x \dealcoloneq
-\mathrm{first\_op}(\mathrm{second\_op}(x))$

    +

    Composition of two linear operators first_op and second_op given by $(\mathrm{first\_op}*\mathrm{second\_op})x \dealcoloneq
+\mathrm{first\_op}(\mathrm{second\_op}(x))$

    Definition at line 587 of file linear_operator.h.

    @@ -1571,7 +1571,7 @@
    -

    Create a PackagedOperation object from a LinearOperator and a reference to a vector u of the Domain space. The object stores the PackagedOperation $\text{op} \,u$ (in matrix notation). return (return_add) are implemented with vmult(__1,u) (vmult_add(__1,u)).

    +

    Create a PackagedOperation object from a LinearOperator and a reference to a vector u of the Domain space. The object stores the PackagedOperation $\text{op} \,u$ (in matrix notation). return (return_add) are implemented with vmult(__1,u) (vmult_add(__1,u)).

    The PackagedOperation object that is created stores a reference to u. Thus, the vector must remain a valid reference for the whole lifetime of the PackagedOperation object. All changes made on u after the creation of the PackagedOperation object are reflected by the operator object.

    Definition at line 669 of file packaged_operation.h.

    @@ -1603,7 +1603,7 @@
    -

    Create a PackagedOperation object from a LinearOperator and a reference to a vector u of the Range space. The object stores the PackagedOperation $\text{op}^T \,u$ (in matrix notation). return (return_add) are implemented with Tvmult(__1,u) (Tvmult_add(__1,u)).

    +

    Create a PackagedOperation object from a LinearOperator and a reference to a vector u of the Range space. The object stores the PackagedOperation $\text{op}^T \,u$ (in matrix notation). return (return_add) are implemented with Tvmult(__1,u) (Tvmult_add(__1,u)).

    The PackagedOperation object that is created stores a reference to u. Thus, the vector must remain a valid reference for the whole lifetime of the PackagedOperation object. All changes made on u after the creation of the PackagedOperation object are reflected by the operator object.

    Definition at line 704 of file packaged_operation.h.

    @@ -1635,7 +1635,7 @@
    -

    Composition of a PackagedOperation object with a LinearOperator. The object stores the computation $\text{op} \,comp$ (in matrix notation).

    +

    Composition of a PackagedOperation object with a LinearOperator. The object stores the computation $\text{op} \,comp$ (in matrix notation).

    Definition at line 731 of file packaged_operation.h.

    @@ -1666,7 +1666,7 @@
    -

    Composition of a PackagedOperation object with a LinearOperator. The object stores the computation $\text{op}^T \,comp$ (in matrix notation).

    +

    Composition of a PackagedOperation object with a LinearOperator. The object stores the computation $\text{op}^T \,comp$ (in matrix notation).

    Definition at line 775 of file packaged_operation.h.

    @@ -1710,7 +1710,7 @@

    Return a LinearOperator that performs the operations associated with the Schur complement. There are two additional helper functions, condense_schur_rhs() and postprocess_schur_solution(), that are likely necessary to be used in order to perform any useful tasks in linear algebra with this operator.

    We construct the definition of the Schur complement in the following way:

    Consider a general system of linear equations that can be decomposed into two major sets of equations:

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
 \mathbf{K}\mathbf{d} = \mathbf{f}
 \quad \Rightarrow\quad
 \left(\begin{array}{cc}
@@ -1723,60 +1723,60 @@
 \left(\begin{array}{cc}
    f \\ g
 \end{array}\right),
-\end{eqnarray*} +\end{eqnarray*}" src="form_1852.png"/>

    -

    where $ A,B,C,D $ represent general subblocks of the matrix $ \mathbf{K} $ and, similarly, general subvectors of $ \mathbf{d},\mathbf{f} $ are given by $ x,y,f,g $ .

    +

    where $ A,B,C,D $ represent general subblocks of the matrix $ \mathbf{K} $ and, similarly, general subvectors of $ \mathbf{d},\mathbf{f} $ are given by $ x,y,f,g $ .

    This is equivalent to the following two statements:

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   (1) \quad Ax + By &=& f \\
   (2) \quad Cx + Dy &=& g \quad .
-\end{eqnarray*} +\end{eqnarray*}" src="form_1857.png"/>

    -

    Assuming that $ A,D $ are both square and invertible, we could then perform one of two possible substitutions,

    -\begin{eqnarray*}
+<p>Assuming that <picture><source srcset=$ A,D $ are both square and invertible, we could then perform one of two possible substitutions,

    +\begin{eqnarray*}
   (3) \quad x &=& A^{-1}(f - By) \quad \text{from} \quad (1) \\
   (4) \quad y &=& D^{-1}(g - Cx) \quad \text{from} \quad (2) ,
-\end{eqnarray*} +\end{eqnarray*}" src="form_1859.png"/>

    which amount to performing block Gaussian elimination on this system of equations.

    For the purpose of the current implementation, we choose to substitute (3) into (2)

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   C \: A^{-1}(f - By) + Dy &=& g \\
   -C \: A^{-1} \: By + Dy &=& g - C \: A^{-1} \: f \quad .
-\end{eqnarray*} +\end{eqnarray*}" src="form_1860.png"/>

    This leads to the result

    -\[
+<picture><source srcset=\[
   (5) \quad (D - C\: A^{-1} \:B)y  = g - C \: A^{-1} f
       \quad \Rightarrow \quad Sy = g'
-\] +\]" src="form_1861.png"/>

    -

    with $ S = (D - C\: A^{-1} \:B) $ being the Schur complement and the modified right-hand side vector $ g' = g - C \: A^{-1} f $ arising from the condensation step. Note that for this choice of $ S $, submatrix $ D $ need not be invertible and may thus be the null matrix. Ideally $ A $ should be well-conditioned.

    -

    So for any arbitrary vector $ a $, the Schur complement performs the following operation:

    -\[
+<p> with <picture><source srcset=$ S = (D - C\: A^{-1} \:B) $ being the Schur complement and the modified right-hand side vector $ g' = g - C \: A^{-1} f $ arising from the condensation step. Note that for this choice of $ S $, submatrix $ D $ need not be invertible and may thus be the null matrix. Ideally $ A $ should be well-conditioned.

    +

    So for any arbitrary vector $ a $, the Schur complement performs the following operation:

    +\[
   (6) \quad Sa = (D - C \: A^{-1} \: B)a
-\] +\]" src="form_1868.png"/>

    A typical set of steps needed the solve a linear system (1),(2) would be:

    1. Define the inverse matrix A_inv (using inverse_operator()).
    2. -
    3. Define the Schur complement $ S $ (using schur_complement()).
    4. -
    5. Define iterative inverse matrix $ S^{-1} $ such that (6) holds. It is necessary to use a solver with a preconditioner to compute the approximate inverse operation of $ S $ since we never compute $ S $ directly, but rather the result of its operation. To achieve this, one may again use the inverse_operator() in conjunction with the Schur complement that we've just constructed. Observe that the both $ S $ and its preconditioner operate over the same space as $ D $.
    6. +
    7. Define the Schur complement $ S $ (using schur_complement()).
    8. +
    9. Define iterative inverse matrix $ S^{-1} $ such that (6) holds. It is necessary to use a solver with a preconditioner to compute the approximate inverse operation of $ S $ since we never compute $ S $ directly, but rather the result of its operation. To achieve this, one may again use the inverse_operator() in conjunction with the Schur complement that we've just constructed. Observe that the both $ S $ and its preconditioner operate over the same space as $ D $.
    10. Perform pre-processing step on the RHS of (5) using condense_schur_rhs():

      -\[
+<picture><source srcset=\[
      g' = g - C \: A^{-1} \: f
-   \] + \]" src="form_1870.png"/>

    11. -
    12. Solve for $ y $ in (5):

      -\[
+<li>Solve for <picture><source srcset=$ y $ in (5):

      +\[
      y =  S^{-1} g'
-   \] + \]" src="form_1872.png"/>

    13. Perform the post-processing step from (3) using postprocess_schur_solution():

      -\[
+<picture><source srcset=\[
      x =  A^{-1} (f - By)
-   \] + \]" src="form_1873.png"/>

    @@ -1822,10 +1822,10 @@
    LinearOperator< Domain, Range, Payload > inverse_operator(const LinearOperator< Range, Domain, Payload > &op, Solver &solver, const Preconditioner &preconditioner)
    PackagedOperation< Domain_1 > postprocess_schur_solution(const LinearOperator< Range_1, Domain_1, Payload > &A_inv, const LinearOperator< Range_1, Domain_2, Payload > &B, const Domain_2 &y, const Range_1 &f)
    -

    In the above example, the preconditioner for $ S $ was defined as the preconditioner for $ D $, which is valid since they operate on the same space. However, if $ D $ and $ S $ are too dissimilar, then this may lead to a large number of solver iterations as $ \text{prec}(D) $ is not a good approximation for $ S^{-1} $.

    -

    A better preconditioner in such a case would be one that provides a more representative approximation for $ S^{-1} $. One approach is shown in step-22, where $ D $ is the null matrix and the preconditioner for $ S^{-1}
-$ is derived from the mass matrix over this space.

    -

    From another viewpoint, a similar result can be achieved by first constructing an object that represents an approximation for $ S $ wherein expensive operation, namely $ A^{-1} $, is approximated. Thereafter we construct the approximate inverse operator $ \tilde{S}^{-1} $ which is then used as the preconditioner for computing $ S^{-1} $.

    // Construction of approximate inverse of Schur complement
    +

    In the above example, the preconditioner for $ S $ was defined as the preconditioner for $ D $, which is valid since they operate on the same space. However, if $ D $ and $ S $ are too dissimilar, then this may lead to a large number of solver iterations as $ \text{prec}(D) $ is not a good approximation for $ S^{-1} $.

    +

    A better preconditioner in such a case would be one that provides a more representative approximation for $ S^{-1} $. One approach is shown in step-22, where $ D $ is the null matrix and the preconditioner for $ S^{-1}
+$ is derived from the mass matrix over this space.

    +

    From another viewpoint, a similar result can be achieved by first constructing an object that represents an approximation for $ S $ wherein expensive operation, namely $ A^{-1} $, is approximated. Thereafter we construct the approximate inverse operator $ \tilde{S}^{-1} $ which is then used as the preconditioner for computing $ S^{-1} $.

    // Construction of approximate inverse of Schur complement
    const auto A_inv_approx = linear_operator(preconditioner_A);
    const auto S_approx = schur_complement(A_inv_approx,B,C,D);
    @@ -1848,8 +1848,8 @@
    // Solve for y
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__UpdateFlags.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__UpdateFlags.html 2023-08-09 23:38:56.266610423 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__UpdateFlags.html 2023-08-09 23:38:56.266610423 +0000 @@ -123,7 +123,7 @@ w_q, \]" src="form_272.png"/>

    - where $q$ indicates the index of the quadrature point, $\hat{\bf x}_q$ its location on the reference cell, and $w_q$ its weight. + where $q$ indicates the index of the quadrature point, $\hat{\bf x}_q$ its location on the reference cell, and $w_q$ its weight.

    In order to evaluate such an expression in an application code, we have to access three different kinds of objects: a quadrature object that describes locations $\hat{\bf x}_q$ and weights $w_q$ of quadrature points on the reference cell; a finite element object that describes the gradients $\hat\nabla \varphi_i(\hat{\bf x}_q)$ of shape functions on the unit cell; and a mapping object that provides the Jacobian as well as its determinant. Dealing with all these objects would be cumbersome and error prone.

    On the other hand, these three kinds of objects almost always appear together, and it is in fact very rare for deal.II application codes to do anything with quadrature, finite element, or mapping objects besides using them together. For this reason, deal.II uses the FEValues abstraction combining information on the shape functions, the geometry of the actual mesh cell and a quadrature rule on a reference cell. Upon construction it takes one object of each of the three mentioned categories. Later, it can be "re-initialized" for a concrete grid cell and then provides mapped quadrature points and weights, mapped shape function values and derivatives as well as some properties of the transformation from the reference cell to the actual mesh cell.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__auto__symb__diff.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__auto__symb__diff.html 2023-08-09 23:38:56.294610632 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__auto__symb__diff.html 2023-08-09 23:38:56.294610632 +0000 @@ -101,7 +101,7 @@ &#href_anchor"memitem:namespaceDifferentiation_1_1SD">namespace  Differentiation::SD &#href_anchor"details" id="details">

    Detailed Description

    A module dedicated to the implementation of functions and classes that relate to automatic and symbolic differentiation.

    -

    Below we provide a very brief introduction as to what automatic and symbolic differentiation are, what variations of these computational/numerical schemes exist, and how they are integrated within deal.II's framework. The purpose of all of these schemes is to automatically compute the derivative of functions, or approximations of it, in cases where one does not want to compute them by hand. Common examples are situations in the finite element context is where one wants to solve a nonlinear problem that is given by requiring that some residual $F(u,\nabla u)=0$ where $F$ is a complicated function that needs to be differentiated to apply Newton's method; and situations where one is given a parameter dependent problem ${\cal A}(q,u,\nabla u) = f$ and wants to form derivatives with regards to the parameters $q$, for example to optimize an output functional with regards to $q$, or for a sensitivity analysis with regards to $q$. One should think of $q$ as design parameters: say, the width or shape of a wing, the stiffness coefficients of a material chosen to build an object, the power sent to a device, the chemical composition of the gases sent to a burner. In all of these cases, one should think of $F$ and $\cal A$ as complicated and cumbersome to differentiate – at least when doing it by hand. A relatively simple case of a nonlinear problem that already highlights the tedium of computing derivatives by hand is shown in step-15. However, in reality, one might, for example, think about problems such as chemically reactive flows where the fluid equations have coefficients such as the density and viscosity that depend strongly and nonlinearly on the chemical composition, temperature, and pressure of the fluid at each point; and where the chemical species react with each other based on reaction coefficients that also depend nonlinearly and in complicated ways on the chemical composition, temperature, and pressure. In many cases, the exact formulas for all of these coefficients can take several lines to write out, may include exponentials and (harmonic or geometric) averages of several nonlinear terms, and/or may contain table lookup of and interpolation between data points. Just getting these terms right is difficult enough; computing derivatives of these terms is impractical in most applications and, in reality, impossible to get right. Higher derivatives are even more impossible to do without computer aid. Automatic or symbolic differentiation is a way out of this: One only has to implement the function that computes these coefficients in terms of their inputs only once, and gets the (correct!) derivatives without further coding effort (though at a non-negligible computational cost either at run time, compile time, or both).

    +

    Below we provide a very brief introduction as to what automatic and symbolic differentiation are, what variations of these computational/numerical schemes exist, and how they are integrated within deal.II's framework. The purpose of all of these schemes is to automatically compute the derivative of functions, or approximations of it, in cases where one does not want to compute them by hand. Common examples are situations in the finite element context is where one wants to solve a nonlinear problem that is given by requiring that some residual $F(u,\nabla u)=0$ where $F$ is a complicated function that needs to be differentiated to apply Newton's method; and situations where one is given a parameter dependent problem ${\cal A}(q,u,\nabla u) = f$ and wants to form derivatives with regards to the parameters $q$, for example to optimize an output functional with regards to $q$, or for a sensitivity analysis with regards to $q$. One should think of $q$ as design parameters: say, the width or shape of a wing, the stiffness coefficients of a material chosen to build an object, the power sent to a device, the chemical composition of the gases sent to a burner. In all of these cases, one should think of $F$ and $\cal A$ as complicated and cumbersome to differentiate – at least when doing it by hand. A relatively simple case of a nonlinear problem that already highlights the tedium of computing derivatives by hand is shown in step-15. However, in reality, one might, for example, think about problems such as chemically reactive flows where the fluid equations have coefficients such as the density and viscosity that depend strongly and nonlinearly on the chemical composition, temperature, and pressure of the fluid at each point; and where the chemical species react with each other based on reaction coefficients that also depend nonlinearly and in complicated ways on the chemical composition, temperature, and pressure. In many cases, the exact formulas for all of these coefficients can take several lines to write out, may include exponentials and (harmonic or geometric) averages of several nonlinear terms, and/or may contain table lookup of and interpolation between data points. Just getting these terms right is difficult enough; computing derivatives of these terms is impractical in most applications and, in reality, impossible to get right. Higher derivatives are even more impossible to do without computer aid. Automatic or symbolic differentiation is a way out of this: One only has to implement the function that computes these coefficients in terms of their inputs only once, and gets the (correct!) derivatives without further coding effort (though at a non-negligible computational cost either at run time, compile time, or both).

    Automatic differentiation

    Automatic differentiation (commonly also referred to as algorithmic differentiation), is a numerical method that can be used to "automatically" compute the first, and perhaps higher-order, derivatives of function(s) with respect to one or more input variables. Although this comes at a certain computational cost, the benefits to using such a tool may be significant. When used correctly the derivatives of often complicated functions can be computed to a very high accuracy. Although the exact accuracy achievable by these frameworks largely depends on their underlying mathematical formulation, some implementations compute with a precision on the order of machine accuracy. Note that this is different to classical numerical differentiation (using, for example, a finite difference approximation of a function by evaluating it at different points), which has an accuracy that depends on both the perturbation size as well as the chosen finite-difference scheme; the error of these methods is measurably larger than well-formulated automatic differentiation approaches.

    @@ -149,38 +149,38 @@
  • reverse-mode (or reverse accumulation) auto-differentiation.
  • As a point of interest, the optimal Jacobian accumulation, which performs a minimal set of computations, lies somewhere between these two limiting cases. Its computation for a general composite function remains an open problem in graph theory.

    -

    With the aid of the diagram below (it and some of the listed details courtesy of this Wikipedia article), let us think about the representation of the calculation of the function $f (\mathbf{x}) = \sin (x_{1}) + x_{1} x_{2}$ and its derivatives:

    -
    Forward mode automatic differentiation
    Forward mode automatic differentiation
    Reverse mode automatic differentiation
    Reverse mode automatic differentiation

    Specifically, we will briefly describe what forward and reverse auto-differentiation are. Note that in the diagram, along the edges of the graph in text are the directional derivative of function $w$ with respect to the $i$-th variable, represented by the notation $\dot{w} = \dfrac{d w}{d x_{i}}$. The specific computations used to render the function value and its directional derivatives for this example are tabulated in the source article. For a second illustrative example, we refer the interested reader to this article.

    -

    Consider first that any composite function $f(x)$, here represented as having two independent variables, can be dissected into a composition of its elementary functions

    -\[
+<p>With the aid of the diagram below (it and some of the listed details courtesy of this <a href=Wikipedia article), let us think about the representation of the calculation of the function $f (\mathbf{x}) = \sin (x_{1}) + x_{1} x_{2}$ and its derivatives:

    +
    Forward mode automatic differentiation
    Forward mode automatic differentiation
    Reverse mode automatic differentiation
    Reverse mode automatic differentiation

    Specifically, we will briefly describe what forward and reverse auto-differentiation are. Note that in the diagram, along the edges of the graph in text are the directional derivative of function $w$ with respect to the $i$-th variable, represented by the notation $\dot{w} = \dfrac{d w}{d x_{i}}$. The specific computations used to render the function value and its directional derivatives for this example are tabulated in the source article. For a second illustrative example, we refer the interested reader to this article.

    +

    Consider first that any composite function $f(x)$, here represented as having two independent variables, can be dissected into a composition of its elementary functions

    +\[
   f (\mathbf{x})
   = f_{0} \circ f_{1} \circ f_{2} \circ \ldots \circ f_{n} (\mathbf{x})
   \quad .
-\] +\]" src="form_10.png"/>

    -

    As was previously mentioned, if each of the primitive operations $f_{n}$ is smooth and differentiable, then the chain-rule can be universally employed to compute the total derivative of $f$, namely $\dfrac{d f(x)}{d \mathbf{x}}$. What distinguishes the "forward" from the "reverse" mode is how the chain-rule is evaluated, but ultimately both compute the total derivative

    -\[
+<p> As was previously mentioned, if each of the primitive operations <picture><source srcset=$f_{n}$ is smooth and differentiable, then the chain-rule can be universally employed to compute the total derivative of $f$, namely $\dfrac{d f(x)}{d \mathbf{x}}$. What distinguishes the "forward" from the "reverse" mode is how the chain-rule is evaluated, but ultimately both compute the total derivative

    +\[
   \dfrac{d f (\mathbf{x})}{d \mathbf{x}}
   = \dfrac{d f_{0}}{d f_{1}} \dfrac{d f_{1}}{d f_{2}} \dfrac{d f_{2}}{d f_{3}} \ldots \dfrac{d f_{n} (\mathbf{x})}{d \mathbf{x}}
   \quad .
-\] +\]" src="form_14.png"/>

    -

    In forward-mode, the chain-rule is computed naturally from the "inside out". The independent variables are therefore fixed, and each sub-function $f'_{i} \vert_{f'_{i+1}}$ is computed recursively and its result returned as inputs to the parent function. Encapsulating and fixing the order of operations using parentheses, this means that we compute

    -\[
+<p>In forward-mode, the chain-rule is computed naturally from the $f'_{i} \vert_{f'_{i+1}}$ is computed recursively and its result returned as inputs to the parent function. Encapsulating and fixing the order of operations using parentheses, this means that we compute

    +\[
   \dfrac{d f (\mathbf{x})}{d \mathbf{x}}
   = \dfrac{d f_{0}}{d f_{1}} \left( \dfrac{d f_{1}}{d f_{2}} \left(\dfrac{d f_{2}}{d f_{3}} \left(\ldots \left( \dfrac{d f_{n} (\mathbf{x})}{d \mathbf{x}} \right)\right)\right)\right)
   \quad .
-\] +\]" src="form_16.png"/>

    The computational complexity of a forward-sweep is proportional to that of the input function. However, for each directional derivative that is to be computed one sweep of the computational graph is required.

    In reverse-mode, the chain-rule is computed somewhat unnaturally from the "outside in". The values of the dependent variables first get computed and fixed, and then the preceding differential operations are evaluated and multiplied in succession with the previous results from left to right. Again, if we encapsulate and fix the order of operations using parentheses, this implies that the reverse calculation is performed by

    -\[
+<picture><source srcset=\[
 \dfrac{d f (\mathbf{x})}{d \mathbf{x}}
   = \left( \left( \left( \left( \left( \dfrac{d f_{0}}{d f_{1}} \right) \dfrac{d f_{1}}{d f_{2}} \right) \dfrac{d f_{2}}{d f_{3}} \right) \ldots \right) \dfrac{d f_{n} (\mathbf{x})}{d \mathbf{x}} \right)
   \quad .
-\] +\]" src="form_17.png"/>

    -

    The intermediate values $\dfrac{d f_{i-1}}{d f_{i}}$ are known as adjoints, which must be computed and stored as the computational graph is traversed. However, for each dependent scalar function one sweep of the computational graph renders all directional derivatives at once.

    +

    The intermediate values $\dfrac{d f_{i-1}}{d f_{i}}$ are known as adjoints, which must be computed and stored as the computational graph is traversed. However, for each dependent scalar function one sweep of the computational graph renders all directional derivatives at once.

    Overall, the efficiency of each mode is determined by the number of independent (input) variables and dependent (output) variables. If the outputs greatly exceed the inputs in number, then forward-mode can be shown to be more efficient than reverse-mode. The converse is true when the number of input variables greatly exceeds that of the output variables. This point may be used to help inform which number type is most suitable for which set of operations are to be performed using automatic differentiation. For example, in many applications for which second derivatives are to be computed it is appropriate to combine both reverse- and forward-modes. The former would then typically be used to calculate the first derivatives, and the latter the second derivatives.

    Supported automatic differentiation libraries

    @@ -328,7 +328,7 @@

    Symbolic expressions and differentiation

    Symbolic differentiation is, in terms of its design and usage, quite different to automatic differentiation. Underlying any symbolic library is a computer algebra system (CAS) that implements a language and collection of algorithms to manipulate symbolic (or "string-like") expressions. This is most similar, from a philosophical point of view, to how algebraic operations would be performed by hand.

    -

    To help better distinguish between symbolic differentiation and numerical methods like automatic differentiation, let's consider a very simple example. Suppose that the function $f(x,y) = [2x+1]^{y}$, where $x$ and $y$ are variables that are independent of one another. By applying the chain-rule, the derivatives of this function are simply $\dfrac{d f(x,y)}{d x} = 2y[2x+1]^{y-1}$ and $\dfrac{d f(x,y)}{d y} = [2x+1]^{y} \ln(2x+1)$. These are exactly the results that you get from a CAS after defining the symbolic variables x and y, defining the symbolic expression f = pow(2x+1, y) and computing the derivatives diff(f, x) and diff(f, y). At this point there is no assumption of what x and y represent; they may later be interpreted as plain (scalar) numbers, complex numbers, or something else for which the power and natural logarithm functions are well defined. Obviously this means that there is also no assumption about which point to evaluate either the expression or its derivatives. One could readily take the expression for $\dfrac{d f(x, y)}{d x}$ and evaluate it at $x=1, y=2.5$ and then later, with no recomputation of the derivative expression itself, evaluate it at $x=3.25, y=-6$. In fact, the interpretation of any symbolic variable or expression, and the inter-dependencies between variables, may be defined or redefined at any point during their manipulation; this leads to a degree of flexibility in computations that cannot be matched by auto-differentiation. For example, one could perform the permanent substitution $g(x) = \dfrac{d f(x, y)}{d x} \vert_{y=1}$ and then recompute $g(x)$ for several different values of $x$. One could also post-factum express an interdependency between x and y, such as $y \rightarrow y(x) := 2x$. For such a case, this means that the initially computed derivatives $\dfrac{d f(x, y)}{d x} \rightarrow \dfrac{\partial f(x, y(x))}{\partial x} = 2y(x) [2x+1]^{y(x)-1} = 4x[2x+1]^{2x-1}$ and $\dfrac{d f(x, y)}{d y} \rightarrow \dfrac{\partial f(x, y(x))}{\partial y} = [2x+1]^{y(x)} \ln(2x+1) = [2x+1]^{2x} \ln(2x+1)$ truly represent partial derivatives rather than total derivatives. Of course, if such an inter-dependency was explicitly defined before the derivatives $\dfrac{d f(x, y(x))}{d x}$ and $\dfrac{d f(x, y(x))}{d y}$ are computed, then this could correspond to the total derivative (which is the only result that auto-differentiation is able to achieve for this example).

    +

    To help better distinguish between symbolic differentiation and numerical methods like automatic differentiation, let's consider a very simple example. Suppose that the function $f(x,y) = [2x+1]^{y}$, where $x$ and $y$ are variables that are independent of one another. By applying the chain-rule, the derivatives of this function are simply $\dfrac{d f(x,y)}{d x} = 2y[2x+1]^{y-1}$ and $\dfrac{d f(x,y)}{d y} = [2x+1]^{y} \ln(2x+1)$. These are exactly the results that you get from a CAS after defining the symbolic variables x and y, defining the symbolic expression f = pow(2x+1, y) and computing the derivatives diff(f, x) and diff(f, y). At this point there is no assumption of what x and y represent; they may later be interpreted as plain (scalar) numbers, complex numbers, or something else for which the power and natural logarithm functions are well defined. Obviously this means that there is also no assumption about which point to evaluate either the expression or its derivatives. One could readily take the expression for $\dfrac{d f(x, y)}{d x}$ and evaluate it at $x=1, y=2.5$ and then later, with no recomputation of the derivative expression itself, evaluate it at $x=3.25, y=-6$. In fact, the interpretation of any symbolic variable or expression, and the inter-dependencies between variables, may be defined or redefined at any point during their manipulation; this leads to a degree of flexibility in computations that cannot be matched by auto-differentiation. For example, one could perform the permanent substitution $g(x) = \dfrac{d f(x, y)}{d x} \vert_{y=1}$ and then recompute $g(x)$ for several different values of $x$. One could also post-factum express an interdependency between x and y, such as $y \rightarrow y(x) := 2x$. For such a case, this means that the initially computed derivatives $\dfrac{d f(x, y)}{d x} \rightarrow \dfrac{\partial f(x, y(x))}{\partial x} = 2y(x) [2x+1]^{y(x)-1} = 4x[2x+1]^{2x-1}$ and $\dfrac{d f(x, y)}{d y} \rightarrow \dfrac{\partial f(x, y(x))}{\partial y} = [2x+1]^{y(x)} \ln(2x+1) = [2x+1]^{2x} \ln(2x+1)$ truly represent partial derivatives rather than total derivatives. Of course, if such an inter-dependency was explicitly defined before the derivatives $\dfrac{d f(x, y(x))}{d x}$ and $\dfrac{d f(x, y(x))}{d y}$ are computed, then this could correspond to the total derivative (which is the only result that auto-differentiation is able to achieve for this example).

    Due to the sophisticated CAS that forms the foundation of symbolic operations, the types of manipulations are not necessarily restricted to differentiation alone, but rather may span a spectrum of manipulations relevant to discrete differential calculus, topics in pure mathematics, and more. The documentation for the SymPy library gives plenty of examples that highlight what a fully-fledged CAS is capable of. Through the Differentiation::SD::Expression class, and the associated functions in the Differentiation::SD namespace, we provide a wrapper to the high-performance SymEngine symbolic manipulation library that has enriched operator overloading and a consistent interface that makes it easy and "natural" to use. In fact, this class can be used as a "drop-in" replacement for arithmetic types in many situations, transforming the operations from being numeric to symbolic in nature; this is made especially easy when classes are templated on the underlying number type. Being focused on numerical simulation of PDEs, the functionality of the CAS that is exposed within deal.II focuses on symbolic expression creation, manipulation, and differentiation.

    The convenience wrappers to SymEngine functionality are primarily focused on manipulations that solely involve dictionary-based (i.e., something reminiscent of "string-based") operations. Although SymEngine performs these operations in an efficient manner, they are still known to be computationally expensive, especially when the operations are performed on large expressions. It should therefore be expected that the performance of the parts of code that perform differentiation, symbolic substitution, etc., may be a limiting factor when using this in production code. deal.II therefore provides an interface to accelerate the evaluation of lengthy symbolic expression through the BatchOptimizer class (itself often leveraging functionality provided by SymEngine). In particular, the BatchOptimizer simultaneously optimizes a collection of symbolic expressions using methods such as common subexpression elimination (CSE), as well as by generating high performance code-paths to evaluate these expressions through the use of a custom-generated std::function or by compiling the expression using the LLVM JIT compiler. The usage of the Differentiation::SD::BatchOptimizer class is exemplified in step-71.

    As a final note, it is important to recognize the remaining major deficiencies in deal.II's current implementation of the interface to the supported symbolic library. The level of functionality currently implemented effectively limits the use of symbolic algebra to the traditional use case (i.e. scalar and tensor algebra, as might be useful to define constitutive relations or complex functions for application as boundary conditions or source terms). In fact, step-71 demonstrates how it can be used to implement challenging constitutive models. In the future we will also implement classes to assist in performing assembly operations in the same spirit as that which has been done in the Differentiation::AD namespace.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__constraints.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__constraints.html 2023-08-09 23:38:56.358611109 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__constraints.html 2023-08-09 23:38:56.358611109 +0000 @@ -205,22 +205,22 @@

    Detailed Description

    This module deals with constraints on degrees of freedom. The central class to deal with constraints is the AffineConstraints class.

    Constraints typically come from several sources, for example:

    -

    In all of these examples, constraints on degrees of freedom are linear and possibly inhomogeneous. In other words, they always have the form $x_{i_1} = \sum_{j=2}^M a_{i_j} x_{i_j} + b_i$. The deal.II class that deals with storing and using these constraints is AffineConstraints.

    +

    In all of these examples, constraints on degrees of freedom are linear and possibly inhomogeneous. In other words, they always have the form $x_{i_1} = \sum_{j=2}^M a_{i_j} x_{i_j} + b_i$. The deal.II class that deals with storing and using these constraints is AffineConstraints.

    Eliminating constraints

    When building the global system matrix and the right hand sides, one can build them without taking care of the constraints, i.e. by simply looping over cells and adding the local contributions to the global matrix and right hand side objects. In order to do actual calculations, you have to 'condense' the linear system: eliminate constrained degrees of freedom and distribute the appropriate values to the unconstrained dofs. This changes the sparsity pattern of the sparse matrices used in finite element calculations and is thus a quite expensive operation. The general scheme of things is then that you build your system, you eliminate (condense) away constrained nodes using the AffineConstraints::condense() functions, then you solve the remaining system, and finally you compute the values of constrained nodes from the values of the unconstrained ones using the AffineConstraints::distribute() function. Note that the AffineConstraints::condense() function is applied to matrix and right hand side of the linear system, while the AffineConstraints::distribute() function is applied to the solution vector.

    This scheme of first building a linear system and then eliminating constrained degrees of freedom is inefficient, and a bottleneck if there are many constraints and matrices are full, i.e. especially for 3d and/or higher order or hp-finite elements. Furthermore, it is impossible to implement for parallel computations where a process may not have access to elements of the matrix. We therefore offer a second way of building linear systems, using the AffineConstraints::add_entries_local_to_global() and AffineConstraints::distribute_local_to_global() functions discussed below. The resulting linear systems are equivalent to those one gets after calling the AffineConstraints::condense() functions.

    @@ -271,23 +271,23 @@
  • Depending on the solver now you have to apply the AffineConstraints::distribute() function to the solution, because the solver could change the constrained values in the solution. For a Krylov based solver this should not be strictly necessary, but it is still possible that there is a difference between the inhomogeneous value and the solution value in the order of machine precision, and you may want to call AffineConstraints::distribute() anyway if you have additional constraints such as from hanging nodes.
  • Of course, both approaches lead to the same final answer but in different ways. Using the first approach (i.e., when using use_inhomogeneities_for_rhs = false in AffineConstraints::distribute_local_to_global()), the linear system we build has zero entries in the right hand side in all those places where a degree of freedom is constrained, and some positive value on the matrix diagonal of these lines. Consequently, the solution vector of the linear system will have a zero value for inhomogeneously constrained degrees of freedom and we need to call AffineConstraints::distribute() to give these degrees of freedom their correct nonzero values.

    -

    On the other hand, in the second approach, the matrix diagonal element and corresponding right hand side entry for inhomogeneously constrained degrees of freedom are so that the solution of the linear system already has the correct value (e.g., if the constraint is that $x_{13}=42$ then row $13$ if the matrix is empty with the exception of the diagonal entry, and $b_{13}/A_{13,13}=42$ so that the solution of $Ax=b$ must satisfy $x_{13}=42$ as desired). As a consequence, we do not need to call AffineConstraints::distribute() after solving to fix up inhomogeneously constrained components of the solution, though there is also no harm in doing so.

    +

    On the other hand, in the second approach, the matrix diagonal element and corresponding right hand side entry for inhomogeneously constrained degrees of freedom are so that the solution of the linear system already has the correct value (e.g., if the constraint is that $x_{13}=42$ then row $13$ if the matrix is empty with the exception of the diagonal entry, and $b_{13}/A_{13,13}=42$ so that the solution of $Ax=b$ must satisfy $x_{13}=42$ as desired). As a consequence, we do not need to call AffineConstraints::distribute() after solving to fix up inhomogeneously constrained components of the solution, though there is also no harm in doing so.

    There remains the question of which of the approaches to take and why we need to set to zero the values of the solution vector in the first approach. The answer to both questions has to do with how iterative solvers solve the linear system. To this end, consider that we typically stop iterations when the residual has dropped below a certain fraction of the norm of the right hand side, or, alternatively, a certain fraction of the norm of the initial residual. Now consider this:

    -

    In addition to these considerations, consider the case where we have inhomogeneous constraints of the kind $x_{3}=\tfrac 12 x_1 + \tfrac 12$, e.g., from a hanging node constraint of the form $x_{3}=\tfrac 12 (x_1 +
-x_2)$ where $x_2$ is itself constrained by boundary values to $x_2=1$. In this case, the AffineConstraints container can of course not figure out what the final value of $x_3$ should be and, consequently, can not set the solution vector's third component correctly. Thus, the second approach will not work and you should take the first.

    +

    In addition to these considerations, consider the case where we have inhomogeneous constraints of the kind $x_{3}=\tfrac 12 x_1 + \tfrac 12$, e.g., from a hanging node constraint of the form $x_{3}=\tfrac 12 (x_1 +
+x_2)$ where $x_2$ is itself constrained by boundary values to $x_2=1$. In this case, the AffineConstraints container can of course not figure out what the final value of $x_3$ should be and, consequently, can not set the solution vector's third component correctly. Thus, the second approach will not work and you should take the first.

    Dealing with conflicting constraints

    There are situations where degrees of freedom are constrained in more than one way, and sometimes in conflicting ways. Consider, for example the following situation:

    -

    Here, degree of freedom $x_0$ marked in blue is a hanging node. If we used trilinear finite elements, i.e. FE_Q(1), then it would carry the constraint $x_0=\frac 12 (x_{1}+x_{2})$. On the other hand, it is at the boundary, and if we have imposed boundary conditions $u|_{\partial\Omega}=g$ then we will have the constraint $x_0=g_0$ where $g_0$ is the value of the boundary function $g(\mathbf x)$ at the location of this degree of freedom.

    +

    Here, degree of freedom $x_0$ marked in blue is a hanging node. If we used trilinear finite elements, i.e. FE_Q(1), then it would carry the constraint $x_0=\frac 12 (x_{1}+x_{2})$. On the other hand, it is at the boundary, and if we have imposed boundary conditions $u|_{\partial\Omega}=g$ then we will have the constraint $x_0=g_0$ where $g_0$ is the value of the boundary function $g(\mathbf x)$ at the location of this degree of freedom.

    So, which one will win? Or maybe: which one should win? There is no good answer to this question:

    That said, what should you do if you know what you want is this:

    and Id_c is the projection to the subspace consisting of all vector entries associated with constrained degrees of freedom.

    This LinearOperator object is used together with constrained_right_hand_side() to build up the following modified system of linear equations:

    -\[
+<picture><source srcset=\[
   (C^T A C + Id_c) x = C^T (b - A\,k)
-\] +\]" src="form_1616.png"/>

    -

    with a given (unconstrained) system matrix $A$, right hand side $b$, and linear constraints $C$ with inhomogeneities $k$.

    +

    with a given (unconstrained) system matrix $A$, right hand side $b$, and linear constraints $C$ with inhomogeneities $k$.

    A detailed explanation of this approach is given in the Constraints on degrees of freedom module.

    Note
    Currently, this function may not work correctly for distributed data structures.
    @@ -871,11 +871,11 @@

    with

    C = distribute_constraints_linear_operator(constraints, linop);
    Ct = transpose_operator(C);

    This LinearOperator object is used together with constrained_right_hand_side() to build up the following modified system of linear equations:

    -\[
+<picture><source srcset=\[
   (C^T A C + Id_c) x = C^T (b - A\,k)
-\] +\]" src="form_1616.png"/>

    -

    with a given (unconstrained) system matrix $A$, right hand side $b$, and linear constraints $C$ with inhomogeneities $k$.

    +

    with a given (unconstrained) system matrix $A$, right hand side $b$, and linear constraints $C$ with inhomogeneities $k$.

    A detailed explanation of this approach is given in the Constraints on degrees of freedom module.

    Note
    Currently, this function may not work correctly for distributed data structures.
    @@ -1259,27 +1259,27 @@

    This function is an updated version of the project_boundary_values_curl_conforming function. The intention is to fix a problem when using the previous function in conjunction with non- rectangular geometries (i.e. elements with non-rectangular faces). The L2-projection method used has been taken from the paper "Electromagnetic scattering simulation using an H (curl) conforming hp-finite element method in three dimensions" by PD Ledger, K Morgan and O Hassan ( Int. J. Num. Meth. Fluids, Volume 53, Issue 8, pages 1267-1296).

    -

    This function will compute constraints that correspond to Dirichlet boundary conditions of the form $\vec{n}\times\vec{E}=\vec{n}\times\vec{F}$ i.e. the tangential components of $\vec{E}$ and $f$ shall coincide.

    +

    This function will compute constraints that correspond to Dirichlet boundary conditions of the form $\vec{n}\times\vec{E}=\vec{n}\times\vec{F}$ i.e. the tangential components of $\vec{E}$ and $f$ shall coincide.

    Computing constraints

    To compute the constraints we use a projection method based upon the paper mentioned above. In 2d this is done in a single stage for the edge- based shape functions, regardless of the order of the finite element. In 3d this is done in two stages, edges first and then faces.

    -

    For each cell, each edge, $e$, is projected by solving the linear system $Ax=b$ where $x$ is the vector of constraints on degrees of freedom on the edge and

    -

    $A_{ij} = \int_{e} (\vec{s}_{i}\cdot\vec{t})(\vec{s}_{j}\cdot\vec{t}) dS$

    -

    $b_{i} = \int_{e} (\vec{s}_{i}\cdot\vec{t})(\vec{F}\cdot\vec{t}) dS$

    -

    with $\vec{s}_{i}$ the $i^{th}$ shape function and $\vec{t}$ the tangent vector.

    -

    Once all edge constraints, $x$, have been computed, we may compute the face constraints in a similar fashion, taking into account the residuals from the edges.

    -

    For each face on the cell, $f$, we solve the linear system $By=c$ where $y$ is the vector of constraints on degrees of freedom on the face and

    -

    $B_{ij} = \int_{f} (\vec{n} \times \vec{s}_{i}) \cdot (\vec{n} \times
-\vec{s}_{j}) dS$

    -

    $c_{i} = \int_{f} (\vec{n} \times \vec{r}) \cdot (\vec{n} \times
-\vec{s}_i) dS$

    -

    and $\vec{r} = \vec{F} - \sum_{e \in f} \sum{i \in e} x_{i}\vec{s}_i$, the edge residual.

    -

    The resulting constraints are then given in the solutions $x$ and $y$.

    +

    For each cell, each edge, $e$, is projected by solving the linear system $Ax=b$ where $x$ is the vector of constraints on degrees of freedom on the edge and

    +

    $A_{ij} = \int_{e} (\vec{s}_{i}\cdot\vec{t})(\vec{s}_{j}\cdot\vec{t}) dS$

    +

    $b_{i} = \int_{e} (\vec{s}_{i}\cdot\vec{t})(\vec{F}\cdot\vec{t}) dS$

    +

    with $\vec{s}_{i}$ the $i^{th}$ shape function and $\vec{t}$ the tangent vector.

    +

    Once all edge constraints, $x$, have been computed, we may compute the face constraints in a similar fashion, taking into account the residuals from the edges.

    +

    For each face on the cell, $f$, we solve the linear system $By=c$ where $y$ is the vector of constraints on degrees of freedom on the face and

    +

    $B_{ij} = \int_{f} (\vec{n} \times \vec{s}_{i}) \cdot (\vec{n} \times
+\vec{s}_{j}) dS$

    +

    $c_{i} = \int_{f} (\vec{n} \times \vec{r}) \cdot (\vec{n} \times
+\vec{s}_i) dS$

    +

    and $\vec{r} = \vec{F} - \sum_{e \in f} \sum{i \in e} x_{i}\vec{s}_i$, the edge residual.

    +

    The resulting constraints are then given in the solutions $x$ and $y$.

    If the AffineConstraints constraints contained values or other constraints before, the new ones are added or the old ones overwritten, if a node of the boundary part to be used was already in the list of constraints. This is handled by using inhomogeneous constraints. Please note that when combining adaptive meshes and this kind of constraints, the Dirichlet conditions should be set first, and then completed by hanging node constraints, in order to make sure that the discretization remains consistent. See the discussion on conflicting constraints in the module on Constraints on degrees of freedom.

    Arguments to this function

    This function is explicitly for use with FE_Nedelec elements, or with FESystem elements which contain FE_Nedelec elements. It will throw an exception if called with any other finite element. The user must ensure that FESystem elements are correctly setup when using this function as this check not possible in this case.

    -

    The second argument of this function denotes the first vector component of the finite element which corresponds to the vector function that you wish to constrain. For example, if we are solving Maxwell's equations in 3d and have components $(E_x,E_y,E_z,B_x,B_y,B_z)$ and we want the boundary conditions $\vec{n}\times\vec{B}=\vec{n}\times\vec{f}$, then first_vector_component would be 3. The boundary_function must return 6 components in this example, with the first 3 corresponding to $\vec{E}$ and the second 3 corresponding to $\vec{B}$. Vectors are implicitly assumed to have exactly dim components that are ordered in the same way as we usually order the coordinate directions, i.e. $x$-, $y$-, and finally $z$-component.

    +

    The second argument of this function denotes the first vector component of the finite element which corresponds to the vector function that you wish to constrain. For example, if we are solving Maxwell's equations in 3d and have components $(E_x,E_y,E_z,B_x,B_y,B_z)$ and we want the boundary conditions $\vec{n}\times\vec{B}=\vec{n}\times\vec{f}$, then first_vector_component would be 3. The boundary_function must return 6 components in this example, with the first 3 corresponding to $\vec{E}$ and the second 3 corresponding to $\vec{B}$. Vectors are implicitly assumed to have exactly dim components that are ordered in the same way as we usually order the coordinate directions, i.e. $x$-, $y$-, and finally $z$-component.

    The parameter boundary_component corresponds to the number boundary_id of the face. numbers::internal_face_boundary_id is an illegal value, since it is reserved for interior faces.

    -

    The last argument is denoted to compute the normal vector $\vec{n}$ at the boundary points.

    +

    The last argument is denoted to compute the normal vector $\vec{n}$ at the boundary points.

    See also
    Glossary entry on boundary indicators
    @@ -1372,11 +1372,11 @@
    -

    Compute constraints that correspond to boundary conditions of the form $\vec{n}^T\vec{u}=\vec{n}^T\vec{f}$, i.e. the normal components of the solution $u$ and a given $f$ shall coincide. The function $f$ is given by boundary_function and the resulting constraints are added to constraints for faces with boundary indicator boundary_component.

    +

    Compute constraints that correspond to boundary conditions of the form $\vec{n}^T\vec{u}=\vec{n}^T\vec{f}$, i.e. the normal components of the solution $u$ and a given $f$ shall coincide. The function $f$ is given by boundary_function and the resulting constraints are added to constraints for faces with boundary indicator boundary_component.

    This function is explicitly written to use with the FE_RaviartThomas elements. Thus it throws an exception, if it is called with other finite elements.

    If the AffineConstraints object constraints contained values or other constraints before, the new ones are added or the old ones overwritten, if a node of the boundary part to be used was already in the list of constraints. This is handled by using inhomogeneous constraints. Please note that when combining adaptive meshes and this kind of constraints, the Dirichlet conditions should be set first, and then completed by hanging node constraints, in order to make sure that the discretization remains consistent. See the discussion on conflicting constraints in the module on Constraints on degrees of freedom.

    -

    The argument first_vector_component denotes the first vector component in the finite element that corresponds to the vector function $\vec{u}$ that you want to constrain. Vectors are implicitly assumed to have exactly dim components that are ordered in the same way as we usually order the coordinate directions, i.e., $x$-, $y$-, and finally $z$-component.

    -

    The parameter boundary_component corresponds to the boundary_id of the faces where the boundary conditions are applied. numbers::internal_face_boundary_id is an illegal value, since it is reserved for interior faces. The mapping is used to compute the normal vector $\vec{n}$ at the boundary points.

    +

    The argument first_vector_component denotes the first vector component in the finite element that corresponds to the vector function $\vec{u}$ that you want to constrain. Vectors are implicitly assumed to have exactly dim components that are ordered in the same way as we usually order the coordinate directions, i.e., $x$-, $y$-, and finally $z$-component.

    +

    The parameter boundary_component corresponds to the boundary_id of the faces where the boundary conditions are applied. numbers::internal_face_boundary_id is an illegal value, since it is reserved for interior faces. The mapping is used to compute the normal vector $\vec{n}$ at the boundary points.

    Computing constraints

    To compute the constraints we use interpolation operator proposed in Brezzi, Fortin (Mixed and Hybrid Finite Element Methods, Springer, 1991) on every face located at the boundary.

    See also
    Glossary entry on boundary indicators
    @@ -1472,16 +1472,16 @@ /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__feaccess.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__feaccess.html 2023-08-09 23:38:56.386611318 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__feaccess.html 2023-08-09 23:38:56.386611318 +0000 @@ -225,7 +225,7 @@ update_quadrature_points&#href_anchor"fielddoc">

    Transformed quadrature points.

    Compute the quadrature points location in real cell coordinates.

    -

    FEValues objects take the quadrature point locations on the reference cell as an argument of the constructor (via the Quadrature object). For most finite elements, knowing the location of quadrature points on the reference cell is all that is necessary to evaluate shape functions, evaluate the mapping, and other things. On the other hand, if you want to evaluate a right hand side function $f(\mathbf x_q)$ at quadrature point locations $\mathbf x_q$ on the real cell, you need to pass this flag to the FEValues constructor to make sure you can later access them.

    +

    FEValues objects take the quadrature point locations on the reference cell as an argument of the constructor (via the Quadrature object). For most finite elements, knowing the location of quadrature points on the reference cell is all that is necessary to evaluate shape functions, evaluate the mapping, and other things. On the other hand, if you want to evaluate a right hand side function $f(\mathbf x_q)$ at quadrature point locations $\mathbf x_q$ on the real cell, you need to pass this flag to the FEValues constructor to make sure you can later access them.

    There are contexts other than FEValues (and related classes) that take update flags. An example is the DataPostprocessor class (and derived classes). In these cases, the update_quadrature_points flag is generally understood to update the location of "evaluation points", i.e., the physical locations of the points at which the solution is evaluated. As a consequence, the flag is misnamed in these contexts: No quadrature (i.e., computation of integrals) is involved, and consequently what is being updated is, in the context of DataPostprocessor, the member variable DataPostprocessorInputs::CommonInputs::evaluation_points.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__hpcollection.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__hpcollection.html 2023-08-09 23:38:56.402611438 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__hpcollection.html 2023-08-09 23:38:56.402611438 +0000 @@ -116,7 +116,7 @@ * fe_collection.push_back (FE_Q<dim>(degree)); *

    This way, one can add elements of polynomial degree 1 through 4 to the collection. It is not necessary to retain the added object: the collection makes a copy of it, it does not only store a pointer to the given finite element object. This same observation also holds for the other collection classes.

    It is customary that within an hp-finite element program, one keeps collections of finite elements and quadrature formulas with the same number of elements, each element of the one collection matching the element in the other. This is not necessary, but it often makes coding a lot simpler. If a collection of mappings is used, the same holds for hp::MappingCollection objects as well.

    -

    Whenever p-adaptivity is considered in an hp-finite element program, a hierarchy of finite elements needs to be established to determine succeeding finite elements for refinement and preceding ones for coarsening. Typically, this hierarchy considers how finite element spaces are nested: for example, a $Q_1$ element describes a sub-space of a $Q_2$ element, and so doing $p$ refinement usually means using a larger (more accurate) finite element space. In other words, the hierarchy of finite elements is built by considering whether some elements of the collection are sub- or super-spaces of others.

    +

    Whenever p-adaptivity is considered in an hp-finite element program, a hierarchy of finite elements needs to be established to determine succeeding finite elements for refinement and preceding ones for coarsening. Typically, this hierarchy considers how finite element spaces are nested: for example, a $Q_1$ element describes a sub-space of a $Q_2$ element, and so doing $p$ refinement usually means using a larger (more accurate) finite element space. In other words, the hierarchy of finite elements is built by considering whether some elements of the collection are sub- or super-spaces of others.

    By default, we assume that finite elements are stored in an ascending order based on their polynomial degree. If the order of elements differs, a corresponding hierarchy needs to be supplied to the collection via the hp::FECollection::set_hierarchy() member function.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__manifold.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__manifold.html 2023-08-09 23:38:56.430611648 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__manifold.html 2023-08-09 23:38:56.430611648 +0000 @@ -238,7 +238,7 @@

    So why does this matter? After all, the last two meshes describe the exact same domain and we know that upon mesh refinement we obtain the correct solution regardless of the choice of cells, as long as the diameter of the largest cell goes to zero.

    -

    There are two answers to this question. First, the numerical effort of solving a partial differential equation to a certain accuracy typically depends on the quality of cells since the constant $C$ in error estimates of the form $\|u-u_h\|_{H^1} \le Ch^p \|u\|_{H^{p+1}}$ depends on factors such as the maximal ratio of radii of the smallest circumscribed to largest inscribed circle over all cells (for triangles; or a suitable generalization for other types of cells). Thus, it is worthwhile creating meshes with cells that are as well-formed as possible. This is arguably not so much of an issue for the meshes shown above, but is sometimes an issue. Consider, for example, the following code and mesh:

    const Point<2> center (1,0);
    +

    There are two answers to this question. First, the numerical effort of solving a partial differential equation to a certain accuracy typically depends on the quality of cells since the constant $C$ in error estimates of the form $\|u-u_h\|_{H^1} \le Ch^p \|u\|_{H^{p+1}}$ depends on factors such as the maximal ratio of radii of the smallest circumscribed to largest inscribed circle over all cells (for triangles; or a suitable generalization for other types of cells). Thus, it is worthwhile creating meshes with cells that are as well-formed as possible. This is arguably not so much of an issue for the meshes shown above, but is sometimes an issue. Consider, for example, the following code and mesh:

    const Point<2> center (1,0);
    const SphericalManifold<2> manifold(center);
    const double inner_radius = 0.5,
    outer_radius = 1.0;
    @@ -289,22 +289,22 @@
    See also
    Glossary entry on manifold indicators

    Computing the weights for combining different manifold descriptions

    In a realistic application, it happens regularly that different manifold descriptions need to be combined. The simplest case is when a curved description is only available for the boundary but not for the interior of the computational domain. The manifold description for a ball also falls into this category, as it needs to combine a spherical manifold at the circular part with a straight-sided description in the center of the domain where the spherical manifold is not valid.

    -

    In general, the process of blending different manifold descriptions in deal.II is achieved by the so-called transfinite interpolation. Its formula in 2D is, for example, described on Wikipedia. Given a point $(u,v)$ on a chart, the image of this point in real space is given by

    -\begin{align*}
+<p>In general, the process of blending different manifold descriptions in deal.II is achieved by the so-called transfinite interpolation. Its formula in 2D is, for example, described on <a href=Wikipedia. Given a point $(u,v)$ on a chart, the image of this point in real space is given by

    +\begin{align*}
    \mathbf S(u,v) &= (1-v)\mathbf c_0(u)+v \mathbf c_1(u) + (1-u)\mathbf c_2(v) + u \mathbf c_3(v) \\
    &\quad - \left[(1-u)(1-v) \mathbf x_0 + u(1-v) \mathbf x_1 + (1-u)v \mathbf x_2 + uv \mathbf x_3 \right]
-   \end{align*} + \end{align*}" src="form_206.png"/>

    -

    where $\bf x_0, \bf x_1, \bf x_2, \bf x_3$ denote the four vertices bounding the image space and $\bf c_0, \bf c_1, \bf c_2, \bf c_3$ are the four curves describing the lines of the cell.

    -

    If we want to find the center of the cell according to the manifold (that is also used when the grid is refined), the chart is the unit cell $(0,1)^2$ and we want to evaluate this formula in the point $(u,v) = (0.5,
-   0.5)$. In that case, $\mathbf c_0(0.5)$ is the position of the midpoint of the lower face (indexed by 2 in deal.II's ordering) that is derived from its own manifold, $\mathbf c_1(0.5)$ is the position of the midpoint of the upper face (indexed by 3 in deal.II), $\mathbf c_2(0.5)$ is the midpoint of the face on the left (indexed by 0), and $\mathbf c_3(0.5)$ is the midpoint of the right face. In this formula, the weights equate to $\frac{\displaystyle 1}{\displaystyle 2}$ for the four midpoints in the faces and to $-\frac{\displaystyle 1}{\displaystyle 4}$ for the four vertices. These weights look weird at first sight because the vertices enter with negative weight but the mechanism does what we want: In case of a cell with curved description on two opposite faces but straight lines on the other two faces, the negative weights of $-\frac{\displaystyle
-   1}{\displaystyle 4}$ in the vertices balance with the center of the two straight lines in radial direction that get weight $\frac{\displaystyle
-   1}{\displaystyle 2}$. Thus, the average is taken over the two center points in curved direction, exactly placing the new point in the middle.

    -

    In three spatial dimensions, the weights are $+\frac{\displaystyle
-   1}{\displaystyle 2}$ for the face midpoints, $-\frac{\displaystyle
-   1}{\displaystyle 4}$ for the line mid points, and $\frac{\displaystyle
-   1}{\displaystyle 8}$ for the vertices, again balancing the different entities. In case all the surrounding of a cell is straight, the formula reduces to the obvious weight $\frac{\displaystyle 1}{\displaystyle 8}$ on each of the eight vertices.

    -

    In the MappingQGeneric class, a generalization of this concept to the support points of a polynomial representation of curved cells, the nodes of the Gauss-Lobatto quadrature, is implemented by evaluating the boundary curves in the respective Gauss-Lobatto points $(u_i,v_i)$ and combining them with the above formula. The weights have been verified to yield optimal convergence rates $\mathcal O(h^{k+1})$ also for very high polynomial degrees, say $k=10$.

    +

    where $\bf x_0, \bf x_1, \bf x_2, \bf x_3$ denote the four vertices bounding the image space and $\bf c_0, \bf c_1, \bf c_2, \bf c_3$ are the four curves describing the lines of the cell.

    +

    If we want to find the center of the cell according to the manifold (that is also used when the grid is refined), the chart is the unit cell $(0,1)^2$ and we want to evaluate this formula in the point $(u,v) = (0.5,
+   0.5)$. In that case, $\mathbf c_0(0.5)$ is the position of the midpoint of the lower face (indexed by 2 in deal.II's ordering) that is derived from its own manifold, $\mathbf c_1(0.5)$ is the position of the midpoint of the upper face (indexed by 3 in deal.II), $\mathbf c_2(0.5)$ is the midpoint of the face on the left (indexed by 0), and $\mathbf c_3(0.5)$ is the midpoint of the right face. In this formula, the weights equate to $\frac{\displaystyle 1}{\displaystyle 2}$ for the four midpoints in the faces and to $-\frac{\displaystyle 1}{\displaystyle 4}$ for the four vertices. These weights look weird at first sight because the vertices enter with negative weight but the mechanism does what we want: In case of a cell with curved description on two opposite faces but straight lines on the other two faces, the negative weights of $-\frac{\displaystyle
+   1}{\displaystyle 4}$ in the vertices balance with the center of the two straight lines in radial direction that get weight $\frac{\displaystyle
+   1}{\displaystyle 2}$. Thus, the average is taken over the two center points in curved direction, exactly placing the new point in the middle.

    +

    In three spatial dimensions, the weights are $+\frac{\displaystyle
+   1}{\displaystyle 2}$ for the face midpoints, $-\frac{\displaystyle
+   1}{\displaystyle 4}$ for the line mid points, and $\frac{\displaystyle
+   1}{\displaystyle 8}$ for the vertices, again balancing the different entities. In case all the surrounding of a cell is straight, the formula reduces to the obvious weight $\frac{\displaystyle 1}{\displaystyle 8}$ on each of the eight vertices.

    +

    In the MappingQGeneric class, a generalization of this concept to the support points of a polynomial representation of curved cells, the nodes of the Gauss-Lobatto quadrature, is implemented by evaluating the boundary curves in the respective Gauss-Lobatto points $(u_i,v_i)$ and combining them with the above formula. The weights have been verified to yield optimal convergence rates $\mathcal O(h^{k+1})$ also for very high polynomial degrees, say $k=10$.

    In the literature, other boundary descriptions are also used. Before version 9.0 deal.II used something called Laplace smoothing where the weights that are applied to the nodes on the circumference to get the position of the interior nodes are determined by solving a Laplace equation on the unit element. However, this led to boundary layers close to the curved description, i.e., singularities in the higher derivatives of the mapping from unit to real cell.

    If the transition from a curved boundary description to a straight description in the interior is done wrong, it is typically impossible to achieve high order convergence rates. For example, the Laplace smoothing inside a single cell leads to a singularity in the fourth derivative of the mapping from the reference to the real cell, limiting the convergence rate to 3 in the cells at the boundary (and 3.5 if global L2 errors were measured in 2D). Other more crude strategies, like completely ignoring the presence of two different manifolds and simply computing the additional points of a high-order mapping in a straight coordinate system, could lead to even worse convergence rates. The current implementation in deal.II, on the other hand, has been extensively verified in this respect and should behave optimally.

    A bad strategy for blending a curved boundary representation with flat interior representations obviously also reflects mesh quality. For example, the above case with only 3 circumferential cells leads to the following mesh with Laplace manifold smoothing rather than the interpolation from the boundary as is implemented in deal.II:

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__mapping.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__mapping.html 2023-08-09 23:38:56.450611796 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__mapping.html 2023-08-09 23:38:56.450611796 +0000 @@ -165,7 +165,7 @@
    -

    A class that implements a polynomial mapping $Q_p$ of degree $p$ on all cells. This class is completely equivalent to the MappingQ class and there for backward compatibility.

    +

    A class that implements a polynomial mapping $Q_p$ of degree $p$ on all cells. This class is completely equivalent to the MappingQ class and there for backward compatibility.

    Definition at line 702 of file mapping_q.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__matrixfree.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__matrixfree.html 2023-08-09 23:38:56.474611975 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__matrixfree.html 2023-08-09 23:38:56.474611975 +0000 @@ -140,7 +140,7 @@
  • Matrix-free methods skip the storage of big global sparse matrices and compute the underlying weak forms on the fly. Since the memory transfer, i.e., the speed at which the data can be read from RAM memory, is the bottleneck for matrix-based computations rather than the actual arithmetic done using this data, a matrix-free evaluation that reads less data can be advantageous even if it does more computations. This concept is building upon a trend in computer architecture which is best described by the term memory wall, saying that compute performance has increased more rapidly than the memory performance. Thus, a certain degree of arithmetic operations is essentially for free, and this share has become larger during the last twenty years. It has enabled this radical algorithm switch going from a matrix-based to a matrix-free implementation of matrix-vector products for iterative solvers, besides their classical use in explicit time integration. Of course, the implementation must be efficient and there cannot be an excess in computations to make it a win in total. The deal.II library uses SIMD vectorization and highly optimized kernels based on templates of the polynomial degree to achieve this goal. To give a perspective, a sparse matrix-vector product for quadratic elements FE_Q used to be equally fast as the matrix-free implementation on processors designed around 2005-2007 (e.g. Pentium 4 or AMD Opteron Barcelona with 2-4 cores per chip). By 2018, the matrix-free evaluation is around eight times as fast (measured on Intel Skylake Server, 14 cores).
  • -Matrix-free methods have a better complexity per degree of freedom as the degree is increased, due to sum factorization. The work per degree of freedom increases as $\mathcal O(k)$ in the degree $k$ for matrix-free schemes, whereas it increases as $\mathcal O(k^d)$ for matrix-based methods. This gives higher order schemes an edge. A particularly nice feature in matrix-free evaluation is that the $\mathcal O(1)$ terms often dominate, so it appears that higher order methods are as fast in terms of evaluation time as low order ones, when they have the same number of degrees of freedom. For the implementation in deal.II, best throughput is typically achieved for polynomial degrees between three and six.
  • +Matrix-free methods have a better complexity per degree of freedom as the degree is increased, due to sum factorization. The work per degree of freedom increases as $\mathcal O(k)$ in the degree $k$ for matrix-free schemes, whereas it increases as $\mathcal O(k^d)$ for matrix-based methods. This gives higher order schemes an edge. A particularly nice feature in matrix-free evaluation is that the $\mathcal O(1)$ terms often dominate, so it appears that higher order methods are as fast in terms of evaluation time as low order ones, when they have the same number of degrees of freedom. For the implementation in deal.II, best throughput is typically achieved for polynomial degrees between three and six.

    To summarize, matrix-free computations are the way to go for higher order elements (where higher order means everything except linear shape functions) and use in explicit time stepping (step-48) or iterative solvers where also preconditioning can be done in a matrix-free way, as demonstrated in the step-37 and step-59 tutorial programs.

    The matrix-free evaluation infrastructure

    @@ -150,7 +150,7 @@

    The motivation for the FEEvaluationAccess classes is to allow for specializations of the value and gradient access of interpolated solution fields depending on the number of components. Whereas the base class FEEvaluationBase returns the gradient as a Tensor<1,n_components,Tensor<1,dim,VectorizedArray<Number>>>, with the outer tensor going over the components and the inner tensor going through the dim components of the gradient. For a scalar field, i.e., n_components=1, we can skip the outer tensor and simply use Tensor<1,dim,VectorizedArray<Number>> as the gradient type. Likewise, for a system with n_components=dim, the appropriate format for the gradient is Tensor<2,dim,VectorizedArray<Number>>.

    The FEFaceEvaluation class

    Face integrals, like for inhomogeneous Neumann conditions in continuous FEM or for the large class of discontinuous Galerkin schemes, require the evaluation of quantities on the quadrature point of a face, besides the cell integrals. The facilities for face evaluation are mostly shared with FEEvaluation, in the sense that FEFaceEvaluation also inherits from FEEvaluationAccess. All data fields regarding the degrees of freedom and shape functions can be reused, the latter because all information consists of 1D shape data anyway. With respect to the mapping data, however, a specialization is used because the data is of structdim=dim-1. As a consequence, the FEEvaluationAccess and FEEvaluationBase are given a template argument is_face to hold pointers to the cell and face mapping information, respectively. Besides access to the function values with FEEvaluationAccess::get_value() or gradients with FEEvaluationAccess::get_gradient(), the face evaluator also enables the access to the normal vector by FEEvaluationAccess::normal_vector() and a specialized field FEEvaluationAccess::get_normal_derivative(), which returns the derivative of the solution field normal to the face. This quantity is computed as the gradient (in real space) multiplied by the normal vector. The combination of the gradient and normal vector is typical of many (simple) second-order elliptic equations, such as the discretization of the Laplacian with the interior penalty method. If the gradient alone is not needed, the combined operation significantly reduces the data access, because only dim data entries for normal * Jacobian per quadrature point are necessary, as opposed to dim^2 fields for the Jacobian and dim fields for the normal when accessing them individually.

    -

    An important optimization for the computation of face integrals is to think about the amount of vector data that must be accessed to evaluate the integrals on a face. Think for example of the case of FE_DGQ, i.e., Lagrange polynomials that have some of their nodes on the element boundary. For evaluation of the function values, only $(k+1)^{d-1}$ degrees of freedom contribute via a non-zero basis function, whereas the rest of the $(k+1)^d$ basis functions evaluate to zero on that boundary. Since vector access is one of the bottlenecks in matrix-free computations, the access to the vector should be restricted to the interesting entries. To enable this setup, the method FEFaceEvaluation::gather_evaluate() (and FEFaceEvaluation::integrate_scatter() for the integration equivalent) combines the vector access with the interpolation to the quadrature points. There exist two specializations, including the aforementioned "non-zero" value case, which is stored as the field internal::MatrixFreeFunctions::ShapeInfo::nodal_at_cell_boundaries. A similar property is also possible for the case where only the value and the first derivative of a selected number of basis functions evaluate to nonzero on a face. The associated element type is FE_DGQHermite and the decision is stored on the property internal::MatrixFreeFunctions::tensor_symmetric_hermite. The decision on whether such an optimized kernel can be used is made automatically inside FEFaceEvaluation::gather_evaluate() and FEFaceEvaluation::integrate_scatter(). It might seem inefficient to do this decision for every integration task, but in the end this is a single if statement (conditional jump) that is easily predictable for a modern CPU as the decision is always the same inside an integration loop. (One only pays by somewhat increased compile times because the compiler needs to generate code for all paths, though).

    +

    An important optimization for the computation of face integrals is to think about the amount of vector data that must be accessed to evaluate the integrals on a face. Think for example of the case of FE_DGQ, i.e., Lagrange polynomials that have some of their nodes on the element boundary. For evaluation of the function values, only $(k+1)^{d-1}$ degrees of freedom contribute via a non-zero basis function, whereas the rest of the $(k+1)^d$ basis functions evaluate to zero on that boundary. Since vector access is one of the bottlenecks in matrix-free computations, the access to the vector should be restricted to the interesting entries. To enable this setup, the method FEFaceEvaluation::gather_evaluate() (and FEFaceEvaluation::integrate_scatter() for the integration equivalent) combines the vector access with the interpolation to the quadrature points. There exist two specializations, including the aforementioned "non-zero" value case, which is stored as the field internal::MatrixFreeFunctions::ShapeInfo::nodal_at_cell_boundaries. A similar property is also possible for the case where only the value and the first derivative of a selected number of basis functions evaluate to nonzero on a face. The associated element type is FE_DGQHermite and the decision is stored on the property internal::MatrixFreeFunctions::tensor_symmetric_hermite. The decision on whether such an optimized kernel can be used is made automatically inside FEFaceEvaluation::gather_evaluate() and FEFaceEvaluation::integrate_scatter(). It might seem inefficient to do this decision for every integration task, but in the end this is a single if statement (conditional jump) that is easily predictable for a modern CPU as the decision is always the same inside an integration loop. (One only pays by somewhat increased compile times because the compiler needs to generate code for all paths, though).

    The data storage through the MatrixFree class

    The tasks performed by FEEvaluation and FEFaceEvaluation can be split into the three categories: index access into vectors, evaluation and integration on the unit cell, and operation on quadrature points including the geometry evaluation. This split is reflected by the major data fields contained by MatrixFree, using internal::MatrixFreeFunctions::DoFInfo, internal::MatrixFreeFunctions::ShapeInfo, and internal::MatrixFreeFunctions::MappingInfo for each these three categories, respectively. Their design principles and internal layout is described in the following subsections.

    The main interface all these data structure adhere to is that integration tasks are broken down into a range of cells or faces that one can index into by a single integer index. The information about an integer range for the cell integrals, inner face integrals, and boundary integrals is provided by the class internal::MatrixFreeFunctions::TaskInfo, using the data fields cell_partition_data, face_partition_data, and boundary_partition_data. This class also contains information about subranges of indices for scheduling tasks in parallel using threads, and a grouping of the index range within {cell,face,boundary}_partition_data for interleaving cell and face integrals such that the access to vector entries for cell and face integrals re-uses data already in caches.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__reordering.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__reordering.html 2023-08-09 23:38:56.494612126 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__reordering.html 2023-08-09 23:38:56.494612126 +0000 @@ -168,7 +168,7 @@

    From the examples above, it is obvious that if we encounter a cell that cannot be added to the cells which have already been entered, we can not usually point to a cell that is the culprit and that must be entered in a different orientation. Furthermore, even if we knew which cell, there might be large number of cells that would then cease to fit into the grid and which we would have to find a different orientation as well (in the second example above, if we rotated cell 1, then we would have to rotate the cells 1 through N-1 as well).

    A brute force approach to this problem is the following: if cell N can't be added, then try to rotate cell N-1. If we can't rotate cell N-1 any more, then try to rotate cell N-2 and try to add cell N with all orientations of cell N-1. And so on. Algorithmically, we can visualize this by a tree structure, where node N has as many children as there are possible orientations of node N+1 (in two space dimensions, there are four orientations in which each cell can be constructed from its four vertices; for example, if the vertex indices are (0 1 3 2), then the four possibilities would be (0 1 3 2), (1 3 2 0), (3 2 0 1), and (2 0 1 3)). When adding one cell after the other, we traverse this tree in a depth-first (pre-order) fashion. When we encounter that one path from the root (cell 0) to a leaf (the last cell) is not allowed (i.e. that the orientations of the cells which are encoded in the path through the tree does not lead to a valid triangulation), we have to track back and try another path through the tree.

    In practice, of course, we do not follow each path to a final node and then find out whether a path leads to a valid triangulation, but rather use an inductive argument: if for all previously added cells the triangulation is a valid one, then we can find out whether a path through the tree can yield a valid triangulation by checking whether entering the present cell would introduce any faces that have a nonunique direction; if that is so, then we can stop following all paths below this point and track back immediately.

    -

    Nevertheless, it is already obvious that the tree has $4^N$ leaves in two space dimensions, since each of the $N$ cells can be added in four orientations. Most of these nodes can be discarded rapidly, since firstly the orientation of the first cell is irrelevant, and secondly if we add one cell that has a neighbor that has already been added, then there are already only two possible orientations left, so the total number of checks we have to make until we find a valid way is significantly smaller than $4^N$. However, the algorithm is still exponential in time and linear in memory (we only have to store the information for the present path in form of a stack of orientations of cells that have already been added).

    +

    Nevertheless, it is already obvious that the tree has $4^N$ leaves in two space dimensions, since each of the $N$ cells can be added in four orientations. Most of these nodes can be discarded rapidly, since firstly the orientation of the first cell is irrelevant, and secondly if we add one cell that has a neighbor that has already been added, then there are already only two possible orientations left, so the total number of checks we have to make until we find a valid way is significantly smaller than $4^N$. However, the algorithm is still exponential in time and linear in memory (we only have to store the information for the present path in form of a stack of orientations of cells that have already been added).

    In fact, the two examples above show that the exponential estimate is not a pessimistic one: we indeed have to track back to one of the very first cells there to find a way to add all cells in a consistent fashion.

    This discouraging situation is greatly improved by the fact that we have an alternative algorithm for 2d that is always linear in runtime (discovered and implemented by Michael Anderson of TICAM, University of Texas, in 2003), and that for 3d we can find an algorithm that in practice is usually only roughly linear in time and memory. We will describe these algorithms in the following. A full description and theoretical analysis is given in [AABB17] .

    The 2d linear complexity algorithm

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__threads.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__threads.html 2023-08-09 23:38:56.530612393 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__threads.html 2023-08-09 23:38:56.530612393 +0000 @@ -302,7 +302,7 @@
    *out = function(*in_1, *in_2);
    }

    In many cases, function has no state, and so we can split this loop into several sub-ranges as explained above. Consequently, deal.II has a set of functions parallel::transform that look like the one above but that do their work in parallel (there are several versions with one, two, and more input iterators for function objects that take one, two, or more arguments). The only difference in calling these functions is that they take an additional last argument that denotes the minimum size of sub-ranges of [begin_in_1,end_in_1); it should be big enough so that we don't spend more time on scheduling sub-ranges to processors but small enough that processors can be efficiently load balanced. A rule of thumb appears to be that a sub-range is too small if it takes less than 2000 instructions to execute it.

    -

    An example of how to use these functions are vector operations like the addition in $z = x+y$ where all three objects are of type Vector<Number>:

    parallel::transform (x.begin(), x.end(),
    +

    An example of how to use these functions are vector operations like the addition in $z = x+y$ where all three objects are of type Vector<Number>:

    parallel::transform (x.begin(), x.end(),
    y.begin(),
    z.begin(),
    [](const Number first, const Number second)
    @@ -313,7 +313,7 @@
    Point< 2 > second
    Definition: grid_out.cc:4616
    Point< 2 > first
    Definition: grid_out.cc:4615
    void transform(const InputIterator &begin_in, const InputIterator &end_in, OutputIterator out, const Function &function, const unsigned int grainsize)
    Definition: parallel.h:148
    -

    In this example, we used a lambda expression to construct, on the fly, a function object that takes two arguments and returns the sum of the two. This is exactly what we needed when we want to add the individual elements of vectors $x$ and $y$ and write the sum of the two into the elements of $z$. The function object that we get here is completely known to the compiler and when it expands the loop that results from parallel::transform will be as if we had written the loop in its obvious form:

    InputIterator1 in_1 = x.begin();
    +

    In this example, we used a lambda expression to construct, on the fly, a function object that takes two arguments and returns the sum of the two. This is exactly what we needed when we want to add the individual elements of vectors $x$ and $y$ and write the sum of the two into the elements of $z$. The function object that we get here is completely known to the compiler and when it expands the loop that results from parallel::transform will be as if we had written the loop in its obvious form:

    InputIterator1 in_1 = x.begin();
    InputIterator2 in_2 = y.begin();
    OutputIterator out = z.begin();
    @@ -406,7 +406,7 @@
    }
    void apply_to_subranges(const Iterator &begin, const std_cxx20::type_identity_t< Iterator > &end, const Function &f, const unsigned int grainsize)
    Definition: parallel.h:435

    Here, we call the vmult_on_subrange function on sub-ranges of at least 200 elements each, so that the initial setup cost can amortize.

    -

    A related operation is when the loops over elements each produce a result that must then be accumulated (other reduction operations than addition of numbers would work as well). An example is to form the matrix norm $x^T M x$ (it really is only a norm if $M$ is positive definite, but let's assume for a moment that it is). A sequential implementation would look like this for sparse matrices:

    double SparseMatrix::mat_norm (const Vector &x) const
    +

    A related operation is when the loops over elements each produce a result that must then be accumulated (other reduction operations than addition of numbers would work as well). An example is to form the matrix norm $x^T M x$ (it really is only a norm if $M$ is positive definite, but let's assume for a moment that it is). A sequential implementation would look like this for sparse matrices:

    double SparseMatrix::mat_norm (const Vector &x) const
    {
    const double *val_ptr = &values[0];
    const unsigned int *colnum_ptr = &colnums[0];
    @@ -551,7 +551,7 @@

  • -

    A second correctness problem is that even if we do lock the global matrix and right hand side objects using a mutex, we do so in a more or less random order: while tasks are created in the order in which we traverse cells normally, there is no guarantee that by the time we get to the point where we want to copy the local into the global contributions the order is still as if we computed things sequentially. In other words, it may happen that we add the contributions of cell 1 before those of cell 0. That may seem harmless because addition is commutative and associative, but in fact it is not if done in floating point arithmetic: $a+b+c \neq a+c+b$ – take for example $a=1, b=-1, c=10^{-20}$ (because $1+10^{-20}=1$ in floating point arithmetic, using double precision).

    +

    A second correctness problem is that even if we do lock the global matrix and right hand side objects using a mutex, we do so in a more or less random order: while tasks are created in the order in which we traverse cells normally, there is no guarantee that by the time we get to the point where we want to copy the local into the global contributions the order is still as if we computed things sequentially. In other words, it may happen that we add the contributions of cell 1 before those of cell 0. That may seem harmless because addition is commutative and associative, but in fact it is not if done in floating point arithmetic: $a+b+c \neq a+c+b$ – take for example $a=1, b=-1, c=10^{-20}$ (because $1+10^{-20}=1$ in floating point arithmetic, using double precision).

    As a consequence, the exact values that end up in the global matrix and right hand side will be close but may differ by amounts close to round-off depending on the order in which tasks happened to finish their job. That's not a desirable outcome, since results will not be reproducible this way.

    As a consequence, the way the WorkStream class is designed is to use two functions: the MyClass::assemble_on_one_cell computes the local contributions and stores them somewhere (we'll get to that next), and a second function, say MyClass::copy_local_to_global, that copies the results computed on each cell into the global objects. The trick implemented in the WorkStream class is that (i) the MyClass::copy_local_to_global never runs more than once in parallel, so we do not need to synchronise execution through a mutex, and (ii) it runs in exactly the same order on cells as they appear in the iterator range, i.e. we add elements into the global matrix the same way every time, independently of when the computation of these element finishes.

    We now only have to discuss how the MyClass::assemble_on_one_cell communicates to MyClass::copy_local_to_global what it has computed. The way this is done is to use an object that holds all temporary data:

    struct PerTaskData {
    @@ -607,7 +607,7 @@

  • -

    The last issue that is worth addressing is that the way we wrote the MyClass::assemble_on_one_cell function above, we create and destroy an FEValues object every time the function is called, i.e. once for each cell in the triangulation. That's an immensely expensive operation because the FEValues class tries to do a lot of work in its constructor in an attempt to reduce the number of operations we have to do on each cell (i.e. it increases the constant in the ${\cal O}(1)$ effort to initialize such an object in order to reduce the constant in the ${\cal O}(N)$ operations to call FEValues::reinit on the $N$ cells of a triangulation). Creating and destroying an FEValues object on each cell invalidates this effort.

    +

    The last issue that is worth addressing is that the way we wrote the MyClass::assemble_on_one_cell function above, we create and destroy an FEValues object every time the function is called, i.e. once for each cell in the triangulation. That's an immensely expensive operation because the FEValues class tries to do a lot of work in its constructor in an attempt to reduce the number of operations we have to do on each cell (i.e. it increases the constant in the ${\cal O}(1)$ effort to initialize such an object in order to reduce the constant in the ${\cal O}(N)$ operations to call FEValues::reinit on the $N$ cells of a triangulation). Creating and destroying an FEValues object on each cell invalidates this effort.

    The way to avoid this is to put the FEValues object into a second structure that will hold scratch data, and initialize it in the constructor:

    struct PerTaskData {
    FullMatrix<double> cell_matrix;
    Vector<double> cell_rhs;
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__vector__valued.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__vector__valued.html 2023-08-09 23:38:56.562612632 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/group__vector__valued.html 2023-08-09 23:38:56.562612632 +0000 @@ -280,8 +280,8 @@ \right) \end{eqnarray*}" src="form_302.png"/>

    -

    indeed has four components. We note that we could change the ordering of the solution components $\textbf u$ and $p$ inside $U$ if we also change columns of the matrix operator.

    -

    Next, we need to think about test functions $V$. We want to multiply both sides of the equation with them, then integrate over $\Omega$. The result should be a scalar equality. We can achieve this by choosing $V$ also vector valued as

    +

    indeed has four components. We note that we could change the ordering of the solution components $\textbf u$ and $p$ inside $U$ if we also change columns of the matrix operator.

    +

    Next, we need to think about test functions $V$. We want to multiply both sides of the equation with them, then integrate over $\Omega$. The result should be a scalar equality. We can achieve this by choosing $V$ also vector valued as

    \begin{eqnarray*}
   V =
   \left(
@@ -449,7 +449,7 @@
 <p class=

  • -

    These views can then be asked for information about these individual components. For example, when you write fe_values[pressure].value(i,q) you get the value of the pressure component of the $i$th shape function $V_i$ at the $q$th quadrature point. Because the extractor pressure represents a scalar component, the results of the operator fe_values[pressure].value(i,q) is a scalar number. On the other hand, the call fe_values[velocities].value(i,q) would produce the value of a whole set of dim components, which would be of type Tensor<1,dim>.

    +

    These views can then be asked for information about these individual components. For example, when you write fe_values[pressure].value(i,q) you get the value of the pressure component of the $i$th shape function $V_i$ at the $q$th quadrature point. Because the extractor pressure represents a scalar component, the results of the operator fe_values[pressure].value(i,q) is a scalar number. On the other hand, the call fe_values[velocities].value(i,q) would produce the value of a whole set of dim components, which would be of type Tensor<1,dim>.

  • @@ -593,10 +593,10 @@
    }
  • So if, again, this is not the code we use in step-8, what do we do there? The answer rests on the finite element we use. In step-8, we use the following element:

    FESystem<dim> finite_element (FE_Q<dim>(1), dim);
    -

    In other words, the finite element we use consists of dim copies of the same scalar element. This is what we call a primitive element: an element that may be vector-valued but where each shape function has exactly one non-zero component. In other words: if the $x$-component of a displacement shape function is nonzero, then the $y$- and $z$-components must be zero and similarly for the other components. What this means is that also derived quantities based on shape functions inherit this sparsity property. For example: the divergence $\mathrm{div}\ \Phi(x,y,z)=\partial_x\varphi_x(x,y,z) +
+</div><!-- fragment --><p> In other words, the finite element we use consists of <code>dim</code> copies of the same scalar element. This is what we call a <a class=primitive element: an element that may be vector-valued but where each shape function has exactly one non-zero component. In other words: if the $x$-component of a displacement shape function is nonzero, then the $y$- and $z$-components must be zero and similarly for the other components. What this means is that also derived quantities based on shape functions inherit this sparsity property. For example: the divergence $\mathrm{div}\ \Phi(x,y,z)=\partial_x\varphi_x(x,y,z) +
    \partial_y\varphi_y(x,y,z) + \partial_z\varphi_z(x,y,z)$ of a vector-valued shape function $\Phi(x,y,z)=(\varphi_x(x,y,z), \varphi_y(x,y,z), \varphi_z(x,y,z))^T$ is, in the present case, either $\mathrm{div}\ \Phi(x,y,z)=\partial_x\varphi_x(x,y,z)$, $\mathrm{div}\ \Phi(x,y,z)=\partial_y\varphi_y(x,y,z)$, or $\mathrm{div}\ \Phi(x,y,z)=\partial_z\varphi_z(x,y,z)$, because exactly one of the $\varphi_\ast$ is nonzero. Knowing this means that we can save a number of computations that, if we were to do them, would only yield zeros to add up.

    In a similar vein, if only one component of a shape function is nonzero, then only one row of its gradient $\nabla\Phi$ is nonzero. What this means for terms like $(\mu \nabla\Phi_i,\nabla\Phi_j)$, where the scalar product between two tensors is defined as $(\tau, \gamma)_\Omega=\int_\Omega \sum_{i,j=1}^d \tau_{ij} \gamma_{ij}$, is that the term is only nonzero if both tensors have their nonzero entries in the same row, which means that the two shape functions have to have their single nonzero component in the same location.

    -

    If we use this sort of knowledge, then we can in a first step avoid computing gradient tensors if we can determine up front that their scalar product will be nonzero, in a second step avoid building the entire tensors and only get its nonzero components, and in a final step simplify the scalar product by only considering that index $i$ for the one nonzero row, rather than multiplying and adding up zeros.

    +

    If we use this sort of knowledge, then we can in a first step avoid computing gradient tensors if we can determine up front that their scalar product will be nonzero, in a second step avoid building the entire tensors and only get its nonzero components, and in a final step simplify the scalar product by only considering that index $i$ for the one nonzero row, rather than multiplying and adding up zeros.

    The vehicle for all this is the ability to determine which vector component is going to be nonzero. This information is provided by the FiniteElement::system_to_component_index function. What can be done with it, using the example above, is explained in detail in step-8.

    Block solvers

    Using techniques as shown above, it isn't particularly complicated to assemble the linear system, i.e. matrix and right hand side, for a vector-valued problem. However, then it also has to be solved. This is more complicated. Naively, one could just consider the matrix as a whole. For most problems, this matrix is not going to be definite (except for special cases like the elasticity equations covered in step-8 and step-17). It will, often, also not be symmetric. This rather general class of matrices presents problems for iterative solvers: the lack of structural properties prevents the use of most efficient methods and preconditioners. While it can be done, the solution process will therefore most often be slower than necessary.

    @@ -614,7 +614,7 @@ \right), \end{eqnarray*}" src="form_337.png"/>

    -

    where $M$ represents the mass matrix that results from discretizing the identity operator $\mathbf 1$ and $B$ the equivalent of the gradient operator.

    +

    where $M$ represents the mass matrix that results from discretizing the identity operator $\mathbf 1$ and $B$ the equivalent of the gradient operator.

    By default, this is not what happens, however. Rather, deal.II assigns numbers to degrees of freedom in a rather random manner. Consequently, if you form a vector out of the values of degrees of freedom will not be neatly ordered in a vector like

    \begin{eqnarray*}
   \left(
@@ -654,8 +654,8 @@
   MU = F-BP.
 \end{eqnarray*}

    -

    This has the advantage that the matrices $B^TM^{-1}B$ and $M$ that we have to solve with are both symmetric and positive definite, as opposed to the large whole matrix we had before.

    -

    How a solver like this is implemented is explained in more detail in step-20, step-31, and a few other tutorial programs. What we would like to point out here is that we now need a way to extract certain parts of a matrix or vector: if we are to multiply, say, the $U$ part of the solution vector by the $M$ part of the global matrix, then we need to have a way to access these parts of the whole.

    +

    This has the advantage that the matrices $B^TM^{-1}B$ and $M$ that we have to solve with are both symmetric and positive definite, as opposed to the large whole matrix we had before.

    +

    How a solver like this is implemented is explained in more detail in step-20, step-31, and a few other tutorial programs. What we would like to point out here is that we now need a way to extract certain parts of a matrix or vector: if we are to multiply, say, the $U$ part of the solution vector by the $M$ part of the global matrix, then we need to have a way to access these parts of the whole.

    This is where the BlockVector, BlockSparseMatrix, and similar classes come in. For all practical purposes, then can be used as regular vectors or sparse matrices, i.e. they offer element access, provide the usual vector operations and implement, for example, matrix-vector multiplications. In other words, assembling matrices and right hand sides works in exactly the same way as for the non-block versions. That said, internally they store the elements of vectors and matrices in "blocks"; for example, instead of using one large array, the BlockVector class stores it as a set of arrays each of which we call a block. The advantage is that, while the whole thing can be used as a vector, one can also access an individual block which then, again, is a vector with all the vector operations.

    To show how to do this, let us consider the second equation $MU=F-BP$ to be solved above. This can be achieved using the following sequence similar to what we have in step-20:

    Vector<double> tmp (solution.block(0).size());
    system_matrix.block(0,1).vmult (tmp, solution.block(1));
    @@ -675,7 +675,7 @@
    Definition: vector.h:109
    -

    What's happening here is that we allocate a temporary vector with as many elements as the first block of the solution vector, i.e. the velocity component $U$, has. We then set this temporary vector equal to the $(0,1)$ block of the matrix, i.e. $B$, times component 1 of the solution which is the previously computed pressure $P$. The result is multiplied by $-1$, and component 0 of the right hand side, $F$ is added to it. The temporary vector now contains $F-BP$. The rest of the code snippet simply solves a linear system with $F-BP$ as right hand side and the $(0,0)$ block of the global matrix, i.e. $M$. Using block vectors and matrices in this way therefore allows us to quite easily write rather complicated solvers making use of the block structure of a linear system.

    +

    What's happening here is that we allocate a temporary vector with as many elements as the first block of the solution vector, i.e. the velocity component $U$, has. We then set this temporary vector equal to the $(0,1)$ block of the matrix, i.e. $B$, times component 1 of the solution which is the previously computed pressure $P$. The result is multiplied by $-1$, and component 0 of the right hand side, $F$ is added to it. The temporary vector now contains $F-BP$. The rest of the code snippet simply solves a linear system with $F-BP$ as right hand side and the $(0,0)$ block of the global matrix, i.e. $M$. Using block vectors and matrices in this way therefore allows us to quite easily write rather complicated solvers making use of the block structure of a linear system.

    Extracting data from solutions

    Once one has computed a solution, it is often necessary to evaluate it at quadrature points, for example to evaluate nonlinear residuals for the next Newton iteration, to evaluate the finite element residual for error estimators, or to compute the right hand side for the next time step in a time dependent problem.

    The way this is done us to again use an FEValues object to evaluate the shape functions at quadrature points, and with those also the values of a finite element function. For the example of the mixed Laplace problem above, consider the following code after solving:

    std::vector<Vector<double> > local_solution_values (n_q_points,
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/index.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/index.html 2023-08-09 23:38:56.578612752 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/index.html 2023-08-09 23:38:56.578612752 +0000 @@ -117,7 +117,7 @@
  • DoFHandler: DoFHandler objects are the confluence of triangulations and finite elements: the finite element class describes how many degrees of freedom it needs per vertex, line, or cell, and the DoFHandler class allocates this space so that each vertex, line, or cell of the triangulation has the correct number of them. It also gives them a global numbering.

    -

    A different viewpoint is this: While the mesh and finite element describe abstract properties of the finite dimensional space $V_h$ in which we seek the discrete solution, the DoFHandler classes enumerate a concrete basis of this space so that we can represent the discrete solution as $u_h(\mathbf x)= \sum_j U_j \varphi_i(\mathbf x)$ by an ordered set of coefficients $U_j$.

    +

    A different viewpoint is this: While the mesh and finite element describe abstract properties of the finite dimensional space $V_h$ in which we seek the discrete solution, the DoFHandler classes enumerate a concrete basis of this space so that we can represent the discrete solution as $u_h(\mathbf x)= \sum_j U_j \varphi_i(\mathbf x)$ by an ordered set of coefficients $U_j$.

    Just as with triangulation objects, most operations on DoFHandlers are done by looping over all cells and doing something on each or a subset of them. The interfaces of the two classes are therefore rather similar: they allow to get iterators to the first and last cell (or face, or line, etc) and offer information through these iterators. The information that can be gotten from these iterators is the geometric and topological information that can already be gotten from the triangulation iterators (they are in fact derived classes) as well as things like the global numbers of the degrees of freedom on the present cell. On can also ask an iterator to extract the values corresponding to the degrees of freedom on the present cell from a data vector that stores values for all degrees of freedom associated with a triangulation.

    It is worth noting that, just as triangulations, DoFHandler classes do not know anything about the mapping from the unit cell to its individual cells. It is also ignorant of the shape functions that correspond to the degrees of freedom it manages: all it knows is that there are, for example, 2 degrees of freedom for each vertex and 4 per cell interior. Nothing about their specifics is relevant to the DoFHandler class with the exception of the fact that they exist.

    The DoFHandler class and its associates are described in the Degrees of Freedom module. In addition, there are specialized versions that can handle multilevel and hp-discretizations. These are described in the Multilevel support and hp-finite element support modules. Finite element methods frequently imply constraints on degrees of freedom, such as for hanging nodes or nodes at which boundary conditions apply; dealing with such constraints is described in the Constraints on degrees of freedom module.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/index__set_8h.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/index__set_8h.html 2023-08-09 23:38:56.594612871 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/index__set_8h.html 2023-08-09 23:38:56.594612871 +0000 @@ -145,7 +145,7 @@
  • -

    Create and return an index set of size $N$ that contains every single index within this range. In essence, this function returns an index set created by

    IndexSet is (N);
    +

    Create and return an index set of size $N$ that contains every single index within this range. In essence, this function returns an index set created by

    IndexSet is (N);
    is.add_range(0, N);

    This function exists so that one can create and initialize index sets that are complete in one step, or so one can write code like

    if (my_index_set == complete_index_set(my_index_set.size())
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceAdaptationStrategies_1_1Coarsening.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceAdaptationStrategies_1_1Coarsening.html 2023-08-09 23:38:56.610612991 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceAdaptationStrategies_1_1Coarsening.html 2023-08-09 23:38:56.610612991 +0000 @@ -139,11 +139,11 @@

    Check if data on all children match, and return value of the first child.

    -\[
+<picture><source srcset=\[
   d_{K_p} = d_{K_c}
   \qquad
   \forall K_c \text{ children of } K_p
-\] +\]" src="form_2146.png"/>

    @@ -176,13 +176,13 @@

    Return sum of data on all children.

    -\[
+<picture><source srcset=\[
   d_{K_p} = \sum d_{K_c}
   \qquad
   \forall K_c \text{ children of } K_p
-\] +\]" src="form_2147.png"/>

    -

    This strategy preserves the $l_1$-norm of the corresponding global data vector before and after adaptation.

    +

    This strategy preserves the $l_1$-norm of the corresponding global data vector before and after adaptation.

    @@ -212,15 +212,15 @@
    -

    Return $ l_2 $-norm of data on all children.

    +

    Return $ l_2 $-norm of data on all children.

    -\[
+<picture><source srcset=\[
   d_{K_p}^2 = \sum d_{K_c}^2
   \qquad
   \forall K_c \text{ children of } K_p
-\] +\]" src="form_2149.png"/>

    -

    This strategy preserves the $l_2$-norm of the corresponding global data vector before and after adaptation.

    +

    This strategy preserves the $l_2$-norm of the corresponding global data vector before and after adaptation.

    @@ -252,11 +252,11 @@

    Return mean value of data on all children.

    -\[
+<picture><source srcset=\[
   d_{K_p} = \sum d_{K_c} / n_\text{children}
   \qquad
   \forall K_c \text{ children of } K_p
-\] +\]" src="form_2150.png"/>

    @@ -289,11 +289,11 @@

    Return maximum value of data on all children.

    -\[
+<picture><source srcset=\[
   d_{K_p} = \max \left( d_{K_c} \right)
   \qquad
   \forall K_c \text{ children of } K_p
-\] +\]" src="form_2151.png"/>

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceAdaptationStrategies_1_1Refinement.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceAdaptationStrategies_1_1Refinement.html 2023-08-09 23:38:56.626613111 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceAdaptationStrategies_1_1Refinement.html 2023-08-09 23:38:56.626613111 +0000 @@ -135,11 +135,11 @@

    Return a vector containing copies of data of the parent cell for each child.

    -\[
+<picture><source srcset=\[
   d_{K_c} = d_{K_p}
   \qquad
   \forall K_c \text{ children of } K_p
-\] +\]" src="form_2143.png"/>

    @@ -172,13 +172,13 @@

    Return a vector which contains data of the parent cell being equally divided among all children.

    -\[
+<picture><source srcset=\[
   d_{K_c} = d_{K_p} / n_\text{children}
   \qquad
   \forall K_c \text{ children of } K_p
-\] +\]" src="form_2144.png"/>

    -

    This strategy preserves the $l_1$-norm of the corresponding global data Vector before and after adaptation.

    +

    This strategy preserves the $l_1$-norm of the corresponding global data Vector before and after adaptation.

    @@ -210,13 +210,13 @@

    Return a vector which contains squared data of the parent cell being equally divided among the squares of all children.

    -\[
+<picture><source srcset=\[
   d_{K_c}^2 = d_{K_p}^2 / n_\text{children}
   \qquad
   \forall K_c \text{ children of } K_p
-\] +\]" src="form_2145.png"/>

    -

    This strategy preserves the $l_2$-norm of the corresponding global data Vector before and after adaptation.

    +

    This strategy preserves the $l_2$-norm of the corresponding global data Vector before and after adaptation.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDataComponentInterpretation.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDataComponentInterpretation.html 2023-08-09 23:38:56.642613230 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDataComponentInterpretation.html 2023-08-09 23:38:56.642613230 +0000 @@ -113,7 +113,7 @@
    -

    The members of this enum are used to describe the logical interpretation of what the various components of a vector-valued data set mean. For example, if one has a finite element for the Stokes equations in 2d, representing components $(u,v,p)$, one would like to indicate that the first two, $u$ and $v$, represent a logical vector so that later on when we generate graphical output we can hand them off to a visualization program that will automatically know to render them as a vector field, rather than as two separate and independent scalar fields.

    +

    The members of this enum are used to describe the logical interpretation of what the various components of a vector-valued data set mean. For example, if one has a finite element for the Stokes equations in 2d, representing components $(u,v,p)$, one would like to indicate that the first two, $u$ and $v$, represent a logical vector so that later on when we generate graphical output we can hand them off to a visualization program that will automatically know to render them as a vector field, rather than as two separate and independent scalar fields.

    By passing a set of enums of the current kind to the DataOut_DoFData::add_data_vector functions, this can be achieved.

    See the step-22 tutorial program for an example on how this information can be used in practice.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDataOutBase.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDataOutBase.html 2023-08-09 23:38:56.686613559 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDataOutBase.html 2023-08-09 23:38:56.686613559 +0000 @@ -593,7 +593,7 @@

    While this discussion applies to two spatial dimensions, it is more complicated in 3d. The reason is that we could still use patches, but it is difficult when trying to visualize them, since if we use a cut through the data (by, for example, using x- and z-coordinates, a fixed y-value and plot function values in z-direction, then the patched data is not a patch in the sense GNUPLOT wants it any more. Therefore, we use another approach, namely writing the data on the 3d grid as a sequence of lines, i.e. two points each associated with one or more data sets. There are therefore 12 lines for each subcells of a patch.

    Given the lines as described above, a cut through this data in Gnuplot can then be achieved like this:

    *   set data style lines
     *   splot [:][:][0:] "T" using 1:2:(\$3==.5 ? \$4 : -1)
    -* 

    This command plots data in $x$- and $y$-direction unbounded, but in $z$-direction only those data points which are above the $x$- $y$-plane (we assume here a positive solution, if it has negative values, you might want to decrease the lower bound). Furthermore, it only takes the data points with z-values (&3) equal to 0.5, i.e. a cut through the domain at z=0.5. For the data points on this plane, the data values of the first data set (&4) are raised in z-direction above the x-y-plane; all other points are denoted the value -1 instead of the value of the data vector and are not plotted due to the lower bound in z plotting direction, given in the third pair of brackets.

    +*

    This command plots data in $x$- and $y$-direction unbounded, but in $z$-direction only those data points which are above the $x$- $y$-plane (we assume here a positive solution, if it has negative values, you might want to decrease the lower bound). Furthermore, it only takes the data points with z-values (&3) equal to 0.5, i.e. a cut through the domain at z=0.5. For the data points on this plane, the data values of the first data set (&4) are raised in z-direction above the x-y-plane; all other points are denoted the value -1 instead of the value of the data vector and are not plotted due to the lower bound in z plotting direction, given in the third pair of brackets.

    More complex cuts are possible, including nonlinear ones. Note however, that only those points which are actually on the cut-surface are plotted.

    Definition at line 3557 of file data_out_base.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDerivativeApproximation.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDerivativeApproximation.html 2023-08-09 23:38:56.706613708 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDerivativeApproximation.html 2023-08-09 23:38:56.706613708 +0000 @@ -118,17 +118,17 @@

    Detailed Description

    This namespace provides functions that compute a cell-wise approximation of the norm of a derivative of a finite element field by taking difference quotients between neighboring cells. This is a rather simple but efficient form to get an error indicator, since it can be computed with relatively little numerical effort and yet gives a reasonable approximation.

    -

    The way the difference quotients are computed on cell $K$ is the following (here described for the approximation of the gradient of a finite element field, but see below for higher derivatives): let $K'$ be a neighboring cell, and let $y_{K'}=x_{K'}-x_K$ be the distance vector between the centers of the two cells, then $ \frac{u_h(x_{K'}) - u_h(x_K)}{ \|y_{K'}\|
-}$ is an approximation of the directional derivative $ \nabla u(x_K) \cdot
-\frac{y_{K'}}{ \|y_{K'}\| }.$ By multiplying both terms by $\frac{y_{K'}}{
-\|y_{K'}\| }$ from the left and summing over all neighbors $K'$, we obtain $ \sum_{K'} \left( \frac{y_{K'}}{ \|y_{K'}\|} \frac{y_{K'}^T}{ \|y_{K'}\| }
+<p>The way the difference quotients are computed on cell <picture><source srcset=$K$ is the following (here described for the approximation of the gradient of a finite element field, but see below for higher derivatives): let $K'$ be a neighboring cell, and let $y_{K'}=x_{K'}-x_K$ be the distance vector between the centers of the two cells, then $ \frac{u_h(x_{K'}) - u_h(x_K)}{ \|y_{K'}\|
+}$ is an approximation of the directional derivative $ \nabla u(x_K) \cdot
+\frac{y_{K'}}{ \|y_{K'}\| }.$ By multiplying both terms by $\frac{y_{K'}}{
+\|y_{K'}\| }$ from the left and summing over all neighbors $K'$, we obtain $ \sum_{K'} \left( \frac{y_{K'}}{ \|y_{K'}\|} \frac{y_{K'}^T}{ \|y_{K'}\| }
 \right) \nabla u(x_K) \approx \sum_{K'} \left( \frac{y_{K'}}{ \|y_{K'}\|}
-\frac{u_h(x_{K'}) - u_h(x_K)}{ \|y_{K'}\| }  \right).$

    -

    Thus, if the matrix $ Y =  \sum_{K'} \left( \frac{y_{K'}}{\|y_{K'}\|}
-\frac{y_{K'}^T}{ \|y_{K'}\| } \right)$ is regular (which is the case when the vectors $y_{K'}$ to all neighbors span the whole space), we can obtain an approximation to the true gradient by $ \nabla u(x_K) \approx Y^{-1}
+\frac{u_h(x_{K'}) - u_h(x_K)}{ \|y_{K'}\| }  \right).$

    +

    Thus, if the matrix $ Y =  \sum_{K'} \left( \frac{y_{K'}}{\|y_{K'}\|}
+\frac{y_{K'}^T}{ \|y_{K'}\| } \right)$ is regular (which is the case when the vectors $y_{K'}$ to all neighbors span the whole space), we can obtain an approximation to the true gradient by $ \nabla u(x_K) \approx Y^{-1}
 \sum_{K'} \left( \frac{y_{K'}}{\|y_{K'}\|} \frac{u_h(x_{K'}) - u_h(x_K)}{
-\|y_{K'}\| } \right).$ This is a quantity that is easily computed. The value returned for each cell when calling the approximate_gradient function of this class is the $l_2$ norm of this approximation to the gradient. To make this a useful quantity, you may want to scale each element by the correct power of the respective cell size.

    -

    The computation of this quantity must fail if a cell has only neighbors for which the direction vectors $y_K$ do not span the whole space, since then the matrix $Y$ is no longer invertible. If this happens, you will get an error similar to this one:

    --------------------------------------------------------
    +\|y_{K'}\| } \right).$" src="form_2171.png"/> This is a quantity that is easily computed. The value returned for each cell when calling the approximate_gradient function of this class is the $l_2$ norm of this approximation to the gradient. To make this a useful quantity, you may want to scale each element by the correct power of the respective cell size.

    +

    The computation of this quantity must fail if a cell has only neighbors for which the direction vectors $y_K$ do not span the whole space, since then the matrix $Y$ is no longer invertible. If this happens, you will get an error similar to this one:

    --------------------------------------------------------
    An error occurred in line <749>
    of file <source/numerics/derivative_approximation.cc> in function
    void DerivativeApproximation::approximate(...)
    @@ -146,19 +146,19 @@
    DEAL_II_HOST constexpr Number determinant(const SymmetricTensor< 2, dim, Number > &)

    As can easily be verified, this can only happen on very coarse grids, when some cells and all their neighbors have not been refined even once. You should therefore only call the functions of this class if all cells are at least once refined. In practice this is not much of a restriction.

    Approximation of higher derivatives

    -

    Similar to the reasoning above, approximations to higher derivatives can be computed in a similar fashion. For example, the tensor of second derivatives is approximated by the formula $ \nabla^2 u(x_K) \approx Y^{-1}
+<p>Similar to the reasoning above, approximations to higher derivatives can be computed in a similar fashion. For example, the tensor of second derivatives is approximated by the formula <picture><source srcset=$ \nabla^2 u(x_K) \approx Y^{-1}
 \sum_{K'} \left( \frac{y_{K'}}{\|y_{K'}\|} \otimes \frac{\nabla u_h(x_{K'})
-- \nabla u_h(x_K)}{ \|y_{K'}\| } \right), $ where $\otimes$ denotes the outer product of two vectors. Note that unlike the true tensor of second derivatives, its approximation is not necessarily symmetric. This is due to the fact that in the derivation, it is not clear whether we shall consider as projected second derivative the term $\nabla^2 u y_{KK'}$ or $y_{KK'}^T
-\nabla^2 u$. Depending on which choice we take, we obtain one approximation of the tensor of second derivatives or its transpose. To avoid this ambiguity, as result we take the symmetrized form, which is the mean value of the approximation and its transpose.

    -

    The returned value on each cell is the spectral norm of the approximated tensor of second derivatives, i.e. the largest eigenvalue by absolute value. This equals the largest curvature of the finite element field at each cell, and the spectral norm is the matrix norm associated to the $l_2$ vector norm.

    +- \nabla u_h(x_K)}{ \|y_{K'}\| } \right), $" src="form_2173.png"/> where $\otimes$ denotes the outer product of two vectors. Note that unlike the true tensor of second derivatives, its approximation is not necessarily symmetric. This is due to the fact that in the derivation, it is not clear whether we shall consider as projected second derivative the term $\nabla^2 u y_{KK'}$ or $y_{KK'}^T
+\nabla^2 u$. Depending on which choice we take, we obtain one approximation of the tensor of second derivatives or its transpose. To avoid this ambiguity, as result we take the symmetrized form, which is the mean value of the approximation and its transpose.

    +

    The returned value on each cell is the spectral norm of the approximated tensor of second derivatives, i.e. the largest eigenvalue by absolute value. This equals the largest curvature of the finite element field at each cell, and the spectral norm is the matrix norm associated to the $l_2$ vector norm.

    Even higher than the second derivative can be obtained along the same lines as exposed above.

    Refinement indicators based on the derivatives

    -

    If you would like to base a refinement criterion upon these approximation of the derivatives, you will have to scale the results of this class by an appropriate power of the mesh width. For example, since $\|u-u_h\|^2_{L_2}
-\le C h^2 \|\nabla u\|^2_{L_2}$, it might be the right thing to scale the indicators as $\eta_K = h \|\nabla u\|_K$, i.e. $\eta_K = h^{1+d/2}
-\|\nabla u\|_{\infty;K}$, i.e. the right power is $1+d/2$.

    -

    Likewise, for the second derivative, one should choose a power of the mesh size $h$ one higher than for the gradient.

    +

    If you would like to base a refinement criterion upon these approximation of the derivatives, you will have to scale the results of this class by an appropriate power of the mesh width. For example, since $\|u-u_h\|^2_{L_2}
+\le C h^2 \|\nabla u\|^2_{L_2}$, it might be the right thing to scale the indicators as $\eta_K = h \|\nabla u\|_K$, i.e. $\eta_K = h^{1+d/2}
+\|\nabla u\|_{\infty;K}$, i.e. the right power is $1+d/2$.

    +

    Likewise, for the second derivative, one should choose a power of the mesh size $h$ one higher than for the gradient.

    Implementation

    -

    The formulae for the computation of approximations to the gradient and to the tensor of second derivatives shown above are very much alike. The basic difference is that in one case the finite difference quotient is a scalar, while in the other case it is a vector. For higher derivatives, this would be a tensor of even higher rank. We then have to form the outer product of this difference quotient with the distance vector $y_{KK'}$, symmetrize it, contract it with the matrix $Y^{-1}$ and compute its norm. To make the implementation simpler and to allow for code reuse, all these operations that are dependent on the actual order of the derivatives to be approximated, as well as the computation of the quantities entering the difference quotient, have been separated into auxiliary nested classes (names Gradient and SecondDerivative) and the main algorithm is simply passed one or the other data types and asks them to perform the order dependent operations. The main framework that is independent of this, such as finding all active neighbors, or setting up the matrix $Y$ is done in the main function approximate.

    +

    The formulae for the computation of approximations to the gradient and to the tensor of second derivatives shown above are very much alike. The basic difference is that in one case the finite difference quotient is a scalar, while in the other case it is a vector. For higher derivatives, this would be a tensor of even higher rank. We then have to form the outer product of this difference quotient with the distance vector $y_{KK'}$, symmetrize it, contract it with the matrix $Y^{-1}$ and compute its norm. To make the implementation simpler and to allow for code reuse, all these operations that are dependent on the actual order of the derivatives to be approximated, as well as the computation of the quantities entering the difference quotient, have been separated into auxiliary nested classes (names Gradient and SecondDerivative) and the main algorithm is simply passed one or the other data types and asks them to perform the order dependent operations. The main framework that is independent of this, such as finding all active neighbors, or setting up the matrix $Y$ is done in the main function approximate.

    Due to this way of operation, the class may be easily extended for higher order derivatives than are presently implemented. Basically, only an additional class along the lines of the derivative descriptor classes Gradient and SecondDerivative has to be implemented, with the respective alias and functions replaced by the appropriate analogues for the derivative that is to be approximated.

    Function Documentation

    @@ -293,7 +293,7 @@
    -

    This function is the analogue to the one above, computing finite difference approximations of the tensor of second derivatives. Pass it the DoF handler object that describes the finite element field, a nodal value vector, and receive the cell-wise spectral norm of the approximated tensor of second derivatives. The spectral norm is the matrix norm associated to the $l_2$ vector norm.

    +

    This function is the analogue to the one above, computing finite difference approximations of the tensor of second derivatives. Pass it the DoF handler object that describes the finite element field, a nodal value vector, and receive the cell-wise spectral norm of the approximated tensor of second derivatives. The spectral norm is the matrix norm associated to the $l_2$ vector norm.

    The last parameter denotes the solution component, for which the gradient is to be computed. It defaults to the first component. For scalar elements, this is the only valid choice; for vector-valued ones, any component between zero and the number of vector components can be given here.

    In a parallel computation the solution vector needs to contain the locally relevant unknowns.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDifferentiation_1_1SD.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDifferentiation_1_1SD.html 2023-08-09 23:38:56.814614515 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDifferentiation_1_1SD.html 2023-08-09 23:38:56.818614545 +0000 @@ -666,7 +666,7 @@
    -

    Return a symbolic number that represents the Euler constant $e \approx 2.71828$ raised to the given exponent.

    +

    Return a symbolic number that represents the Euler constant $e \approx 2.71828$ raised to the given exponent.

    Mimics the function std::exp(exponent) using the standard math library.

    Definition at line 60 of file symengine_math.cc.

    @@ -2894,7 +2894,7 @@

    Return an Expression representing a scalar symbolic variable with the identifier specified by symbol.

    -

    For example, if the symbol is the string "x" then the scalar symbolic variable that is returned represents the scalar $x$.

    +

    For example, if the symbol is the string "x" then the scalar symbolic variable that is returned represents the scalar $x$.

    Parameters
    @@ -2933,7 +2933,7 @@
    [in]symbolAn identifier (or name) for the returned symbolic variable.

    Return an Expression representing a scalar symbolic function with the identifier specified by symbol. The function's symbolic dependencies are specified by the input arguments.

    -

    For example, if the symbol is the string "f", and the arguments to the function that is generated are the symbolic variable x and the symbolic expression y+z, then the generic symbolic function that is returned represents $f(x, y+z)$.

    +

    For example, if the symbol is the string "f", and the arguments to the function that is generated are the symbolic variable x and the symbolic expression y+z, then the generic symbolic function that is returned represents $f(x, y+z)$.

    Parameters
    @@ -2971,7 +2971,7 @@
    [in]symbolAn identifier (or name) for the returned symbolic function.

    Return an Expression representing a scalar symbolic function with the identifier specified by symbol. The function's symbolic dependencies are specified by the keys to the input arguments map; the values stored in the map are ignored.

    -

    For example, if the symbol is the string "f", and the arguments to the function that is generated are the symbolic variable x and the symbolic expression y+z, then the generic symbolic function that is returned represents $f(x, y+z)$.

    +

    For example, if the symbol is the string "f", and the arguments to the function that is generated are the symbolic variable x and the symbolic expression y+z, then the generic symbolic function that is returned represents $f(x, y+z)$.

    Parameters
    @@ -3015,7 +3015,7 @@
    [in]symbolAn identifier (or name) for the returned symbolic function.
    -
    Returns
    The symbolic function or expression representing the result $\frac{\partial f}{\partial x}$.
    +
    Returns
    The symbolic function or expression representing the result $\frac{\partial f}{\partial x}$.

    Definition at line 70 of file symengine_scalar_operations.cc.

    @@ -4270,7 +4270,7 @@

    Return a substitution map that has any explicit interdependencies between the entries of the input substitution_map resolved.

    The force_cyclic_dependency_resolution flag exists to ensure, if desired, that no cyclic dependencies can exist in the returned map. If a cyclic dependency exists in the input substitution map, substitution_map, then with this flag set to true the dependency cycle is broken by a dictionary-ordered substitution. For example, if the substitution map contains two entries map["a"] -> "b" and map["b"] -> "a", then the result of calling this function would be a map with the elements map["a"] -> "a" and map["b"] -> "a".

    If one symbol is an explicit function of another, and it is desired that all their values are completely resolved, then it may be necessary to perform substitution a number of times before the result is finalized. This function performs substitution sweeps for a set of symbolic variables until all explicit relationships between the symbols in the map have been resolved. Whether each entry returns a symbolic or real value depends on the nature of the values stored in the substitution map. If the values associated with a key are also symbolic then the returned result may still be symbolic in nature. The terminal result of using the input substitution map, symbol_values, is then guaranteed to be rendered by a single substitution of the returned dependency-resolved map.

    -

    Example: If map["a"] -> 1 and map["b"] -> "a"+ 2, then the function $f(a,b(a)) = a+b$ will be evaluated and the result $f\vert_{a=1,b=a+2} = 3+a$ is determined upon the completion of the first sweep. A second sweep is therefore necessary to resolve the final symbol, and the returned value is ultimately $f = [3+a]_{a=1} = 4$. By resolving the explicit relationships between all symbols in the map, we determine that map["a"] -> 1 and map["b"] -> 1 + 2 = 3 and thus, using only one substitution, that $f = a+b = 1 + 3 = 4$.

    +

    Example: If map["a"] -> 1 and map["b"] -> "a"+ 2, then the function $f(a,b(a)) = a+b$ will be evaluated and the result $f\vert_{a=1,b=a+2} = 3+a$ is determined upon the completion of the first sweep. A second sweep is therefore necessary to resolve the final symbol, and the returned value is ultimately $f = [3+a]_{a=1} = 4$. By resolving the explicit relationships between all symbols in the map, we determine that map["a"] -> 1 and map["b"] -> 1 + 2 = 3 and thus, using only one substitution, that $f = a+b = 1 + 3 = 4$.

    @@ -4345,11 +4345,11 @@ If the symbols stored in the map are explicitly dependent on one another, then the returned result depends on the order in which the map is traversed. It is recommended to first resolve all interdependencies in the map using the resolve_explicit_dependencies() function.

    Examples:

    1. -

      If map["a"] == 1 and map["b"] == "a" + 2, then the function $f(a,b(a)) := a+b$ will be evaluated and the result $f\vert_{a=1,b=a+2} = 3+a$ is returned. This return is because the symbol "a" is substituted throughout the function first, and only then is the symbol "b(a)" substituted, by which time its explicit dependency on "a" cannot be resolved.

      +

      If map["a"] == 1 and map["b"] == "a" + 2, then the function $f(a,b(a)) := a+b$ will be evaluated and the result $f\vert_{a=1,b=a+2} = 3+a$ is returned. This return is because the symbol "a" is substituted throughout the function first, and only then is the symbol "b(a)" substituted, by which time its explicit dependency on "a" cannot be resolved.

    2. -If map["a"] == "b"+2 and map["b"] == 1, then the function $f(a(b),b): = a+b$ will be evaluated and the result $f\vert_{a=b+2, b} = [b+2+b]_{b=1} = 4$ is returned. This is because the explicitly dependent symbol "a(b)" is substituted first followed by the symbol "b".
    3. +If map["a"] == "b"+2 and map["b"] == 1, then the function $f(a(b),b): = a+b$ will be evaluated and the result $f\vert_{a=b+2, b} = [b+2+b]_{b=1} = 4$ is returned. This is because the explicitly dependent symbol "a(b)" is substituted first followed by the symbol "b".
    @@ -4531,7 +4531,7 @@

    Return a vector of Expressions representing a vectorial symbolic variable with the identifier specified by symbol.

    -

    For example, if the symbol is the string "v" then the vectorial symbolic variable that is returned represents the vector $v$. Each component of $v$ is prefixed by the given symbol, and has a suffix that indicates its component index.

    +

    For example, if the symbol is the string "v" then the vectorial symbolic variable that is returned represents the vector $v$. Each component of $v$ is prefixed by the given symbol, and has a suffix that indicates its component index.

    Template Parameters
    @@ -4568,7 +4568,7 @@
    dimThe dimension of the returned tensor.

    Return a tensor of Expressions representing a tensorial symbolic variable with the identifier specified by symbol.

    -

    For example, if the symbol is the string "T" then the tensorial symbolic variable that is returned represents the vector $T$. Each component of $T$ is prefixed by the given symbol, and has a suffix that indicates its component indices.

    +

    For example, if the symbol is the string "T" then the tensorial symbolic variable that is returned represents the vector $T$. Each component of $T$ is prefixed by the given symbol, and has a suffix that indicates its component indices.

    Template Parameters
    @@ -4797,7 +4797,7 @@
    rankThe rank of the returned tensor.
    -
    Returns
    The tensor of symbolic functions or expressions representing the result $\frac{\partial f}{\partial \mathbf{T}}$.
    +
    Returns
    The tensor of symbolic functions or expressions representing the result $\frac{\partial f}{\partial \mathbf{T}}$.
    @@ -4834,7 +4834,7 @@ -
    Returns
    The symmetric tensor of symbolic functions or expressions representing the result $\frac{\partial f}{\partial \mathbf{S}}$.
    +
    Returns
    The symmetric tensor of symbolic functions or expressions representing the result $\frac{\partial f}{\partial \mathbf{S}}$.
    @@ -4871,7 +4871,7 @@ -
    Returns
    The tensor of symbolic functions or expressions representing the result $\frac{\partial f}{\partial \mathbf{T}}$.
    +
    Returns
    The tensor of symbolic functions or expressions representing the result $\frac{\partial f}{\partial \mathbf{T}}$.
    @@ -4908,7 +4908,7 @@ -
    Returns
    The symmetric tensor of symbolic functions or expressions representing the result $\frac{\partial f}{\partial \mathbf{S}}$.
    +
    Returns
    The symmetric tensor of symbolic functions or expressions representing the result $\frac{\partial f}{\partial \mathbf{S}}$.
    @@ -4945,7 +4945,7 @@ -
    Returns
    The tensor of symbolic functions or expressions representing the result $\frac{\partial \mathbf{T}}{\partial x}$.
    +
    Returns
    The tensor of symbolic functions or expressions representing the result $\frac{\partial \mathbf{T}}{\partial x}$.
    @@ -4982,7 +4982,7 @@ -
    Returns
    The symmetric tensor of symbolic functions or expressions representing the result $\frac{\partial \mathbf{S}}{\partial x}$.
    +
    Returns
    The symmetric tensor of symbolic functions or expressions representing the result $\frac{\partial \mathbf{S}}{\partial x}$.
    @@ -5019,7 +5019,7 @@ -
    Returns
    The tensor of symbolic functions or expressions representing the result $\frac{\partial \mathbf{T}}{\partial x}$.
    +
    Returns
    The tensor of symbolic functions or expressions representing the result $\frac{\partial \mathbf{T}}{\partial x}$.
    @@ -5056,7 +5056,7 @@ -
    Returns
    The symmetric tensor of symbolic functions or expressions representing the result $\frac{\partial \mathbf{S}}{\partial x}$.
    +
    Returns
    The symmetric tensor of symbolic functions or expressions representing the result $\frac{\partial \mathbf{S}}{\partial x}$.
    @@ -5093,8 +5093,8 @@ -
    Returns
    The tensor of symbolic functions or variables representing the result $\frac{\partial \mathbf{T}_{1}}{\partial
-\mathbf{T}_{2}}$.
    +
    Returns
    The tensor of symbolic functions or variables representing the result $\frac{\partial \mathbf{T}_{1}}{\partial
+\mathbf{T}_{2}}$.
    @@ -5131,8 +5131,8 @@ -
    Returns
    The symmetric tensor of symbolic functions or variables representing the result $\frac{\partial \mathbf{S}_{1}}{\partial
-\mathbf{S}_{2}}$.
    +
    Returns
    The symmetric tensor of symbolic functions or variables representing the result $\frac{\partial \mathbf{S}_{1}}{\partial
+\mathbf{S}_{2}}$.
    @@ -5169,7 +5169,7 @@ -
    Returns
    The tensor of symbolic functions or variables representing the result $\frac{\partial \mathbf{T}}{\partial \mathbf{S}}$.
    +
    Returns
    The tensor of symbolic functions or variables representing the result $\frac{\partial \mathbf{T}}{\partial \mathbf{S}}$.
    @@ -5206,7 +5206,7 @@ -
    Returns
    The tensor of symbolic functions or variables representing the result $\frac{\partial \mathbf{S}}{\partial \mathbf{T}}$.
    +
    Returns
    The tensor of symbolic functions or variables representing the result $\frac{\partial \mathbf{S}}{\partial \mathbf{T}}$.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDoFRenumbering.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDoFRenumbering.html 2023-08-09 23:38:56.874614962 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDoFRenumbering.html 2023-08-09 23:38:56.874614962 +0000 @@ -226,13 +226,13 @@

    Using the constraint information usually leads to reductions in bandwidth of 10 or 20 per cent, but may for some very unstructured grids also lead to an increase. You have to weigh the decrease in your case with the time spent to use the constraint information, which usually is several times longer than the ‘pure’ renumbering algorithm.

    In almost all cases, the renumbering scheme finds a corner to start with. Since there is more than one corner in most grids and since even an interior degree of freedom may be a better starting point, giving the starting point by the user may be a viable way if you have a simple scheme to derive a suitable point (e.g. by successively taking the third child of the cell top left of the coarsest level, taking its third vertex and the dof index thereof, if you want the top left corner vertex). If you do not know beforehand what your grid will look like (e.g. when using adaptive algorithms), searching a best starting point may be difficult, however, and in many cases will not justify the effort.

    Component-wise and block-wise numberings

    -

    For finite elements composed of several base elements using the FESystem class, or for elements which provide several components themselves, it may be of interest to sort the DoF indices by component. This will then bring out the block matrix structure, since otherwise the degrees of freedom are numbered cell-wise without taking into account that they may belong to different components. For example, one may want to sort degree of freedom for a Stokes discretization so that we first get all velocities and then all the pressures so that the resulting matrix naturally decomposes into a $2\times 2$ system.

    +

    For finite elements composed of several base elements using the FESystem class, or for elements which provide several components themselves, it may be of interest to sort the DoF indices by component. This will then bring out the block matrix structure, since otherwise the degrees of freedom are numbered cell-wise without taking into account that they may belong to different components. For example, one may want to sort degree of freedom for a Stokes discretization so that we first get all velocities and then all the pressures so that the resulting matrix naturally decomposes into a $2\times 2$ system.

    This kind of numbering may be obtained by calling the component_wise() function of this class. Since it does not touch the order of indices within each component, it may be worthwhile to first renumber using the Cuthill- McKee or a similar algorithm and afterwards renumbering component-wise. This will bring out the matrix structure and additionally have a good numbering within each block.

    The component_wise() function allows not only to honor enumeration based on vector components, but also allows to group together vector components into "blocks" using a defaulted argument to the various DoFRenumbering::component_wise() functions (see GlossComponent vs GlossBlock for a description of the difference). The blocks designated through this argument may, but do not have to be, equal to the blocks that the finite element reports. For example, a typical Stokes element would be

    FESystem<dim> stokes_fe (FE_Q<dim>(2), dim, // dim velocities
    FE_Q<dim>(1), 1); // one pressure
    Definition: fe_system.h:209
    Definition: fe_q.h:551
    -

    This element has dim+1 vector components and equally many blocks. However, one may want to consider the velocities as one logical block so that all velocity degrees of freedom are enumerated the same way, independent of whether they are $x$- or $y$-velocities. This is done, for example, in step-20 and step-22 as well as several other tutorial programs.

    +

    This element has dim+1 vector components and equally many blocks. However, one may want to consider the velocities as one logical block so that all velocity degrees of freedom are enumerated the same way, independent of whether they are $x$- or $y$-velocities. This is done, for example, in step-20 and step-22 as well as several other tutorial programs.

    On the other hand, if you really want to use block structure reported by the finite element itself (a case that is often the case if you have finite elements that have multiple vector components, e.g. the FE_RaviartThomas or FE_Nedelec elements) then you can use the DoFRenumbering::block_wise instead of the DoFRenumbering::component_wise functions.

    Cell-wise numbering

    Given an ordered vector of cells, the function cell_wise() sorts the degrees of freedom such that degrees on earlier cells of this vector will occur before degrees on later cells.

    @@ -245,7 +245,7 @@

    The MatrixFree class provides optimized algorithms for interleaving operations on vectors before and after the access of the vector data in the respective loops. The algorithm matrix_free_data_locality() makes sure that all unknowns with a short distance between the first and last access are grouped together, in order to increase the spatial data locality.

    A comparison of reordering strategies

    As a benchmark of comparison, let us consider what the different sparsity patterns produced by the various algorithms when using the $Q_2^d\times
-Q_1$ element combination typically employed in the discretization of Stokes equations, when used on the mesh obtained in step-22 after one adaptive mesh refinement in 3d. The space dimension together with the coupled finite element leads to a rather dense system matrix with, on average around 180 nonzero entries per row. After applying each of the reordering strategies shown below, the degrees of freedom are also sorted using DoFRenumbering::component_wise into velocity and pressure groups; this produces the $2\times 2$ block structure seen below with the large velocity-velocity block at top left, small pressure-pressure block at bottom right, and coupling blocks at top right and bottom left.

    +Q_1$" src="form_951.png"/> element combination typically employed in the discretization of Stokes equations, when used on the mesh obtained in step-22 after one adaptive mesh refinement in 3d. The space dimension together with the coupled finite element leads to a rather dense system matrix with, on average around 180 nonzero entries per row. After applying each of the reordering strategies shown below, the degrees of freedom are also sorted using DoFRenumbering::component_wise into velocity and pressure groups; this produces the $2\times 2$ block structure seen below with the large velocity-velocity block at top left, small pressure-pressure block at bottom right, and coupling blocks at top right and bottom left.

    The goal of reordering strategies is to improve the preconditioner. In step-22 we use a SparseILU to preconditioner for the velocity-velocity block at the top left. The quality of the preconditioner can then be measured by the number of CG iterations required to solve a linear system with this block. For some of the reordering strategies below we record this number for adaptive refinement cycle 3, with 93176 degrees of freedom; because we solve several linear systems with the same matrix in the Schur complement, the average number of iterations is reported. The lower the number the better the preconditioner and consequently the better the renumbering of degrees of freedom is suited for this task. We also state the run-time of the program, in part determined by the number of iterations needed, for the first 4 cycles on one of our machines. Note that the reported times correspond to the run time of the entire program, not just the affected solver; if a program runs twice as fast with one particular ordering than with another one, then this means that the actual solver is actually several times faster.

    @@ -473,7 +473,7 @@
    const std::vector< unsigned int > &&#href_anchor"paramname">target_component = std::vector<unsigned int>()&#href_anchor"memdoc"> -

    Sort the degrees of freedom by vector component. The numbering within each component is not touched, so a degree of freedom with index $i$, belonging to some component, and another degree of freedom with index $j$ belonging to the same component will be assigned new indices $n(i)$ and $n(j)$ with $n(i)<n(j)$ if $i<j$ and $n(i)>n(j)$ if $i>j$.

    +

    Sort the degrees of freedom by vector component. The numbering within each component is not touched, so a degree of freedom with index $i$, belonging to some component, and another degree of freedom with index $j$ belonging to the same component will be assigned new indices $n(i)$ and $n(j)$ with $n(i)<n(j)$ if $i<j$ and $n(i)>n(j)$ if $i>j$.

    You can specify that the components are ordered in a different way than suggested by the FESystem object you use. To this end, set up the vector target_component such that the entry at index i denotes the number of the target component for dofs with component i in the FESystem. Naming the same target component more than once is possible and results in a blocking of several components into one. This is discussed in step-22. If you omit this argument, the same order as given by the finite element is used.

    If one of the base finite elements from which the global finite element under consideration here, is a non-primitive one, i.e. its shape functions have more than one non-zero component, then it is not possible to associate these degrees of freedom with a single vector component. In this case, they are associated with the first vector component to which they belong.

    For finite elements with only one component, or a single non-primitive base element, this function is the identity operation.

    @@ -575,7 +575,7 @@
    -

    Sort the degrees of freedom by vector block. The numbering within each block is not touched, so a degree of freedom with index $i$, belonging to some block, and another degree of freedom with index $j$ belonging to the same block will be assigned new indices $n(i)$ and $n(j)$ with $n(i)<n(j)$ if $i<j$ and $n(i)>n(j)$ if $i>j$.

    +

    Sort the degrees of freedom by vector block. The numbering within each block is not touched, so a degree of freedom with index $i$, belonging to some block, and another degree of freedom with index $j$ belonging to the same block will be assigned new indices $n(i)$ and $n(j)$ with $n(i)<n(j)$ if $i<j$ and $n(i)>n(j)$ if $i>j$.

    Note
    This function only succeeds if each of the elements in the hp::FECollection attached to the DoFHandler argument has exactly the same number of blocks (see the glossary for more information). Note that this is not always given: while the hp::FECollection class ensures that all of its elements have the same number of vector components, they need not have the same number of blocks. At the same time, this function here needs to match individual blocks across elements and therefore requires that elements have the same number of blocks and that subsequent blocks in one element have the same meaning as in another element.

    Definition at line 999 of file dof_renumbering.cc.

    @@ -679,7 +679,7 @@
  • For meshes based on parallel::distributed::Triangulation, the locally owned cells of each MPI process are contiguous in Z order. That means that numbering degrees of freedom by visiting cells in Z order yields locally owned DoF indices that consist of contiguous ranges for each process. This is also true for the default ordering of DoFs on such triangulations, but the default ordering creates an enumeration that also depends on how many processors participate in the mesh, whereas the one generated by this function enumerates the degrees of freedom on a particular cell with indices that will be the same regardless of how many processes the mesh is split up between.
  • For meshes based on parallel::shared::Triangulation, the situation is more complex. Here, the set of locally owned cells is determined by a partitioning algorithm (selected by passing an object of type parallel::shared::Triangulation::Settings to the constructor of the triangulation), and in general these partitioning algorithms may assign cells to subdomains based on decisions that may have nothing to do with the Z order. (Though it is possible to select these flags in a way so that partitioning uses the Z order.) As a consequence, the cells of one subdomain are not contiguous in Z order, and if one renumbered degrees of freedom based on the Z order of cells, one would generally end up with DoF indices that on each processor do not form a contiguous range. This is often inconvenient (for example, because PETSc cannot store vectors and matrices for which the locally owned set of indices is not contiguous), and consequently this function uses the following algorithm for parallel::shared::Triangulation objects:

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDoFTools.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDoFTools.html 2023-08-09 23:38:56.946615500 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceDoFTools.html 2023-08-09 23:38:56.942615470 +0000 @@ -306,7 +306,7 @@

    (As a side note, for corner cases: The question what a degree of freedom on the boundary is, is not so easy. It should really be a degree of freedom of which the respective basis function has nonzero values on the boundary. At least for Lagrange elements this definition is equal to the statement that the off-point, or what deal.II calls support_point, of the shape function, i.e. the point where the function assumes its nominal value (for Lagrange elements this is the point where it has the function value 1), is located on the boundary. We do not check this directly, the criterion is rather defined through the information the finite element class gives: the FiniteElement class defines the numbers of basis functions per vertex, per line, and so on and the basis functions are numbered after this information; a basis function is to be considered to be on the face of a cell (and thus on the boundary if the cell is at the boundary) according to it belonging to a vertex, line, etc but not to the interior of the cell. The finite element uses the same cell-wise numbering so that we can say that if a degree of freedom was numbered as one of the dofs on lines, we assume that it is located on the line. Where the off-point actually is, is a secret of the finite element (well, you can ask it, but we don't do it here) and not relevant in this context.)

    Setting up sparsity patterns for boundary matrices

    In some cases, one wants to only work with DoFs that sit on the boundary. One application is, for example, if rather than interpolating non- homogeneous boundary values, one would like to project them. For this, we need two things: a way to identify nodes that are located on (parts of) the boundary, and a way to build matrices out of only degrees of freedom that are on the boundary (i.e. much smaller matrices, in which we do not even build the large zero block that stems from the fact that most degrees of freedom have no support on the boundary of the domain). The first of these tasks is done by the map_dof_to_boundary_indices() function (described above).

    -

    The second part requires us first to build a sparsity pattern for the couplings between boundary nodes, and then to actually build the components of this matrix. While actually computing the entries of these small boundary matrices is discussed in the MatrixCreator namespace, the creation of the sparsity pattern is done by the create_boundary_sparsity_pattern() function. For its work, it needs to have a numbering of all those degrees of freedom that are on those parts of the boundary that we are interested in. You can get this from the map_dof_to_boundary_indices() function. It then builds the sparsity pattern corresponding to integrals like $\int_\Gamma \varphi_{b2d(i)} \varphi_{b2d(j)} dx$, where $i$ and $j$ are indices into the matrix, and $b2d(i)$ is the global DoF number of a degree of freedom sitting on a boundary (i.e., $b2d$ is the inverse of the mapping returned by map_dof_to_boundary_indices() function).

    +

    The second part requires us first to build a sparsity pattern for the couplings between boundary nodes, and then to actually build the components of this matrix. While actually computing the entries of these small boundary matrices is discussed in the MatrixCreator namespace, the creation of the sparsity pattern is done by the create_boundary_sparsity_pattern() function. For its work, it needs to have a numbering of all those degrees of freedom that are on those parts of the boundary that we are interested in. You can get this from the map_dof_to_boundary_indices() function. It then builds the sparsity pattern corresponding to integrals like $\int_\Gamma \varphi_{b2d(i)} \varphi_{b2d(j)} dx$, where $i$ and $j$ are indices into the matrix, and $b2d(i)$ is the global DoF number of a degree of freedom sitting on a boundary (i.e., $b2d$ is the inverse of the mapping returned by map_dof_to_boundary_indices() function).

    Enumeration Type Documentation

    ◆ Coupling

    @@ -512,7 +512,7 @@

    Otherwise, if face_1 and face_2 are not active faces, this function loops recursively over the children of face_1 and face_2. If only one of the two faces is active, then we recursively iterate over the children of the non-active ones and make sure that the solution function on the refined side equals that on the non-refined face in much the same way as we enforce hanging node constraints at places where differently refined cells come together. (However, unlike hanging nodes, we do not enforce the requirement that there be only a difference of one refinement level between the two sides of the domain you would like to be periodic).

    This routine only constrains DoFs that are not already constrained. If this routine encounters a DoF that already is constrained (for instance by Dirichlet boundary conditions), the old setting of the constraint (dofs the entry is constrained to, inhomogeneities) is kept and nothing happens.

    The flags in the component_mask (see GlossComponentMask) denote which components of the finite element space shall be constrained with periodic boundary conditions. If it is left as specified by the default value all components are constrained. If it is different from the default value, it is assumed that the number of entries equals the number of components of the finite element. This can be used to enforce periodicity in only one variable in a system of equations.

    -

    face_orientation, face_flip and face_rotation describe an orientation that should be applied to face_1 prior to matching and constraining DoFs. This has nothing to do with the actual orientation of the given faces in their respective cells (which for boundary faces is always the default) but instead how you want to see periodicity to be enforced. For example, by using these flags, you can enforce a condition of the kind $u(0,y)=u(1,1-y)$ (i.e., a Moebius band) or in 3d a twisted torus. More precisely, these flags match local face DoF indices in the following manner:

    +

    face_orientation, face_flip and face_rotation describe an orientation that should be applied to face_1 prior to matching and constraining DoFs. This has nothing to do with the actual orientation of the given faces in their respective cells (which for boundary faces is always the default) but instead how you want to see periodicity to be enforced. For example, by using these flags, you can enforce a condition of the kind $u(0,y)=u(1,1-y)$ (i.e., a Moebius band) or in 3d a twisted torus. More precisely, these flags match local face DoF indices in the following manner:

    In 2d: face_orientation must always be true, face_rotation is always false, and face_flip has the meaning of line_flip; this implies e.g. for Q1:

    face_orientation = true, face_flip = false, face_rotation = false:
    @@ -585,7 +585,7 @@
    and any combination of that...

    Optionally a matrix matrix along with a std::vector first_vector_components can be specified that describes how DoFs on face_1 should be modified prior to constraining to the DoFs of face_2. Here, two declarations are possible: If the std::vector first_vector_components is non empty the matrix is interpreted as a dim $\times$ dim rotation matrix that is applied to all vector valued blocks listed in first_vector_components of the FESystem. If first_vector_components is empty the matrix is interpreted as an interpolation matrix with size no_face_dofs $\times$ no_face_dofs.

    This function makes sure that identity constraints don't create cycles in constraints.

    -

    periodicity_factor can be used to implement Bloch periodic conditions (a.k.a. phase shift periodic conditions) of the form $\psi(\mathbf{r})=e^{-i\mathbf{k}\cdot\mathbf{r}}u(\mathbf{r})$ where $u$ is periodic with the same periodicity as the crystal lattice and $\mathbf{k}$ is the wavevector, see https://en.wikipedia.org/wiki/Bloch_wave. The solution at face_2 is equal to the solution at face_1 times periodicity_factor. For example, if the solution at face_1 is $\psi(0)$ and $\mathbf{d}$ is the corresponding point on face_2, then the solution at face_2 should be $\psi(d) = \psi(0)e^{-i \mathbf{k}\cdot \mathbf{d}}$. This condition can be implemented using $\mathrm{periodicity\_factor}=e^{-i \mathbf{k}\cdot \mathbf{d}}$.

    +

    periodicity_factor can be used to implement Bloch periodic conditions (a.k.a. phase shift periodic conditions) of the form $\psi(\mathbf{r})=e^{-i\mathbf{k}\cdot\mathbf{r}}u(\mathbf{r})$ where $u$ is periodic with the same periodicity as the crystal lattice and $\mathbf{k}$ is the wavevector, see https://en.wikipedia.org/wiki/Bloch_wave. The solution at face_2 is equal to the solution at face_1 times periodicity_factor. For example, if the solution at face_1 is $\psi(0)$ and $\mathbf{d}$ is the corresponding point on face_2, then the solution at face_2 should be $\psi(d) = \psi(0)e^{-i \mathbf{k}\cdot \mathbf{d}}$. This condition can be implemented using $\mathrm{periodicity\_factor}=e^{-i \mathbf{k}\cdot \mathbf{d}}$.

    Detailed information can be found in the see Glossary entry on periodic boundary conditions.

    Definition at line 2292 of file dof_tools_constraints.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFESeries.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFESeries.html 2023-08-09 23:38:56.962615619 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFESeries.html 2023-08-09 23:38:56.962615619 +0000 @@ -177,7 +177,7 @@
    -

    Linear regression least-square fit of $y = k \, x + b$. The size of the input vectors should be equal and more than 1. The returned pair will contain $k$ (first) and $b$ (second).

    +

    Linear regression least-square fit of $y = k \, x + b$. The size of the input vectors should be equal and more than 1. The returned pair will contain $k$ (first) and $b$ (second).

    Definition at line 30 of file fe_series.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFETools.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFETools.html 2023-08-09 23:38:57.002615918 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFETools.html 2023-08-09 23:38:57.002615918 +0000 @@ -186,7 +186,7 @@ void&#href_anchor"memTemplItemRight" valign="bottom">extrapolate (const DoFHandler< dim, spacedim > &dof1, const InVector &z1, const DoFHandler< dim, spacedim > &dof2, const AffineConstraints< typename OutVector::value_type > &constraints, OutVector &z2) &#href_anchor"details" id="details">

    Detailed Description

    This namespace offers interpolations and extrapolations of discrete functions of one FiniteElement fe1 to another FiniteElement fe2.

    -

    It also provides the local interpolation matrices that interpolate on each cell. Furthermore it provides the difference matrix $id-I_h$ that is needed for evaluating $(id-I_h)z$ for e.g. the dual solution $z$.

    +

    It also provides the local interpolation matrices that interpolate on each cell. Furthermore it provides the difference matrix $id-I_h$ that is needed for evaluating $(id-I_h)z$ for e.g. the dual solution $z$.

    For more information about the spacedim template parameter check the documentation of FiniteElement or the one of Triangulation.

    Function Documentation

    @@ -370,7 +370,7 @@

    Compute the identity matrix minus the back interpolation matrix. The difference_matrix will be of size (fe1.n_dofs_per_cell(), fe1.n_dofs_per_cell()) after this function. Previous content of the argument will be overwritten.

    -

    This function computes the matrix that transforms a fe1 function $z$ to $z-I_hz$ where $I_h$ denotes the interpolation operator from the fe1 space to the fe2 space. This matrix hence is useful to evaluate error-representations where $z$ denotes the dual solution.

    +

    This function computes the matrix that transforms a fe1 function $z$ to $z-I_hz$ where $I_h$ denotes the interpolation operator from the fe1 space to the fe2 space. This matrix hence is useful to evaluate error-representations where $z$ denotes the dual solution.

    @@ -425,20 +425,20 @@

    This is a rather specialized function used during the construction of finite element objects. It is used to build the basis of shape functions for an element, given a set of polynomials and interpolation points. The function is only implemented for finite elements with exactly dim vector components. In particular, this applies to classes derived from the FE_PolyTensor class.

    -

    Specifically, the purpose of this function is as follows: FE_PolyTensor receives, from its derived classes, an argument that describes a polynomial space. This space may be parameterized in terms of monomials, or in some other way, but is in general not in the form that we use for finite elements where we typically want to use a basis that is derived from some kind of node functional (e.g., the interpolation at specific points). Concretely, assume that the basis used by the polynomial space is $\{\tilde\varphi_j(\mathbf x)\}_{j=1}^N$, and that the node functionals of the finite element are $\{\Psi_i\}_{i=1}^N$. We then want to compute a basis $\{\varphi_j(\mathbf x)\}_{j=1}^N$ for the finite element space so that $\Psi_i[\varphi_j] = \delta_{ij}$. To do this, we can set $\varphi_j(\mathbf x) = \sum_{k=1}^N c_{jk} \tilde\varphi_k(\mathbf x)$ where we need to determine the expansion coefficients $c_{jk}$. We do this by applying $\Psi_i$ to both sides of the equation, to obtain

    +

    Specifically, the purpose of this function is as follows: FE_PolyTensor receives, from its derived classes, an argument that describes a polynomial space. This space may be parameterized in terms of monomials, or in some other way, but is in general not in the form that we use for finite elements where we typically want to use a basis that is derived from some kind of node functional (e.g., the interpolation at specific points). Concretely, assume that the basis used by the polynomial space is $\{\tilde\varphi_j(\mathbf x)\}_{j=1}^N$, and that the node functionals of the finite element are $\{\Psi_i\}_{i=1}^N$. We then want to compute a basis $\{\varphi_j(\mathbf x)\}_{j=1}^N$ for the finite element space so that $\Psi_i[\varphi_j] = \delta_{ij}$. To do this, we can set $\varphi_j(\mathbf x) = \sum_{k=1}^N c_{jk} \tilde\varphi_k(\mathbf x)$ where we need to determine the expansion coefficients $c_{jk}$. We do this by applying $\Psi_i$ to both sides of the equation, to obtain

    \begin{align*}
   \Psi_i [\varphi_j] = \sum_{k=1}^N c_{jk} \Psi_i[\tilde\varphi_k],
 \end{align*}

    -

    and we know that the left hand side equals $\delta_{ij}$. If you think of this as a system of $N\times N$ equations for the elements of a matrix on the left and on the right, then this can be written as

    +

    and we know that the left hand side equals $\delta_{ij}$. If you think of this as a system of $N\times N$ equations for the elements of a matrix on the left and on the right, then this can be written as

    \begin{align*}
   I = C X^T
 \end{align*}

    -

    where $C$ is the matrix of coefficients $c_{jk}$ and $X_{ik} = \Psi_i[\tilde\varphi_k]$. Consequently, in order to compute the expansion coefficients $C=X^{-T}$, we need to apply the node functionals to all functions of the "raw" basis of the polynomial space.

    +

    where $C$ is the matrix of coefficients $c_{jk}$ and $X_{ik} = \Psi_i[\tilde\varphi_k]$. Consequently, in order to compute the expansion coefficients $C=X^{-T}$, we need to apply the node functionals to all functions of the "raw" basis of the polynomial space.

    Until the finite element receives this matrix $X$ back, it describes its shape functions (e.g., in FiniteElement::shape_value()) in the form $\tilde\varphi_j$. After it calls this function, it has the expansion coefficients and can describe its shape functions as $\varphi_j$.

    This function therefore computes this matrix $X$, for the following specific circumstances:

    @@ -1071,7 +1071,7 @@
    -

    Compute $(Id-I_h)z_1$ for a given dof1-function $z_1$, where $I_h$ is the interpolation from fe1 to fe2. The result $(Id-I_h)z_1$ is written into z1_difference.

    +

    Compute $(Id-I_h)z_1$ for a given dof1-function $z_1$, where $I_h$ is the interpolation from fe1 to fe2. The result $(Id-I_h)z_1$ is written into z1_difference.

    Note, that this function does not work for continuous elements at hanging nodes. For that case use the interpolation_difference function, below, that takes an additional AffineConstraints object.

    @@ -1123,7 +1123,7 @@
    -

    Compute $(Id-I_h)z_1$ for a given dof1-function $z_1$, where $I_h$ is the interpolation from fe1 to fe2. The result $(Id-I_h)z_1$ is written into z1_difference. constraints1 and constraints2 are the hanging node constraints corresponding to dof1 and dof2, respectively. These objects are particular important when continuous elements on grids with hanging nodes (locally refined grids) are involved.

    +

    Compute $(Id-I_h)z_1$ for a given dof1-function $z_1$, where $I_h$ is the interpolation from fe1 to fe2. The result $(Id-I_h)z_1$ is written into z1_difference. constraints1 and constraints2 are the hanging node constraints corresponding to dof1 and dof2, respectively. These objects are particular important when continuous elements on grids with hanging nodes (locally refined grids) are involved.

    For parallel computations, supply z1 with ghost elements and z1_difference without ghost elements.

    @@ -1214,7 +1214,7 @@
  • It then performs a loop over all non-active cells of dof2. If such a non-active cell has at least one active child, then we call the children of this cell a "patch". We then interpolate from the children of this patch to the patch, using the finite element space associated with dof2 and immediately interpolate back to the children. In essence, this information throws away all information in the solution vector that lives on a scale smaller than the patch cell.
  • Since we traverse non-active cells from the coarsest to the finest levels, we may find patches that correspond to child cells of previously treated patches if the mesh had been refined adaptively (this cannot happen if the mesh has been refined globally because there the children of a patch are all active). We also perform the operation described above on these patches, but it is easy to see that on patches that are children of previously treated patches, the operation is now the identity operation (since it interpolates from the children of the current patch a function that had previously been interpolated to these children from an even coarser patch). Consequently, this does not alter the solution vector any more.
  • -

    The name of the function originates from the fact that it can be used to construct a representation of a function of higher polynomial degree on a once coarser mesh. For example, if you imagine that you start with a $Q_1$ function on a globally refined mesh, and that dof2 is associated with a $Q_2$ element, then this function computes the equivalent of the operator $I_{2h}^{(2)}$ interpolating the original piecewise linear function onto a quadratic function on a once coarser mesh with mesh size $2h$ (but representing this function on the original mesh with size $h$). If the exact solution is sufficiently smooth, then $u^\ast=I_{2h}^{(2)}u_h$ is typically a better approximation to the exact solution $u$ of the PDE than $u_h$ is. In other words, this function provides a postprocessing step that improves the solution in a similar way one often obtains by extrapolating a sequence of solutions, explaining the origin of the function's name.

    +

    The name of the function originates from the fact that it can be used to construct a representation of a function of higher polynomial degree on a once coarser mesh. For example, if you imagine that you start with a $Q_1$ function on a globally refined mesh, and that dof2 is associated with a $Q_2$ element, then this function computes the equivalent of the operator $I_{2h}^{(2)}$ interpolating the original piecewise linear function onto a quadratic function on a once coarser mesh with mesh size $2h$ (but representing this function on the original mesh with size $h$). If the exact solution is sufficiently smooth, then $u^\ast=I_{2h}^{(2)}u_h$ is typically a better approximation to the exact solution $u$ of the PDE than $u_h$ is. In other words, this function provides a postprocessing step that improves the solution in a similar way one often obtains by extrapolating a sequence of solutions, explaining the origin of the function's name.

    Note
    The resulting field does not satisfy continuity requirements of the given finite elements if the algorithm outlined above is used. When you use continuous elements on grids with hanging nodes, please use the extrapolate function with an additional AffineConstraints argument, see below.
    Since this function operates on patches of cells, it requires that the underlying grid is refined at least once for every coarse grid cell. If this is not the case, an exception will be raised.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFETools_1_1Compositing.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFETools_1_1Compositing.html 2023-08-09 23:38:57.026616097 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFETools_1_1Compositing.html 2023-08-09 23:38:57.026616097 +0000 @@ -125,13 +125,13 @@
    1. Tensor product construction (do_tensor_product=true): The tensor product construction, in the simplest case, builds a vector-valued element from scalar elements (see this documentation module and this glossary entry for more information). To give an example, consider creating a vector-valued element with two vector components, where the first should have linear shape functions and the second quadratic shape functions. In 1d, the shape functions (on the reference cell) of the base elements are then

      -\begin{align*}
+<picture><source srcset=\begin{align*}
   Q_1 &= \{ 1-x, x \},
   \\  Q_2 &= \{ 2(\frac 12 - x)(1-x), 2(x - \frac 12)x, 4x(1-x) \},
-\end{align*} +\end{align*}" src="form_1232.png"/>

      where shape functions are ordered in the usual way (first on the first vertex, then on the second vertex, then in the interior of the cell). The tensor product construction will create an element with the following shape functions:

      -\begin{align*}
+<picture><source srcset=\begin{align*}
   Q_1 \times Q_2 &=
   \left\{
     \begin{pmatrix} 1-x \\ 0 \end{pmatrix},
@@ -140,7 +140,7 @@
     \begin{pmatrix} 0 \\ 2(x - \frac 12)x \end{pmatrix},
     \begin{pmatrix} 0 \\ 4x(1-x) \end{pmatrix}
   \right\}.
-\end{align*} +\end{align*}" src="form_1233.png"/>

      The list here is again in standard order.

      Of course, the procedure also works if the base elements are already vector valued themselves: in that case, the composed element simply has as many vector components as the base elements taken together.

      @@ -148,10 +148,10 @@
    2. Combining shape functions (do_tensor_product=false): In contrast to the previous strategy, combining shape functions simply takes all of the shape functions together. In the case above, this would yield the following element:

      -\begin{align*}
+<picture><source srcset=\begin{align*}
   Q_1 + Q_2 &= \{ 1-x, 2(\frac 12 - x)(1-x),
                   x, 2(x - \frac 12)x, 4x(1-x) \}.
-\end{align*} +\end{align*}" src="form_1234.png"/>

      In other words, if the base elements are scalar, the resulting element will also be. In general, the base elements all will have to have the same number of vector components.

      The element constructed above of course no longer has a linearly independent set of shape functions. As a consequence, any matrix one creates by treating all shape functions of the composed element in the same way will be singular. In practice, this strategy is therefore typically used in situations where one explicitly makes sure that certain shape functions are treated differently (e.g., by multiplying them with weight functions), or in cases where the shape functions one combines are not linearly dependent.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFiniteElementDomination.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFiniteElementDomination.html 2023-08-09 23:38:57.042616217 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFiniteElementDomination.html 2023-08-09 23:38:57.042616217 +0000 @@ -124,10 +124,10 @@
      -

      An enum that describes the outcome of comparing two elements for mutual domination. If one element dominates another, then the restriction of the space described by the dominated element to a face of the cell is strictly larger than that of the dominating element. For example, in 2-d Q(2) elements dominate Q(4) elements, because the traces of Q(4) elements are quartic polynomials which is a space strictly larger than the quadratic polynomials (the restriction of the Q(2) element). Similar reasonings apply for vertices and cells as well. In general, Q(k) dominates Q(k') if $k\le k'$.

      +

      An enum that describes the outcome of comparing two elements for mutual domination. If one element dominates another, then the restriction of the space described by the dominated element to a face of the cell is strictly larger than that of the dominating element. For example, in 2-d Q(2) elements dominate Q(4) elements, because the traces of Q(4) elements are quartic polynomials which is a space strictly larger than the quadratic polynomials (the restriction of the Q(2) element). Similar reasonings apply for vertices and cells as well. In general, Q(k) dominates Q(k') if $k\le k'$.

      This enum is used in the FiniteElement::compare_for_domination() function that is used in the context of hp-finite element methods when determining what to do at faces where two different finite elements meet (see the hp-paper for a more detailed description of the following). In that case, the degrees of freedom of one side need to be constrained to those on the other side. The determination which side is which is based on the outcome of a comparison for mutual domination: the dominated side is constrained to the dominating one.

      -

      Note that there are situations where neither side dominates. The hp-paper lists two case, with the simpler one being that a $Q_2\times Q_1$ vector- valued element (i.e. a FESystem(FE_Q(2),1,FE_Q(1),1)) meets a $Q_1\times Q_2$ element: here, for each of the two vector-components, we can define a domination relationship, but it is different for the two components.

      -

      It is clear that the concept of domination doesn't matter for discontinuous elements. However, discontinuous elements may be part of vector-valued elements and may therefore be compared against each other for domination. They should return either_element_can_dominate in that case. Likewise, when comparing two identical finite elements, they should return this code; the reason is that we can not decide which element will dominate at the time we look at the first component of, for example, two $Q_2\times Q_1$ and $Q_2\times Q_2$ elements, and have to keep our options open until we get to the second base element.

      +

      Note that there are situations where neither side dominates. The hp-paper lists two case, with the simpler one being that a $Q_2\times Q_1$ vector- valued element (i.e. a FESystem(FE_Q(2),1,FE_Q(1),1)) meets a $Q_1\times Q_2$ element: here, for each of the two vector-components, we can define a domination relationship, but it is different for the two components.

      +

      It is clear that the concept of domination doesn't matter for discontinuous elements. However, discontinuous elements may be part of vector-valued elements and may therefore be compared against each other for domination. They should return either_element_can_dominate in that case. Likewise, when comparing two identical finite elements, they should return this code; the reason is that we can not decide which element will dominate at the time we look at the first component of, for example, two $Q_2\times Q_1$ and $Q_2\times Q_2$ elements, and have to keep our options open until we get to the second base element.

      Finally, the code no_requirements exists for cases where elements impose no continuity requirements. The case is primarily meant for FE_Nothing which is an element that has no degrees of freedom in a subdomain. It could also be used by discontinuous elements, for example.

      More details on domination can be found in the hp-paper.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFunctionTools.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFunctionTools.html 2023-08-09 23:38:57.058616336 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceFunctionTools.html 2023-08-09 23:38:57.058616336 +0000 @@ -138,13 +138,13 @@
      -

      Estimate bounds on the value and bounds on each gradient component of a Function, $f$, over a BoundingBox, by approximating it by a 2nd order Taylor polynomial starting from the box center.

      -

      Each lower and upper bound is returned as a std::pair<double, double>, such that the first entry is the lower bound, $L$, and the second is the upper bound, $U$, i.e. $f(x) \in [L, U]$.

      +

      Estimate bounds on the value and bounds on each gradient component of a Function, $f$, over a BoundingBox, by approximating it by a 2nd order Taylor polynomial starting from the box center.

      +

      Each lower and upper bound is returned as a std::pair<double, double>, such that the first entry is the lower bound, $L$, and the second is the upper bound, $U$, i.e. $f(x) \in [L, U]$.

      The function value, gradient, and Hessian are computed at the box center. The bounds on the value of the function are then estimated as

      -

      $f(x) \in [f(x_c) - F, f(x_c) + F]$, where $F = \sum_i |\partial_i f(x_c)| h_i
-   + 1/2 \sum_i \sum_j |\partial_i \partial_j f(x_c)| h_i h_j$.

      -

      Here, $h_i$ is half the side length of the box in the $i$th coordinate direction, which is the distance we extrapolate. The bounds on the gradient components are estimated similarly as

      -

      $\partial_i f \in [\partial_i f(x_c) - G_i, \partial_i f(x_c) + G_i]$, where $G_i = \sum_j |\partial_i \partial_j f(x_c)| h_j$.

      +

      $f(x) \in [f(x_c) - F, f(x_c) + F]$, where $F = \sum_i |\partial_i f(x_c)| h_i
+   + 1/2 \sum_i \sum_j |\partial_i \partial_j f(x_c)| h_i h_j$.

      +

      Here, $h_i$ is half the side length of the box in the $i$th coordinate direction, which is the distance we extrapolate. The bounds on the gradient components are estimated similarly as

      +

      $\partial_i f \in [\partial_i f(x_c) - G_i, \partial_i f(x_c) + G_i]$, where $G_i = \sum_j |\partial_i \partial_j f(x_c)| h_j$.

      If the function has more than 1 component the component parameter can be used to specify which function component the bounds should be computed for.

      Definition at line 26 of file function_tools.cc.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGeometricUtilities_1_1Coordinates.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGeometricUtilities_1_1Coordinates.html 2023-08-09 23:38:57.070616426 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGeometricUtilities_1_1Coordinates.html 2023-08-09 23:38:57.074616456 +0000 @@ -128,13 +128,13 @@
      -

      Return spherical coordinates of a Cartesian point point. The returned array is filled with radius, azimuth angle $\in [0,2 \pi)$ and polar/inclination angle $ \in [0,\pi]$ (omitted in 2d).

      +

      Return spherical coordinates of a Cartesian point point. The returned array is filled with radius, azimuth angle $\in [0,2 \pi)$ and polar/inclination angle $ \in [0,\pi]$ (omitted in 2d).

      In 3d the transformation is given by

      -\begin{align*}
+<picture><source srcset=\begin{align*}
  r &= \sqrt{x^2+y^2+z^2} \\
  \theta &= {\rm atan}(y/x) \\
  \phi &= {\rm acos} (z/r)
-\end{align*} +\end{align*}" src="form_546.png"/>

      The use of this function is demonstrated in step-75.

      @@ -158,13 +158,13 @@
      -

      Return the Cartesian coordinates of a spherical point defined by scoord which is filled with radius $r \in [0,\infty)$, azimuth angle $\theta \in [0,2 \pi)$ and polar/inclination angle $\phi \in [0,\pi]$ (omitted in 2d).

      +

      Return the Cartesian coordinates of a spherical point defined by scoord which is filled with radius $r \in [0,\infty)$, azimuth angle $\theta \in [0,2 \pi)$ and polar/inclination angle $\phi \in [0,\pi]$ (omitted in 2d).

      In 3d the transformation is given by

      -\begin{align*}
+<picture><source srcset=\begin{align*}
  x &= r\, \cos(\theta) \, \sin(\phi) \\
  y &= r\, \sin(\theta) \, \sin(\phi) \\
  z &= r\, \cos(\phi)
-\end{align*} +\end{align*}" src="form_550.png"/>

      Definition at line 77 of file geometric_utilities.cc.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGraphColoring.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGraphColoring.html 2023-08-09 23:38:57.086616545 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGraphColoring.html 2023-08-09 23:38:57.086616545 +0000 @@ -141,9 +141,9 @@

      Create a partitioning of the given range of iterators so that iterators that point to conflicting objects will be placed into different partitions, where the question whether two objects conflict is determined by a user-provided function.

      This function can also be considered as a graph coloring: each object pointed to by an iterator is considered to be a node and there is an edge between each two nodes that conflict. The graph coloring algorithm then assigns a color to each node in such a way that two nodes connected by an edge do not have the same color.

      A typical use case for this function is in assembling a matrix in parallel. There, one would like to assemble local contributions on different cells at the same time (an operation that is purely local and so requires no synchronization) but then we need to add these local contributions to the global matrix. In general, the contributions from different cells may be to the same matrix entries if the cells share degrees of freedom and, consequently, can not happen at the same time unless we want to risk a race condition (see http://en.wikipedia.org/wiki/Race_condition). Thus, we call these two cells in conflict, and we can only allow operations in parallel from cells that do not conflict. In other words, two cells are in conflict if the set of matrix entries (for example characterized by the rows) have a nonempty intersection.

      -

      In this generality, computing the graph of conflicts would require calling a function that determines whether two iterators (or the two objects they represent) conflict, and calling it for every pair of iterators, i.e., $\frac 12 N (N-1)$ times. This is too expensive in general. A better approach is to require a user-defined function that returns for every iterator it is called for a set of indicators of some kind that characterize a conflict; two iterators are in conflict if their conflict indicator sets have a nonempty intersection. In the example of assembling a matrix, the conflict indicator set would contain the indices of all degrees of freedom on the cell pointed to (in the case of continuous Galerkin methods) or the union of indices of degree of freedom on the current cell and all cells adjacent to the faces of the current cell (in the case of discontinuous Galerkin methods, because there one computes face integrals coupling the degrees of freedom connected by a common face – see step-12).

      +

      In this generality, computing the graph of conflicts would require calling a function that determines whether two iterators (or the two objects they represent) conflict, and calling it for every pair of iterators, i.e., $\frac 12 N (N-1)$ times. This is too expensive in general. A better approach is to require a user-defined function that returns for every iterator it is called for a set of indicators of some kind that characterize a conflict; two iterators are in conflict if their conflict indicator sets have a nonempty intersection. In the example of assembling a matrix, the conflict indicator set would contain the indices of all degrees of freedom on the cell pointed to (in the case of continuous Galerkin methods) or the union of indices of degree of freedom on the current cell and all cells adjacent to the faces of the current cell (in the case of discontinuous Galerkin methods, because there one computes face integrals coupling the degrees of freedom connected by a common face – see step-12).

      Note
      The conflict set returned by the user defined function passed as third argument needs to accurately describe all degrees of freedom for which anything is written into the matrix or right hand side. In other words, if the writing happens through a function like AffineConstraints::copy_local_to_global(), then the set of conflict indices must actually contain not only the degrees of freedom on the current cell, but also those they are linked to by constraints such as hanging nodes.
      -

      In other situations, the conflict indicator sets may represent something different altogether – it is up to the caller of this function to describe what it means for two iterators to conflict. Given this, computing conflict graph edges can be done significantly more cheaply than with ${\cal O}(N^2)$ operations.

      +

      In other situations, the conflict indicator sets may represent something different altogether – it is up to the caller of this function to describe what it means for two iterators to conflict. Given this, computing conflict graph edges can be done significantly more cheaply than with ${\cal O}(N^2)$ operations.

      In any case, the result of the function will be so that iterators whose conflict indicator sets have overlap will not be assigned to the same color.

      Note
      The algorithm used in this function is described in a paper by Turcksin, Kronbichler and Bangerth, see workstream_paper.
      Parameters
      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridGenerator.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridGenerator.html 2023-08-09 23:38:57.162617113 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridGenerator.html 2023-08-09 23:38:57.162617113 +0000 @@ -303,7 +303,7 @@
      -

      Initialize the given triangulation with a hypercube (line in 1d, square in 2d, etc) consisting of exactly one cell. The hypercube volume is the tensor product interval $[left,right]^{\text{dim}}$ in the present number of dimensions, where the limits are given as arguments. They default to zero and unity, then producing the unit hypercube.

      +

      Initialize the given triangulation with a hypercube (line in 1d, square in 2d, etc) consisting of exactly one cell. The hypercube volume is the tensor product interval $[left,right]^{\text{dim}}$ in the present number of dimensions, where the limits are given as arguments. They default to zero and unity, then producing the unit hypercube.

      If the argument colorize is false, then all boundary indicators are set to zero (the default boundary indicator) for 2d and 3d. If it is true, the boundary is colorized as in hyper_rectangle(). In 1d the indicators are always colorized, see hyper_rectangle().

      @@ -339,7 +339,7 @@
      -

      Create a $d$-simplex (i.e., a triangle in 2d, or a tetrahedron in 3d) with $d+1$ corners. Since deal.II does not support triangular and tetrahedral cells, the simplex described by the input arguments is subdivided into quadrilaterals and hexahedra by adding edge, face, and simplex midpoints, resulting in a mesh that consists of $d+1$ quadrilateral or hexahedral cells.

      +

      Create a $d$-simplex (i.e., a triangle in 2d, or a tetrahedron in 3d) with $d+1$ corners. Since deal.II does not support triangular and tetrahedral cells, the simplex described by the input arguments is subdivided into quadrilaterals and hexahedra by adding edge, face, and simplex midpoints, resulting in a mesh that consists of $d+1$ quadrilateral or hexahedral cells.

      The vertices argument contains a vector with all d+1 vertices defining the corners of the simplex. They must be given in an order such that the vectors from the first vertex to each of the others form a right-handed system.

      The meshes generated in two and three dimensions are:

      @@ -832,7 +832,7 @@
      -

      Generate a grid consisting of a channel with a cylinder. This is a common benchmark for Navier-Stokes solvers. The geometry consists of a channel of size $[0, 2.2] \times [0, 0.41] \times [0, 0.41] $ (where the $z$ dimension is omitted in 2d) with a cylinder, parallel to the $z$ axis with diameter $0.1$, centered at $(0.2, 0.2, 0)$. The channel has three distinct regions:

        +

        Generate a grid consisting of a channel with a cylinder. This is a common benchmark for Navier-Stokes solvers. The geometry consists of a channel of size $[0, 2.2] \times [0, 0.41] \times [0, 0.41] $ (where the $z$ dimension is omitted in 2d) with a cylinder, parallel to the $z$ axis with diameter $0.1$, centered at $(0.2, 0.2, 0)$. The channel has three distinct regions:

        1. If n_shells is greater than zero, then there are that many shells centered around the cylinder,
        2. @@ -856,10 +856,10 @@
          Parameters
          - + - +
          triaTriangulation to be created. Must be empty upon calling this function.
          shell_region_widthWidth of the layer of shells around the cylinder. This value should be between $0$ and $0.05$; the default value is $0.03$.
          shell_region_widthWidth of the layer of shells around the cylinder. This value should be between $0$ and $0.05$; the default value is $0.03$.
          n_shellsNumber of shells to use in the shell layer.
          skewnessParameter controlling how close the shells are to the cylinder: see the mathematical definition given in GridGenerator::concentric_hyper_shells.
          colorizeIf true, then assign different boundary ids to different parts of the boundary. For more information on boundary indicators see this glossary entry. The left boundary (at $x = 0$) is assigned an id of $0$, the right boundary (at $x = 2.2$) is assigned an id of $1$; the boundary of the obstacle in the middle (i.e., the circle in 2d or the cylinder walls in 3d) is assigned an id of $2$, and the channel walls are assigned an id of $3$.
          colorizeIf true, then assign different boundary ids to different parts of the boundary. For more information on boundary indicators see this glossary entry. The left boundary (at $x = 0$) is assigned an id of $0$, the right boundary (at $x = 2.2$) is assigned an id of $1$; the boundary of the obstacle in the middle (i.e., the circle in 2d or the cylinder walls in 3d) is assigned an id of $2$, and the channel walls are assigned an id of $3$.
          @@ -1227,7 +1227,7 @@

          This function is declared to exist for triangulations of all space dimensions, but throws an error if called in 1d.

          By default, the manifold_id is set to 0 on the boundary faces, 1 on the boundary cells, and numbers::flat_manifold_id on the central cell and on internal faces.

          A SphericalManifold is attached by default to the boundary faces for correct placement of boundary vertices upon refinement and to be able to use higher order mappings. However, it turns out that this strategy may not be the optimal one to create a good a mesh for a hyperball. The "Possibilities for extensions" section of step-6 has an extensive discussion of how one would construct better meshes and what one needs to do for it. Setting the argument attach_spherical_manifold_on_boundary_cells to true attaches a SphericalManifold manifold also to the cells adjacent to the boundary, and not only to the boundary faces.

          -
          Note
          Since this is likely one of the earliest functions users typically consider to create meshes with curved boundaries, let us also comment on one aspect that is often confusing: Namely, that what one sees is not always what is actually happening. Specifically, if you output the coarse mesh with a function such as GridOut::write_vtk() using default options, then one doesn't generally get to see curved faces at the boundary. That's because most file formats by default only store vertex locations, with the implicit understanding that cells are composed from these vertices and bounded by straight edges. At the same time, the fact that this function attaches a SphericalManifold object to the boundary faces means that at least internally, edges really are curved. If you want to see them that way, you need to make sure that the function you use to output the mesh actually plots boundary faces as curved lines rather than straight lines characterized by only the locations of the two end points. For example, GridOut::write_gnuplot() can do that if you set the corresponding flag in the GridOutFlags::Gnuplot structure. It is, however, an entirely separate consideration whether you are actually computing on curved cells. In typical finite element computations, one has to compute integrals and these are computed by transforming back actual cells using a mapping to the reference cell. What mapping is used determines what shape the cells have for these internal computations: For example, with the widely used $Q_1$ mapping (implicitly used in step-6), integration always happens on cells that are assumed to have straight boundaries described by only the vertex locations. In other words, if such a mapping is used, then the cells of the domain really do have straight edges, regardless of the manifold description attached to these edges and regardless of the flags given when generating output. As a consequence of all of this, it is important to distinguish three things: (i) the manifold description attached to an object in the mesh; (ii) the mapping used in integration; and (iii) the style used in outputting graphical information about the mesh. All of these can be chosen more or less independently of each other, and what you see visualized is not necessarily exactly what is happening.
          +
          Note
          Since this is likely one of the earliest functions users typically consider to create meshes with curved boundaries, let us also comment on one aspect that is often confusing: Namely, that what one sees is not always what is actually happening. Specifically, if you output the coarse mesh with a function such as GridOut::write_vtk() using default options, then one doesn't generally get to see curved faces at the boundary. That's because most file formats by default only store vertex locations, with the implicit understanding that cells are composed from these vertices and bounded by straight edges. At the same time, the fact that this function attaches a SphericalManifold object to the boundary faces means that at least internally, edges really are curved. If you want to see them that way, you need to make sure that the function you use to output the mesh actually plots boundary faces as curved lines rather than straight lines characterized by only the locations of the two end points. For example, GridOut::write_gnuplot() can do that if you set the corresponding flag in the GridOutFlags::Gnuplot structure. It is, however, an entirely separate consideration whether you are actually computing on curved cells. In typical finite element computations, one has to compute integrals and these are computed by transforming back actual cells using a mapping to the reference cell. What mapping is used determines what shape the cells have for these internal computations: For example, with the widely used $Q_1$ mapping (implicitly used in step-6), integration always happens on cells that are assumed to have straight boundaries described by only the vertex locations. In other words, if such a mapping is used, then the cells of the domain really do have straight edges, regardless of the manifold description attached to these edges and regardless of the flags given when generating output. As a consequence of all of this, it is important to distinguish three things: (i) the manifold description attached to an object in the mesh; (ii) the mapping used in integration; and (iii) the style used in outputting graphical information about the mesh. All of these can be chosen more or less independently of each other, and what you see visualized is not necessarily exactly what is happening.
          Precondition
          The triangulation passed as argument needs to be empty when calling this function.
      @@ -1529,7 +1529,7 @@
      -

      Create a dim dimensional cylinder where the $x$-axis serves as the axis of the cylinder. For the purposes of this function, a cylinder is defined as a (dim - 1) dimensional disk of given radius, extruded along the axis of the cylinder (which is the first coordinate direction). Consequently, in three dimensions, the cylinder extends from x=-half_length to x=+half_length and its projection into the yz-plane is a circle of radius radius. In two dimensions, the cylinder is a rectangle from x=-half_length to x=+half_length and from y=-radius to y=radius.

      +

      Create a dim dimensional cylinder where the $x$-axis serves as the axis of the cylinder. For the purposes of this function, a cylinder is defined as a (dim - 1) dimensional disk of given radius, extruded along the axis of the cylinder (which is the first coordinate direction). Consequently, in three dimensions, the cylinder extends from x=-half_length to x=+half_length and its projection into the yz-plane is a circle of radius radius. In two dimensions, the cylinder is a rectangle from x=-half_length to x=+half_length and from y=-radius to y=radius.

      The boundaries are colored according to the following scheme: 0 for the hull of the cylinder, 1 for the left hand face and 2 for the right hand face (see the glossary entry on colorization).

      The manifold id for the hull of the cylinder is set to zero, and a CylindricalManifold is attached to it.

      Precondition
      The triangulation passed as argument needs to be empty when calling this function.
      @@ -1573,7 +1573,7 @@
      -

      Create a dim dimensional cylinder where the $x$-axis serves as the axis of the cylinder. For the purposes of this function, a cylinder is defined as a (dim - 1) dimensional disk of given radius, extruded along the axis of the cylinder (which is the first coordinate direction). Consequently, in three dimensions, the cylinder extends from x=-half_length to x=+half_length and its projection into the yz-plane is a circle of radius radius. In two dimensions, the cylinder is a rectangle from x=-half_length to x=+half_length and from y=-radius to y=radius. This function is only implemented for dim==3.

      +

      Create a dim dimensional cylinder where the $x$-axis serves as the axis of the cylinder. For the purposes of this function, a cylinder is defined as a (dim - 1) dimensional disk of given radius, extruded along the axis of the cylinder (which is the first coordinate direction). Consequently, in three dimensions, the cylinder extends from x=-half_length to x=+half_length and its projection into the yz-plane is a circle of radius radius. In two dimensions, the cylinder is a rectangle from x=-half_length to x=+half_length and from y=-radius to y=radius. This function is only implemented for dim==3.

      The boundaries are colored according to the following scheme: 0 for the hull of the cylinder, 1 for the left hand face and 2 for the right hand face (see the glossary entry on colorization).

      The manifold id for the hull of the cylinder is set to zero, and a CylindricalManifold is attached to it.

      @@ -1799,7 +1799,7 @@
      Parameters
      - +
      triaA Triangulation object which has to be empty.
      sizesA vector of integers of dimension GeometryInfo<dim>::faces_per_cell with the following meaning: the legs of the cross are stacked on the faces of the center cell, in the usual order of deal.II cells, namely first $-x$, then $x$, then $-y$ and so on. The corresponding entries in sizes name the number of cells stacked on this face. All numbers may be zero, thus L- and T-shaped domains are specializations of this domain.
      sizesA vector of integers of dimension GeometryInfo<dim>::faces_per_cell with the following meaning: the legs of the cross are stacked on the faces of the center cell, in the usual order of deal.II cells, namely first $-x$, then $x$, then $-y$ and so on. The corresponding entries in sizes name the number of cells stacked on this face. All numbers may be zero, thus L- and T-shaped domains are specializations of this domain.
      colorize_cellsIf colorization is enabled, then the material id of a cells corresponds to the leg it is in. The id of the center cell is zero, and then the legs are numbered starting at one (see the glossary entry on colorization).
      @@ -2024,7 +2024,7 @@
    3. 96 for the rhombic dodecahedron refined once. This choice dates from an older version of deal.II before the Manifold classes were implemented: today this choce is equivalent to the rhombic dodecahedron after performing one global refinement.
    4. -Numbers of the kind $192\times 2^m$ with $m\geq 0$ integer. This choice is similar to the 24 and 48 cell cases, but provides additional refinements in azimuthal direction combined with a single layer in radial direction. The base mesh is either the 6 or 12 cell version, depending on whether $m$ in the power is odd or even, respectively.
    5. +Numbers of the kind $192\times 2^m$ with $m\geq 0$ integer. This choice is similar to the 24 and 48 cell cases, but provides additional refinements in azimuthal direction combined with a single layer in radial direction. The base mesh is either the 6 or 12 cell version, depending on whether $m$ in the power is odd or even, respectively.
    6. The versions with 24, 48, and $2^m 192$ cells are useful if the shell is thin and the radial lengths should be made more similar to the circumferential lengths.

      The 3d grids with 12 and 96 cells are plotted below:

      @@ -2260,7 +2260,7 @@
      -

      Produce a domain that is the space between two cylinders in 3d, with given length, inner and outer radius and a given number of elements. The cylinder shell is built around the $z$-axis with the two faces located at $z = 0$ and $z = $ length.

      +

      Produce a domain that is the space between two cylinders in 3d, with given length, inner and outer radius and a given number of elements. The cylinder shell is built around the $z$-axis with the two faces located at $z = 0$ and $z = $ length.

      If n_radial_cells is zero (as is the default), then it is computed adaptively such that the resulting elements have the least aspect ratio. The same holds for n_axial_cells.

      Note
      Although this function is declared as a template, it does not make sense in 1d and 2d. Also keep in mind that this object is rotated and positioned differently than the one created by cylinder().

      All manifold ids are set to zero, and a CylindricalManifold is attached to the triangulation.

      @@ -2315,7 +2315,7 @@
      -

      Produce the volume or surface mesh of a torus. The axis of the torus is the $y$-axis while the plane of the torus is the $x$- $z$ plane.

      +

      Produce the volume or surface mesh of a torus. The axis of the torus is the $y$-axis while the plane of the torus is the $x$- $z$ plane.

      If dim is 3, the mesh will be the volume of the torus, using a mesh equivalent to the circle in the poloidal coordinates with 5 cells on the cross section. This function attaches a TorusManifold to all boundary faces which are marked with a manifold id of 1, a CylindricalManifold to the interior cells and all their faces which are marked with a manifold id of 2 (representing a flat state within the poloidal coordinates), and a TransfiniteInterpolationManifold to the cells between the TorusManifold on the surface and the ToroidalManifold in the center, with cells marked with manifold id 0.

      An example for the case if dim is 3 with a cut through the domain at $z=0$, 6 toroidal cells, $R=2$ and $r=0.5$ without any global refinement is given here:

      @@ -2385,7 +2385,7 @@
      -

      This function produces a square in the xy-plane with a cylindrical hole in the middle. The square and the circle are centered at the origin. In 3d, this geometry is extruded in $z$ direction to the interval $[0,L]$.

      +

      This function produces a square in the xy-plane with a cylindrical hole in the middle. The square and the circle are centered at the origin. In 3d, this geometry is extruded in $z$ direction to the interval $[0,L]$.

      The inner boundary has a manifold id of $0$ and a boundary id of $6$. This function attaches a PolarManifold or CylindricalManifold to the interior boundary in 2d and 3d respectively. The other faces have boundary ids of $0, 1, 2, 3, 4$, or $5$ given in the standard order of faces in 2d or 3d.

      @@ -2464,7 +2464,7 @@

      Produce a grid consisting of concentric shells. The primary difference between this function and GridGenerator::hyper_shell() is that this function permits unevenly spaced (in the radial direction) coarse level cells.

      -

      The parameters center, inner_radius, and outer_radius behave in the same way as the first three arguments to GridGenerator::hyper_shell. n_shells gives the total number of shells to use (i.e., the number of cells in the radial direction). The outer radius of the $k$th shell is given by

      +

      The parameters center, inner_radius, and outer_radius behave in the same way as the first three arguments to GridGenerator::hyper_shell. n_shells gives the total number of shells to use (i.e., the number of cells in the radial direction). The outer radius of the $k$th shell is given by

      \[
     r = r_{\mathrm{inner}} + (r_\mathrm{outer} - r_\mathrm{inner})
@@ -2472,7 +2472,7 @@
          {\tanh(\mathrm{skewness})}\right)
 \]

      -

      where skewness is a parameter controlling the shell spacing in the radial direction: values of skewness close to zero correspond to even spacing, while larger values of skewness (such as $2$ or $3$) correspond to shells biased to the inner radius.

      +

      where skewness is a parameter controlling the shell spacing in the radial direction: values of skewness close to zero correspond to even spacing, while larger values of skewness (such as $2$ or $3$) correspond to shells biased to the inner radius.

      n_cells_per_shell is the same as in GridGenerator::hyper_shell: in 2d the default choice of zero will result in 8 cells per shell (and 12 in 3d). The only valid values in 3d are 6 (the default), 12, and 96 cells: see the documentation of GridGenerator::hyper_shell for more information.

      If colorize is true then the outer boundary of the merged shells has a boundary id of $1$ and the inner boundary has a boundary id of $0$.

      Example: The following code (see, e.g., step-10 for instructions on how to visualize GNUPLOT output)

      @@ -3055,10 +3055,10 @@
      -

      Extrude the Triangulation input in the $z$ direction from $z = 0$ to $z =
-\text{height}$ and store it in result. This is done by replicating the input triangulation n_slices times in $z$ direction, and then forming (n_slices-1) layers of cells out of these replicates.

      -

      The boundary indicators of the faces of input will be assigned to the corresponding side walls in $z$ direction. The bottom and top get the next two free boundary indicators: i.e., if input has boundary ids of $0$, $1$, and $42$, then the $z = 0$ boundary id of result will be $43$ and the $z = \text{height}$ boundary id will be $44$.

      -

      This function does not, by default, copy manifold ids. The reason for this is that there is no way to set the manifold ids on the lines of the resulting Triangulation without more information: for example, if two faces of input with different manifold ids meet at a shared vertex then there is no a priori reason to pick one manifold id or another for the lines created in result that are parallel to the $z$-axis and pass through that point. If copy_manifold_ids is true then this function sets line manifold ids by picking the one that appears first in manifold_priorities. For example: if manifold_priorities is {0, 42, numbers::flat_manifold_id} and the line under consideration is adjacent to faces with manifold ids of 0 and 42, then that line will have a manifold id of 0. The correct ordering is almost always

        +

        Extrude the Triangulation input in the $z$ direction from $z = 0$ to $z =
+\text{height}$ and store it in result. This is done by replicating the input triangulation n_slices times in $z$ direction, and then forming (n_slices-1) layers of cells out of these replicates.

        +

        The boundary indicators of the faces of input will be assigned to the corresponding side walls in $z$ direction. The bottom and top get the next two free boundary indicators: i.e., if input has boundary ids of $0$, $1$, and $42$, then the $z = 0$ boundary id of result will be $43$ and the $z = \text{height}$ boundary id will be $44$.

        +

        This function does not, by default, copy manifold ids. The reason for this is that there is no way to set the manifold ids on the lines of the resulting Triangulation without more information: for example, if two faces of input with different manifold ids meet at a shared vertex then there is no a priori reason to pick one manifold id or another for the lines created in result that are parallel to the $z$-axis and pass through that point. If copy_manifold_ids is true then this function sets line manifold ids by picking the one that appears first in manifold_priorities. For example: if manifold_priorities is {0, 42, numbers::flat_manifold_id} and the line under consideration is adjacent to faces with manifold ids of 0 and 42, then that line will have a manifold id of 0. The correct ordering is almost always

        1. manifold ids set on the boundary,
        2. @@ -3076,8 +3076,8 @@
          Parameters
          - - + + @@ -3253,7 +3253,7 @@
          [in]inputA two-dimensional input triangulation.
          [in]n_slicesThe number of times the input triangulation will be replicated in $z$ direction. These slices will then be connected into (n_slices-1) layers of three-dimensional cells. Clearly, n_slices must be at least two.
          [in]heightThe distance in $z$ direction between the individual slices.
          [in]n_slicesThe number of times the input triangulation will be replicated in $z$ direction. These slices will then be connected into (n_slices-1) layers of three-dimensional cells. Clearly, n_slices must be at least two.
          [in]heightThe distance in $z$ direction between the individual slices.
          [out]resultThe resulting three-dimensional triangulation.
          [in]copy_manifold_idsSee the description above.
          [in]manifold_prioritiesSee the description above.
      -

      Given an input triangulation in_tria, this function makes a new flat triangulation out_tria which contains a single level with all active cells of the input triangulation. If spacedim1 and spacedim2 are different, only the first few components of the vertex coordinates are copied over. This is useful to create a Triangulation<2,3> out of a Triangulation<2,2>, or to project a Triangulation<2,3> into a Triangulation<2,2>, by neglecting the $z$ components of the vertices.

      +

      Given an input triangulation in_tria, this function makes a new flat triangulation out_tria which contains a single level with all active cells of the input triangulation. If spacedim1 and spacedim2 are different, only the first few components of the vertex coordinates are copied over. This is useful to create a Triangulation<2,3> out of a Triangulation<2,2>, or to project a Triangulation<2,3> into a Triangulation<2,2>, by neglecting the $z$ components of the vertices.

      No internal checks are performed on the vertices, which are assumed to make sense topologically in the target spacedim2 dimensional space. If this is not the case, you will encounter problems when using the triangulation later on.

      All information about cell manifold indicators and material indicators are copied from one triangulation to the other. The same is true for the manifold indicators and, if an object is at the boundary, the boundary indicators of faces and edges of the triangulation.

      This function will fail if the input Triangulation is of type parallel::distributed::Triangulation, as well as when the input Triangulation contains hanging nodes. In other words, this function only works for globally refined triangulations.

      @@ -3407,7 +3407,7 @@
      -

      Initialize the given triangulation with a hypercube (square in 2d and cube in 3d) consisting of repetitions cells in each direction. The hypercube volume is the tensor product interval $[left,right]^{\text{dim}}$ in the present number of dimensions, where the limits are given as arguments. They default to zero and unity, then producing the unit hypercube.

      +

      Initialize the given triangulation with a hypercube (square in 2d and cube in 3d) consisting of repetitions cells in each direction. The hypercube volume is the tensor product interval $[left,right]^{\text{dim}}$ in the present number of dimensions, where the limits are given as arguments. They default to zero and unity, then producing the unit hypercube.

      Note
      This function connects internally 4/8 vertices to quadrilateral/hexahedral cells and subdivides these into 2/5 triangular/tetrahedral cells.

      Also see Simplex support.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridRefinement.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridRefinement.html 2023-08-09 23:38:57.186617292 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridRefinement.html 2023-08-09 23:38:57.186617292 +0000 @@ -222,7 +222,7 @@

    -

    As an example, with no coarsening, setting top_fraction_of_cells to 1/3 will result in approximately doubling the number of cells in two dimensions. That is because each of these 1/3 of cells will be replaced by its four children, resulting in $4\times \frac 13 N$ cells, whereas the remaining 2/3 of cells remains untouched – thus yielding a total of $4\times \frac 13 N + \frac 23 N = 2N$ cells. The same effect in three dimensions is achieved by refining 1/7th of the cells. These values are therefore frequently used because they ensure that the cost of computations on subsequent meshes become expensive sufficiently quickly that the fraction of time spent on the coarse meshes is not too large. On the other hand, the fractions are small enough that mesh adaptation does not refine too many cells in each step.

    +

    As an example, with no coarsening, setting top_fraction_of_cells to 1/3 will result in approximately doubling the number of cells in two dimensions. That is because each of these 1/3 of cells will be replaced by its four children, resulting in $4\times \frac 13 N$ cells, whereas the remaining 2/3 of cells remains untouched – thus yielding a total of $4\times \frac 13 N + \frac 23 N = 2N$ cells. The same effect in three dimensions is achieved by refining 1/7th of the cells. These values are therefore frequently used because they ensure that the cost of computations on subsequent meshes become expensive sufficiently quickly that the fraction of time spent on the coarse meshes is not too large. On the other hand, the fractions are small enough that mesh adaptation does not refine too many cells in each step.

    Note
    This function only sets the coarsening and refinement flags. The mesh is not changed until you call Triangulation::execute_coarsening_and_refinement().
    Parameters
    @@ -290,14 +290,14 @@

    This function provides a strategy to mark cells for refinement and coarsening with the goal of controlling the reduction of the error estimate.

    Also known as the bulk criterion or Dörfler marking, this function computes the thresholds for refinement and coarsening such that the criteria of cells getting flagged for refinement make up for a certain fraction of the total error. We explain its operation for refinement, coarsening works analogously.

    Let cK be the criterion of cell K. Then the total error estimate is computed by the formula

    -\[
+<picture><source srcset=\[
 E = \sum_{K\in \cal T} c_K.
-\] +\]" src="form_1368.png"/>

    -

    If 0 < a < 1 is top_fraction, then we refine the smallest subset $\cal M$ of the Triangulation $\cal T$ such that

    -\[
+<p>If <em> 0 < a < 1</em> is <code>top_fraction</code>, then we refine the smallest subset <picture><source srcset=$\cal M$ of the Triangulation $\cal T$ such that

    +\[
 a E \le \sum_{K\in \cal M} c_K
-\] +\]" src="form_1371.png"/>

    The algorithm is performed by the greedy algorithm described in refine_and_coarsen_fixed_number().

    Note
    The often used formula with squares on the left and right is recovered by actually storing the square of cK in the vector criteria.
    @@ -348,32 +348,32 @@
    -

    This function flags cells of a triangulation for refinement with the aim to reach a grid that is optimal with respect to an objective function that tries to balance reducing the error and increasing the numerical cost when the mesh is refined. Specifically, this function makes the assumption that if you refine a cell $K$ with error indicator $\eta_K$ provided by the second argument to this function, then the error on the children (for all children together) will only be $2^{-\text{order}}\eta_K$ where order is the third argument of this function. This makes the assumption that the error is only a local property on a mesh and can be reduced by local refinement – an assumption that is true for the interpolation operator, but not for the usual Galerkin projection, although it is approximately true for elliptic problems where the Greens function decays quickly and the error here is not too much affected by a too coarse mesh somewhere else.

    -

    With this, we can define the objective function this function tries to optimize. Let us assume that the mesh currently has $N_0$ cells. Then, if we refine the $m$ cells with the largest errors, we expect to get (in $d$ space dimensions)

    -\[
+<p>This function flags cells of a triangulation for refinement with the aim to reach a grid that is optimal with respect to an objective function that tries to balance reducing the error and increasing the numerical cost when the mesh is refined. Specifically, this function makes the assumption that if you refine a cell <picture><source srcset=$K$ with error indicator $\eta_K$ provided by the second argument to this function, then the error on the children (for all children together) will only be $2^{-\text{order}}\eta_K$ where order is the third argument of this function. This makes the assumption that the error is only a local property on a mesh and can be reduced by local refinement – an assumption that is true for the interpolation operator, but not for the usual Galerkin projection, although it is approximately true for elliptic problems where the Greens function decays quickly and the error here is not too much affected by a too coarse mesh somewhere else.

    +

    With this, we can define the objective function this function tries to optimize. Let us assume that the mesh currently has $N_0$ cells. Then, if we refine the $m$ cells with the largest errors, we expect to get (in $d$ space dimensions)

    +\[
   N(m) = (N_0-m) + 2^d m = N_0 + (2^d-1)m
-\] +\]" src="form_1375.png"/>

    -

    cells ( $N_0-m$ are not refined, and each of the $m$ cells we refine yield $2^d$ child cells. On the other hand, with refining $m$ cells, and using the assumptions above, we expect that the error will be

    -\[
+<p> cells ( <picture><source srcset=$N_0-m$ are not refined, and each of the $m$ cells we refine yield $2^d$ child cells. On the other hand, with refining $m$ cells, and using the assumptions above, we expect that the error will be

    +\[
   \eta^\text{exp}(m)
   =
   \sum_{K, K\; \text{will not be refined}} \eta_K
   +
   \sum_{K, K\; \text{will be refined}} 2^{-\text{order}}\eta_K
-\] +\]" src="form_1378.png"/>

    -

    where the first sum extends over $N_0-m$ cells and the second over the $m$ cells that will be refined. Note that $N(m)$ is an increasing function of $m$ whereas $\eta^\text{exp}(m)$ is a decreasing function.

    -

    This function then tries to find that number $m$ of cells to mark for refinement for which the objective function

    -\[
+<p> where the first sum extends over <picture><source srcset=$N_0-m$ cells and the second over the $m$ cells that will be refined. Note that $N(m)$ is an increasing function of $m$ whereas $\eta^\text{exp}(m)$ is a decreasing function.

    +

    This function then tries to find that number $m$ of cells to mark for refinement for which the objective function

    +\[
   J(m) = N(m)^{\text{order}/d} \eta^\text{exp}(m)
-\] +\]" src="form_1381.png"/>

    is minimal.

    The rationale for this function is two-fold. First, compared to the refine_and_coarsen_fixed_fraction() and refine_and_coarsen_fixed_number() functions, this function has the property that if all refinement indicators are the same (i.e., we have achieved a mesh where the error per cell is equilibrated), then the entire mesh is refined. This is based on the observation that a mesh with equilibrated error indicators is the optimal mesh (i.e., has the least overall error) among all meshes with the same number of cells. (For proofs of this, see R. Becker, M. Braack, R. Rannacher: "Numerical simulation of laminar flames at low Mach number with adaptive finite elements", Combustion Theory and Modelling, Vol. 3, Nr. 3, p. 503-534 1999; and W. Bangerth, R. Rannacher: "Adaptive Finite Element Methods for Differential Equations", Birkhauser, 2003.)

    -

    Second, the function uses the observation that ideally, the error behaves like $e \approx c N^{-\alpha}$ with some constant $\alpha$ that depends on the dimension and the finite element degree. It should - given optimal mesh refinement - not depend so much on the regularity of the solution, as it is based on the idea, that all singularities can be resolved by refinement. Mesh refinement is then based on the idea that we want to make $c=e N^\alpha$ small. This corresponds to the functional $J(m)$ above.

    +

    Second, the function uses the observation that ideally, the error behaves like $e \approx c N^{-\alpha}$ with some constant $\alpha$ that depends on the dimension and the finite element degree. It should - given optimal mesh refinement - not depend so much on the regularity of the solution, as it is based on the idea, that all singularities can be resolved by refinement. Mesh refinement is then based on the idea that we want to make $c=e N^\alpha$ small. This corresponds to the functional $J(m)$ above.

    Note
    This function was originally implemented by Thomas Richter. It follows a strategy described in [Richter2005]. See in particular Section 4.3, pp. 42-43.

    Definition at line 448 of file grid_refinement.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridTools.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridTools.html 2023-08-09 23:38:57.290618069 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceGridTools.html 2023-08-09 23:38:57.294618099 +0000 @@ -508,8 +508,8 @@
    -

    Compute the volume (i.e. the dim-dimensional measure) of the triangulation. We compute the measure using the integral $\sum_K \int_K 1
-\; dx$ where $K$ are the cells of the given triangulation. The integral is approximated via quadrature. This version of the function uses a linear mapping to compute the JxW values on each cell.

    +

    Compute the volume (i.e. the dim-dimensional measure) of the triangulation. We compute the measure using the integral $\sum_K \int_K 1
+\; dx$ where $K$ are the cells of the given triangulation. The integral is approximated via quadrature. This version of the function uses a linear mapping to compute the JxW values on each cell.

    If the triangulation is a dim-dimensional one embedded in a higher dimensional space of dimension spacedim, then the value returned is the dim-dimensional measure. For example, for a two-dimensional triangulation in three-dimensional space, the value returned is the area of the surface so described. (This obviously makes sense since the spacedim-dimensional measure of a dim-dimensional triangulation would always be zero if dim < spacedim).

    This function also works for objects of type parallel::distributed::Triangulation, in which case the function is a collective operation.

    Parameters
    @@ -549,8 +549,8 @@
    -

    Compute the volume (i.e. the dim-dimensional measure) of the triangulation. We compute the measure using the integral $\sum_K \int_K 1
-\; dx$ where $K$ are the cells of the given triangulation. The integral is approximated via quadrature for which we use the mapping argument.

    +

    Compute the volume (i.e. the dim-dimensional measure) of the triangulation. We compute the measure using the integral $\sum_K \int_K 1
+\; dx$ where $K$ are the cells of the given triangulation. The integral is approximated via quadrature for which we use the mapping argument.

    If the triangulation is a dim-dimensional one embedded in a higher dimensional space of dimension spacedim, then the value returned is the dim-dimensional measure. For example, for a two-dimensional triangulation in three-dimensional space, the value returned is the area of the surface so described. (This obviously makes sense since the spacedim-dimensional measure of a dim-dimensional triangulation would always be zero if dim < spacedim.

    This function also works for objects of type parallel::distributed::Triangulation, in which case the function is a collective operation.

    Parameters
    @@ -707,8 +707,8 @@
    -

    This function computes an affine approximation of the map from the unit coordinates to the real coordinates of the form $p_\text{real} = A
-p_\text{unit} + b $ by a least squares fit of this affine function to the $2^\text{dim}$ vertices representing a quadrilateral or hexahedral cell in spacedim dimensions. The result is returned as a pair with the matrix A as the first argument and the vector b describing distance of the plane to the origin.

    +

    This function computes an affine approximation of the map from the unit coordinates to the real coordinates of the form $p_\text{real} = A
+p_\text{unit} + b $ by a least squares fit of this affine function to the $2^\text{dim}$ vertices representing a quadrilateral or hexahedral cell in spacedim dimensions. The result is returned as a pair with the matrix A as the first argument and the vector b describing distance of the plane to the origin.

    For any valid mesh cell whose geometry is not degenerate, this operation results in a unique affine mapping, even in cases where the actual transformation by a bi-/trilinear or higher order mapping might be singular. The result is exact in case the transformation from the unit to the real cell is indeed affine, such as in one dimension or for Cartesian and affine (parallelogram) meshes in 2d/3d.

    This approximation is underlying the function TriaAccessor::real_to_unit_cell_affine_approximation() function.

    For exact transformations to the unit cell, use Mapping::transform_real_to_unit_cell().

    @@ -747,7 +747,7 @@
    -

    Computes an aspect ratio measure for all locally-owned active cells and fills a vector with one entry per cell, given a triangulation and mapping. The size of the vector that is returned equals the number of active cells. The vector contains zero for non locally-owned cells. The aspect ratio of a cell is defined as the ratio of the maximum to minimum singular value of the Jacobian, taking the maximum over all quadrature points of a quadrature rule specified via quadrature. For example, for the special case of rectangular elements in 2d with dimensions $a$ and $b$ ( $a \geq b$), this function returns the usual aspect ratio definition $a/b$. The above definition using singular values is a generalization to arbitrarily deformed elements. This function is intended to be used for $d=2,3$ space dimensions, but it can also be used for $d=1$ returning a value of 1.

    +

    Computes an aspect ratio measure for all locally-owned active cells and fills a vector with one entry per cell, given a triangulation and mapping. The size of the vector that is returned equals the number of active cells. The vector contains zero for non locally-owned cells. The aspect ratio of a cell is defined as the ratio of the maximum to minimum singular value of the Jacobian, taking the maximum over all quadrature points of a quadrature rule specified via quadrature. For example, for the special case of rectangular elements in 2d with dimensions $a$ and $b$ ( $a \geq b$), this function returns the usual aspect ratio definition $a/b$. The above definition using singular values is a generalization to arbitrarily deformed elements. This function is intended to be used for $d=2,3$ space dimensions, but it can also be used for $d=1$ returning a value of 1.

    Note
    Inverted elements do not throw an exception. Instead, a value of inf is written into the vector in case of inverted elements.
    Make sure to use enough quadrature points for a precise calculation of the aspect ratio in case of deformed elements.
    @@ -954,7 +954,7 @@

    Remove vertices that are duplicated, due to the input of a structured grid, for example. If these vertices are not removed, the faces bounded by these vertices become part of the boundary, even if they are in the interior of the mesh.

    -

    This function is called by some GridIn::read_* functions. Only the vertices with indices in considered_vertices are tested for equality. This speeds up the algorithm, which is, for worst-case hyper cube geometries $O(N^{3/2})$ in 2d and $O(N^{5/3})$ in 3d: quite slow. However, if you wish to consider all vertices, simply pass an empty vector. In that case, the function fills considered_vertices with all vertices.

    +

    This function is called by some GridIn::read_* functions. Only the vertices with indices in considered_vertices are tested for equality. This speeds up the algorithm, which is, for worst-case hyper cube geometries $O(N^{3/2})$ in 2d and $O(N^{5/3})$ in 3d: quite slow. However, if you wish to consider all vertices, simply pass an empty vector. In that case, the function fills considered_vertices with all vertices.

    Two vertices are considered equal if their difference in each coordinate direction is less than tol. This implies that nothing happens if the tolerance is set to zero.

    Definition at line 761 of file grid_tools.cc.

    @@ -1122,7 +1122,7 @@

    Transform the vertices of the given triangulation by applying the function object provided as first argument to all its vertices.

    -

    The transformation given as argument is used to transform each vertex. Its respective type has to offer a function-like syntax, i.e. the predicate is either an object of a type that has an operator(), or it is a pointer to a non-member function, or it is a lambda function object. In either case, argument and return value have to be of type Point<spacedim>. An example – a simple transformation that moves the object two units to the right in the $x_1$ direction – could look like as follows:

    +

    The transformation given as argument is used to transform each vertex. Its respective type has to offer a function-like syntax, i.e. the predicate is either an object of a type that has an operator(), or it is a pointer to a non-member function, or it is a lambda function object. In either case, argument and return value have to be of type Point<spacedim>. An example – a simple transformation that moves the object two units to the right in the $x_1$ direction – could look like as follows:

    ... // fill triangulation with something
    {
    @@ -1344,13 +1344,13 @@

    Transform the given triangulation smoothly to a different domain where, typically, each of the vertices at the boundary of the triangulation is mapped to the corresponding points in the new_points map.

    -

    The unknown displacement field $u_d(\mathbf x)$ in direction $d$ is obtained from the minimization problem

    -\[ \min\, \int \frac{1}{2}
+<p>The unknown displacement field <picture><source srcset=$u_d(\mathbf x)$ in direction $d$ is obtained from the minimization problem

    +\[ \min\, \int \frac{1}{2}
   c(\mathbf x)
   \mathbf \nabla u_d(\mathbf x) \cdot
   \mathbf \nabla u_d(\mathbf x)
   \,\rm d x
-\] +\]" src="form_1395.png"/>

    subject to prescribed constraints. The minimizer is obtained by solving the Laplace equation of the dim components of a displacement field that maps the current domain into one described by new_points . Linear finite elements with four Gaussian quadrature points in each direction are used. The difference between the vertex positions specified in new_points and their current value in tria therefore represents the prescribed values of this displacement field at the boundary of the domain, or more precisely at all of those locations for which new_points provides values (which may be at part of the boundary, or even in the interior of the domain). The function then evaluates this displacement field at each unconstrained vertex and uses it to place the mapped vertex where the displacement field locates it. Because the solution of the Laplace equation is smooth, this guarantees a smooth mapping from the old domain to the new one.

    Parameters
    @@ -3410,7 +3410,7 @@

    This function does the same as the previous one, i.e. it partitions a triangulation using a partitioning algorithm into a number of subdomains identified by the cell->subdomain_id() flag.

    The difference to the previous function is the second argument, a sparsity pattern that represents the connectivity pattern between cells.

    -

    While the function above builds it directly from the triangulation by considering which cells neighbor each other, this function can take a more refined connectivity graph. The sparsity pattern needs to be of size $N\times N$, where $N$ is the number of active cells in the triangulation. If the sparsity pattern contains an entry at position $(i,j)$, then this means that cells $i$ and $j$ (in the order in which they are traversed by active cell iterators) are to be considered connected; partitioning algorithm will then try to partition the domain in such a way that (i) the subdomains are of roughly equal size, and (ii) a minimal number of connections are broken.

    +

    While the function above builds it directly from the triangulation by considering which cells neighbor each other, this function can take a more refined connectivity graph. The sparsity pattern needs to be of size $N\times N$, where $N$ is the number of active cells in the triangulation. If the sparsity pattern contains an entry at position $(i,j)$, then this means that cells $i$ and $j$ (in the order in which they are traversed by active cell iterators) are to be considered connected; partitioning algorithm will then try to partition the domain in such a way that (i) the subdomains are of roughly equal size, and (ii) a minimal number of connections are broken.

    This function is mainly useful in cases where connections between cells exist that are not present in the triangulation alone (otherwise the previous function would be the simpler one to use). Such connections may include that certain parts of the boundary of a domain are coupled through symmetric boundary conditions or integrals (e.g. friction contact between the two sides of a crack in the domain), or if a numerical scheme is used that not only connects immediate neighbors but a larger neighborhood of cells (e.g. when solving integral equations).

    In addition, this function may be useful in cases where the default sparsity pattern is not entirely sufficient. This can happen because the default is to just consider face neighbors, not neighboring cells that are connected by edges or vertices. While the latter couple when using continuous finite elements, they are typically still closely connected in the neighborship graph, and partitioning algorithm will not usually cut important connections in this case. However, if there are vertices in the mesh where many cells (many more than the common 4 or 6 in 2d and 3d, respectively) come together, then there will be a significant number of cells that are connected across a vertex, but several degrees removed in the connectivity graph built only using face neighbors. In a case like this, partitioning algorithm may sometimes make bad decisions and you may want to build your own connectivity graph.

    Note
    If the weight signal has been attached to the triangulation, then this will be used and passed to the partitioner.
    @@ -4016,7 +4016,7 @@

    An orthogonal equality test for faces.

    face1 and face2 are considered equal, if a one to one matching between its vertices can be achieved via an orthogonal equality relation.

    -

    Here, two vertices v_1 and v_2 are considered equal, if $M\cdot v_1 + offset - v_2$ is parallel to the unit vector in unit direction direction. If the parameter matrix is a reference to a spacedim x spacedim matrix, $M$ is set to matrix, otherwise $M$ is the identity matrix.

    +

    Here, two vertices v_1 and v_2 are considered equal, if $M\cdot v_1 + offset - v_2$ is parallel to the unit vector in unit direction direction. If the parameter matrix is a reference to a spacedim x spacedim matrix, $M$ is set to matrix, otherwise $M$ is the identity matrix.

    If the matching was successful, the relative orientation of face1 with respect to face2 is returned in the bitset orientation, where

    orientation[0] -> face_orientation
    orientation[1] -> face_flip
    orientation[2] -> face_rotation
    @@ -4135,8 +4135,8 @@

    This function tries to match all faces belonging to the first boundary with faces belonging to the second boundary with the help of orthogonal_equality().

    The bitset that is returned inside of PeriodicFacePair encodes the relative orientation of the first face with respect to the second face, see the documentation of orthogonal_equality() for further details.

    The direction refers to the space direction in which periodicity is enforced. When matching periodic faces this vector component is ignored.

    -

    The offset is a vector tangential to the faces that is added to the location of vertices of the 'first' boundary when attempting to match them to the corresponding vertices of the 'second' boundary. This can be used to implement conditions such as $u(0,y)=u(1,y+1)$.

    -

    Optionally, a $dim\times dim$ rotation matrix can be specified that describes how vector valued DoFs of the first face should be modified prior to constraining to the DoFs of the second face. The matrix is used in two places. First, matrix will be supplied to orthogonal_equality() and used for matching faces: Two vertices $v_1$ and $v_2$ match if $\text{matrix}\cdot v_1 + \text{offset} - v_2$ is parallel to the unit vector in unit direction direction. (For more details see DoFTools::make_periodicity_constraints(), the glossary glossary entry on periodic conditions and step-45). Second, matrix will be stored in the PeriodicFacePair collection matched_pairs for further use.

    +

    The offset is a vector tangential to the faces that is added to the location of vertices of the 'first' boundary when attempting to match them to the corresponding vertices of the 'second' boundary. This can be used to implement conditions such as $u(0,y)=u(1,y+1)$.

    +

    Optionally, a $dim\times dim$ rotation matrix can be specified that describes how vector valued DoFs of the first face should be modified prior to constraining to the DoFs of the second face. The matrix is used in two places. First, matrix will be supplied to orthogonal_equality() and used for matching faces: Two vertices $v_1$ and $v_2$ match if $\text{matrix}\cdot v_1 + \text{offset} - v_2$ is parallel to the unit vector in unit direction direction. (For more details see DoFTools::make_periodicity_constraints(), the glossary glossary entry on periodic conditions and step-45). Second, matrix will be stored in the PeriodicFacePair collection matched_pairs for further use.

    Template Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators.html 2023-08-09 23:38:57.318618278 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators.html 2023-08-09 23:38:57.318618278 +0000 @@ -125,9 +125,9 @@

    The namespace L2 contains functions for mass matrices and L2-inner products.

    Notational conventions

    In most cases, the action of a function in this namespace can be described by a single integral. We distinguish between integrals over cells Z and over faces F. If an integral is denoted as

    -\[
+<picture><source srcset=\[
   \int_Z u \otimes v \,dx,
-\] +\]" src="form_1564.png"/>

    it will yield the following results, depending on the type of operation

    • @@ -137,7 +137,7 @@
    • If the function returns a number, then this number is the integral of the two given functions u and v.
    -

    We will use regular cursive symbols $u$ for scalars and bold symbols $\mathbf u$ for vectors. Test functions are always v and trial functions are always u. Parameters are Greek and the face normal vectors are $\mathbf n = \mathbf n_1 = -\mathbf n_2$.

    +

    We will use regular cursive symbols $u$ for scalars and bold symbols $\mathbf u$ for vectors. Test functions are always v and trial functions are always u. Parameters are Greek and the face normal vectors are $\mathbf n = \mathbf n_1 = -\mathbf n_2$.

    Signature of functions

    Functions in this namespace follow a generic signature. In the simplest case, you have two related functions

    template <int dim>
    void
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Advection.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Advection.html 2023-08-09 23:38:57.342618457 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Advection.html 2023-08-09 23:38:57.342618457 +0000 @@ -169,8 +169,8 @@
    MeshTypeA type that satisfies the requirements of the MeshType concept.

    Advection along the direction w in weak form with derivative on the test function

    -\[ m_{ij} = \int_Z u_j\,(\mathbf w \cdot \nabla) v_i
-\, dx. \] +\[ m_{ij} = \int_Z u_j\,(\mathbf w \cdot \nabla) v_i
+\, dx. \]

    The FiniteElement in fe may be scalar or vector valued. In the latter case, the advection operator is applied to each component separately.

    Parameters
    @@ -239,7 +239,7 @@

    Scalar advection residual operator in strong form

    -\[ r_i = \int_Z  (\mathbf w \cdot \nabla)u\, v_i \, dx. \] +\[ r_i = \int_Z  (\mathbf w \cdot \nabla)u\, v_i \, dx. \]

    Warning
    This is not the residual consistent with cell_matrix(), but with its transpose.
    @@ -298,8 +298,8 @@

    Vector-valued advection residual operator in strong form

    -\[ r_i = \int_Z \bigl((\mathbf w \cdot \nabla) \mathbf u\bigr)
-\cdot\mathbf v_i \, dx. \] +\[ r_i = \int_Z \bigl((\mathbf w \cdot \nabla) \mathbf u\bigr)
+\cdot\mathbf v_i \, dx. \]

    Warning
    This is not the residual consistent with cell_matrix(), but with its transpose.
    @@ -359,7 +359,7 @@

    Scalar advection residual operator in weak form

    -\[ r_i = \int_Z  (\mathbf w \cdot \nabla)v\, u_i \, dx. \] +\[ r_i = \int_Z  (\mathbf w \cdot \nabla)v\, u_i \, dx. \]

    Definition at line 216 of file advection.h.

    @@ -417,8 +417,8 @@

    Vector-valued advection residual operator in weak form

    -\[ r_i = \int_Z \bigl((\mathbf w \cdot \nabla) \mathbf v\bigr)
-\cdot\mathbf u_i \, dx. \] +\[ r_i = \int_Z \bigl((\mathbf w \cdot \nabla) \mathbf v\bigr)
+\cdot\mathbf u_i \, dx. \]

    Definition at line 256 of file advection.h.

    @@ -467,11 +467,11 @@

    Upwind flux at the boundary for weak advection operator. This is the value of the trial function at the outflow boundary and zero else:

    -\[
+<picture><source srcset=\[
 a_{ij} = \int_{\partial\Omega}
 [\mathbf w\cdot\mathbf n]_+
 u_i v_j \, ds
-\] +\]" src="form_1518.png"/>

    The velocity is provided as an ArrayView, having dim vectors, one for each velocity component. Each of the vectors must either have only a single entry, if the advection velocity is constant, or have an entry for each quadrature point.

    The finite element can have several components, in which case each component is advected by the same velocity.

    @@ -537,13 +537,13 @@

    Scalar case: Residual for upwind flux at the boundary for weak advection operator. This is the value of the trial function at the outflow boundary and the value of the incoming boundary condition on the inflow boundary:

    -\[
+<picture><source srcset=\[
 a_{ij} = \int_{\partial\Omega}
 (\mathbf w\cdot\mathbf n)
 \widehat u v_j \, ds
-\] +\]" src="form_1519.png"/>

    -

    Here, the numerical flux $\widehat u$ is the upwind value at the face, namely the finite element function whose values are given in the argument input on the outflow boundary. On the inflow boundary, it is the inhomogeneous boundary value in the argument data.

    +

    Here, the numerical flux $\widehat u$ is the upwind value at the face, namely the finite element function whose values are given in the argument input on the outflow boundary. On the inflow boundary, it is the inhomogeneous boundary value in the argument data.

    The velocity is provided as an ArrayView, having dim vectors, one for each velocity component. Each of the vectors must either have only a single entry, if the advection velocity is constant, or have an entry for each quadrature point.

    The finite element can have several components, in which case each component is advected by the same velocity.

    @@ -606,13 +606,13 @@

    Vector-valued case: Residual for upwind flux at the boundary for weak advection operator. This is the value of the trial function at the outflow boundary and the value of the incoming boundary condition on the inflow boundary:

    -\[
+<picture><source srcset=\[
 a_{ij} = \int_{\partial\Omega}
 (\mathbf w\cdot\mathbf n)
 \widehat u v_j \, ds
-\] +\]" src="form_1519.png"/>

    -

    Here, the numerical flux $\widehat u$ is the upwind value at the face, namely the finite element function whose values are given in the argument input on the outflow boundary. On the inflow boundary, it is the inhomogeneous boundary value in the argument data.

    +

    Here, the numerical flux $\widehat u$ is the upwind value at the face, namely the finite element function whose values are given in the argument input on the outflow boundary. On the inflow boundary, it is the inhomogeneous boundary value in the argument data.

    The velocity is provided as an ArrayView, having dim vectors, one for each velocity component. Each of the vectors must either have only a single entry, if the advection velocity is constant, or have an entry for each quadrature point.

    The finite element can have several components, in which case each component is advected by the same velocity.

    @@ -687,13 +687,13 @@

    Upwind flux in the interior for weak advection operator. Matrix entries correspond to the upwind value of the trial function, multiplied by the jump of the test functions

    -\[
+<picture><source srcset=\[
 a_{ij} = \int_F \left|\mathbf w
 \cdot \mathbf n\right|
 u^\uparrow
 (v^\uparrow-v^\downarrow)
 \,ds
-\] +\]" src="form_1521.png"/>

    The velocity is provided as an ArrayView, having dim vectors, one for each velocity component. Each of the vectors must either have only a single entry, if the advection velocity is constant, or have an entry for each quadrature point.

    The finite element can have several components, in which case each component is advected the same way.

    @@ -761,13 +761,13 @@

    Scalar case: Upwind flux in the interior for weak advection operator. Matrix entries correspond to the upwind value of the trial function, multiplied by the jump of the test functions

    -\[
+<picture><source srcset=\[
 a_{ij} = \int_F \left|\mathbf w
 \cdot \mathbf n\right|
 u^\uparrow
 (v^\uparrow-v^\downarrow)
 \,ds
-\] +\]" src="form_1521.png"/>

    The velocity is provided as an ArrayView, having dim vectors, one for each velocity component. Each of the vectors must either have only a single entry, if the advection velocity is constant, or have an entry for each quadrature point.

    The finite element can have several components, in which case each component is advected the same way.

    @@ -833,13 +833,13 @@

    Vector-valued case: Upwind flux in the interior for weak advection operator. Matrix entries correspond to the upwind value of the trial function, multiplied by the jump of the test functions

    -\[
+<picture><source srcset=\[
 a_{ij} = \int_F \left|\mathbf w
 \cdot \mathbf n\right|
 u^\uparrow
 (v^\uparrow-v^\downarrow)
 \,ds
-\] +\]" src="form_1521.png"/>

    The velocity is provided as an ArrayView, having dim vectors, one for each velocity component. Each of the vectors must either have only a single entry, if the advection velocity is constant, or have an entry for each quadrature point.

    The finite element can have several components, in which case each component is advected the same way.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Divergence.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Divergence.html 2023-08-09 23:38:57.362618607 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Divergence.html 2023-08-09 23:38:57.362618607 +0000 @@ -164,7 +164,7 @@

    Cell matrix for divergence. The derivative is on the trial function.

    -\[ \int_Z v\nabla \cdot \mathbf u \,dx \] +\[ \int_Z v\nabla \cdot \mathbf u \,dx \]

    This is the strong divergence operator and the trial space should be at least Hdiv. The test functions may be discontinuous.

    @@ -209,8 +209,8 @@

    The residual of the divergence operator in strong form.

    -\[ \int_Z
-v\nabla \cdot \mathbf u \,dx \] +\[ \int_Z
+v\nabla \cdot \mathbf u \,dx \]

    This is the strong divergence operator and the trial space should be at least Hdiv. The test functions may be discontinuous.

    The function cell_matrix() is the Frechet derivative of this function with respect to the test functions.

    @@ -256,8 +256,8 @@

    The residual of the divergence operator in weak form.

    -\[ - \int_Z
-\nabla v \cdot \mathbf u \,dx \] +\[ - \int_Z
+\nabla v \cdot \mathbf u \,dx \]

    This is the weak divergence operator and the test space should be at least H1. The trial functions may be discontinuous.

    Todo:
    Verify: The function cell_matrix() is the Frechet derivative of this function with respect to the test functions.
    @@ -303,8 +303,8 @@

    Cell matrix for gradient. The derivative is on the trial function.

    -\[
-\int_Z \nabla u \cdot \mathbf v\,dx \] +\[
+\int_Z \nabla u \cdot \mathbf v\,dx \]

    This is the strong gradient and the trial space should be at least in H1. The test functions can be discontinuous.

    @@ -349,8 +349,8 @@

    The residual of the gradient operator in strong form.

    -\[ \int_Z
-\mathbf v\cdot\nabla u \,dx \] +\[ \int_Z
+\mathbf v\cdot\nabla u \,dx \]

    This is the strong gradient operator and the trial space should be at least H1. The test functions may be discontinuous.

    The function gradient_matrix() is the Frechet derivative of this function with respect to the test functions.

    @@ -397,8 +397,8 @@

    The residual of the gradient operator in weak form.

    -\[ -\int_Z
-\nabla\cdot \mathbf v u \,dx \] +\[ -\int_Z
+\nabla\cdot \mathbf v u \,dx \]

    This is the weak gradient operator and the test space should be at least Hdiv. The trial functions may be discontinuous.

    Todo:
    Verify: The function gradient_matrix() is the Frechet derivative of this function with respect to the test functions.
    @@ -444,7 +444,7 @@

    The trace of the divergence operator, namely the product of the normal component of the vector valued trial space and the test space.

    -\[ \int_F (\mathbf u\cdot \mathbf n) v \,ds \] +\[ \int_F (\mathbf u\cdot \mathbf n) v \,ds \]

    Definition at line 259 of file divergence.h.

    @@ -493,9 +493,9 @@

    The trace of the divergence operator, namely the product of the normal component of the vector valued trial space and the test space.

    -\[
+<picture><source srcset=\[
 \int_F (\mathbf u\cdot \mathbf n) v \,ds
-\] +\]" src="form_1529.png"/>

    Definition at line 292 of file divergence.h.

    @@ -540,9 +540,9 @@

    The trace of the gradient operator, namely the product of the normal component of the vector valued test space and the trial space.

    -\[
+<picture><source srcset=\[
 \int_F u (\mathbf v\cdot \mathbf n) \,ds
-\] +\]" src="form_1530.png"/>

    Definition at line 324 of file divergence.h.

    @@ -611,10 +611,10 @@

    The trace of the divergence operator, namely the product of the jump of the normal component of the vector valued trial function and the mean value of the test function.

    -\[
+<picture><source srcset=\[
 \int_F (\mathbf u_1\cdot \mathbf n_1 + \mathbf u_2 \cdot \mathbf n_2)
 \frac{v_1+v_2}{2} \,ds
-\] +\]" src="form_1531.png"/>

    Definition at line 358 of file divergence.h.

    @@ -673,12 +673,12 @@

    The jump of the normal component

    -\[
+<picture><source srcset=\[
 \int_F
  (\mathbf u_1\cdot \mathbf n_1 + \mathbf u_2 \cdot \mathbf n_2)
  (\mathbf v_1\cdot \mathbf n_1 + \mathbf v_2 \cdot \mathbf n_2)
 \,ds
-\] +\]" src="form_1532.png"/>

    Definition at line 417 of file divergence.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Elasticity.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Elasticity.html 2023-08-09 23:38:57.386618786 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Elasticity.html 2023-08-09 23:38:57.386618786 +0000 @@ -162,7 +162,7 @@

    The linear elasticity operator in weak form, namely double contraction of symmetric gradients.

    -\[ \int_Z \varepsilon(u): \varepsilon(v)\,dx \] +\[ \int_Z \varepsilon(u): \varepsilon(v)\,dx \]

    Definition at line 51 of file elasticity.h.

    @@ -215,7 +215,7 @@

    Vector-valued residual operator for linear elasticity in weak form

    -\[ - \int_Z \varepsilon(u): \varepsilon(v) \,dx \] +\[ - \int_Z \varepsilon(u): \varepsilon(v) \,dx \]

    Definition at line 84 of file elasticity.h.

    @@ -268,10 +268,10 @@

    The matrix for the weak boundary condition of Nitsche type for linear elasticity:

    -\[
+<picture><source srcset=\[
 \int_F \Bigl(\gamma u \cdot v - n^T \epsilon(u) v - u \epsilon(v)
 n\Bigr)\;ds.
-\] +\]" src="form_1535.png"/>

    Definition at line 123 of file elasticity.h.

    @@ -324,10 +324,10 @@

    The matrix for the weak boundary condition of Nitsche type for the tangential displacement in linear elasticity:

    -\[
+<picture><source srcset=\[
 \int_F \Bigl(\gamma u_\tau \cdot v_\tau - n^T \epsilon(u_\tau) v_\tau -
 u_\tau^T \epsilon(v_\tau) n\Bigr)\;ds.
-\] +\]" src="form_1536.png"/>

    Definition at line 178 of file elasticity.h.

    @@ -387,12 +387,12 @@

    Weak boundary condition for the elasticity operator by Nitsche, namely on the face F the vector

    -\[
+<picture><source srcset=\[
 \int_F \Bigl(\gamma (u-g) \cdot v - n^T \epsilon(u) v - (u-g) \epsilon(v)
 n^T\Bigr)\;ds.
-\] +\]" src="form_1537.png"/>

    -

    Here, u is the finite element function whose values and gradient are given in the arguments input and Dinput, respectively. g is the inhomogeneous boundary value in the argument data. $n$ is the outer normal vector and $\gamma$ is the usual penalty parameter.

    +

    Here, u is the finite element function whose values and gradient are given in the arguments input and Dinput, respectively. g is the inhomogeneous boundary value in the argument data. $n$ is the outer normal vector and $\gamma$ is the usual penalty parameter.

    Definition at line 257 of file elasticity.h.

    @@ -459,10 +459,10 @@

    The weak boundary condition of Nitsche type for the tangential displacement in linear elasticity:

    -\[
+<picture><source srcset=\[
 \int_F \Bigl(\gamma (u_\tau-g_\tau) \cdot v_\tau - n^T \epsilon(u_\tau) v
 - (u_\tau-g_\tau) \epsilon(v_\tau) n\Bigr)\;ds.
-\] +\]" src="form_1539.png"/>

    Definition at line 309 of file elasticity.h.

    @@ -517,12 +517,12 @@

    Homogeneous weak boundary condition for the elasticity operator by Nitsche, namely on the face F the vector

    -\[
+<picture><source srcset=\[
 \int_F \Bigl(\gamma u \cdot v - n^T \epsilon(u) v - u \epsilon(v)
 n^T\Bigr)\;ds.
-\] +\]" src="form_1540.png"/>

    -

    Here, u is the finite element function whose values and gradient are given in the arguments input and Dinput, respectively. $n$ is the outer normal vector and $\gamma$ is the usual penalty parameter.

    +

    Here, u is the finite element function whose values and gradient are given in the arguments input and Dinput, respectively. $n$ is the outer normal vector and $\gamma$ is the usual penalty parameter.

    Definition at line 387 of file elasticity.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1GradDiv.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1GradDiv.html 2023-08-09 23:38:57.406618935 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1GradDiv.html 2023-08-09 23:38:57.406618935 +0000 @@ -144,9 +144,9 @@

    The weak form of the grad-div operator penalizing volume changes

    -\[
+<picture><source srcset=\[
  \int_Z \nabla\cdot u \nabla \cdot v \,dx
-\] +\]" src="form_1541.png"/>

    Definition at line 52 of file grad_div.h.

    @@ -190,9 +190,9 @@

    The weak form of the grad-div residual

    -\[
+<picture><source srcset=\[
  \int_Z \nabla\cdot u \nabla \cdot v \,dx
-\] +\]" src="form_1541.png"/>

    Definition at line 86 of file grad_div.h.

    @@ -245,10 +245,10 @@

    The matrix for the weak boundary condition of Nitsche type for linear elasticity:

    -\[
+<picture><source srcset=\[
 \int_F \Bigl(\gamma (u \cdot n)(v \cdot n)  - \nabla\cdot u
 v\cdot n - u \cdot n \nabla \cdot v \Bigr)\;ds.
-\] +\]" src="form_1542.png"/>

    Definition at line 122 of file grad_div.h.

    @@ -308,14 +308,14 @@

    Weak boundary condition for the Laplace operator by Nitsche, vector valued version, namely on the face F the vector

    -\[
+<picture><source srcset=\[
 \int_F \Bigl(\gamma (\mathbf u \cdot \mathbf n- \mathbf g \cdot
 \mathbf n) (\mathbf v \cdot \mathbf n)
 - \nabla \cdot \mathbf u (\mathbf v \cdot \mathbf n)
 - (\mathbf u-\mathbf g) \cdot \mathbf n \nabla \cdot v\Bigr)\;ds.
-\] +\]" src="form_1543.png"/>

    -

    Here, u is the finite element function whose values and gradient are given in the arguments input and Dinput, respectively. g is the inhomogeneous boundary value in the argument data. $\gamma$ is the usual penalty parameter.

    +

    Here, u is the finite element function whose values and gradient are given in the arguments input and Dinput, respectively. g is the inhomogeneous boundary value in the argument data. $\gamma$ is the usual penalty parameter.

    Definition at line 174 of file grad_div.h.

    @@ -464,12 +464,12 @@

    Grad-div residual term for the symmetric interior penalty method:

    -\[
+<picture><source srcset=\[
 \int_F \Bigl( \gamma [\mathbf u \cdot\mathbf n]
 \cdot[\mathbf v \cdot \mathbf n]
 - \{\nabla \cdot \mathbf u\}[\mathbf v\cdot \mathbf n]
 - [\mathbf u\times \mathbf n]\{\nabla\cdot \mathbf v\} \Bigr) \; ds.
-\] +\]" src="form_1544.png"/>

    See for instance Hansbo and Larson, 2002

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1L2.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1L2.html 2023-08-09 23:38:57.422619054 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1L2.html 2023-08-09 23:38:57.422619054 +0000 @@ -262,7 +262,7 @@ - +
    resultThe vector obtained as result.
    feThe FEValues object describing the local trial function space. update_values and update_JxW_values must be set.
    inputThe representation of $f$ evaluated at the quadrature points in the finite element (size must be equal to the number of quadrature points in the element).
    inputThe representation of $f$ evaluated at the quadrature points in the finite element (size must be equal to the number of quadrature points in the element).
    factorA constant that multiplies the result.
    @@ -383,7 +383,7 @@
    -

    The jump matrix between two cells for scalar or vector values finite elements. Note that the factor $\gamma$ can be used to implement weighted jumps.

    +

    The jump matrix between two cells for scalar or vector values finite elements. Note that the factor $\gamma$ can be used to implement weighted jumps.

    \[ \int_F [\gamma u][\gamma v]\,ds \quad \text{or}
 \int_F [\gamma \mathbf u]\cdot [\gamma \mathbf v]\,ds \]

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Laplace.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Laplace.html 2023-08-09 23:38:57.446619234 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Laplace.html 2023-08-09 23:38:57.446619234 +0000 @@ -159,8 +159,8 @@

    Laplacian in weak form, namely on the cell Z the matrix

    -\[
-\int_Z \nu \nabla u \cdot \nabla v \, dx. \] +\[
+\int_Z \nu \nabla u \cdot \nabla v \, dx. \]

    The FiniteElement in fe may be scalar or vector valued. In the latter case, the Laplacian is applied to each component separately.

    @@ -214,7 +214,7 @@

    Laplacian residual operator in weak form

    -\[ \int_Z \nu \nabla u \cdot \nabla v \, dx. \] +\[ \int_Z \nu \nabla u \cdot \nabla v \, dx. \]

    Definition at line 92 of file laplace.h.

    @@ -267,7 +267,7 @@

    Vector-valued Laplacian residual operator in weak form

    -\[ \int_Z \nu \nabla u : \nabla v \, dx. \] +\[ \int_Z \nu \nabla u : \nabla v \, dx. \]

    Definition at line 119 of file laplace.h.

    @@ -312,11 +312,11 @@

    Weak boundary condition of Nitsche type for the Laplacian, namely on the face F the matrix

    -\[
+<picture><source srcset=\[
 \int_F \Bigl(\gamma u v - \partial_n u v - u \partial_n v\Bigr)\;ds.
-\] +\]" src="form_1557.png"/>

    -

    Here, $\gamma$ is the penalty parameter suitably computed with compute_penalty().

    +

    Here, $\gamma$ is the penalty parameter suitably computed with compute_penalty().

    Definition at line 157 of file laplace.h.

    @@ -360,12 +360,12 @@

    Weak boundary condition of Nitsche type for the Laplacian applied to the tangential component only, namely on the face F the matrix

    -\[
+<picture><source srcset=\[
 \int_F \Bigl(\gamma u_\tau v_\tau - \partial_n u_\tau v_\tau - u_\tau
 \partial_n v_\tau\Bigr)\;ds.
-\] +\]" src="form_1558.png"/>

    -

    Here, $\gamma$ is the penalty parameter suitably computed with compute_penalty().

    +

    Here, $\gamma$ is the penalty parameter suitably computed with compute_penalty().

    Definition at line 198 of file laplace.h.

    @@ -426,12 +426,12 @@

    Weak boundary condition for the Laplace operator by Nitsche, scalar version, namely on the face F the vector

    -\[
+<picture><source srcset=\[
 \int_F \Bigl(\gamma (u-g) v - \partial_n u v - (u-g) \partial_n
 v\Bigr)\;ds.
-\] +\]" src="form_1559.png"/>

    -

    Here, u is the finite element function whose values and gradient are given in the arguments input and Dinput, respectively. g is the inhomogeneous boundary value in the argument data. $\gamma$ is the usual penalty parameter.

    +

    Here, u is the finite element function whose values and gradient are given in the arguments input and Dinput, respectively. g is the inhomogeneous boundary value in the argument data. $\gamma$ is the usual penalty parameter.

    Definition at line 261 of file laplace.h.

    @@ -490,13 +490,13 @@

    Weak boundary condition for the Laplace operator by Nitsche, vector valued version, namely on the face F the vector

    -\[
+<picture><source srcset=\[
 \int_F \Bigl(\gamma (\mathbf u- \mathbf g) \cdot \mathbf v
 - \partial_n \mathbf u \cdot \mathbf v
 - (\mathbf u-\mathbf g) \cdot \partial_n \mathbf v\Bigr)\;ds.
-\] +\]" src="form_1560.png"/>

    -

    Here, u is the finite element function whose values and gradient are given in the arguments input and Dinput, respectively. g is the inhomogeneous boundary value in the argument data. $\gamma$ is the usual penalty parameter.

    +

    Here, u is the finite element function whose values and gradient are given in the arguments input and Dinput, respectively. g is the inhomogeneous boundary value in the argument data. $\gamma$ is the usual penalty parameter.

    Definition at line 308 of file laplace.h.

    @@ -566,10 +566,10 @@

    Flux for the interior penalty method for the Laplacian, namely on the face F the matrices associated with the bilinear form

    -\[
+<picture><source srcset=\[
 \int_F \Bigl( \gamma [u][v] - \{\nabla u\}[v\mathbf n] - [u\mathbf
 n]\{\nabla v\} \Bigr) \; ds.
-\] +\]" src="form_1561.png"/>

    The penalty parameter should always be the mean value of the penalties needed for stability on each side. In the case of constant coefficients, it can be computed using compute_penalty().

    If factor2 is missing or negative, the factor is assumed the same on both sides. If factors differ, note that the penalty parameter has to be computed accordingly.

    @@ -642,10 +642,10 @@

    Flux for the interior penalty method for the Laplacian applied to the tangential components of a vector field, namely on the face F the matrices associated with the bilinear form

    -\[
+<picture><source srcset=\[
 \int_F \Bigl( \gamma [u_\tau][v_\tau] - \{\nabla u_\tau\}[v_\tau\mathbf
 n] - [u_\tau\mathbf n]\{\nabla v_\tau\} \Bigr) \; ds.
-\] +\]" src="form_1562.png"/>

    Warning
    This function is still under development!
    @@ -729,10 +729,10 @@

    Residual term for the symmetric interior penalty method:

    -\[
+<picture><source srcset=\[
 \int_F \Bigl( \gamma [u][v] - \{\nabla u\}[v\mathbf n] - [u\mathbf
 n]\{\nabla v\} \Bigr) \; ds.
-\] +\]" src="form_1561.png"/>

    Definition at line 544 of file laplace.h.

    @@ -813,11 +813,11 @@

    Vector-valued residual term for the symmetric interior penalty method:

    -\[
+<picture><source srcset=\[
 \int_F \Bigl( \gamma [\mathbf u]\cdot[\mathbf v]
 - \{\nabla \mathbf u\}[\mathbf v\otimes \mathbf n]
 - [\mathbf u\otimes \mathbf n]\{\nabla \mathbf v\} \Bigr) \; ds.
-\] +\]" src="form_1563.png"/>

    Definition at line 611 of file laplace.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Maxwell.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Maxwell.html 2023-08-09 23:38:57.466619384 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceLocalIntegrators_1_1Maxwell.html 2023-08-09 23:38:57.466619384 +0000 @@ -118,22 +118,22 @@

    Local integrators related to curl operators and their traces.

    We use the following conventions for curl operators. First, in three space dimensions

    -\[
+<picture><source srcset=\[
 \nabla\times \mathbf u = \begin{pmatrix}
   \partial_2 u_3 - \partial_3 u_2 \\
   \partial_3 u_1 - \partial_1 u_3 \\
   \partial_1 u_2 - \partial_2 u_1
 \end{pmatrix}.
-\] +\]" src="form_1566.png"/>

    -

    In two space dimensions, the curl is obtained by extending a vector u to $(u_1, u_2, 0)^T$ and a scalar p to $(0,0,p)^T$. Computing the nonzero components, we obtain the scalar curl of a vector function and the vector curl of a scalar function. The current implementation exchanges the sign and we have:

    -\[
+<p>In two space dimensions, the curl is obtained by extending a vector <b>u</b> to <picture><source srcset=$(u_1, u_2, 0)^T$ and a scalar p to $(0,0,p)^T$. Computing the nonzero components, we obtain the scalar curl of a vector function and the vector curl of a scalar function. The current implementation exchanges the sign and we have:

    +\[
  \nabla \times \mathbf u = \partial_1 u_2 - \partial_2 u_1,
  \qquad
  \nabla \times p = \begin{pmatrix}
    \partial_2 p \\ -\partial_1 p
  \end{pmatrix}
-\] +\]" src="form_1569.png"/>

    Function Documentation

    @@ -167,7 +167,7 @@

    Auxiliary function. Given the tensors of dim second derivatives, compute the curl of the curl of a vector function. The result in two and three dimensions is:

    -\[
+<picture><source srcset=\[
 \nabla\times\nabla\times \mathbf u = \begin{pmatrix}
 \partial_1\partial_2 u_2 - \partial_2^2 u_1 \\
 \partial_1\partial_2 u_1 - \partial_1^2 u_2
@@ -181,7 +181,7 @@
 \partial_3\partial_1 u_1 + \partial_3\partial_2 u_2
 - (\partial_1^2+\partial_2^2) u_3
 \end{pmatrix}
-\] +\]" src="form_1570.png"/>

    Note
    The third tensor argument is not used in two dimensions and can for instance duplicate one of the previous.
    @@ -225,9 +225,9 @@

    Auxiliary function. Given dim tensors of first derivatives and a normal vector, compute the tangential curl

    -\[
+<picture><source srcset=\[
 \mathbf n \times \nabla \times u.
-\] +\]" src="form_1571.png"/>

    Note
    The third tensor argument is not used in two dimensions and can for instance duplicate one of the previous.
    @@ -267,10 +267,10 @@

    The curl-curl operator

    -\[
+<picture><source srcset=\[
 \int_Z \nabla\times u \cdot
 \nabla \times v \,dx
-\] +\]" src="form_1572.png"/>

    in weak form.

    @@ -315,9 +315,9 @@

    The matrix for the curl operator

    -\[
+<picture><source srcset=\[
 \int_Z \nabla \times u \cdot v \,dx.
-\] +\]" src="form_1573.png"/>

    This is the standard curl operator in 3d and the scalar curl in 2d. The vector curl operator can be obtained by exchanging test and trial functions.

    @@ -369,14 +369,14 @@

    The matrix for weak boundary condition of Nitsche type for the tangential component in Maxwell systems.

    -\[
+<picture><source srcset=\[
 \int_F \biggl( 2\gamma
 (u\times n) (v\times n) -
 (u\times n)(\nu \nabla\times
 v) - (v\times
 n)(\nu \nabla\times u)
 \biggr)
-\] +\]" src="form_1574.png"/>

    Definition at line 265 of file maxwell.h.

    @@ -415,10 +415,10 @@

    The product of two tangential traces,

    -\[
+<picture><source srcset=\[
 \int_F (u\times n)(v\times n)
 \, ds.
-\] +\]" src="form_1575.png"/>

    Definition at line 328 of file maxwell.h.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceMatrixCreator.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceMatrixCreator.html 2023-08-09 23:38:57.502619652 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceMatrixCreator.html 2023-08-09 23:38:57.502619652 +0000 @@ -139,7 +139,7 @@

    Detailed Description

    This namespace provides functions that assemble certain standard matrices for a given triangulation, using a given finite element, a given mapping and a quadrature formula.

    Conventions for all functions

    -

    There exist two versions of almost all functions, one that takes an explicit Mapping argument and one that does not. The second one generally calls the first with an implicit $Q_1$ argument (i.e., with an argument of kind MappingQ(1)). If your intend your code to use a different mapping than a (bi-/tri-)linear one, then you need to call the functions with mapping argument should be used.

    +

    There exist two versions of almost all functions, one that takes an explicit Mapping argument and one that does not. The second one generally calls the first with an implicit $Q_1$ argument (i.e., with an argument of kind MappingQ(1)). If your intend your code to use a different mapping than a (bi-/tri-)linear one, then you need to call the functions with mapping argument should be used.

    All functions take a sparse matrix object to hold the matrix to be created. The functions assume that the matrix is initialized with a sparsity pattern (SparsityPattern) corresponding to the given degree of freedom handler, i.e. the sparsity structure is already as needed. You can do this by calling the DoFTools::make_sparsity_pattern() function.

    Furthermore it is assumed that no relevant data is in the matrix. Some entries will be overwritten and some others will contain invalid data if the matrix wasn't empty before. Therefore you may want to clear the matrix before assemblage.

    By default, all created matrices are ‘raw’: they are not condensed, i.e. hanging nodes are not eliminated. The reason is that you may want to add several matrices and could then condense afterwards only once, instead of for every matrix. To actually do computations with these matrices, you have to condense the matrix using the AffineConstraints::condense function; you also have to condense the right hand side accordingly and distribute the solution afterwards. Alternatively, you can give an optional argument AffineConstraints that writes cell matrix (and vector) entries with distribute_local_to_global into the global matrix and vector. This way, adding several matrices from different sources is more complicated and you should make sure that you do not mix different ways of applying constraints. Particular caution is necessary when the given AffineConstraints object contains inhomogeneous constraints: In that case, the matrix assembled this way must be the only matrix (or you need to assemble the same right hand side for every matrix you generate and add together).

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceNonMatching.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceNonMatching.html 2023-08-09 23:38:57.530619861 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceNonMatching.html 2023-08-09 23:38:57.530619861 +0000 @@ -160,8 +160,8 @@
    -

    Type describing how a cell or a face is located relative to the zero contour of a level set function, $\psi$. The values of the type correspond to:

    -

    inside if $\psi(x) < 0$, outside if $\psi(x) > 0$, intersected if $\psi(x)$ varies in sign,

    +

    Type describing how a cell or a face is located relative to the zero contour of a level set function, $\psi$. The values of the type correspond to:

    +

    inside if $\psi(x) < 0$, outside if $\psi(x) > 0$, intersected if $\psi(x)$ varies in sign,

    over the cell/face. The value "unassigned" is used to describe that the location of a cell/face has not yet been determined.

    @@ -227,17 +227,17 @@
    Enumerator
    inside 
    const AffineConstraints< number > &&#href_anchor"paramname">immersed_constraints = AffineConstraints<number>()&#href_anchor"memdoc">

    Create a coupling sparsity pattern for non-matching, overlapping grids.

    -

    Given two non-matching triangulations, representing the domains $\Omega$ and $B$, with $B \subseteq \Omega$, and two finite element spaces $V(\Omega) = \text{span}\{v_i\}_{i=0}^n$ and $Q(B) =
-\text{span}\{w_j\}_{j=0}^m$, compute the sparsity pattern that would be necessary to assemble the matrix

    -\[
+<p>Given two non-matching triangulations, representing the domains <picture><source srcset=$\Omega$ and $B$, with $B \subseteq \Omega$, and two finite element spaces $V(\Omega) = \text{span}\{v_i\}_{i=0}^n$ and $Q(B) =
+\text{span}\{w_j\}_{j=0}^m$, compute the sparsity pattern that would be necessary to assemble the matrix

    +\[
 M_{ij} \dealcoloneq \int_{B} v_i(x) w_j(x) dx,
                     \quad i \in [0,n), j \in [0,m),
-\] +\]" src="form_2012.png"/>

    -

    where $V(\Omega)$ is the finite element space associated with the space_dh passed to this function (or part of it, if specified in space_comps), while $Q(B)$ is the finite element space associated with the immersed_dh passed to this function (or part of it, if specified in immersed_comps).

    -

    The sparsity is filled by locating the position of quadrature points (obtained by the reference quadrature quad) defined on elements of $B$ with respect to the embedding triangulation $\Omega$. For each overlapping cell, the entries corresponding to space_comps in space_dh and immersed_comps in immersed_dh are added to the sparsity pattern.

    +

    where $V(\Omega)$ is the finite element space associated with the space_dh passed to this function (or part of it, if specified in space_comps), while $Q(B)$ is the finite element space associated with the immersed_dh passed to this function (or part of it, if specified in immersed_comps).

    +

    The sparsity is filled by locating the position of quadrature points (obtained by the reference quadrature quad) defined on elements of $B$ with respect to the embedding triangulation $\Omega$. For each overlapping cell, the entries corresponding to space_comps in space_dh and immersed_comps in immersed_dh are added to the sparsity pattern.

    The space_comps and immersed_comps masks are assumed to be ordered in the same way: the first component of space_comps will couple with the first component of immersed_comps, the second with the second, and so on. If one of the two masks has more non-zero than the other, then the excess components will be ignored.

    -

    If the domain $B$ does not fall within $\Omega$, an exception will be thrown by the algorithm that computes the quadrature point locations. In particular, notice that this function only makes sens for dim1 lower or equal than dim0. A static assert guards that this is actually the case.

    +

    If the domain $B$ does not fall within $\Omega$, an exception will be thrown by the algorithm that computes the quadrature point locations. In particular, notice that this function only makes sens for dim1 lower or equal than dim0. A static assert guards that this is actually the case.

    For both spaces, it is possible to specify a custom Mapping, which defaults to StaticMappingQ1 for both.

    This function will also work in parallel, provided that the immersed triangulation is of type parallel::shared::Triangulation<dim1,spacedim>. An exception is thrown if you use an immersed parallel::distributed::Triangulation<dim1,spacedim>.

    See the tutorial program step-60 for an example on how to use this function.

    @@ -356,17 +356,17 @@
    const AffineConstraints< typename Matrix::value_type > &&#href_anchor"paramname">immersed_constraints = AffineConstraints<typename&#href_anchor"memdoc">

    Create a coupling mass matrix for non-matching, overlapping grids.

    -

    Given two non-matching triangulations, representing the domains $\Omega$ and $B$, with $B \subseteq \Omega$, and two finite element spaces $V(\Omega) = \text{span}\{v_i\}_{i=0}^n$ and $Q(B) =
-\text{span}\{w_j\}_{j=0}^m$, compute the coupling matrix

    -\[
+<p>Given two non-matching triangulations, representing the domains <picture><source srcset=$\Omega$ and $B$, with $B \subseteq \Omega$, and two finite element spaces $V(\Omega) = \text{span}\{v_i\}_{i=0}^n$ and $Q(B) =
+\text{span}\{w_j\}_{j=0}^m$, compute the coupling matrix

    +\[
 M_{ij} \dealcoloneq \int_{B} v_i(x) w_j(x) dx,
                     \quad i \in [0,n), j \in [0,m),
-\] +\]" src="form_2012.png"/>

    -

    where $V(\Omega)$ is the finite element space associated with the space_dh passed to this function (or part of it, if specified in space_comps), while $Q(B)$ is the finite element space associated with the immersed_dh passed to this function (or part of it, if specified in immersed_comps).

    -

    The corresponding sparsity patterns can be computed by calling the make_coupling_sparsity_pattern function. The elements of the matrix are computed by locating the position of quadrature points defined on elements of $B$ with respect to the embedding triangulation $\Omega$.

    +

    where $V(\Omega)$ is the finite element space associated with the space_dh passed to this function (or part of it, if specified in space_comps), while $Q(B)$ is the finite element space associated with the immersed_dh passed to this function (or part of it, if specified in immersed_comps).

    +

    The corresponding sparsity patterns can be computed by calling the make_coupling_sparsity_pattern function. The elements of the matrix are computed by locating the position of quadrature points defined on elements of $B$ with respect to the embedding triangulation $\Omega$.

    The space_comps and immersed_comps masks are assumed to be ordered in the same way: the first component of space_comps will couple with the first component of immersed_comps, the second with the second, and so on. If one of the two masks has more non-zero entries non-zero than the other, then the excess components will be ignored.

    -

    If the domain $B$ does not fall within $\Omega$, an exception will be thrown by the algorithm that computes the quadrature point locations. In particular, notice that this function only makes sense for dim1 lower or equal than dim0. A static assert guards that this is actually the case.

    +

    If the domain $B$ does not fall within $\Omega$, an exception will be thrown by the algorithm that computes the quadrature point locations. In particular, notice that this function only makes sense for dim1 lower or equal than dim0. A static assert guards that this is actually the case.

    For both spaces, it is possible to specify a custom Mapping, which defaults to StaticMappingQ1 for both.

    This function will also work in parallel, provided that the immersed triangulation is of type parallel::shared::Triangulation<dim1,spacedim>. An exception is thrown if you use an immersed parallel::distributed::Triangulation<dim1,spacedim>.

    See the tutorial program step-60 for an example on how to use this function.

    @@ -491,16 +491,16 @@
    const ComponentMask &&#href_anchor"paramname">comps1 = ComponentMask()&#href_anchor"memdoc">

    Create a coupling sparsity pattern for non-matching independent grids, using a convolution kernel with compact support of radius epsilon.

    -

    Given two non-matching triangulations, representing the domains $\Omega^0$ and $\Omega^1$, both embedded in $\mathbb{R}^d$, and two finite element spaces $V^0(\Omega^0) = \text{span}\{v_i\}_{i=0}^n$ and $V^1(\Omega^1) =
-\text{span}\{w_\alpha\}_{\alpha=0}^m$, compute the sparsity pattern that would be necessary to assemble the matrix

    +

    Given two non-matching triangulations, representing the domains $\Omega^0$ and $\Omega^1$, both embedded in $\mathbb{R}^d$, and two finite element spaces $V^0(\Omega^0) = \text{span}\{v_i\}_{i=0}^n$ and $V^1(\Omega^1) =
+\text{span}\{w_\alpha\}_{\alpha=0}^m$, compute the sparsity pattern that would be necessary to assemble the matrix

    -\[
+<picture><source srcset=\[
 M_{i\alpha} \dealcoloneq \int_{\Omega^0} \int_{\Omega^1}
 v_i(x) K^{\epsilon}(x-y) w_\alpha(y) dx \ dy,
 \quad i \in [0,n), \alpha \in [0,m),
-\] +\]" src="form_2020.png"/>

    -

    where $V^0(\Omega^0)$ is the finite element space associated with the dh0 passed to this function (or part of it, if specified in comps0), while $V^1(\Omega^1)$ is the finite element space associated with the dh1 passed to this function (or part of it, if specified in comps1), and $K^\epsilon$ is a function derived from CutOffFunctionBase with compact support included in a ball of radius $\epsilon$.

    +

    where $V^0(\Omega^0)$ is the finite element space associated with the dh0 passed to this function (or part of it, if specified in comps0), while $V^1(\Omega^1)$ is the finite element space associated with the dh1 passed to this function (or part of it, if specified in comps1), and $K^\epsilon$ is a function derived from CutOffFunctionBase with compact support included in a ball of radius $\epsilon$.

    The comps0 and comps1 masks are assumed to be ordered in the same way: the first component of comps0 will couple with the first component of comps1, the second with the second, and so on. If one of the two masks has more active components than the other, then the excess components will be ignored.

    For both spaces, it is possible to specify a custom Mapping, which defaults to StaticMappingQ1 for both.

    This function will also work in parallel, provided that at least one of the triangulations is of type parallel::shared::Triangulation<dim1,spacedim>. An exception is thrown if both triagnulations are of type parallel::distributed::Triangulation<dim1,spacedim>.

    @@ -577,15 +577,15 @@
    const ComponentMask &&#href_anchor"paramname">comps1 = ComponentMask()&#href_anchor"memdoc">

    Create a coupling mass matrix for non-matching independent grids, using a convolution kernel with compact support.

    -

    Given two non-matching triangulations, representing the domains $\Omega^0$ and $\Omega^1$, both embedded in $\mathbb{R}^d$, and two finite element spaces $V^0(\Omega^0) = \text{span}\{v_i\}_{i=0}^n$ and $V^1(\Omega^1) = \text{span}\{w_\alpha\}_{\alpha=0}^m$, compute the matrix

    +

    Given two non-matching triangulations, representing the domains $\Omega^0$ and $\Omega^1$, both embedded in $\mathbb{R}^d$, and two finite element spaces $V^0(\Omega^0) = \text{span}\{v_i\}_{i=0}^n$ and $V^1(\Omega^1) = \text{span}\{w_\alpha\}_{\alpha=0}^m$, compute the matrix

    -\[
+<picture><source srcset=\[
 M_{i\alpha} \dealcoloneq \int_{\Omega^0} \int_{\Omega^1}
 v_i(x) K^{\epsilon}(x-y) w_\alpha(y) dx \ dy,
 \quad i \in [0,n), \alpha \in [0,m),
-\] +\]" src="form_2020.png"/>

    -

    where $V^0(\Omega^0)$ is the finite element space associated with the dh0 passed to this function (or part of it, if specified in comps0), while $V^1(\Omega^1)$ is the finite element space associated with the dh1 passed to this function (or part of it, if specified in comps1), and $K^\epsilon$ is a function derived from CutOffFunctionBase with compact support included in a ball of radius $\epsilon$.

    +

    where $V^0(\Omega^0)$ is the finite element space associated with the dh0 passed to this function (or part of it, if specified in comps0), while $V^1(\Omega^1)$ is the finite element space associated with the dh1 passed to this function (or part of it, if specified in comps1), and $K^\epsilon$ is a function derived from CutOffFunctionBase with compact support included in a ball of radius $\epsilon$.

    The corresponding sparsity patterns can be computed by calling the make_coupling_sparsity_pattern() function.

    The comps0 and comps1 masks are assumed to be ordered in the same way: the first component of comps0 will couple with the first component of comps1, the second with the second, and so on. If one of the two masks has more active components than the other, then the excess components will be ignored.

    For both spaces, it is possible to specify a custom Mapping, which defaults to StaticMappingQ1 for both.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceNonMatching_1_1internal_1_1QuadratureGeneratorImplementation.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceNonMatching_1_1internal_1_1QuadratureGeneratorImplementation.html 2023-08-09 23:38:57.558620070 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceNonMatching_1_1internal_1_1QuadratureGeneratorImplementation.html 2023-08-09 23:38:57.558620070 +0000 @@ -296,7 +296,7 @@
    -

    Returns the max/min bounds on the value, taken over all the entries in the incoming vector of FunctionBounds. That is, given the incoming function bounds, $[L_j, U_j]$, this function returns $[L, U]$, where $L = \min_{j} L_j$ and $U = \max_{j} U_j$.

    +

    Returns the max/min bounds on the value, taken over all the entries in the incoming vector of FunctionBounds. That is, given the incoming function bounds, $[L_j, U_j]$, this function returns $[L, U]$, where $L = \min_{j} L_j$ and $U = \max_{j} U_j$.

    Definition at line 201 of file quadrature_generator.cc.

    @@ -318,21 +318,21 @@
    -

    Finds the best choice of height function direction, given the FunctionBounds for a number of functions $\{\psi_j\}_{j=0}^{n-1}$. Here, "best" is meant in the sense of the implicit function theorem.

    -

    Let $J_I$ be the index set of the indefinite functions:

    -

    $J_I = \{0,..., n - 1\} \setminus \{ j : |\psi_j| > 0 \}$.

    -

    This function converts the incoming bounds to a lower bound, $L_{ij}$, on the absolute value of each component of the gradient:

    -

    $|\partial_k \psi_j| > L_{jk}$.

    -

    and then returns a coordinate direction, $i$, and a lower bound $L$, such that

    +

    Finds the best choice of height function direction, given the FunctionBounds for a number of functions $\{\psi_j\}_{j=0}^{n-1}$. Here, "best" is meant in the sense of the implicit function theorem.

    +

    Let $J_I$ be the index set of the indefinite functions:

    +

    $J_I = \{0,..., n - 1\} \setminus \{ j : |\psi_j| > 0 \}$.

    +

    This function converts the incoming bounds to a lower bound, $L_{ij}$, on the absolute value of each component of the gradient:

    +

    $|\partial_k \psi_j| > L_{jk}$.

    +

    and then returns a coordinate direction, $i$, and a lower bound $L$, such that

    -\[
+<picture><source srcset=\[
 i = \arg \max_{k} \min_{j \in J_I} L_{jk}, \\
 L =      \max_{k} \min_{j \in J_I} L_{jk}.
-\] +\]" src="form_2134.png"/>

    -

    This means $i$ is a coordinate direction such that all functions intersected by the zero contour (i.e. those belonging to $J_I$) fulfill

    -

    $|\partial_i \psi_j| > L$.

    -

    Note that the estimated lower bound, $L$, can be zero or negative. This means that no suitable height function direction exists. If all of the incoming functions are positive or negative definite the returned std::optional is non-set.

    +

    This means $i$ is a coordinate direction such that all functions intersected by the zero contour (i.e. those belonging to $J_I$) fulfill

    +

    $|\partial_i \psi_j| > L$.

    +

    Note that the estimated lower bound, $L$, can be zero or negative. This means that no suitable height function direction exists. If all of the incoming functions are positive or negative definite the returned std::optional is non-set.

    Definition at line 275 of file quadrature_generator.cc.

    @@ -422,7 +422,7 @@
    -

    Given the incoming lower and upper bounds on the value of a function $[L, U]$, return the minimum/maximum of $[L, U]$ and the function values at the vertices. That is, this function returns

    +

    Given the incoming lower and upper bounds on the value of a function $[L, U]$, return the minimum/maximum of $[L, U]$ and the function values at the vertices. That is, this function returns

    $[\min(L, L_f), \max(U, U_f)]$,

    where $L_f = \min_{v} f(x_v)$, $U_f = \max_{v} f(x_v)|$, and $x_v$ is a vertex.

    It is assumed that the incoming function is scalar valued.

    @@ -519,7 +519,7 @@
    -

    Return a lower bound, $L_a$, on the absolute value of a function, $f(x)$:

    +

    Return a lower bound, $L_a$, on the absolute value of a function, $f(x)$:

    $L_a \leq |f(x)|$,

    by estimating it from the incoming lower and upper bounds: $L \leq f(x) \leq U$.

    By rewriting the lower and upper bounds as $F - C \leq f(x) \leq F + C$, where $L = F - C$, $U = F + C$ (or $F = (U + L)/2$, $C = (U - L)/2$), we get $|f(x) - F| \leq C$. Using the inverse triangle inequality gives $|F| - |f(x)| \leq |f(x) - F| \leq C$. Thus, $L_a = |F| - C$.

    @@ -742,7 +742,7 @@
    -

    Let $\{ y_0, ..., y_{n+1} \}$ be such that $[y_0, y_{n+1}]$ is the interval and $\{ y_1, ..., y_n \}$ are the roots. In each subinterval, $[y_i, y_{i+1}]$, distribute point according to the 1D-quadrature rule $\{(x_q, w_q)\}_q$ (quadrature1D). Take the tensor product with the quadrature point $(x, w)$ (point, weight) to create dim-dimensional quadrature points

    +

    Let $\{ y_0, ..., y_{n+1} \}$ be such that $[y_0, y_{n+1}]$ is the interval and $\{ y_1, ..., y_n \}$ are the roots. In each subinterval, $[y_i, y_{i+1}]$, distribute point according to the 1D-quadrature rule $\{(x_q, w_q)\}_q$ (quadrature1D). Take the tensor product with the quadrature point $(x, w)$ (point, weight) to create dim-dimensional quadrature points

    \[
 X_q = x_I \times (y_i + (y_{i+1} - y_i) x_q),
 W_q = w_I (y_{i+1} - y_i) w_q,
@@ -843,7 +843,7 @@
       </table>
 </div><div class=

    Return the coordinate direction that the box should be split in, assuming that the box should be split it half.

    -

    If the box is larger in one coordante direction, this direction is returned. If the box have the same extent in all directions, we choose the coordinate direction which is closest to being a height-function direction. That is, the direction $i$ that has a least negative estimate of $|\partial_i \psi_j|$. As a last resort, we choose the direction 0, if height_direction_data non-set.

    +

    If the box is larger in one coordante direction, this direction is returned. If the box have the same extent in all directions, we choose the coordinate direction which is closest to being a height-function direction. That is, the direction $i$ that has a least negative estimate of $|\partial_i \psi_j|$. As a last resort, we choose the direction 0, if height_direction_data non-set.

    Definition at line 995 of file quadrature_generator.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceOpenCASCADE.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceOpenCASCADE.html 2023-08-09 23:38:57.586620279 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceOpenCASCADE.html 2023-08-09 23:38:57.586620279 +0000 @@ -643,7 +643,7 @@ const Mapping< 2, spacedim > &&#href_anchor"paramname">mapping = StaticMappingQ1<2,&#href_anchor"memdoc">

    Given a Triangulation and an optional Mapping, create a vector of smooth curves that interpolate the connected parts of the boundary vertices of the Triangulation and return them as a vector of TopoDS_Edge objects.

    -

    This function constructs closed Bspline curve objects passing through all vertices of the boundary of the triangulation, with $C^2$ Continuity on each vertex except the first, where only $C^1$ continuity is guaranteed.

    +

    This function constructs closed Bspline curve objects passing through all vertices of the boundary of the triangulation, with $C^2$ Continuity on each vertex except the first, where only $C^1$ continuity is guaranteed.

    The returned curves are ordered with respect to the indices of the faces that make up the triangulation boundary, i.e., the first curve is the one extracted starting from the face with the lowest index, and so on.

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceParticles_1_1Utilities.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceParticles_1_1Utilities.html 2023-08-09 23:38:57.606620428 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceParticles_1_1Utilities.html 2023-08-09 23:38:57.606620428 +0000 @@ -139,21 +139,21 @@
    const ComponentMask &&#href_anchor"paramname">space_comps = ComponentMask()&#href_anchor"memdoc">

    Create an interpolation sparsity pattern for particles.

    -

    Given a triangulation representing the domain $\Omega$, a particle handler of particles in $\Omega$, and a scalar finite element space $V(\Omega) = \text{span}\{v_j\}_{j=0}^n$, compute the sparsity pattern that would be necessary to assemble the matrix

    -\[
+<p>Given a triangulation representing the domain <picture><source srcset=$\Omega$, a particle handler of particles in $\Omega$, and a scalar finite element space $V(\Omega) = \text{span}\{v_j\}_{j=0}^n$, compute the sparsity pattern that would be necessary to assemble the matrix

    +\[
 M_{i,j} \dealcoloneq v_j(x_i) ,
-\] +\]" src="form_2424.png"/>

    -

    where $V(\Omega)$ is the finite element space associated with the space_dh, and the index i is given by the particle id whose position is x_i.

    +

    where $V(\Omega)$ is the finite element space associated with the space_dh, and the index i is given by the particle id whose position is x_i.

    In the case of vector valued finite element spaces, the components on which interpolation must be performed can be selected using a component mask. Only primitive finite element spaces are supported.

    When selecting more than one component, the resulting sparsity will have dimension equal to particle_handler.n_global_particles() * mask.n_selected_components() times space_dh.n_dofs(), and the corresponding matrix entries are given by

    -\[
+<picture><source srcset=\[
  M_{(i*n_comps+k),j} \dealcoloneq v_j(x_i) \cdot e_{comp_j},
-\] +\]" src="form_2425.png"/>

    -

    where comp_j is the only non zero component of the vector valued basis function v_j (equal to fe.system_to_component_index(j).first), k corresponds to its index within the selected components of the mask, and $e_{comp_j}$ is the unit vector in the direction comp_j.

    -

    The sparsity is filled by locating the position of the particle with index i within the particle handler with respect to the embedding triangulation $\Omega$, and coupling it with all the local degrees of freedom specified in the component mask space_comps, following the ordering in which they are selected in the mask space_comps.

    -

    If a particle does not fall within $\Omega$, it is ignored, and the corresponding rows of the sparsity will be empty.

    +

    where comp_j is the only non zero component of the vector valued basis function v_j (equal to fe.system_to_component_index(j).first), k corresponds to its index within the selected components of the mask, and $e_{comp_j}$ is the unit vector in the direction comp_j.

    +

    The sparsity is filled by locating the position of the particle with index i within the particle handler with respect to the embedding triangulation $\Omega$, and coupling it with all the local degrees of freedom specified in the component mask space_comps, following the ordering in which they are selected in the mask space_comps.

    +

    If a particle does not fall within $\Omega$, it is ignored, and the corresponding rows of the sparsity will be empty.

    Constraints of the form supported by the AffineConstraints class may be supplied with the constraints argument. The method AffineConstraints::add_entries_local_to_global() is used to fill the final sparsity pattern.

    Definition at line 32 of file utilities.cc.

    @@ -191,21 +191,21 @@
    const ComponentMask &&#href_anchor"paramname">space_comps = ComponentMask()&#href_anchor"memdoc">

    Create an interpolation matrix for particles.

    -

    Given a triangulation representing the domains $\Omega$, a particle handler of particles in $\Omega$, and a scalar finite element space $V(\Omega) = \text{span}\{v_j\}_{j=0}^n$, compute the matrix

    -\[
+<p>Given a triangulation representing the domains <picture><source srcset=$\Omega$, a particle handler of particles in $\Omega$, and a scalar finite element space $V(\Omega) = \text{span}\{v_j\}_{j=0}^n$, compute the matrix

    +\[
 M_{ij} \dealcoloneq v_j(x_i) ,
-\] +\]" src="form_2427.png"/>

    -

    where $V(\Omega)$ is the finite element space associated with the space_dh, and the index i is given by the particle id whose position is x_i.

    +

    where $V(\Omega)$ is the finite element space associated with the space_dh, and the index i is given by the particle id whose position is x_i.

    In the case of vector valued finite element spaces, the components on which interpolation must be performed can be selected using a component mask. Only primitive finite element spaces are supported.

    When selecting more than one component, the resulting sparsity will have dimension equal to particle_handler.n_global_particles() * mask.n_selected_components() times space_dh.n_dofs(), and the corresponding matrix entries are given by

    -\[
+<picture><source srcset=\[
  M_{(i*n_comps+k),j} \dealcoloneq v_j(x_i) \cdot e_{comp_j},
-\] +\]" src="form_2425.png"/>

    -

    where comp_j is the only non zero component of the vector valued basis function v_j (equal to fe.system_to_component_index(j).first), k corresponds to its index within the selected components of the mask, and $e_{comp_j}$ is the unit vector in the direction comp_j.

    -

    The matrix is filled by locating the position of the particle with index i within the particle handler with respect to the embedding triangulation $\Omega$, and coupling it with all the local degrees of freedom specified in the component mask space_comps, following the ordering in which they are selected in the mask space_comps.

    -

    If a particle does not fall within $\Omega$, it is ignored, and the corresponding rows of the matrix will be zero.

    +

    where comp_j is the only non zero component of the vector valued basis function v_j (equal to fe.system_to_component_index(j).first), k corresponds to its index within the selected components of the mask, and $e_{comp_j}$ is the unit vector in the direction comp_j.

    +

    The matrix is filled by locating the position of the particle with index i within the particle handler with respect to the embedding triangulation $\Omega$, and coupling it with all the local degrees of freedom specified in the component mask space_comps, following the ordering in which they are selected in the mask space_comps.

    +

    If a particle does not fall within $\Omega$, it is ignored, and the corresponding rows of the matrix will be zero.

    Constraints of the form supported by the AffineConstraints class may be supplied with the constraints argument. The method AffineConstraints::distribute_local_to_global() is used to distribute the entries of the matrix to respect the given constraints.

    Definition at line 114 of file utilities.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Elasticity.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Elasticity.html 2023-08-09 23:38:57.622620548 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Elasticity.html 2023-08-09 23:38:57.622620548 +0000 @@ -124,53 +124,53 @@
    note = {ISBN: 978-3-540-71000-4},
    doi = {10.1007/978-3-540-71001-1}
    }
    -

    For convenience we will predefine some commonly referenced tensors and operations. Considering the position vector $\mathbf{X}$ in the referential (material) configuration, points $\mathbf{X}$ are transformed to points $\mathbf{x}$ in the current (spatial) configuration through the nonlinear map

    -\[
+</div><!-- fragment --><p>For convenience we will predefine some commonly referenced tensors and operations. Considering the position vector <picture><source srcset=$\mathbf{X}$ in the referential (material) configuration, points $\mathbf{X}$ are transformed to points $\mathbf{x}$ in the current (spatial) configuration through the nonlinear map

    +\[
  \mathbf{x}
   \dealcoloneq \boldsymbol{\varphi} \left( \mathbf{X} \right)
    = \mathbf{X} + \mathbf{u}(\mathbf{X}) \, ,
-\] +\]" src="form_248.png"/>

    -

    where the $\mathbf{u}(\mathbf{X})$ represents the displacement vector. From this we can compute the deformation gradient tensor as

    -\[
+<p> where the <picture><source srcset=$\mathbf{u}(\mathbf{X})$ represents the displacement vector. From this we can compute the deformation gradient tensor as

    +\[
  \mathbf{F} \dealcoloneq \mathbf{I} + \nabla_{0}\mathbf{u} \, ,
-\] +\]" src="form_250.png"/>

    -

    wherein the differential operator $\nabla_{0}$ is defined as $\frac{\partial}{\partial \mathbf{X}}$ and $\mathbf{I}$ is the identity tensor.

    -

    Finally, two common tensor operators are represented by $\cdot$ and $:$ operators. These respectively represent a single and double contraction over the inner tensor indices. Vectors and second-order tensors are highlighted by bold font, while fourth-order tensors are denoted by calliagraphic font.

    +

    wherein the differential operator $\nabla_{0}$ is defined as $\frac{\partial}{\partial \mathbf{X}}$ and $\mathbf{I}$ is the identity tensor.

    +

    Finally, two common tensor operators are represented by $\cdot$ and $:$ operators. These respectively represent a single and double contraction over the inner tensor indices. Vectors and second-order tensors are highlighted by bold font, while fourth-order tensors are denoted by calliagraphic font.

    One can think of fourth-order tensors as linear operators mapping second-order tensors (matrices) onto themselves in much the same way as matrices map vectors onto vectors. To provide some context to the implemented class members and functions, consider the following fundamental operations performed on tensors with special properties:

    -

    If we represent a general second-order tensor as $\mathbf{A}$, then the general fourth-order unit tensors $\mathcal{I}$ and $\overline{\mathcal{I}}$ are defined by

    -\[
+<p>If we represent a general second-order tensor as <picture><source srcset=$\mathbf{A}$, then the general fourth-order unit tensors $\mathcal{I}$ and $\overline{\mathcal{I}}$ are defined by

    +\[
  \mathbf{A} = \mathcal{I}:\mathbf{A}
        \qquad \text{and} \qquad
      \mathbf{A}^T = \overline{\mathcal{I}}:\mathbf{A} \, ,
-\] +\]" src="form_258.png"/>

    or, in indicial notation,

    -\[
+<picture><source srcset=\[
   I_{ijkl} = \delta_{ik}\delta_{jl}
        \qquad \text{and} \qquad
     \overline I_{ijkl} = \delta_{il}\delta_{jk}
-\] +\]" src="form_259.png"/>

    -

    with the Kronecker deltas taking their common definition. Note that $\mathcal{I} \neq \overline{\mathcal{I}}^T$.

    +

    with the Kronecker deltas taking their common definition. Note that $\mathcal{I} \neq \overline{\mathcal{I}}^T$.

    We then define the symmetric and skew-symmetric fourth-order unit tensors by

    -\[
+<picture><source srcset=\[
 \mathcal{S} \dealcoloneq
 \dfrac{1}{2}[\mathcal{I} + \overline{\mathcal{I}}]
 \qquad \text{and} \qquad
 \mathcal{W} \dealcoloneq
 \dfrac{1}{2}[\mathcal{I} - \overline{\mathcal{I}}] \, ,
-\] +\]" src="form_261.png"/>

    such that

    -\[
+<picture><source srcset=\[
      \mathcal{S}:\mathbf{A} = \dfrac{1}{2}[\mathbf{A} + \mathbf{A}^T]
    \qquad \text{and} \qquad
      \mathcal{W}:\mathbf{A} = \dfrac{1}{2}[\mathbf{A} - \mathbf{A}^T] \, .
-\] +\]" src="form_262.png"/>

    -

    The fourth-order symmetric tensor returned by identity_tensor() is $\mathcal{S}$.

    +

    The fourth-order symmetric tensor returned by identity_tensor() is $\mathcal{S}$.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Elasticity_1_1Kinematics.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Elasticity_1_1Kinematics.html 2023-08-09 23:38:57.642620697 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Elasticity_1_1Kinematics.html 2023-08-09 23:38:57.642620697 +0000 @@ -154,7 +154,7 @@ =\mathbf{I} + \nabla_{0}\mathbf{u} \]" src="form_2428.png"/>

    -

    where $\mathbf{u} = \mathbf{u}\left(\mathbf{X}\right)$ is the displacement at position $\mathbf{X}$ in the referential configuration. The differential operator $\nabla_{0}$ is defined as $\frac{\partial}{\partial \mathbf{X}}$.

    +

    where $\mathbf{u} = \mathbf{u}\left(\mathbf{X}\right)$ is the displacement at position $\mathbf{X}$ in the referential configuration. The differential operator $\nabla_{0}$ is defined as $\frac{\partial}{\partial \mathbf{X}}$.

    Note
    For a discussion of the background of this function, see P. Wriggers: "Nonlinear finite element methods" (2008), and in particular formula (3.14) on p. 23 (or thereabouts).
    For a discussion of the background of this function, see G. A. Holzapfel: "Nonlinear solid mechanics. A Continuum Approach for Engineering" (2007), and in particular formula (2.39) on p. 71 (or thereabouts).
    @@ -321,7 +321,7 @@ \left[ \nabla_{0}\mathbf{u} + [\nabla_{0}\mathbf{u}]^{T} \right] \, . \]" src="form_2436.png"/>

    -

    where $\mathbf{u} = \mathbf{u}(\mathbf{X})$ is the displacement at position $\mathbf{X}$ in the referential configuration. The differential operator $\nabla_{0}$ is defined as $\frac{\partial}{\partial \mathbf{X}}$.

    +

    where $\mathbf{u} = \mathbf{u}(\mathbf{X})$ is the displacement at position $\mathbf{X}$ in the referential configuration. The differential operator $\nabla_{0}$ is defined as $\frac{\partial}{\partial \mathbf{X}}$.

    Note
    For a discussion of the background of this function, see P. Wriggers: "Nonlinear finite element methods" (2008), and in particular formula (3.17) on p. 24 (or thereabouts).
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Notation.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Notation.html 2023-08-09 23:38:57.654620787 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Notation.html 2023-08-09 23:38:57.654620787 +0000 @@ -100,7 +100,7 @@
    namespace &#href_anchor"memItemRight" valign="bottom">Kelvin
    &#href_anchor"mdescRight">A namespace with functions that assist in the conversion of vectors and tensors to and from a compressed format using Kelvin notation and weighting.
    &#href_anchor"details" id="details">

    Detailed Description

    -

    Notations that reduce the order of tensors, effectively storing them in some sort of consistent compressed storage pattern. An example is storing the 6 independent components of $3\times 3$ symmetric tensors of rank 2 as a vector with 6 components, and then representing the 36 independent elements of symmetric $3\times 3 \times 3\times 3$ tensors of rank 4 (which when applied to a symmetric rank-2 tensor yields another symmetric rank-2 tensor) as a $6 \times 6$ matrix.

    +

    Notations that reduce the order of tensors, effectively storing them in some sort of consistent compressed storage pattern. An example is storing the 6 independent components of $3\times 3$ symmetric tensors of rank 2 as a vector with 6 components, and then representing the 36 independent elements of symmetric $3\times 3 \times 3\times 3$ tensors of rank 4 (which when applied to a symmetric rank-2 tensor yields another symmetric rank-2 tensor) as a $6 \times 6$ matrix.

    Although this method of representing tensors is most regularly associated with the efficient storage of the fourth-order elasticity tensor, with its generalization it has wider applicability. This representation is also common in the physics, material science and FEM literature.

    There are several variations of tensor notation, each a slightly different structure. The primary difference between the various forms of tensor notation is the weighting prescribed to the various elements of the compressed tensors. This wikipedia article has some further general insights on this topic.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Notation_1_1Kelvin.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Notation_1_1Kelvin.html 2023-08-09 23:38:57.686621026 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Notation_1_1Kelvin.html 2023-08-09 23:38:57.686621026 +0000 @@ -166,8 +166,8 @@
    TensorType to_tensor (const FullMatrix< Number > &vec)
    &#href_anchor"details" id="details">

    Detailed Description

    A namespace with functions that assist in the conversion of vectors and tensors to and from a compressed format using Kelvin notation and weighting.

    -

    Both Kelvin and Voigt notation adopt the same indexing convention. With specific reference to the spatial dimension 3 case, for a rank-2 symmetric tensor $\mathbf{S}$ we enumerate its tensor components

    -\[
+<p>Both <a class=Kelvin and Voigt notation adopt the same indexing convention. With specific reference to the spatial dimension 3 case, for a rank-2 symmetric tensor $\mathbf{S}$ we enumerate its tensor components

    +\[
 \mathbf{S} \dealcoloneq \left[ \begin{array}{ccc}
  S_{00}          & S_{01}          & S_{02} \\
  S_{10} = S_{01} & S_{11}          & S_{12} \\
@@ -179,10 +179,10 @@
  sym   & n = 1 & n = 3 \\
  sym   & sym   & n = 2
 \end{array} \right] ,
-\] +\]" src="form_2465.png"/>

    -

    where $n$ denotes the Kelvin index for the tensor component, while for a general rank-2 tensor $\mathbf{T}$

    -\[
+<p> where <picture><source srcset=$n$ denotes the Kelvin index for the tensor component, while for a general rank-2 tensor $\mathbf{T}$

    +\[
 \mathbf{T} \dealcoloneq \left[ \begin{array}{ccc}
  T_{00} & T_{01} & T_{02} \\
  T_{10} & T_{11} & T_{12} \\
@@ -194,10 +194,10 @@
  n = 6 & n = 1 & n = 3 \\
  n = 7 & n = 8 & n = 2
 \end{array}\right] ,
-\] +\]" src="form_2467.png"/>

    -

    and for a rank-1 tensor $\mathbf{v}$

    -\[
+<p> and for a rank-1 tensor <picture><source srcset=$\mathbf{v}$

    +\[
 \mathbf{v} \dealcoloneq \left[ \begin{array}{c}
  v_{0} \\ v_{1} \\ v_{2}
 \end{array}\right]
@@ -205,7 +205,7 @@
 \left[ \begin{array}{c}
  n = 0 \\ n = 1 \\ n = 2
 \end{array}\right] .
-\] +\]" src="form_2469.png"/>

    To summarize, the relationship between tensor and Kelvin indices for both the three-dimensional case and the analogously discerned two-dimensional case outlined in the following table:

    @@ -247,23 +247,23 @@
    -

    To illustrate the purpose of this notation, consider the rank-2 symmetric tensors $\mathbf{S}$ and $\mathbf{E}$ that are related to one another by $\mathbf{S} = \cal{C} : \mathbf{E}$, where the operator $\cal{C}$ is a fourth-order symmetric tensor. As opposed to the commonly used Voigt notation, Kelvin (or Mandel) notation keeps the same definition of the inner product $\mathbf{S} : \mathbf{E}$ when both $\mathbf{S}$ and $\mathbf{E}$ are symmetric. In general, the inner product of all symmetric and general tensors remain the same regardless of the notation with which it is represented.

    +

    To illustrate the purpose of this notation, consider the rank-2 symmetric tensors $\mathbf{S}$ and $\mathbf{E}$ that are related to one another by $\mathbf{S} = \cal{C} : \mathbf{E}$, where the operator $\cal{C}$ is a fourth-order symmetric tensor. As opposed to the commonly used Voigt notation, Kelvin (or Mandel) notation keeps the same definition of the inner product $\mathbf{S} : \mathbf{E}$ when both $\mathbf{S}$ and $\mathbf{E}$ are symmetric. In general, the inner product of all symmetric and general tensors remain the same regardless of the notation with which it is represented.

    To achieve these two properties, namely that

    -\[
+<picture><source srcset=\[
 \mathbf{S} = \cal{C} : \mathbf{E}
 \quad \Rightarrow   \quad
 \tilde{\mathbf{S}} = \tilde{\cal{C}} \; \tilde{\mathbf{E}}
-\] +\]" src="form_2474.png"/>

    and

    -\[
+<picture><source srcset=\[
 \mathbf{S} : \mathbf{E}
 \, \equiv \,
 \tilde{\mathbf{S}} \cdot \tilde{\mathbf{E}} ,
-\] +\]" src="form_2475.png"/>

    -

    it holds that the Kelvin-condensed equivalents of the previously defined symmetric tensors, indicated by the $\tilde{\left(\bullet\right)}$, must be defined as

    -\[
+<p> it holds that the Kelvin-condensed equivalents of the previously defined symmetric tensors, indicated by the <picture><source srcset=$\tilde{\left(\bullet\right)}$, must be defined as

    +\[
 \tilde{\mathbf{S}}
   = \left[ \begin{array}{c}
   S_{00} \\ S_{11} \\ S_{22} \\ \sqrt{2} S_{12} \\ \sqrt{2} S_{02} \\
@@ -272,10 +272,10 @@
   = \left[ \begin{array}{c}
   E_{00} \\ E_{11} \\ E_{22} \\ \sqrt{2} E_{12} \\ \sqrt{2} E_{02} \\
 \sqrt{2} E_{01} \end{array}\right] .
-\] +\]" src="form_2477.png"/>

    The corresponding and consistent condensed fourth-order symmetric tensor is

    -\[
+<picture><source srcset=\[
 \tilde{\cal{C}}
   = \left[ \begin{array}{cccccc}
   \tilde{\cal{C}}_{00} & \tilde{\cal{C}}_{01} & \tilde{\cal{C}}_{02} &
@@ -310,10 +310,10 @@
 {\cal{C}}_{0201}        \\ \sqrt{2} {\cal{C}}_{0100}  & \sqrt{2}
 {\cal{C}}_{0111} & \sqrt{2} {\cal{C}}_{0122}  & 2 {\cal{C}}_{0112} & 2
 {\cal{C}}_{0102}         & 2 {\cal{C}}_{0101} \end{array}\right] .
-\] +\]" src="form_2478.png"/>

    -

    The mapping from the two Kelvin indices of the FullMatrix $\tilde{\cal{C}}$ to the rank-4 SymmetricTensor $\cal{C}$ can be inferred using the table shown above.

    -

    An important observation is that both the left-hand side tensor $\tilde{\mathbf{S}}$ and right-hand side tensor $\tilde{\mathbf{E}}$ have the same form; this is a property that is not present in Voigt notation. The various factors introduced into $\tilde{\mathbf{S}}$, $\tilde{\mathbf{E}}$ and $\tilde{\cal{C}}$ account for the symmetry of the tensors. The Kelvin description of their non-symmetric counterparts include no such factors.

    +

    The mapping from the two Kelvin indices of the FullMatrix $\tilde{\cal{C}}$ to the rank-4 SymmetricTensor $\cal{C}$ can be inferred using the table shown above.

    +

    An important observation is that both the left-hand side tensor $\tilde{\mathbf{S}}$ and right-hand side tensor $\tilde{\mathbf{E}}$ have the same form; this is a property that is not present in Voigt notation. The various factors introduced into $\tilde{\mathbf{S}}$, $\tilde{\mathbf{E}}$ and $\tilde{\cal{C}}$ account for the symmetry of the tensors. The Kelvin description of their non-symmetric counterparts include no such factors.

    Some useful references that show how this notation works include, amongst others,

    @article{Nagel2016,
    author = {Nagel, T. and G{\"o}rke, U-J. and Moerman, K. and Kolditz,
    O.},
    @@ -395,7 +395,7 @@

    Convert a rank-1 tensor to its compressed vector equivalent.

    -

    The output vector has $dim$ entries.

    +

    The output vector has $dim$ entries.

    @@ -500,7 +500,7 @@

    Convert a rank-1 tensor to its compressed matrix equivalent.

    -

    The output matrix will have $dim$ rows and one column.

    +

    The output matrix will have $dim$ rows and one column.

    @@ -521,7 +521,7 @@

    Convert a rank-2 tensor to its compressed matrix equivalent.

    -

    The output matrix will have $dim$ rows and $dim$ columns.

    +

    The output matrix will have $dim$ rows and $dim$ columns.

    @@ -542,7 +542,7 @@

    Convert a rank-2 symmetric tensor to its compressed matrix equivalent.

    -

    The output matrix will have $dim$ rows and $dim$ columns, with the same format as the equivalent function for non-symmetric tensors. This is because it is not possible to compress the SymmetricTensor<2,dim>::n_independent_components unique entries into a square matrix.

    +

    The output matrix will have $dim$ rows and $dim$ columns, with the same format as the equivalent function for non-symmetric tensors. This is because it is not possible to compress the SymmetricTensor<2,dim>::n_independent_components unique entries into a square matrix.

    @@ -578,7 +578,7 @@
    Definition: tensor.h:516
    -

    the matrix mtrx_1 will have $dim \times dim$ rows and $dim$ columns (i.e. size Tensor<2,dim>::n_independent_components $\times$ Tensor<1,dim>::n_independent_components), while those of the matrix mtrx_2 will have $dim$ rows and $(dim \times dim + dim)/2$ columns (i.e. size Tensor<1,dim>::n_independent_components $\times$ SymmetricTensor<2,dim>::n_independent_components), as it is assumed that the entries corresponding to the alternation of the second and third indices are equal. That is to say that r3_symm_tnsr[i][j][k] == r3_symm_tnsr[i][k][j].

    +

    the matrix mtrx_1 will have $dim \times dim$ rows and $dim$ columns (i.e. size Tensor<2,dim>::n_independent_components $\times$ Tensor<1,dim>::n_independent_components), while those of the matrix mtrx_2 will have $dim$ rows and $(dim \times dim + dim)/2$ columns (i.e. size Tensor<1,dim>::n_independent_components $\times$ SymmetricTensor<2,dim>::n_independent_components), as it is assumed that the entries corresponding to the alternation of the second and third indices are equal. That is to say that r3_symm_tnsr[i][j][k] == r3_symm_tnsr[i][k][j].

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations.html 2023-08-09 23:38:57.706621175 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations.html 2023-08-09 23:38:57.706621175 +0000 @@ -121,8 +121,8 @@ &#href_anchor"details" id="details">

    Detailed Description

    A collection of operations to assist in the transformation of tensor quantities from the reference to spatial configuration, and vice versa. These types of transformation are typically used to re-express quantities measured or computed in one configuration in terms of a second configuration.

    Notation

    -

    We will use the same notation for the coordinates $\mathbf{X}, \mathbf{x}$, transformations $\varphi$, differential operator $\nabla_{0}$ and deformation gradient $\mathbf{F}$ as discussed for namespace Physics::Elasticity.

    -

    As a further point on notation, we will follow Holzapfel (2007) and denote the push forward transformation as $\chi\left(\bullet\right)$ and the pull back transformation as $\chi^{-1}\left(\bullet\right)$. We will also use the annotation $\left(\bullet\right)^{\sharp}$ to indicate that a tensor $\left(\bullet\right)$ is a contravariant tensor, and $\left(\bullet\right)^{\flat}$ that it is covariant. In other words, these indices do not actually change the tensor, they just indicate the kind of object a particular tensor is.

    +

    We will use the same notation for the coordinates $\mathbf{X}, \mathbf{x}$, transformations $\varphi$, differential operator $\nabla_{0}$ and deformation gradient $\mathbf{F}$ as discussed for namespace Physics::Elasticity.

    +

    As a further point on notation, we will follow Holzapfel (2007) and denote the push forward transformation as $\chi\left(\bullet\right)$ and the pull back transformation as $\chi^{-1}\left(\bullet\right)$. We will also use the annotation $\left(\bullet\right)^{\sharp}$ to indicate that a tensor $\left(\bullet\right)$ is a contravariant tensor, and $\left(\bullet\right)^{\flat}$ that it is covariant. In other words, these indices do not actually change the tensor, they just indicate the kind of object a particular tensor is.

    Note
    For these transformations, unless otherwise stated, we will strictly assume that all indices of the transformed tensors derive from one coordinate system; that is to say that they are not multi-point tensors (such as the Piola stress in elasticity).

    Function Documentation

    @@ -150,24 +150,24 @@
    -

    Return the result of applying Nanson's formula for the transformation of the material surface area element $d\mathbf{A}$ to the current surfaces area element $d\mathbf{a}$ under the nonlinear transformation map $\mathbf{x} = \boldsymbol{\varphi} \left( \mathbf{X} \right)$.

    +

    Return the result of applying Nanson's formula for the transformation of the material surface area element $d\mathbf{A}$ to the current surfaces area element $d\mathbf{a}$ under the nonlinear transformation map $\mathbf{x} = \boldsymbol{\varphi} \left( \mathbf{X} \right)$.

    The returned result is the spatial normal scaled by the ratio of areas between the reference and spatial surface elements, i.e.

    -\[
+<picture><source srcset=\[
  \mathbf{n} \frac{da}{dA}
  \dealcoloneq \textrm{det} \mathbf{F} \, \mathbf{F}^{-T} \cdot \mathbf{N}
  = \textrm{cof} \mathbf{F} \cdot \mathbf{N} \, .
-\] +\]" src="form_2503.png"/>

    Parameters
    - - + +
    [in]NThe referential normal unit vector $\mathbf{N}$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]NThe referential normal unit vector $\mathbf{N}$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    The scaled spatial normal vector $\mathbf{n}
-\frac{da}{dA}$
    +
    Returns
    The scaled spatial normal vector $\mathbf{n}
+\frac{da}{dA}$
    Note
    For a discussion of the background of this function, see G. A. Holzapfel: "Nonlinear solid mechanics. A Continuum Approach for Engineering" (2007), and in particular formula (2.55) on p. 75 (or thereabouts).
    For a discussion of the background of this function, see P. Wriggers: "Nonlinear finite element methods" (2008), and in particular formula (3.11) on p. 23 (or thereabouts).
    @@ -200,18 +200,18 @@

    Return a vector with a changed basis, i.e.

    -\[
+<picture><source srcset=\[
  \mathbf{V}^{\prime} \dealcoloneq \mathbf{B} \cdot \mathbf{V}
-\] +\]" src="form_2506.png"/>

    Parameters
    - - + +
    [in]VThe vector to be transformed $\mathbf{V}$
    [in]BThe transformation matrix $\mathbf{B}$
    [in]VThe vector to be transformed $\mathbf{V}$
    [in]BThe transformation matrix $\mathbf{B}$
    -
    Returns
    $\mathbf{V}^{\prime}$
    +
    Returns
    $\mathbf{V}^{\prime}$
    @@ -241,19 +241,19 @@

    Return a rank-2 tensor with a changed basis, i.e.

    -\[
+<picture><source srcset=\[
  \mathbf{T}^{\prime} \dealcoloneq \mathbf{B} \cdot \mathbf{T} \cdot
 \mathbf{B}^{T}
-\] +\]" src="form_2508.png"/>

    Parameters
    - - + +
    [in]TThe tensor to be transformed $\mathbf{T}$
    [in]BThe transformation matrix $\mathbf{B}$
    [in]TThe tensor to be transformed $\mathbf{T}$
    [in]BThe transformation matrix $\mathbf{B}$
    -
    Returns
    $\mathbf{T}^{\prime}$
    +
    Returns
    $\mathbf{T}^{\prime}$
    @@ -283,19 +283,19 @@

    Return a symmetric rank-2 tensor with a changed basis, i.e.

    -\[
+<picture><source srcset=\[
  \mathbf{T}^{\prime} \dealcoloneq \mathbf{B} \cdot \mathbf{T} \cdot
 \mathbf{B}^{T}
-\] +\]" src="form_2508.png"/>

    Parameters
    - - + +
    [in]TThe tensor to be transformed $\mathbf{T}$
    [in]BThe transformation matrix $\mathbf{B}$
    [in]TThe tensor to be transformed $\mathbf{T}$
    [in]BThe transformation matrix $\mathbf{B}$
    -
    Returns
    $\mathbf{T}^{\prime}$
    +
    Returns
    $\mathbf{T}^{\prime}$
    @@ -325,18 +325,18 @@

    Return a rank-4 tensor with a changed basis, i.e. (in index notation):

    -\[
+<picture><source srcset=\[
  H_{ijkl}^{\prime} \dealcoloneq B_{iI} B_{jJ} H_{IJKL} B_{kK} B_{lL}
-\] +\]" src="form_2510.png"/>

    Parameters
    - - + +
    [in]HThe tensor to be transformed $\mathbf{T}$
    [in]BThe transformation matrix $\mathbf{B}$
    [in]HThe tensor to be transformed $\mathbf{T}$
    [in]BThe transformation matrix $\mathbf{B}$
    -
    Returns
    $\mathbf{H}^{\prime}$
    +
    Returns
    $\mathbf{H}^{\prime}$
    @@ -366,18 +366,18 @@

    Return a symmetric rank-4 tensor with a changed basis, i.e. (in index notation):

    -\[
+<picture><source srcset=\[
  H_{ijkl}^{\prime} \dealcoloneq B_{iI} B_{jJ} H_{IJKL} B_{kK} B_{lL}
-\] +\]" src="form_2510.png"/>

    Parameters
    - - + +
    [in]HThe tensor to be transformed $\mathbf{T}$
    [in]BThe transformation matrix $\mathbf{B}$
    [in]HThe tensor to be transformed $\mathbf{T}$
    [in]BThe transformation matrix $\mathbf{B}$
    -
    Returns
    $\mathbf{H}^{\prime}$
    +
    Returns
    $\mathbf{H}^{\prime}$
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Contravariant.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Contravariant.html 2023-08-09 23:38:57.726621325 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Contravariant.html 2023-08-09 23:38:57.726621325 +0000 @@ -118,16 +118,16 @@ &#href_anchor"memitem:af70b1a5907ac2a88ab2a053dfb055dbe">template<int dim, typename Number > SymmetricTensor< 4, dim, Number >&#href_anchor"memTemplItemRight" valign="bottom">pull_back (const SymmetricTensor< 4, dim, Number > &h, const Tensor< 2, dim, Number > &F) &#href_anchor"details" id="details">

    Detailed Description

    -

    Transformation of tensors that are defined in terms of a set of contravariant bases. Rank-1 and rank-2 contravariant tensors $\left(\bullet\right)^{\sharp} = \mathbf{T}$ (and its spatial counterpart $\mathbf{t}$) typically satisfy the relation

    -\[
+<div class=

    Transformation of tensors that are defined in terms of a set of contravariant bases. Rank-1 and rank-2 contravariant tensors $\left(\bullet\right)^{\sharp} = \mathbf{T}$ (and its spatial counterpart $\mathbf{t}$) typically satisfy the relation

    +\[
    \int_{V_{0}} \nabla_{0} \cdot \mathbf{T} \; dV
      = \int_{\partial V_{0}} \mathbf{T} \cdot \mathbf{N} \; dA
      = \int_{\partial V_{t}} \mathbf{T} \cdot \mathbf{n} \; da
      = \int_{V_{t}} \nabla \cdot \mathbf{t} \; dv
-\] +\]" src="form_2486.png"/>

    -

    where $V_{0}$ and $V_{t}$ are respectively control volumes in the reference and spatial configurations, and their surfaces $\partial
-V_{0}$ and $\partial V_{t}$ have the outwards facing normals $\mathbf{N}$ and $\mathbf{n}$.

    +

    where $V_{0}$ and $V_{t}$ are respectively control volumes in the reference and spatial configurations, and their surfaces $\partial
+V_{0}$ and $\partial V_{t}$ have the outwards facing normals $\mathbf{N}$ and $\mathbf{n}$.

    Function Documentation

    ◆ push_forward() [1/5]

    @@ -155,20 +155,20 @@

    Return the result of the push forward transformation on a contravariant vector, i.e.

    -\[
+<picture><source srcset=\[
  \chi\left(\bullet\right)^{\sharp}
    \dealcoloneq \mathbf{F} \cdot \left(\bullet\right)^{\sharp}
-\] +\]" src="form_2517.png"/>

    Parameters
    - +
    [in]VThe (referential) vector to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\chi\left( \mathbf{V} \right)$
    +
    Returns
    $\chi\left( \mathbf{V} \right)$
    @@ -198,21 +198,21 @@

    Return the result of the push forward transformation on a rank-2 contravariant tensor, i.e.

    -\[
+<picture><source srcset=\[
  \chi\left(\bullet\right)^{\sharp}
    \dealcoloneq \mathbf{F} \cdot \left(\bullet\right)^{\sharp} \cdot
 \mathbf{F}^{T}
-\] +\]" src="form_2519.png"/>

    Parameters
    - +
    [in]TThe (referential) rank-2 tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\chi\left( \mathbf{T} \right)$
    +
    Returns
    $\chi\left( \mathbf{T} \right)$
    @@ -242,21 +242,21 @@

    Return the result of the push forward transformation on a rank-2 contravariant symmetric tensor, i.e.

    -\[
+<picture><source srcset=\[
  \chi\left(\bullet\right)^{\sharp}
    \dealcoloneq \mathbf{F} \cdot \left(\bullet\right)^{\sharp} \cdot
 \mathbf{F}^{T}
-\] +\]" src="form_2519.png"/>

    Parameters
    - +
    [in]TThe (referential) rank-2 symmetric tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\chi\left( \mathbf{T} \right)$
    +
    Returns
    $\chi\left( \mathbf{T} \right)$
    @@ -286,21 +286,21 @@

    Return the result of the push forward transformation on a rank-4 contravariant tensor, i.e. (in index notation):

    -\[
+<picture><source srcset=\[
  \left[ \chi\left(\bullet\right)^{\sharp} \right]_{ijkl}
    \dealcoloneq F_{iI} F_{jJ}
    \left(\bullet\right)^{\sharp}_{IJKL} F_{kK} F_{lL}
-\] +\]" src="form_2521.png"/>

    Parameters
    - +
    [in]HThe (referential) rank-4 tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\chi\left( \mathbf{H} \right)$
    +
    Returns
    $\chi\left( \mathbf{H} \right)$
    @@ -330,21 +330,21 @@

    Return the result of the push forward transformation on a rank-4 contravariant symmetric tensor, i.e. (in index notation):

    -\[
+<picture><source srcset=\[
  \left[ \chi\left(\bullet\right)^{\sharp} \right]_{ijkl}
    \dealcoloneq F_{iI} F_{jJ}
    \left(\bullet\right)^{\sharp}_{IJKL} F_{kK} F_{lL}
-\] +\]" src="form_2521.png"/>

    Parameters
    - +
    [in]HThe (referential) rank-4 symmetric tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\chi\left( \mathbf{H} \right)$
    +
    Returns
    $\chi\left( \mathbf{H} \right)$
    @@ -374,20 +374,20 @@

    Return the result of the pull back transformation on a contravariant vector, i.e.

    -\[
+<picture><source srcset=\[
  \chi^{-1}\left(\bullet\right)^{\sharp}
    \dealcoloneq \mathbf{F}^{-1} \cdot \left(\bullet\right)^{\sharp}
-\] +\]" src="form_2523.png"/>

    Parameters
    - +
    [in]vThe (spatial) vector to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\chi^{-1}\left( \mathbf{v} \right)$
    +
    Returns
    $\chi^{-1}\left( \mathbf{v} \right)$
    @@ -417,21 +417,21 @@

    Return the result of the pull back transformation on a rank-2 contravariant tensor, i.e.

    -\[
+<picture><source srcset=\[
  \chi^{-1}\left(\bullet\right)^{\sharp}
    \dealcoloneq \mathbf{F}^{-1} \cdot \left(\bullet\right)^{\sharp}
    \cdot \mathbf{F}^{-T}
-\] +\]" src="form_2525.png"/>

    Parameters
    -
    [in]tThe (spatial) tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Covariant.html differs (HTML document, ASCII text, with very long lines)
--- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Covariant.html	2023-08-09 23:38:57.746621474 +0000
+++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Covariant.html	2023-08-09 23:38:57.746621474 +0000
@@ -118,16 +118,16 @@
 <tr class=&#href_anchor"memitem:a138fff54a44ba86bc2d1a6200b148e90">template<int dim, typename Number >
    SymmetricTensor< 4, dim, Number >&#href_anchor"memTemplItemRight" valign="bottom">pull_back (const SymmetricTensor< 4, dim, Number > &h, const Tensor< 2, dim, Number > &F)
    &#href_anchor"details" id="details">

    Detailed Description

    -

    Transformation of tensors that are defined in terms of a set of covariant basis vectors. Rank-1 and rank-2 covariant tensors $\left(\bullet\right)^{\flat} = \mathbf{T}$ (and its spatial counterpart $\mathbf{t}$) typically satisfy the relation

    -\[
+<div class=

    Transformation of tensors that are defined in terms of a set of covariant basis vectors. Rank-1 and rank-2 covariant tensors $\left(\bullet\right)^{\flat} = \mathbf{T}$ (and its spatial counterpart $\mathbf{t}$) typically satisfy the relation

    +\[
    \int_{\partial V_{0}} \left[ \nabla_{0} \times \mathbf{T} \right]
 \cdot \mathbf{N} \; dA = \oint_{\partial A_{0}} \mathbf{T} \cdot
 \mathbf{L} \; dL = \oint_{\partial A_{t}} \mathbf{t} \cdot \mathbf{l} \;
 dl = \int_{\partial V_{t}} \left[ \nabla \times \mathbf{t} \right] \cdot
 \mathbf{n} \; da
-\] +\]" src="form_2494.png"/>

    -

    where the control surfaces $\partial V_{0}$ and $\partial V_{t}$ with outwards facing normals $\mathbf{N}$ and $\mathbf{n}$ are bounded by the curves $\partial A_{0}$ and $\partial A_{t}$ that are, respectively, associated with the line directors $\mathbf{L}$ and $\mathbf{l}$.

    +

    where the control surfaces $\partial V_{0}$ and $\partial V_{t}$ with outwards facing normals $\mathbf{N}$ and $\mathbf{n}$ are bounded by the curves $\partial A_{0}$ and $\partial A_{t}$ that are, respectively, associated with the line directors $\mathbf{L}$ and $\mathbf{l}$.

    Function Documentation

    ◆ push_forward() [1/5]

    @@ -155,20 +155,20 @@

    Return the result of the push forward transformation on a covariant vector, i.e.

    -\[
+<picture><source srcset=\[
  \chi\left(\bullet\right)^{\flat}
    \dealcoloneq \mathbf{F}^{-T} \cdot \left(\bullet\right)^{\flat}
-\] +\]" src="form_2530.png"/>

    Parameters
    - +
    [in]VThe (referential) vector to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\chi\left( \mathbf{V} \right)$
    +
    Returns
    $\chi\left( \mathbf{V} \right)$
    @@ -198,21 +198,21 @@

    Return the result of the push forward transformation on a rank-2 covariant tensor, i.e.

    -\[
+<picture><source srcset=\[
  \chi\left(\bullet\right)^{\flat}
    \dealcoloneq \mathbf{F}^{-T} \cdot \left(\bullet\right)^{\flat}
    \cdot \mathbf{F}^{-1}
-\] +\]" src="form_2531.png"/>

    Parameters
    - +
    [in]TThe (referential) rank-2 tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\chi\left( \mathbf{T} \right)$
    +
    Returns
    $\chi\left( \mathbf{T} \right)$
    @@ -242,21 +242,21 @@

    Return the result of the push forward transformation on a rank-2 covariant symmetric tensor, i.e.

    -\[
+<picture><source srcset=\[
  \chi\left(\bullet\right)^{\flat}
    \dealcoloneq \mathbf{F}^{-T} \cdot \left(\bullet\right)^{\flat}
    \cdot \mathbf{F}^{-1}
-\] +\]" src="form_2531.png"/>

    Parameters
    - +
    [in]TThe (referential) rank-2 symmetric tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\chi\left( \mathbf{T} \right)$
    +
    Returns
    $\chi\left( \mathbf{T} \right)$
    @@ -286,21 +286,21 @@

    Return the result of the push forward transformation on a rank-4 covariant tensor, i.e. (in index notation):

    -\[
+<picture><source srcset=\[
  \left[ \chi\left(\bullet\right)^{\flat} \right]_{ijkl}
    \dealcoloneq F^{-T}_{iI} F^{-T}_{jJ}
    \left(\bullet\right)^{\flat}_{IJKL} F^{-T}_{kK} F^{-T}_{lL}
-\] +\]" src="form_2532.png"/>

    Parameters
    - +
    [in]HThe (referential) rank-4 tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\chi\left( \mathbf{H} \right)$
    +
    Returns
    $\chi\left( \mathbf{H} \right)$
    @@ -330,21 +330,21 @@

    Return the result of the push forward transformation on a rank-4 covariant symmetric tensor, i.e. (in index notation):

    -\[
+<picture><source srcset=\[
  \left[ \chi\left(\bullet\right)^{\flat} \right]_{ijkl}
    \dealcoloneq F^{-T}_{iI} F^{-T}_{jJ}
    \left(\bullet\right)^{\flat}_{IJKL} F^{-T}_{kK} F^{-T}_{lL}
-\] +\]" src="form_2532.png"/>

    Parameters
    - +
    [in]HThe (referential) rank-4 symmetric tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\chi\left( \mathbf{H} \right)$
    +
    Returns
    $\chi\left( \mathbf{H} \right)$
    @@ -374,20 +374,20 @@

    Return the result of the pull back transformation on a covariant vector, i.e.

    -\[
+<picture><source srcset=\[
  \chi^{-1}\left(\bullet\right)^{\flat}
    \dealcoloneq \mathbf{F}^{T} \cdot \left(\bullet\right)^{\flat}
-\] +\]" src="form_2533.png"/>

    Parameters
    - +
    [in]vThe (spatial) vector to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\chi^{-1}\left( \mathbf{v} \right)$
    +
    Returns
    $\chi^{-1}\left( \mathbf{v} \right)$
    @@ -417,21 +417,21 @@

    Return the result of the pull back transformation on a rank-2 covariant tensor, i.e.

    -\[
+<picture><source srcset=\[
  \chi^{-1}\left(\bullet\right)^{\flat}
    \dealcoloneq \mathbf{F}^{T} \cdot \left(\bullet\right)^{\flat} \cdot
 \mathbf{F}
-\] +\]" src="form_2534.png"/>

    Parameters
    - /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Piola.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Piola.html 2023-08-09 23:38:57.766621623 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Piola.html 2023-08-09 23:38:57.766621623 +0000 @@ -146,22 +146,22 @@
    [in]tThe (spatial) tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$

    Return the result of the push forward transformation on a contravariant vector, i.e.

    -\[
+<picture><source srcset=\[
  \textrm{det} \mathbf{F}^{-1} \; \chi\left(\bullet\right)^{\sharp}
  \dealcoloneq \frac{1}{\textrm{det} \mathbf{F}} \; \mathbf{F} \cdot
  \left(\bullet\right)^{\sharp}
-\] +\]" src="form_2537.png"/>

    Parameters
    - +
    [in]VThe (referential) vector to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\frac{1}{\textrm{det} \mathbf{F}} \; \chi\left(
-\mathbf{V} \right)$
    +
    Returns
    $\frac{1}{\textrm{det} \mathbf{F}} \; \chi\left(
+\mathbf{V} \right)$
    @@ -191,22 +191,22 @@

    Return the result of the push forward transformation on a rank-2 contravariant tensor, i.e.

    -\[
+<picture><source srcset=\[
  \textrm{det} \mathbf{F}^{-1} \; \chi\left(\bullet\right)^{\sharp}
    \dealcoloneq \frac{1}{\textrm{det} \mathbf{F}} \; \mathbf{F} \cdot
 \left(\bullet\right)^{\sharp} \cdot \mathbf{F}^{T}
-\] +\]" src="form_2539.png"/>

    Parameters
    - +
    [in]TThe (referential) rank-2 tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\frac{1}{\textrm{det} \mathbf{F}} \; \chi\left(
-\mathbf{T} \right)$
    +
    Returns
    $\frac{1}{\textrm{det} \mathbf{F}} \; \chi\left(
+\mathbf{T} \right)$
    @@ -236,22 +236,22 @@

    Return the result of the push forward transformation on a rank-2 contravariant symmetric tensor, i.e.

    -\[
+<picture><source srcset=\[
  \textrm{det} \mathbf{F}^{-1} \; \chi\left(\bullet\right)^{\sharp}
    \dealcoloneq \frac{1}{\textrm{det} \mathbf{F}} \; \mathbf{F} \cdot
 \left(\bullet\right)^{\sharp} \cdot \mathbf{F}^{T}
-\] +\]" src="form_2539.png"/>

    Parameters
    - +
    [in]TThe (referential) rank-2 symmetric tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\frac{1}{\textrm{det} \mathbf{F}} \; \chi\left(
-\mathbf{T} \right)$
    +
    Returns
    $\frac{1}{\textrm{det} \mathbf{F}} \; \chi\left(
+\mathbf{T} \right)$
    @@ -281,23 +281,23 @@

    Return the result of the push forward transformation on a rank-4 contravariant tensor, i.e. (in index notation):

    -\[
+<picture><source srcset=\[
  \textrm{det} \mathbf{F}^{-1} \; \left[
 \chi\left(\bullet\right)^{\sharp} \right]_{ijkl}
    \dealcoloneq \frac{1}{\textrm{det} \mathbf{F}} \; F_{iI} F_{jJ}
 \left(\bullet\right)^{\sharp}_{IJKL} F_{kK} F_{lL}
-\] +\]" src="form_2541.png"/>

    Parameters
    - +
    [in]HThe (referential) rank-4 tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\frac{1}{\textrm{det} \mathbf{F}} \; \chi\left(
-\mathbf{H} \right)$
    +
    Returns
    $\frac{1}{\textrm{det} \mathbf{F}} \; \chi\left(
+\mathbf{H} \right)$
    @@ -327,23 +327,23 @@

    Return the result of the push forward transformation on a rank-4 contravariant symmetric tensor, i.e. (in index notation):

    -\[
+<picture><source srcset=\[
  \textrm{det} \mathbf{F}^{-1} \; \left[
 \chi\left(\bullet\right)^{\sharp} \right]_{ijkl}
    \dealcoloneq \frac{1}{\textrm{det} \mathbf{F}} \; F_{iI} F_{jJ}
 \left(\bullet\right)^{\sharp}_{IJKL} F_{kK} F_{lL}
-\] +\]" src="form_2541.png"/>

    Parameters
    - +
    [in]HThe (referential) rank-4 symmetric tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\frac{1}{\textrm{det} \mathbf{F}} \; \chi\left(
-\mathbf{H} \right)$
    +
    Returns
    $\frac{1}{\textrm{det} \mathbf{F}} \; \chi\left(
+\mathbf{H} \right)$
    @@ -373,22 +373,22 @@

    Return the result of the pull back transformation on a contravariant vector, i.e.

    -\[
+<picture><source srcset=\[
  \textrm{det} \mathbf{F} \; \chi^{-1}\left(\bullet\right)^{\sharp}
    \dealcoloneq \textrm{det} \mathbf{F} \; \mathbf{F}^{-1} \cdot
 \left(\bullet\right)^{\sharp}
-\] +\]" src="form_2543.png"/>

    Parameters
    - +
    [in]vThe (spatial) vector to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    -
    Returns
    $\textrm{det} \mathbf{F} \; \chi^{-1}\left( \mathbf{v}
-\right)$
    +
    Returns
    $\textrm{det} \mathbf{F} \; \chi^{-1}\left( \mathbf{v}
+\right)$
    @@ -418,22 +418,22 @@

    Return the result of the pull back transformation on a rank-2 contravariant tensor, i.e.

    -\[
+<picture><source srcset=\[
  \textrm{det} \mathbf{F} \; \chi^{-1}\left(\bullet\right)^{\sharp}
    \dealcoloneq \textrm{det} \mathbf{F} \; \mathbf{F}^{-1} \cdot
 \left(\bullet\right)^{\sharp} \cdot \mathbf{F}^{-T}
-\] +\]" src="form_2545.png"/>

    Parameters
    - +
    [in]tThe (spatial) tensor to be operated on
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
-\mathbf{X} \right)$
    [in]FThe deformation gradient tensor $\mathbf{F} \left(
+\mathbf{X} \right)$
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Rotations.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Rotations.html 2023-08-09 23:38:57.786621773 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1Transformations_1_1Rotations.html 2023-08-09 23:38:57.786621773 +0000 @@ -123,14 +123,14 @@

    Return the rotation matrix for 2-d Euclidean space, namely

    -\[
+<picture><source srcset=\[
  \mathbf{R} \dealcoloneq \left[ \begin{array}{cc}
  cos(\theta) & -sin(\theta) \\
  sin(\theta) & cos(\theta)
 \end{array}\right]
-\] +\]" src="form_2512.png"/>

    -

    where $\theta$ is the rotation angle given in radians. In particular, this describes the counter-clockwise rotation of a vector relative to a fixed set of right-handed axes.

    +

    where $\theta$ is the rotation angle given in radians. In particular, this describes the counter-clockwise rotation of a vector relative to a fixed set of right-handed axes.

    Parameters
    @@ -167,12 +167,12 @@
    [in]angleThe rotation angle (about the z-axis) in radians

    Return the rotation matrix for 3-d Euclidean space. Most concisely stated using the Rodrigues' rotation formula, this function returns the equivalent of

    -\[
+<picture><source srcset=\[
  \mathbf{R} \dealcoloneq cos(\theta)\mathbf{I} + sin(\theta)\mathbf{W}
              + (1-cos(\theta))\mathbf{u}\otimes\mathbf{u}
-\] +\]" src="form_2514.png"/>

    -

    where $\mathbf{u}$ is the axial vector (an axial vector) and $\theta$ is the rotation angle given in radians, $\mathbf{I}$ is the identity tensor and $\mathbf{W}$ is the skew symmetric tensor of $\mathbf{u}$.

    +

    where $\mathbf{u}$ is the axial vector (an axial vector) and $\theta$ is the rotation angle given in radians, $\mathbf{I}$ is the identity tensor and $\mathbf{W}$ is the skew symmetric tensor of $\mathbf{u}$.

    Note
    For a discussion of the background of this function, see P. Wriggers: "Nonlinear finite element methods" (2008), and in particular formula (9.194) on p. 374 (or thereabouts). This presents Rodrigues' rotation formula, but the implementation used in this function is described in this wikipedia link. In particular, this describes the counter-clockwise rotation of a vector in a plane with its normal. defined by the axis of rotation. An alternative implementation is discussed at this link, but is inconsistent (sign-wise) with the Rodrigues' rotation formula as it describes the rotation of a coordinate system.
    Parameters
    @@ -213,12 +213,12 @@

    Return the rotation matrix for 3-d Euclidean space. Most concisely stated using the Rodrigues' rotation formula, this function returns the equivalent of

    -\[
+<picture><source srcset=\[
  \mathbf{R} \dealcoloneq cos(\theta)\mathbf{I} + sin(\theta)\mathbf{W}
              + (1-cos(\theta))\mathbf{u}\otimes\mathbf{u}
-\] +\]" src="form_2514.png"/>

    -

    where $\mathbf{u}$ is the axial vector (an axial vector) and $\theta$ is the rotation angle given in radians, $\mathbf{I}$ is the identity tensor and $\mathbf{W}$ is the skew symmetric tensor of $\mathbf{u}$.

    +

    where $\mathbf{u}$ is the axial vector (an axial vector) and $\theta$ is the rotation angle given in radians, $\mathbf{I}$ is the identity tensor and $\mathbf{W}$ is the skew symmetric tensor of $\mathbf{u}$.

    Note
    For a discussion of the background of this function, see P. Wriggers: "Nonlinear finite element methods" (2008), and in particular formula (9.194) on p. 374 (or thereabouts). This presents Rodrigues' rotation formula, but the implementation used in this function is described in this wikipedia link. In particular, this describes the counter-clockwise rotation of a vector in a plane with its normal. defined by the axis of rotation. An alternative implementation is discussed at this link, but is inconsistent (sign-wise) with the Rodrigues' rotation formula as it describes the rotation of a coordinate system.
    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1VectorRelations.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1VectorRelations.html 2023-08-09 23:38:57.802621892 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacePhysics_1_1VectorRelations.html 2023-08-09 23:38:57.806621922 +0000 @@ -129,11 +129,11 @@
    -

    Calculate the angle $\theta$ between two vectors a and b. The returned angle will be in the range $[0, \pi]$.

    +

    Calculate the angle $\theta$ between two vectors a and b. The returned angle will be in the range $[0, \pi]$.

    This function uses the geometric definition of the scalar product.

    -\[
+<picture><source srcset=\[
   \vec{a} \cdot \vec{b} = \|\vec{a}\| \|\vec{b}\| \cos(\theta)
-\] +\]" src="form_2550.png"/>

    @@ -168,21 +168,21 @@
    -

    Calculate the angle $\theta$ between two vectors a and b, where both vectors are located in a plane described by a normal vector axis.

    -

    The angle computed by this function corresponds to the rotation angle that would transform the vector a into the vector b around the vector axis. Thus, contrary to the function above, we get a signed angle which will be in the range $[-\pi, \pi]$.

    +

    Calculate the angle $\theta$ between two vectors a and b, where both vectors are located in a plane described by a normal vector axis.

    +

    The angle computed by this function corresponds to the rotation angle that would transform the vector a into the vector b around the vector axis. Thus, contrary to the function above, we get a signed angle which will be in the range $[-\pi, \pi]$.

    The vector axis needs to be a unit vector and be perpendicular to both vectors a and b.

    This function uses the geometric definitions of both the scalar and cross product.

    -\begin{align*}
+<picture><source srcset=\begin{align*}
   \vec{a} \cdot  \vec{b} &= \|\vec{a}\| \|\vec{b}\| \cos(\theta) \\
   \vec{a} \times \vec{b} &= \|\vec{a}\| \|\vec{b}\| \sin(\theta) \vec{n}
-\end{align*} +\end{align*}" src="form_2552.png"/>

    We can create the tangent of the angle using both products.

    -\[
+<picture><source srcset=\[
   \tan{\theta}
   = \frac{\sin(\theta)}{\cos(theta)}
   = \frac{(\vec{a} \times \vec{b}) \cdot \vec{n}}{\vec{a} \cdot \vec{b}}
-\] +\]" src="form_2553.png"/>

    Note
    Only applicable for three-dimensional vectors spacedim == 3.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSLEPcWrappers.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSLEPcWrappers.html 2023-08-09 23:38:57.822622042 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSLEPcWrappers.html 2023-08-09 23:38:57.826622072 +0000 @@ -108,13 +108,13 @@ &#href_anchor"memitem:">class  TransformationSpectrumFolding &#href_anchor"details" id="details">

    Detailed Description

    Base namespace for solver classes using the SLEPc solvers which are selected based on flags passed to the eigenvalue problem solver context. Derived classes set the right flags to set the right solver.

    -

    The SLEPc solvers are intended to be used for solving the generalized eigenspectrum problem $(A-\lambda B)x=0$, for $x\neq0$; where $A$ is a system matrix, $B$ is a mass matrix, and $\lambda, x$ are a set of eigenvalues and eigenvectors respectively. The emphasis is on methods and techniques appropriate for problems in which the associated matrices are sparse. Most of the methods offered by the SLEPc library are projection methods or other methods with similar properties; and wrappers are provided to interface to SLEPc solvers that handle both of these problem sets.

    +

    The SLEPc solvers are intended to be used for solving the generalized eigenspectrum problem $(A-\lambda B)x=0$, for $x\neq0$; where $A$ is a system matrix, $B$ is a mass matrix, and $\lambda, x$ are a set of eigenvalues and eigenvectors respectively. The emphasis is on methods and techniques appropriate for problems in which the associated matrices are sparse. Most of the methods offered by the SLEPc library are projection methods or other methods with similar properties; and wrappers are provided to interface to SLEPc solvers that handle both of these problem sets.

    SLEPcWrappers can be implemented in application codes in the following way:

    SolverControl solver_control (1000, 1e-9);
    SolverArnoldi system (solver_control, mpi_communicator);
    system.solve (A, B, lambda, x, size_of_spectrum);
    -

    for the generalized eigenvalue problem $Ax=B\lambda x$, where the variable const unsigned int size_of_spectrum tells SLEPc the number of eigenvector/eigenvalue pairs to solve for. Additional options and solver parameters can be passed to the SLEPc solvers before calling solve(). For example, if the matrices of the general eigenspectrum problem are not hermitian and the lower eigenvalues are wanted only, the following code can be implemented before calling solve():

    system.set_problem_type (EPS_NHEP);
    +

    for the generalized eigenvalue problem $Ax=B\lambda x$, where the variable const unsigned int size_of_spectrum tells SLEPc the number of eigenvector/eigenvalue pairs to solve for. Additional options and solver parameters can be passed to the SLEPc solvers before calling solve(). For example, if the matrices of the general eigenspectrum problem are not hermitian and the lower eigenvalues are wanted only, the following code can be implemented before calling solve():

    system.set_problem_type (EPS_NHEP);
    system.set_which_eigenpairs (EPS_SMALLEST_REAL);

    These options can also be set at the command line.

    See also step-36 for a hands-on example.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSUNDIALS.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSUNDIALS.html 2023-08-09 23:38:57.842622191 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSUNDIALS.html 2023-08-09 23:38:57.842622191 +0000 @@ -133,7 +133,7 @@

    Type of function objects to interface with SUNDIALS' linear solvers

    -

    This function type encapsulates the action of solving $P^{-1}Ax=P^{-1}b$. The LinearOperator op encapsulates the matrix vector product $Ax$ and the LinearOperator prec encapsulates the application of the preconditioner $P^{-1}z$. The user can specify function objects of this type to attach custom linear solver routines to SUNDIALS. The two LinearOperators op and prec are built internally by SUNDIALS based on user settings. The parameters are interpreted as follows:

    +

    This function type encapsulates the action of solving $P^{-1}Ax=P^{-1}b$. The LinearOperator op encapsulates the matrix vector product $Ax$ and the LinearOperator prec encapsulates the application of the preconditioner $P^{-1}z$. The user can specify function objects of this type to attach custom linear solver routines to SUNDIALS. The two LinearOperators op and prec are built internally by SUNDIALS based on user settings. The parameters are interpreted as follows:

    Parameters
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSmoothnessEstimator_1_1Fourier.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSmoothnessEstimator_1_1Fourier.html 2023-08-09 23:38:57.866622370 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSmoothnessEstimator_1_1Fourier.html 2023-08-09 23:38:57.866622370 +0000 @@ -107,19 +107,19 @@
    [in]opA LinearOperator that applies the matrix vector product

    Detailed Description

    Smoothness estimation strategy based on the decay of Fourier expansion coefficients.

    -

    From the definition, we can write our Fourier series expansion $a_{\bf k}$ of the finite element solution on cell $K$ with polynomial degree $p$ as a matrix product

    -\begin{eqnarray*}
+<p>From the definition, we can write our <a class=Fourier series expansion $a_{\bf k}$ of the finite element solution on cell $K$ with polynomial degree $p$ as a matrix product

    +\begin{eqnarray*}
    u_h({\bf x}) &=& \sum_j u_j \varphi_j ({\bf x}) \\
    u_{h, {\bf k}}({\bf x}) &=&
      \sum_{{\bf k}, \|{\bf k}\|\le p} a_{\bf k} \phi_{\bf k}({\bf x}),
      \quad a_{\bf k} = \sum_j {\cal F}_{{\bf k},j} u_j
-\end{eqnarray*} +\end{eqnarray*}" src="form_2228.png"/>

    -

    with $u_j$ the degrees of freedom and $\varphi_j$ the corresponding shape functions. $\{\phi_{\bf k}({\bf x}) = \exp(i \, 2 \pi \, {\bf k} \cdot
-{\bf x}) \}$ are exponential functions on cell $K$. $a_{\bf k}$ and ${\cal
-F}_{{\bf k},j}$ are coefficients and transformation matrices from the Fourier expansion of each shape function. For practical reasons, we will perform the calculation of these matrices and coefficients only on the reference cell $\hat K$. We only have to calculate the transformation matrices once this way. However, results are only applicable if mapping from the reference cell to the actual cell is linear. We use the class FESeries::Fourier to determine all coefficients $a_{\bf k}$.

    -

    If the finite element approximation on cell $K$ is part of the Hilbert space $H^s(K)$, then the following integral must exist for both the finite element and spectral representation of our solution

    -\begin{eqnarray*}
+<p> with <picture><source srcset=$u_j$ the degrees of freedom and $\varphi_j$ the corresponding shape functions. $\{\phi_{\bf k}({\bf x}) = \exp(i \, 2 \pi \, {\bf k} \cdot
+{\bf x}) \}$ are exponential functions on cell $K$. $a_{\bf k}$ and ${\cal
+F}_{{\bf k},j}$ are coefficients and transformation matrices from the Fourier expansion of each shape function. For practical reasons, we will perform the calculation of these matrices and coefficients only on the reference cell $\hat K$. We only have to calculate the transformation matrices once this way. However, results are only applicable if mapping from the reference cell to the actual cell is linear. We use the class FESeries::Fourier to determine all coefficients $a_{\bf k}$.

    +

    If the finite element approximation on cell $K$ is part of the Hilbert space $H^s(K)$, then the following integral must exist for both the finite element and spectral representation of our solution

    +\begin{eqnarray*}
   \| \nabla^s u_h({\bf x}) \|_{L^2(K)}^2 &=&
     \int\limits_K \left| \nabla^s u_h({\bf x}) \right|^2 d{\bf x} <
     \infty \\
@@ -128,40 +128,40 @@
     a_{\bf k} \, \phi_{\bf k}({\bf x}) \right|^2 d{\bf x} =
     (2 \pi)^{2s} \sum\limits_{\bf k} \left| a_{\bf k} \right|^2
     \|{\bf k}\|_2^{2s} < \infty
-\end{eqnarray*} +\end{eqnarray*}" src="form_2232.png"/>

    The sum is finite only if the summands decay at least with order

    -\[
+<picture><source srcset=\[
   |a_{\bf k}|^2 \|{\bf k}\|_2^{2s} \|{\bf k}\|_2^{d - 1} =
     {\cal O}\left( \|{\bf k}\|_2^{-1-\epsilon} \right)
-\] +\]" src="form_2233.png"/>

    -

    for all $\epsilon > 0$. The additional factor stems from the fact that, since we sum over all multi-indices ${\bf k}$ that are located on a dim-dimensional sphere, we actually have, up to a constant, $\|{\bf k}\|_2^{d-1}$ modes located in each increment $\|{\bf k}\|_2 +
-d\|{\bf k}\|_2$ that need to be taken into account. By a comparison of exponents, we can rewrite this condition as

    -\[
+<p> for all <picture><source srcset=$\epsilon > 0$. The additional factor stems from the fact that, since we sum over all multi-indices ${\bf k}$ that are located on a dim-dimensional sphere, we actually have, up to a constant, $\|{\bf k}\|_2^{d-1}$ modes located in each increment $\|{\bf k}\|_2 +
+d\|{\bf k}\|_2$ that need to be taken into account. By a comparison of exponents, we can rewrite this condition as

    +\[
   |a_{\bf k}| = {\cal O}\left(\|{\bf k}\|_2^
     {-\left(s + \frac d2 + \epsilon \right)} \right)
-\] +\]" src="form_2238.png"/>

    -

    The next step is to estimate how fast these coefficients decay with $\|{\bf k}\|_2$. Thus, we perform a least-squares fit

    -\[
+<p>The next step is to estimate how fast these coefficients decay with <picture><source srcset=$\|{\bf k}\|_2$. Thus, we perform a least-squares fit

    +\[
    \min_{\alpha,\sigma}
    \frac 12 \sum_{{\bf k}, \|{\bf k}\|_2 \le p}
    \left( |a_{\bf k}| - \alpha \|{\bf k}\|_2^{-\sigma}\right)^2
-\] +\]" src="form_2240.png"/>

    -

    with regression coefficients $\alpha$ and $\sigma$. For simplification, we apply a logarithm on our minimization problem

    -\[
+<p> with regression coefficients <picture><source srcset=$\alpha$ and $\sigma$. For simplification, we apply a logarithm on our minimization problem

    +\[
    \min_{\beta,\sigma}
    Q(\beta,\sigma) =
    \frac 12 \sum_{{\bf k}, \|{\bf k}\|_2 \le p}
    \left( \ln |a_{\bf k}| - \beta + \sigma \ln \|{\bf k}\|_2
 \right)^2,
-\] +\]" src="form_2241.png"/>

    -

    where $\beta=\ln \alpha$. This is now a problem for which the optimality conditions $\frac{\partial Q}{\partial\beta}=0,
-\frac{\partial Q}{\partial\sigma}=0$, are linear in $\beta,\sigma$. We can write these conditions as follows:

    -\[
+<p> where <picture><source srcset=$\beta=\ln \alpha$. This is now a problem for which the optimality conditions $\frac{\partial Q}{\partial\beta}=0,
+\frac{\partial Q}{\partial\sigma}=0$, are linear in $\beta,\sigma$. We can write these conditions as follows:

    +\[
    \left(\begin{array}{cc}
    \sum_{{\bf k}, \|{\bf k}\|_2 \le p} 1 &
    \sum_{{\bf k}, \|{\bf k}\|_2 \le p} \ln \|{\bf k}\|_2
@@ -178,10 +178,10 @@
    \\
    \sum_{{\bf k}, \|{\bf k}\|_2\le p} \ln |a_{{\bf k}}| \ln \|{\bf
 k}\|_2 \end{array}\right)
-\] +\]" src="form_2245.png"/>

    -

    Solving for $\beta$ and $\sigma$ is just a linear regression fit and to do that we will use FESeries::linear_regression().

    -

    While we are not particularly interested in the actual value of $\beta$, the formula above gives us a means to calculate the value of the exponent $\sigma$ that we can then use to determine that $u(\hat{\bf x})$ is in $H^s(K)$ with $s=\sigma-\frac d2$. The decay rates $\sigma$ will suffice as our smoothness indicators and will be calculated on each cell for any provided solution.

    +

    Solving for $\beta$ and $\sigma$ is just a linear regression fit and to do that we will use FESeries::linear_regression().

    +

    While we are not particularly interested in the actual value of $\beta$, the formula above gives us a means to calculate the value of the exponent $\sigma$ that we can then use to determine that $u(\hat{\bf x})$ is in $H^s(K)$ with $s=\sigma-\frac d2$. The decay rates $\sigma$ will suffice as our smoothness indicators and will be calculated on each cell for any provided solution.

    Note
    An extensive demonstration of the use of these functions is provided in step-27.

    Function Documentation

    @@ -237,17 +237,17 @@
    -

    In this variant of the estimation strategy for higher dimensions, we will consider all mode vectors $\bf k$ describing Fourier polynomials $P_{\bf k}$ and perform one least-squares fit over all coefficients at once. If there are multiple coefficients corresponding to the same absolute value of modes $\|\bf k\|_2$, we take the maximum among those. Thus, the least-squares fit is performed on

    -\[
+<p>In this variant of the estimation strategy for higher dimensions, we will consider all mode vectors <picture><source srcset=$\bf k$ describing Fourier polynomials $P_{\bf k}$ and perform one least-squares fit over all coefficients at once. If there are multiple coefficients corresponding to the same absolute value of modes $\|\bf k\|_2$, we take the maximum among those. Thus, the least-squares fit is performed on

    +\[
   \ln \left( \max\limits_{\|{\bf k}\|_2} |a_{\bf k}| \right) \sim
     C - \sigma \ln \|{\bf k}\|_2
-\] +\]" src="form_2259.png"/>

    -

    for ${\bf k}=(k_1,\ldots,k_d)$ and $k_i=0,\ldots,p$, with $p$ the polynomial degree of the finite element. We exclude the $\|{\bf k}\|_2=0$ modes to avoid the singularity of the logarithm.

    -

    The regression_strategy parameter determines which norm will be used on the subset of coefficients $\bf k$ with the same absolute value $\|{\bf k}\|_2$. Default is VectorTools::Linfty_norm for a maximum approximation.

    -

    For a provided solution vector solution defined on a DoFHandler dof_handler, this function returns a vector smoothness_indicators with as many elements as there are cells where each element contains the estimated regularity $\sigma$.

    +

    for ${\bf k}=(k_1,\ldots,k_d)$ and $k_i=0,\ldots,p$, with $p$ the polynomial degree of the finite element. We exclude the $\|{\bf k}\|_2=0$ modes to avoid the singularity of the logarithm.

    +

    The regression_strategy parameter determines which norm will be used on the subset of coefficients $\bf k$ with the same absolute value $\|{\bf k}\|_2$. Default is VectorTools::Linfty_norm for a maximum approximation.

    +

    For a provided solution vector solution defined on a DoFHandler dof_handler, this function returns a vector smoothness_indicators with as many elements as there are cells where each element contains the estimated regularity $\sigma$.

    A series expansion object fe_fourier has to be supplied, which needs to be constructed with the same FECollection object as the dof_handler.

    -

    The parameter smallest_abs_coefficient allows to ignore small (in absolute value) coefficients within the linear regression fit. In case there are less than two nonzero coefficients for a coordinate direction, this direction will be skipped. If all coefficients are zero, the returned value for this cell will be $\sigma=\infty$.

    +

    The parameter smallest_abs_coefficient allows to ignore small (in absolute value) coefficients within the linear regression fit. In case there are less than two nonzero coefficients for a coordinate direction, this direction will be skipped. If all coefficients are zero, the returned value for this cell will be $\sigma=\infty$.

    Smoothness indicators are usually used to decide whether to perform h- or p-adaptation. So in most cases, we only need to calculate those indicators on cells flagged for refinement or coarsening. The parameter only_flagged_cells controls whether this particular subset or all cells will be considered. By default, all cells will be considered. When only flagged cells are supposed to be considered, smoothness indicators will only be set on those vector entries of flagged cells; the others will be set to a signaling NaN.

    Definition at line 370 of file smoothness_estimator.cc.

    @@ -305,11 +305,11 @@
    -

    In this variant of the estimation strategy for higher dimensions, we only consider modes in each coordinate direction, i.e., only mode vectors $\bf k$ with one nonzero entry. We perform the least-squares fit in each coordinate direction separately and take the lowest decay rate $\sigma$ among them.

    -

    The coefficients_predicate parameter selects Fourier coefficients $a_j$, $j=0,\ldots,p$ for linear regression in each coordinate direction. The user is responsible for updating the vector of flags provided to this function. Note that its size is $p+1$, where $p$ is the polynomial degree of the FE basis on a given element. The default implementation will use all Fourier coefficients in each coordinate direction, i.e., set all the elements of the vector to true.

    -

    For a provided solution vector solution defined on a DoFHandler dof_handler, this function returns a vector smoothness_indicators with as many elements as there are cells where each element contains the estimated regularity $\sigma$.

    +

    In this variant of the estimation strategy for higher dimensions, we only consider modes in each coordinate direction, i.e., only mode vectors $\bf k$ with one nonzero entry. We perform the least-squares fit in each coordinate direction separately and take the lowest decay rate $\sigma$ among them.

    +

    The coefficients_predicate parameter selects Fourier coefficients $a_j$, $j=0,\ldots,p$ for linear regression in each coordinate direction. The user is responsible for updating the vector of flags provided to this function. Note that its size is $p+1$, where $p$ is the polynomial degree of the FE basis on a given element. The default implementation will use all Fourier coefficients in each coordinate direction, i.e., set all the elements of the vector to true.

    +

    For a provided solution vector solution defined on a DoFHandler dof_handler, this function returns a vector smoothness_indicators with as many elements as there are cells where each element contains the estimated regularity $\sigma$.

    A series expansion object fe_fourier has to be supplied, which needs to be constructed with the same FECollection object as the dof_handler.

    -

    The parameter smallest_abs_coefficient allows to ignore small (in absolute value) coefficients within the linear regression fit. In case there are fewer than two nonzero coefficients for a coordinate direction, this direction will be skipped. If all coefficients are zero, the returned value for this cell will be $\sigma=\infty$.

    +

    The parameter smallest_abs_coefficient allows to ignore small (in absolute value) coefficients within the linear regression fit. In case there are fewer than two nonzero coefficients for a coordinate direction, this direction will be skipped. If all coefficients are zero, the returned value for this cell will be $\sigma=\infty$.

    Smoothness indicators are usually used to decide whether to perform h- or p-adaptation. So in most cases, we only need to calculate those indicators on cells flagged for refinement or coarsening. The parameter only_flagged_cells controls whether this particular subset or all cells will be considered. By default, all cells will be considered. When only flagged cells are supposed to be considered, smoothness indicators will only be set on those vector entries of flagged cells; the others will be set to a signaling NaN.

    Definition at line 468 of file smoothness_estimator.cc.

    @@ -342,7 +342,7 @@

    Returns a FESeries::Fourier object for Fourier series expansions with the default configuration for smoothness estimation purposes.

    -

    For each finite element of the provided fe_collection, we use as many modes as its polynomial degree plus two. Further for each element, we use a 5-point Gaussian quarature iterated in each dimension by the maximal wave number, which is the number of modes decreased by one since we start with $k = 0$.

    +

    For each finite element of the provided fe_collection, we use as many modes as its polynomial degree plus two. Further for each element, we use a 5-point Gaussian quarature iterated in each dimension by the maximal wave number, which is the number of modes decreased by one since we start with $k = 0$.

    As the Fourier expansion can only be performed on scalar fields, this class does not operate on vector-valued finite elements and will therefore throw an assertion. However, each component of a finite element field can be treated as a scalar field, respectively, on which Fourier expansions are again possible. For this purpose, the optional parameter component defines which component of each FiniteElement will be used. The default value of component only applies to scalar FEs, in which case it indicates that the sole component is to be decomposed. For vector-valued FEs, a non-default value must be explicitly provided.

    Definition at line 577 of file smoothness_estimator.cc.

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSmoothnessEstimator_1_1Legendre.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSmoothnessEstimator_1_1Legendre.html 2023-08-09 23:38:57.890622550 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSmoothnessEstimator_1_1Legendre.html 2023-08-09 23:38:57.890622550 +0000 @@ -107,25 +107,25 @@

    Detailed Description

    Smoothness estimation strategy based on the decay of Legendre expansion coefficients.

    -

    In one dimension, the finite element solution on cell $K$ with polynomial degree $p$ can be written as

    -\begin{eqnarray*}
+<p>In one dimension, the finite element solution on cell <picture><source srcset=$K$ with polynomial degree $p$ can be written as

    +\begin{eqnarray*}
    u_h(x) &=& \sum_j u_j \varphi_j (x) \\
    u_{h, k}(x) &=& \sum_{k=0}^{p} a_k \widetilde P_k (x),
    \quad a_k = \sum_j {\cal L}_{k,j} u_j
-\end{eqnarray*} +\end{eqnarray*}" src="form_2217.png"/>

    -

    where $u_j$ are degrees of freedom and $\varphi_j$ are the corresponding shape functions. $\{\widetilde P_k(x)\}$ are Legendre polynomials on cell $K$. $a_k$ and ${\cal L}_{k,j}$ are coefficients and transformation matrices from the Legendre expansion of each shape function. For practical reasons, we will perform the calculation of these matrices and coefficients only on the reference cell $\hat K$. We only have to calculate the transformation matrices once this way. However, results are only applicable if the mapping from the reference cell to the actual cell is affine. We use the class FESeries::Legendre to determine all coefficients $a_k$.

    +

    where $u_j$ are degrees of freedom and $\varphi_j$ are the corresponding shape functions. $\{\widetilde P_k(x)\}$ are Legendre polynomials on cell $K$. $a_k$ and ${\cal L}_{k,j}$ are coefficients and transformation matrices from the Legendre expansion of each shape function. For practical reasons, we will perform the calculation of these matrices and coefficients only on the reference cell $\hat K$. We only have to calculate the transformation matrices once this way. However, results are only applicable if the mapping from the reference cell to the actual cell is affine. We use the class FESeries::Legendre to determine all coefficients $a_k$.

    A function is analytic, i.e., representable by a power series, if and only if their Legendre expansion coefficients decay as (see [eibner2007hp])

    -\[
+<picture><source srcset=\[
   |a_k| \sim c \, \exp(-\sigma k)
-\] +\]" src="form_2222.png"/>

    -

    We determine their decay rate $\sigma$ by performing the linear regression fit of

    -\[
+<p> We determine their decay rate <picture><source srcset=$\sigma$ by performing the linear regression fit of

    +\[
   \ln |a_k| \sim C - \sigma k
-\] +\]" src="form_2224.png"/>

    -

    for $k=0,\ldots,p$, with $p$ the polynomial degree of the finite element. The rate of the decay $\sigma$ can be used to estimate the smoothness. For example, one strategy to implement hp-refinement criteria is to perform p-refinement if $\sigma>1$ (see [mavriplis1994hp]).

    +

    for $k=0,\ldots,p$, with $p$ the polynomial degree of the finite element. The rate of the decay $\sigma$ can be used to estimate the smoothness. For example, one strategy to implement hp-refinement criteria is to perform p-refinement if $\sigma>1$ (see [mavriplis1994hp]).

    Function Documentation

    ◆ coefficient_decay()

    @@ -180,24 +180,24 @@
    -

    In this variant of the estimation strategy for higher dimensions, we will consider all mode vectors $\bf k$ describing Legendre polynomials $\widetilde P_{\bf k}$ and perform one least-squares fit over all coefficients at once. If there are multiple coefficients corresponding to the same absolute value of modes $\|{\bf k}\|_1$, we take the maximum among those. Thus, the least-squares fit is performed on

    -\begin{eqnarray*}
+<p>In this variant of the estimation strategy for higher dimensions, we will consider all mode vectors <picture><source srcset=$\bf k$ describing Legendre polynomials $\widetilde P_{\bf k}$ and perform one least-squares fit over all coefficients at once. If there are multiple coefficients corresponding to the same absolute value of modes $\|{\bf k}\|_1$, we take the maximum among those. Thus, the least-squares fit is performed on

    +\begin{eqnarray*}
   \widetilde P_{\bf k}({\bf x}) &=&
     \widetilde P_{k_1} (x_1) \ldots \widetilde P_{k_d} (x_d) \\
   \ln \left( \max\limits_{\|{\bf k}\|_1} |a_{\bf k}| \right) &\sim&
     C - \sigma \|{\bf k}\|_1
-\end{eqnarray*} +\end{eqnarray*}" src="form_2251.png"/>

    -

    for ${\bf k}=(k_1,\ldots,k_d)$ and $k_i=0,\ldots,p$, with $p$ the polynomial degree of the finite element.

    +

    for ${\bf k}=(k_1,\ldots,k_d)$ and $k_i=0,\ldots,p$, with $p$ the polynomial degree of the finite element.

    For a finite element approximation solution, this function writes the decay rate for every cell into the output vector smoothness_indicators.

    Parameters
    - + - - + +
    [in]fe_legendreFESeries::Legendre object to calculate coefficients. This object needs to be initialized to have at least $p+1$ coefficients in each direction for every finite element in the collection, where $p$ is its polynomial degree.
    [in]fe_legendreFESeries::Legendre object to calculate coefficients. This object needs to be initialized to have at least $p+1$ coefficients in each direction for every finite element in the collection, where $p$ is its polynomial degree.
    [in]dof_handlerA DoFHandler.
    [in]solutionA solution vector.
    [out]smoothness_indicatorsA vector for smoothness indicators.
    [in]regression_strategyDetermines which norm will be used on the subset of coefficients $\mathbf{k}$ with the same absolute value $\|{\bf k}\|_1$. Default is VectorTools::Linfty_norm for a maximum approximation.
    [in]smallest_abs_coefficientThe smallest absolute value of the coefficient to be used in linear regression. Note that Legendre coefficients of some functions may have a repeating pattern of zero coefficients (i.e. for functions that are locally symmetric or antisymmetric about the midpoint of the element in any coordinate direction). Thus this parameters allows to ignore small (in absolute value) coefficients within the linear regression fit. In case there are less than two nonzero coefficients, the returned value for this cell will be $\sigma=\infty$.
    [in]regression_strategyDetermines which norm will be used on the subset of coefficients $\mathbf{k}$ with the same absolute value $\|{\bf k}\|_1$. Default is VectorTools::Linfty_norm for a maximum approximation.
    [in]smallest_abs_coefficientThe smallest absolute value of the coefficient to be used in linear regression. Note that Legendre coefficients of some functions may have a repeating pattern of zero coefficients (i.e. for functions that are locally symmetric or antisymmetric about the midpoint of the element in any coordinate direction). Thus this parameters allows to ignore small (in absolute value) coefficients within the linear regression fit. In case there are less than two nonzero coefficients, the returned value for this cell will be $\sigma=\infty$.
    [in]only_flagged_cellsSmoothness indicators are usually used to decide whether to perform h- or p-adaptation. So in most cases, we only need to calculate those indicators on cells flagged for refinement or coarsening. This parameter controls whether this particular subset or all cells will be considered. By default, all cells will be considered. When only flagged cells are supposed to be considered, smoothness indicators will only be set on those vector entries of flagged cells; the others will be set to a signaling NaN.
    @@ -259,16 +259,16 @@
    -

    In this variant of the estimation strategy for higher dimensions, we only consider modes in each coordinate direction, i.e., only mode vectors $\bf k$ with one nonzero entry. We perform the least-squares fit in each coordinate direction separately and take the lowest decay rate $\sigma$ among them.

    +

    In this variant of the estimation strategy for higher dimensions, we only consider modes in each coordinate direction, i.e., only mode vectors $\bf k$ with one nonzero entry. We perform the least-squares fit in each coordinate direction separately and take the lowest decay rate $\sigma$ among them.

    For a finite element approximation solution, this function writes the decay rate for every cell into the output vector smoothness_indicators.

    Parameters
    - + - - + +
    [in]fe_legendreFESeries::Legendre object to calculate coefficients. This object needs to be initialized to have at least $p+1$ coefficients in each direction, where $p$ is the maximum polynomial degree to be used.
    [in]fe_legendreFESeries::Legendre object to calculate coefficients. This object needs to be initialized to have at least $p+1$ coefficients in each direction, where $p$ is the maximum polynomial degree to be used.
    [in]dof_handlerA DoFHandler
    [in]solutionA solution vector
    [out]smoothness_indicatorsA vector for smoothness indicators
    [in]coefficients_predicateA predicate to select Legendre coefficients $a_j$, $j=0,\ldots,p$ for linear regression in each coordinate direction. The user is responsible for updating the vector of flags provided to this function. Note that its size is $p+1$, where $p$ is the polynomial degree of the FE basis on a given element. The default implementation will use all Legendre coefficients in each coordinate direction, i.e. set all elements of the vector to true.
    [in]smallest_abs_coefficientThe smallest absolute value of the coefficient to be used in linear regression in each coordinate direction. Note that Legendre coefficients of some functions may have a repeating pattern of zero coefficients (i.e. for functions that are locally symmetric or antisymmetric about the midpoint of the element in any coordinate direction). Thus this parameters allows to ignore small (in absolute value) coefficients within the linear regression fit. In case there are less than two nonzero coefficients for a coordinate direction, this direction will be skipped. If all coefficients are zero, the returned value for this cell will be $\sigma=\infty$.
    [in]coefficients_predicateA predicate to select Legendre coefficients $a_j$, $j=0,\ldots,p$ for linear regression in each coordinate direction. The user is responsible for updating the vector of flags provided to this function. Note that its size is $p+1$, where $p$ is the polynomial degree of the FE basis on a given element. The default implementation will use all Legendre coefficients in each coordinate direction, i.e. set all elements of the vector to true.
    [in]smallest_abs_coefficientThe smallest absolute value of the coefficient to be used in linear regression in each coordinate direction. Note that Legendre coefficients of some functions may have a repeating pattern of zero coefficients (i.e. for functions that are locally symmetric or antisymmetric about the midpoint of the element in any coordinate direction). Thus this parameters allows to ignore small (in absolute value) coefficients within the linear regression fit. In case there are less than two nonzero coefficients for a coordinate direction, this direction will be skipped. If all coefficients are zero, the returned value for this cell will be $\sigma=\infty$.
    [in]only_flagged_cellsSmoothness indicators are usually used to decide whether to perform h- or p-adaptation. So in most cases, we only need to calculate those indicators on cells flagged for refinement or coarsening. This parameter controls whether this particular subset or all cells will be considered. By default, all cells will be considered. When only flagged cells are supposed to be considered, smoothness indicators will only be set on those vector entries of flagged cells; the others will be set to NaN.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSparseMatrixTools.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSparseMatrixTools.html 2023-08-09 23:38:57.906622669 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceSparseMatrixTools.html 2023-08-09 23:38:57.910622699 +0000 @@ -149,18 +149,18 @@

    Given a sparse matrix (system_matrix, sparsity_pattern), construct a new sparse matrix (system_matrix_out, sparsity_pattern_out) by restriction

    -\[
+<picture><source srcset=\[
  A_i = R_i A R_i^T,
-\] +\]" src="form_1926.png"/>

    -

    where the Boolean matrix $R_i$ is defined by the entries of requested_is.

    -

    The function can be called by multiple processes with different sets of indices, allowing to assign each process a different $A_i$.

    +

    where the Boolean matrix $R_i$ is defined by the entries of requested_is.

    +

    The function can be called by multiple processes with different sets of indices, allowing to assign each process a different $A_i$.

    Such a function is useful to implement Schwarz methods, where operations of type

    -\[
+<picture><source srcset=\[
  u^{n} = u^{n-1} + \sum_{i} R_i^T A_i^{-1} R_i (f - A u^{n-1})
-\] +\]" src="form_1928.png"/>

    -

    are performed to iteratively solve a system of type $Au=f$.

    +

    are performed to iteratively solve a system of type $Au=f$.

    Warning
    This is a collective call that needs to be executed by all processes in the communicator of sparse_matrix_in.
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceTensorAccessors.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceTensorAccessors.html 2023-08-09 23:38:57.930622848 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceTensorAccessors.html 2023-08-09 23:38:57.930622848 +0000 @@ -175,7 +175,7 @@
    Note
    This function returns an internal class object consisting of an array subscript operator operator[](unsigned int) and an alias value_type describing its return value.
    Template Parameters
    - +
    indexThe index to be shifted to the end. Indices are counted from 0, thus the valid range is $0\le\text{index}<\text{rank}$.
    indexThe index to be shifted to the end. Indices are counted from 0, thus the valid range is $0\le\text{index}<\text{rank}$.
    rankRank of the tensorial object t
    TA tensorial object of rank rank. T must provide a local alias value_type and an index operator operator[]() that returns a (const or non-const) reference of value_type.
    @@ -280,12 +280,12 @@

    This function contracts two tensorial objects left and right and stores the result in result. The contraction is done over the last no_contr indices of both tensorial objects:

    -\[
+<picture><source srcset=\[
   \text{result}_{i_1,..,i_{r1},j_1,..,j_{r2}}
   = \sum_{k_1,..,k_{\mathrm{no\_contr}}}
     \mathrm{left}_{i_1,..,i_{r1},k_1,..,k_{\mathrm{no\_contr}}}
     \mathrm{right}_{j_1,..,j_{r2},k_1,..,k_{\mathrm{no\_contr}}}
-\] +\]" src="form_865.png"/>

    Calling this function is equivalent of writing the following low level code:

    for(unsigned int i_0 = 0; i_0 < dim; ++i_0)
    ...
    @@ -351,12 +351,12 @@

    Full contraction of three tensorial objects:

    -\[
+<picture><source srcset=\[
   \sum_{i_1,..,i_{r1},j_1,..,j_{r2}}
   \text{left}_{i_1,..,i_{r1}}
   \text{middle}_{i_1,..,i_{r1},j_1,..,j_{r2}}
   \text{right}_{j_1,..,j_{r2}}
-\] +\]" src="form_866.png"/>

    Calling this function is equivalent of writing the following low level code:

    T1 result = T1();
    for(unsigned int i_0 = 0; i_0 < dim; ++i_0)
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceUtilities_1_1LinearAlgebra.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceUtilities_1_1LinearAlgebra.html 2023-08-09 23:38:57.946622967 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceUtilities_1_1LinearAlgebra.html 2023-08-09 23:38:57.950622997 +0000 @@ -139,8 +139,8 @@

    Return the elements of a continuous Givens rotation matrix and the norm of the input vector.

    -

    That is for a given pair x and y, return $c$ , $s$ and $\sqrt{x^2+y^2}$ such that

    -\[
+<p>That is for a given pair <code>x</code> and <code>y</code>, return <picture><source srcset=$c$ , $s$ and $\sqrt{x^2+y^2}$ such that

    +\[
 \begin{bmatrix}
 c  & s \\
 -s & c
@@ -154,7 +154,7 @@
 \sqrt{x^2+y^2} \\
 0
 \end{bmatrix}
-\] +\]" src="form_1964.png"/>

    Note
    The function is implemented for real valued numbers only.
    @@ -188,8 +188,8 @@

    Return the elements of a hyperbolic rotation matrix.

    -

    That is for a given pair x and y, return $c$ , $s$ and $r$ such that

    -\[
+<p>That is for a given pair <code>x</code> and <code>y</code>, return <picture><source srcset=$c$ , $s$ and $r$ such that

    +\[
 \begin{bmatrix}
 c  & -s \\
 -s & c
@@ -203,9 +203,9 @@
 r \\
 0
 \end{bmatrix}
-\] +\]" src="form_1965.png"/>

    -

    Real valued solution only exists if $|x|>|g|$, the function will throw an error otherwise.

    +

    Real valued solution only exists if $|x|>|g|$, the function will throw an error otherwise.

    Note
    The function is implemented for real valued numbers only.
    @@ -253,7 +253,7 @@
    -

    Estimate an upper bound for the largest eigenvalue of H by a k -step Lanczos process starting from the initial vector v0. Typical values of k are below 10. This estimator computes a k-step Lanczos decomposition $H V_k=V_k T_k+f_k e_k^T$ where $V_k$ contains k Lanczos basis, $V_k^TV_k=I_k$, $T_k$ is the tridiagonal Lanczos matrix, $f_k$ is a residual vector $f_k^TV_k=0$, and $e_k$ is the k-th canonical basis of $R^k$. The returned value is $ ||T_k||_2 + ||f_k||_2$. If eigenvalues is not nullptr, the eigenvalues of $T_k$ will be written there.

    +

    Estimate an upper bound for the largest eigenvalue of H by a k -step Lanczos process starting from the initial vector v0. Typical values of k are below 10. This estimator computes a k-step Lanczos decomposition $H V_k=V_k T_k+f_k e_k^T$ where $V_k$ contains k Lanczos basis, $V_k^TV_k=I_k$, $T_k$ is the tridiagonal Lanczos matrix, $f_k$ is a residual vector $f_k^TV_k=0$, and $e_k$ is the k-th canonical basis of $R^k$. The returned value is $ ||T_k||_2 + ||f_k||_2$. If eigenvalues is not nullptr, the eigenvalues of $T_k$ will be written there.

    vector_memory is used to allocate memory for temporary vectors. OperatorType has to provide vmult operation with VectorType.

    This function implements the algorithm from

    @article{Zhou2006,
    Title = {Self-consistent-field Calculations Using Chebyshev-filtered
    @@ -265,7 +265,7 @@
    Volume = {219},
    Pages = {172--184},
    }
    -
    Note
    This function uses Lapack routines to compute the largest eigenvalue of $T_k$.
    +
    Note
    This function uses Lapack routines to compute the largest eigenvalue of $T_k$.
    This function provides an alternate estimate to that obtained from several steps of SolverCG with SolverCG<VectorType>::connect_eigenvalues_slot().
    @@ -320,19 +320,19 @@
    -

    Apply Chebyshev polynomial of the operator H to x. For a non-defective operator $H$ with a complete set of eigenpairs $H \psi_i = \lambda_i \psi_i$, the action of a polynomial filter $p$ is given by $p(H)x =\sum_i a_i p(\lambda_i) \psi_i$, where $x=: \sum_i a_i
-\psi_i$. Thus by appropriately choosing the polynomial filter, one can alter the eigenmodes contained in $x$.

    -

    This function uses Chebyshev polynomials of first kind. Below is an example of polynomial $T_n(x)$ of degree $n=8$ normalized to unity at $-1.2$.

    +

    Apply Chebyshev polynomial of the operator H to x. For a non-defective operator $H$ with a complete set of eigenpairs $H \psi_i = \lambda_i \psi_i$, the action of a polynomial filter $p$ is given by $p(H)x =\sum_i a_i p(\lambda_i) \psi_i$, where $x=: \sum_i a_i
+\psi_i$. Thus by appropriately choosing the polynomial filter, one can alter the eigenmodes contained in $x$.

    +

    This function uses Chebyshev polynomials of first kind. Below is an example of polynomial $T_n(x)$ of degree $n=8$ normalized to unity at $-1.2$.

    -

    By introducing a linear mapping $L$ from unwanted_spectrum to $[-1,1]$, we can dump the corresponding modes in x. The higher the polynomial degree $n$, the more rapid it grows outside of the $[-1,1]$. In order to avoid numerical overflow, we normalize polynomial filter to unity at tau. Thus, the filtered operator is $p(H) = T_n(L(H))/T_n(L(\tau))$.

    -

    The action of the Chebyshev filter only requires evaluation of vmult() of H and is based on the recursion equation for Chebyshev polynomial of degree $n$: $T_{n}(x) = 2x T_{n-1}(x) - T_{n-2}(x)$ with $T_0(x)=1$ and $T_1(x)=x$.

    +

    By introducing a linear mapping $L$ from unwanted_spectrum to $[-1,1]$, we can dump the corresponding modes in x. The higher the polynomial degree $n$, the more rapid it grows outside of the $[-1,1]$. In order to avoid numerical overflow, we normalize polynomial filter to unity at tau. Thus, the filtered operator is $p(H) = T_n(L(H))/T_n(L(\tau))$.

    +

    The action of the Chebyshev filter only requires evaluation of vmult() of H and is based on the recursion equation for Chebyshev polynomial of degree $n$: $T_{n}(x) = 2x T_{n-1}(x) - T_{n-2}(x)$ with $T_0(x)=1$ and $T_1(x)=x$.

    vector_memory is used to allocate memory for temporary objects.

    -

    This function implements the algorithm (with a minor fix of sign of $\sigma_1$) from

    @article{Zhou2014,
    +

    This function implements the algorithm (with a minor fix of sign of $\sigma_1$) from

    @article{Zhou2014,
    Title = {Chebyshev-filtered subspace iteration method free of sparse
    diagonalization for solving the Kohn--Sham equation},
    Author = {Zhou, Yunkai and Chelikowsky, James R and Saad, Yousef},
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceUtilities_1_1MPI_1_1ConsensusAlgorithms.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceUtilities_1_1MPI_1_1ConsensusAlgorithms.html 2023-08-09 23:38:57.974623176 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceUtilities_1_1MPI_1_1ConsensusAlgorithms.html 2023-08-09 23:38:57.978623206 +0000 @@ -135,7 +135,7 @@

    Detailed Description

    A namespace for algorithms that implement the task of communicating in a dynamic-sparse way. In computer science, this is often called a consensus problem.

    -

    The problem consensus algorithms are trying to solve is this: Let's say you have $P$ processes that work together via MPI. Each (or at least some) of these want to send information to some of the other processes, or request information from other processes. No process knows which other process wants to communicate with them. The challenge is to determine who needs to talk to whom and what information needs to be sent, and to come up with an algorithm that ensures that this communication happens.

    +

    The problem consensus algorithms are trying to solve is this: Let's say you have $P$ processes that work together via MPI. Each (or at least some) of these want to send information to some of the other processes, or request information from other processes. No process knows which other process wants to communicate with them. The challenge is to determine who needs to talk to whom and what information needs to be sent, and to come up with an algorithm that ensures that this communication happens.

    That this is not a trivial problem can be seen by an analogy of the postal service. There, some senders may request information from some other participants in the postal service. So they send a letter that requests the information, but the recipients do not know how many such letters they need to expect (or that they should expect any at all). They also do not know how long they need to keep checking their mailbox for incoming requests. The recipients can be considered reliable, however: We can assume that everyone who is sent a request puts a letter with the answer in the mail. This time at least the recipients of these answers know that they are waiting for these answers because they have previously sent a request. They do not know in advance, however, when the answer will arrive and how long to wait. The goal of a consensus algorithm is then to come up with a strategy in which every participant can say who they want to send requests to, what that request is, and is then guaranteed an answer. The algorithm will only return when all requests by all participants have been answered and the answer delivered to the requesters.

    The problem is generally posed in terms of requests and answers. In practice, either of these two may be empty messages. For example, processes may simply want to send information to others that they know these others need; in this case, the "answer" message may be empty and its meaning is simply an affirmation that the information was received. Similarly, in some cases processes simply need to inform others that they want information, but the destination process knows what information is being requested (based on where in the program the request happens) and can send that information without there be any identifying information in the request; in that case, the request message may be empty and simply serve to identify the requester. (Each message can be queried for its sender.)

    As mentioned in the first paragraph, the algorithms we are interested in are "dynamic-sparse":

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceVectorTools.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceVectorTools.html 2023-08-09 23:38:58.082623983 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceVectorTools.html 2023-08-09 23:38:58.086624014 +0000 @@ -321,7 +321,7 @@

      Detailed Description

      Provide a namespace which offers some operations on vectors. Among these are assembling of standard vectors, integration of the difference of a finite element solution and a continuous function, interpolations and projections of continuous functions to the finite element space and other operations.

      -
      Note
      There exist two versions of almost all functions, one that takes an explicit Mapping argument and one that does not. The second one generally calls the first with an implicit $Q_1$ argument (i.e., with an argument of kind MappingQ(1)). If your intend your code to use a different mapping than a (bi-/tri-)linear one, then you need to call the functions with mapping argument should be used.
      +
      Note
      There exist two versions of almost all functions, one that takes an explicit Mapping argument and one that does not. The second one generally calls the first with an implicit $Q_1$ argument (i.e., with an argument of kind MappingQ(1)). If your intend your code to use a different mapping than a (bi-/tri-)linear one, then you need to call the functions with mapping argument should be used.

      Description of operations

      This collection of methods offers the following operations:

      • @@ -330,7 +330,7 @@

      • -

        Projection: compute the L2-projection of the given function onto the finite element space, i.e. if f is the function to be projected, compute fh in Vh such that (fh,vh)=(f,vh) for all discrete test functions vh. This is done through the solution of the linear system of equations M v = f where M is the mass matrix $m_{ij} = \int_\Omega \phi_i(x) \phi_j(x) dx$ and $f_i = \int_\Omega f(x) \phi_i(x) dx$. The solution vector $v$ then is the nodal representation of the projection fh. The project() functions are used in the step-21 and step-23 tutorial programs.

        +

        Projection: compute the L2-projection of the given function onto the finite element space, i.e. if f is the function to be projected, compute fh in Vh such that (fh,vh)=(f,vh) for all discrete test functions vh. This is done through the solution of the linear system of equations M v = f where M is the mass matrix $m_{ij} = \int_\Omega \phi_i(x) \phi_j(x) dx$ and $f_i = \int_\Omega f(x) \phi_i(x) dx$. The solution vector $v$ then is the nodal representation of the projection fh. The project() functions are used in the step-21 and step-23 tutorial programs.

        In order to get proper results, it be may necessary to treat boundary conditions right. Below are listed some cases where this may be needed. If needed, this is done by L2-projection of the trace of the given function onto the finite element space restricted to the boundary of the domain, then taking this information and using it to eliminate the boundary nodes from the mass matrix of the whole domain, using the MatrixTools::apply_boundary_values() function. The projection of the trace of the function to the boundary is done with the VectorTools::project_boundary_values() (see below) function, which is called with a map of boundary functions std::map<types::boundary_id, const Function<spacedim,number>*> in which all boundary indicators from zero to numbers::internal_face_boundary_id-1 (numbers::internal_face_boundary_id is used for other purposes, see the Triangulation class documentation) point to the function to be projected. The projection to the boundary takes place using a second quadrature formula on the boundary given to the project() function. The first quadrature formula is used to compute the right hand side and for numerical quadrature of the mass matrix.

        The projection of the boundary values first, then eliminating them from the global system of equations is not needed usually. It may be necessary if you want to enforce special restrictions on the boundary values of the projected function, for example in time dependent problems: you may want to project the initial values but need consistency with the boundary values for later times. Since the latter are projected onto the boundary in each time step, it is necessary that we also project the boundary values of the initial values, before projecting them to the whole domain.

        Obviously, the results of the two schemes for projection are different. Usually, when projecting to the boundary first, the L2-norm of the difference between original function and projection over the whole domain will be larger (factors of five have been observed) while the L2-norm of the error integrated over the boundary should of course be less. The reverse should also hold if no projection to the boundary is performed.

        @@ -340,17 +340,17 @@

      • -

        Creation of right hand side vectors: The create_right_hand_side() function computes the vector $f_i = \int_\Omega f(x) \phi_i(x) dx$. This is the same as what the MatrixCreator::create_* functions which take a right hand side do, but without assembling a matrix.

        +

        Creation of right hand side vectors: The create_right_hand_side() function computes the vector $f_i = \int_\Omega f(x) \phi_i(x) dx$. This is the same as what the MatrixCreator::create_* functions which take a right hand side do, but without assembling a matrix.

      • -

        Creation of right hand side vectors for point sources: The create_point_source_vector() function computes the vector $F_i =
-\int_\Omega \delta(x-x_0) \phi_i(x) dx$.

        +

        Creation of right hand side vectors for point sources: The create_point_source_vector() function computes the vector $F_i =
+\int_\Omega \delta(x-x_0) \phi_i(x) dx$.

      • -

        Creation of boundary right hand side vectors: The create_boundary_right_hand_side() function computes the vector $f_i =
-\int_{\partial\Omega} g(x) \phi_i(x) dx$. This is the right hand side contribution of boundary forces when having inhomogeneous Neumann boundary values in Laplace's equation or other second order operators. This function also takes an optional argument denoting over which parts of the boundary the integration shall extend. If the default argument is used, it is applied to all boundaries.

        +

        Creation of boundary right hand side vectors: The create_boundary_right_hand_side() function computes the vector $f_i =
+\int_{\partial\Omega} g(x) \phi_i(x) dx$. This is the right hand side contribution of boundary forces when having inhomogeneous Neumann boundary values in Laplace's equation or other second order operators. This function also takes an optional argument denoting over which parts of the boundary the integration shall extend. If the default argument is used, it is applied to all boundaries.

      • @@ -393,220 +393,220 @@
      -

      Denote which norm/integral is to be computed by the integrate_difference() function on each cell and compute_global_error() for the whole domain. Let $f:\Omega \rightarrow \mathbb{R}^c$ be a finite element function with $c$ components where component $c$ is denoted by $f_c$ and $\hat{f}$ be the reference function (the fe_function and exact_solution arguments to integrate_difference()). Let $e_c = \hat{f}_c - f_c$ be the difference or error between the two. Further, let $w:\Omega \rightarrow \mathbb{R}^c$ be the weight function of integrate_difference(), which is assumed to be equal to one if not supplied. Finally, let $p$ be the exponent argument (for $L_p$-norms).

      -

      In the following,we denote by $E_K$ the local error computed by integrate_difference() on cell $K$, whereas $E$ is the global error computed by compute_global_error(). Note that integrals are approximated by quadrature in the usual way:

      -\[
+<p>Denote which norm/integral is to be computed by the <a class=integrate_difference() function on each cell and compute_global_error() for the whole domain. Let $f:\Omega \rightarrow \mathbb{R}^c$ be a finite element function with $c$ components where component $c$ is denoted by $f_c$ and $\hat{f}$ be the reference function (the fe_function and exact_solution arguments to integrate_difference()). Let $e_c = \hat{f}_c - f_c$ be the difference or error between the two. Further, let $w:\Omega \rightarrow \mathbb{R}^c$ be the weight function of integrate_difference(), which is assumed to be equal to one if not supplied. Finally, let $p$ be the exponent argument (for $L_p$-norms).

      +

      In the following,we denote by $E_K$ the local error computed by integrate_difference() on cell $K$, whereas $E$ is the global error computed by compute_global_error(). Note that integrals are approximated by quadrature in the usual way:

      +\[
 \int_A f(x) dx \approx \sum_q f(x_q) \omega_q.
-\] +\]" src="form_2308.png"/>

      -

      Similarly for suprema over a cell $T$:

      -\[
+<p> Similarly for suprema over a cell <picture><source srcset=$T$:

      +\[
 \sup_{x\in T} |f(x)| dx \approx \max_q |f(x_q)|.
-\] +\]" src="form_2309.png"/>

      -
      Enumerator
      mean 

      The function or difference of functions is integrated on each cell $K$:

      -\[
+<picture><source srcset=\[
   E_K
 = \int_K \sum_c (\hat{f}_c - f_c) \, w_c
 = \int_K \sum_c e_c \, w_c
-\] +\]" src="form_2310.png"/>

      and summed up to get

      -\[
+<picture><source srcset=\[
   E = \sum_K E_K
     = \int_\Omega \sum_c (\hat{f}_c - f_c) \, w_c
-\] +\]" src="form_2311.png"/>

      -

      or, for $w \equiv 1$:

      -\[
+<p> or, for <picture><source srcset=$w \equiv 1$:

      +\[
   E = \int_\Omega (\hat{f} - f)
     = \int_\Omega e.
-\] +\]" src="form_2313.png"/>

      -

      Note: This differs from what is typically known as the mean of a function by a factor of $\frac{1}{|\Omega|}$. To compute the mean you can also use compute_mean_value(). Finally, pay attention to the sign: if $\hat{f}=0$, this will compute the negative of the mean of $f$.

      +

      Note: This differs from what is typically known as the mean of a function by a factor of $\frac{1}{|\Omega|}$. To compute the mean you can also use compute_mean_value(). Finally, pay attention to the sign: if $\hat{f}=0$, this will compute the negative of the mean of $f$.

      L1_norm 

      The absolute value of the function is integrated:

      -\[
+<picture><source srcset=\[
   E_K = \int_K \sum_c |e_c| \, w_c
-\] +\]" src="form_2316.png"/>

      and

      -\[
+<picture><source srcset=\[
   E = \sum_K E_K = \int_\Omega \sum_c |e_c| w_c,
-\] +\]" src="form_2317.png"/>

      -

      or, for $w \equiv 1$:

      -\[
+<p> or, for <picture><source srcset=$w \equiv 1$:

      +\[
   E  = \| e \|_{L^1}.
-\] +\]" src="form_2318.png"/>

      L2_norm 

      The square of the function is integrated and the square root of the result is computed on each cell:

      -\[
+<picture><source srcset=\[
   E_K = \sqrt{ \int_K \sum_c e_c^2 \, w_c }
-\] +\]" src="form_2319.png"/>

      and

      -\[
+<picture><source srcset=\[
   E = \sqrt{\sum_K E_K^2} = \sqrt{ \int_\Omega  \sum_c e_c^2 \, w_c }
-\] +\]" src="form_2320.png"/>

      -

      or, for $w \equiv 1$:

      -\[
+<p> or, for <picture><source srcset=$w \equiv 1$:

      +\[
   E = \sqrt{ \int_\Omega e^2 }
     = \| e \|_{L^2}
-\] +\]" src="form_2321.png"/>

      Lp_norm 

      The absolute value to the $p$-th power is integrated and the $p$-th root is computed on each cell. The exponent $p$ is the exponent argument of integrate_difference() and compute_mean_value():

      -\[
+<tr><td class=Lp_norm 

      The absolute value to the $p$-th power is integrated and the $p$-th root is computed on each cell. The exponent $p$ is the exponent argument of integrate_difference() and compute_mean_value():

      +\[
   E_K = \left( \int_K \sum_c |e_c|^p \, w_c \right)^{1/p}
-\] +\]" src="form_2322.png"/>

      and

      -\[
+<picture><source srcset=\[
   E = \left( \sum_K E_K^p \right)^{1/p}
-\] +\]" src="form_2323.png"/>

      -

      or, for $w \equiv 1$:

      -\[
+<p> or, for <picture><source srcset=$w \equiv 1$:

      +\[
   E = \| e \|_{L^p}.
-\] +\]" src="form_2324.png"/>

      Linfty_norm 

      The maximum absolute value of the function:

      -\[
+<picture><source srcset=\[
   E_K = \sup_K \max_c |e_c| \, w_c
-\] +\]" src="form_2325.png"/>

      and

      -\[
+<picture><source srcset=\[
   E = \max_K E_K
 = \sup_\Omega \max_c |e_c| \, w_c
-\] +\]" src="form_2326.png"/>

      -

      or, for $w \equiv 1$:

      -\[
+<p> or, for <picture><source srcset=$w \equiv 1$:

      +\[
   E  = \sup_\Omega \|e\|_\infty = \| e \|_{L^\infty}.
-\] +\]" src="form_2327.png"/>

      H1_seminorm 

      L2_norm of the gradient:

      -\[
+<picture><source srcset=\[
   E_K = \sqrt{ \int_K \sum_c (\nabla e_c)^2 \, w_c }
-\] +\]" src="form_2328.png"/>

      and

      -\[
+<picture><source srcset=\[
/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacehp_1_1Refinement.html differs (HTML document, ASCII text, with very long lines)
--- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacehp_1_1Refinement.html	2023-08-09 23:38:58.118624253 +0000
+++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespacehp_1_1Refinement.html	2023-08-09 23:38:58.118624253 +0000
@@ -581,9 +581,9 @@
         </tr>
       </table>
 </div><div class= -

      Predict how the current error_indicators will adapt after refinement and coarsening were to happen on the provided dof_handler, and write its results to predicted_errors. Each entry of error_indicators and predicted_errors corresponds to an active cell on the underlying Triangulation, thus each container has to be of size Triangulation::n_active_cells(). The errors are interpreted to be measured in the energy norm; this assumption enters the rate of convergence that is used in the prediction. The $l_2$-norm of the output argument predicted_errors corresponds to the predicted global error after adaptation.

      +

      Predict how the current error_indicators will adapt after refinement and coarsening were to happen on the provided dof_handler, and write its results to predicted_errors. Each entry of error_indicators and predicted_errors corresponds to an active cell on the underlying Triangulation, thus each container has to be of size Triangulation::n_active_cells(). The errors are interpreted to be measured in the energy norm; this assumption enters the rate of convergence that is used in the prediction. The $l_2$-norm of the output argument predicted_errors corresponds to the predicted global error after adaptation.

      For p-adaptation, the local error is expected to converge exponentially with the polynomial degree of the assigned finite element. Each increase or decrease of the degree will thus change its value by a user-defined control parameter gamma_p.

      -

      For h-adaptation, we expect the local error $\eta_K$ on cell $K$ to be proportional to $(h_K)^{p_K}$ in the energy norm, where $h_K$ denotes the cell diameter and $p_K$ the polynomial degree of the currently assigned finite element on cell $K$.

      +

      For h-adaptation, we expect the local error $\eta_K$ on cell $K$ to be proportional to $(h_K)^{p_K}$ in the energy norm, where $h_K$ denotes the cell diameter and $p_K$ the polynomial degree of the currently assigned finite element on cell $K$.

      During h-coarsening, the finite elements on siblings may be different, and their parent cell will be assigned to their least dominating finite element that belongs to its most general child. Thus, we will always interpolate on an enclosing finite element space. Additionally assuming that the finite elements on the cells to be coarsened are sufficient to represent the solution correctly (e.g. at least quadratic basis functions for a quadratic solution), we are confident to say that the error will not change by sole interpolation on the larger finite element space.

      For p-adaptation, the local error is expected to converge exponentially with the polynomial degree of the assigned finite element. Each increase or decrease of the degree will thus change its value by a user-defined control parameter gamma_p. The assumption of exponential convergence is only valid if both h- and p-adaptive methods are combined in a sense that they are both utilized throughout a mesh, but do not have to be applied both on a cell simultaneously.

      The prediction algorithm is formulated as follows with control parameters gamma_p, gamma_h and gamma_n that may be used to influence prediction for each adaptation type individually. The results for each individual cell are stored in the predicted_errors output argument.

      @@ -605,7 +605,7 @@ \gamma_\text{p}^{(p_{K,\text{future}} - p_{K})}$" src="form_1500.png"/>

      On basis of the refinement history, we use the predicted error estimates to decide how cells will be adapted in the next adaptation step. Comparing the predicted error from the previous adaptation step to the error estimates of the current step allows us to justify whether our previous choice of adaptation was justified, and lets us decide how to adapt in the next one.

      -

      We thus have to transfer the predicted error from the old to the adapted mesh. When transferring the predicted error to the adapted mesh, make sure to configure your CellDataTransfer object with AdaptationStrategies::Refinement::l2_norm() as a refinement strategy and AdaptationStrategies::Coarsening::l2_norm() as a coarsening strategy. This ensures that the $l_2$-norm of the predict errors is preserved on both meshes.

      +

      We thus have to transfer the predicted error from the old to the adapted mesh. When transferring the predicted error to the adapted mesh, make sure to configure your CellDataTransfer object with AdaptationStrategies::Refinement::l2_norm() as a refinement strategy and AdaptationStrategies::Coarsening::l2_norm() as a coarsening strategy. This ensures that the $l_2$-norm of the predict errors is preserved on both meshes.

      In this context, we assume that the local error on a cell to be h-refined will be divided equally on all of its $n_{K_c}$ children, whereas local errors on siblings will be summed up on the parent cell in case of h-coarsening. This assumption is often not satisfied in practice: For example, if a cell is at a corner singularity, then the one child cell that ends up closest to the singularity will inherit the majority of the remaining error – but this function can not know where the singularity will be, and consequently assumes equal distribution.

      Incorporating the transfer from the old to the adapted mesh, the complete error prediction algorithm reads as follows:

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceinternal.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceinternal.html 2023-08-09 23:38:58.214624969 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceinternal.html 2023-08-09 23:38:58.214624969 +0000 @@ -857,8 +857,8 @@

      Creates a (dim + 1)-dimensional point by copying over the coordinates of the incoming dim-dimensional point and setting the "missing" (dim + 1)-dimensional component to the incoming coordinate value.

      -

      For example, given the input $\{(x, y), 2, z \}$ this function creates the point $(x, y, z)$.

      -

      The coordinates of the dim-dimensional point are written to the coordinates of the (dim + 1)-dimensional point in the order of the convention given by the function coordinate_to_one_dim_higher. Thus, the order of coordinates on the lower-dimensional point are not preserved: $\{(z, x), 1, y \}$ creates the point $(x, y, z)$.

      +

      For example, given the input $\{(x, y), 2, z \}$ this function creates the point $(x, y, z)$.

      +

      The coordinates of the dim-dimensional point are written to the coordinates of the (dim + 1)-dimensional point in the order of the convention given by the function coordinate_to_one_dim_higher. Thus, the order of coordinates on the lower-dimensional point are not preserved: $\{(z, x), 1, y \}$ creates the point $(x, y, z)$.

      Definition at line 24 of file function_restriction.cc.

      @@ -1959,7 +1959,7 @@
      -

      Compute the polynomial interpolation of a tensor product shape function $\varphi_i$ given a vector of coefficients $u_i$ in the form $u_h(\mathbf{x}) = \sum_{i=1}^{k^d} \varphi_i(\mathbf{x}) u_i$. The shape functions $\varphi_i(\mathbf{x}) =
+<p>Compute the polynomial interpolation of a tensor product shape function <picture><source srcset=$\varphi_i$ given a vector of coefficients $u_i$ in the form $u_h(\mathbf{x}) = \sum_{i=1}^{k^d} \varphi_i(\mathbf{x}) u_i$. The shape functions $\varphi_i(\mathbf{x}) =
 \prod_{d=1}^{\text{dim}}\varphi_{i_d}^\text{1d}(x_d)$ represent a tensor product. The function returns a pair with the value of the interpolation as the first component and the gradient in reference coordinates as the second component. Note that for compound types (e.g. the values field begin a Point<spacedim> argument), the components of the gradient are sorted as Tensor<1, dim, Tensor<1, spacedim>> with the derivatives as the first index; this is a consequence of the generic arguments in the function.

      Parameters
      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceparallel.html differs (HTML document, ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceparallel.html 2023-08-09 23:38:58.238625148 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/namespaceparallel.html 2023-08-09 23:38:58.238625148 +0000 @@ -356,7 +356,7 @@

      This function applies the given function argument f to all elements in the range [begin,end) and may do so in parallel. An example of its use is given in step-69.

      However, in many cases it is not efficient to call a function on each element, so this function calls the given function object on sub-ranges. In other words: if the given range [begin,end) is smaller than grainsize or if multithreading is not enabled, then we call f(begin,end); otherwise, we may execute, possibly in parallel, a sequence of calls f(b,e) where [b,e) are subintervals of [begin,end) and the collection of calls we do to f(.,.) will happen on disjoint subintervals that collectively cover the original interval [begin,end).

      -

      Oftentimes, the called function will of course have to get additional information, such as the object to work on for a given value of the iterator argument. This can be achieved by binding certain arguments. For example, here is an implementation of a matrix-vector multiplication $y=Ax$ for a full matrix $A$ and vectors $x,y$:

      void matrix_vector_product (const FullMatrix &A,
      +

      Oftentimes, the called function will of course have to get additional information, such as the object to work on for a given value of the iterator argument. This can be achieved by binding certain arguments. For example, here is an implementation of a matrix-vector multiplication $y=Ax$ for a full matrix $A$ and vectors $x,y$:

      void matrix_vector_product (const FullMatrix &A,
      const Vector &x,
      Vector &y)
      {
      @@ -433,7 +433,7 @@

      This function works a lot like the apply_to_subranges() function, but it allows to accumulate numerical results computed on each subrange into one number. The type of this number is given by the ResultType template argument that needs to be explicitly specified.

      -

      An example of use of this function is to compute the value of the expression $x^T A x$ for a square matrix $A$ and a vector $x$. The sum over rows can be parallelized and the whole code might look like this:

      void matrix_norm (const FullMatrix &A,
      +

      An example of use of this function is to compute the value of the expression $x^T A x$ for a square matrix $A$ and a vector $x$. The sum over rows can be parallelized and the whole code might look like this:

      void matrix_norm (const FullMatrix &A,
      const Vector &x)
      {
      return
      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_10.js differs (ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_10.js 2023-07-22 00:00:00.000000000 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_10.js 2023-07-22 00:00:00.000000000 +0000 @@ -187,19 +187,19 @@ ['fe_5findex_184',['fe_index',['../namespacetypes.html#a6349a42041132a6bc7e1e9ffb7e119b3',1,'types']]], ['fe_5findex_5fconversion_185',['fe_index_conversion',['../structinternal_1_1MatrixFreeFunctions_1_1DoFInfo.html#a67df5ade1fbe05fc62d3d8d336c189db',1,'internal::MatrixFreeFunctions::DoFInfo']]], ['fe_5findex_5ffrom_5fdegree_186',['fe_index_from_degree',['../structinternal_1_1MatrixFreeFunctions_1_1DoFInfo.html#a3de471c386cdaa3b88906599db12f4e1',1,'internal::MatrixFreeFunctions::DoFInfo']]], - ['fe_5findex_5fis_5factive_187',['fe_index_is_active',['../classDoFAccessor.html#af13c59bcaf71115b1fe63422393e232e',1,'DoFAccessor::fe_index_is_active()'],['../classDoFAccessor_3_010_00_011_00_01spacedim_00_01level__dof__access_01_4.html#ae5819b33020882c155a85023ac89cc2b',1,'DoFAccessor< 0, 1, spacedim, level_dof_access >::fe_index_is_active()'],['../classinternal_1_1DoFHandlerImplementation_1_1DoFObjects.html#aa9236174e26c195aca11b8a8bb3a2a82',1,'internal::DoFHandlerImplementation::DoFObjects::fe_index_is_active()']]], + ['fe_5findex_5fis_5factive_187',['fe_index_is_active',['../classinternal_1_1DoFHandlerImplementation_1_1DoFObjects.html#aa9236174e26c195aca11b8a8bb3a2a82',1,'internal::DoFHandlerImplementation::DoFObjects::fe_index_is_active()'],['../classDoFAccessor_3_010_00_011_00_01spacedim_00_01level__dof__access_01_4.html#ae5819b33020882c155a85023ac89cc2b',1,'DoFAccessor< 0, 1, spacedim, level_dof_access >::fe_index_is_active()'],['../classDoFAccessor.html#af13c59bcaf71115b1fe63422393e232e',1,'DoFAccessor::fe_index_is_active()']]], ['fe_5findex_5fvalid_188',['fe_index_valid',['../classMatrixFreeTools_1_1ElementActivationAndDeactivationMatrixFree.html#ad107d7319e4ba3ec4afbb6373d8d7a2e',1,'MatrixFreeTools::ElementActivationAndDeactivationMatrixFree']]], ['fe_5finterface_189',['fe_interface',['../classFEInterfaceViews_1_1Base.html#af8ecd3d8d3c7179087bf1bdb4a584d97',1,'FEInterfaceViews::Base']]], ['fe_5finterface_5fvalues_2eh_190',['fe_interface_values.h',['../fe__interface__values_8h.html',1,'']]], ['fe_5fmask_191',['fe_mask',['../classMappingFEField.html#a0f6f8685e003abaecde8885c7e1d4617',1,'MappingFEField']]], - ['fe_5fnedelec_192',['FE_Nedelec',['../classFE__Nedelec.html#ae173be2027aa6827f8336ff5cd362e8f',1,'FE_Nedelec::FE_Nedelec()'],['../classFE__Nedelec.html#ac88889abb6a6ef6210c7b49f1487038f',1,'FE_Nedelec::FE_Nedelec(const unsigned int order)'],['../classFE__Nedelec.html',1,'FE_Nedelec< dim >']]], + ['fe_5fnedelec_192',['FE_Nedelec',['../classFE__Nedelec.html#ae173be2027aa6827f8336ff5cd362e8f',1,'FE_Nedelec::FE_Nedelec()'],['../classFE__Nedelec.html',1,'FE_Nedelec< dim >'],['../classFE__Nedelec.html#ac88889abb6a6ef6210c7b49f1487038f',1,'FE_Nedelec::FE_Nedelec()']]], ['fe_5fnedelec_2ecc_193',['fe_nedelec.cc',['../fe__nedelec_8cc.html',1,'']]], ['fe_5fnedelec_2eh_194',['fe_nedelec.h',['../fe__nedelec_8h.html',1,'']]], ['fe_5fnedelec_5fsz_2ecc_195',['fe_nedelec_sz.cc',['../fe__nedelec__sz_8cc.html',1,'']]], ['fe_5fnedelec_5fsz_2eh_196',['fe_nedelec_sz.h',['../fe__nedelec__sz_8h.html',1,'']]], - ['fe_5fnedelecsz_197',['FE_NedelecSZ',['../classFE__NedelecSZ.html#a3b628f8d46a6010139d6641f1110c80f',1,'FE_NedelecSZ::FE_NedelecSZ()'],['../classFE__NedelecSZ.html',1,'FE_NedelecSZ< dim, spacedim >']]], - ['fe_5fnothing_198',['fe_nothing',['../structColorEnriched_1_1Helper.html#a8d6152d5fc1ef14877cf1c10c596b20b',1,'ColorEnriched::Helper']]], - ['fe_5fnothing_199',['FE_Nothing',['../classFE__Nothing.html#adc059d476e456724d9431b35d6ed5547',1,'FE_Nothing::FE_Nothing(const unsigned int n_components=1, const bool dominate=false)'],['../classFE__Nothing.html#a69940158d653b46222943f09c6b25a4c',1,'FE_Nothing::FE_Nothing(const ReferenceCell &type, const unsigned int n_components=1, const bool dominate=false)'],['../classFE__Nothing.html',1,'FE_Nothing< dim, spacedim >']]], + ['fe_5fnedelecsz_197',['FE_NedelecSZ',['../classFE__NedelecSZ.html',1,'FE_NedelecSZ< dim, spacedim >'],['../classFE__NedelecSZ.html#a3b628f8d46a6010139d6641f1110c80f',1,'FE_NedelecSZ::FE_NedelecSZ()']]], + ['fe_5fnothing_198',['FE_Nothing',['../classFE__Nothing.html',1,'FE_Nothing< dim, spacedim >'],['../classFE__Nothing.html#adc059d476e456724d9431b35d6ed5547',1,'FE_Nothing::FE_Nothing(const unsigned int n_components=1, const bool dominate=false)'],['../classFE__Nothing.html#a69940158d653b46222943f09c6b25a4c',1,'FE_Nothing::FE_Nothing(const ReferenceCell &type, const unsigned int n_components=1, const bool dominate=false)']]], + ['fe_5fnothing_199',['fe_nothing',['../structColorEnriched_1_1Helper.html#a8d6152d5fc1ef14877cf1c10c596b20b',1,'ColorEnriched::Helper']]], ['fe_5fnothing_2ecc_200',['fe_nothing.cc',['../fe__nothing_8cc.html',1,'']]], ['fe_5fnothing_2eh_201',['fe_nothing.h',['../fe__nothing_8h.html',1,'']]], ['fe_5fnothing_3c_20dim_2c_20dim_20_3e_202',['FE_Nothing< dim, dim >',['../classFE__Nothing.html',1,'']]], @@ -210,7 +210,7 @@ ['fe_5fpoint_5fevaluation_2ecc_207',['fe_point_evaluation.cc',['../fe__point__evaluation_8cc.html',1,'']]], ['fe_5fpoint_5fevaluation_2eh_208',['fe_point_evaluation.h',['../fe__point__evaluation_8h.html',1,'']]], ['fe_5fpointer_209',['fe_pointer',['../classMeshWorker_1_1IntegrationInfo.html#ad8104a9fbad9a17daf6b27a47d233f85',1,'MeshWorker::IntegrationInfo']]], - ['fe_5fpoly_210',['FE_Poly',['../classFE__Poly.html#a3e3707af821b633b0938fc25af8e1d4e',1,'FE_Poly::FE_Poly(const ScalarPolynomialsBase< dim > &poly_space, const FiniteElementData< dim > &fe_data, const std::vector< bool > &restriction_is_additive_flags, const std::vector< ComponentMask > &nonzero_components)'],['../classFE__Poly.html#a0f7afbda20c71e4c0e9fd422137f9922',1,'FE_Poly::FE_Poly(const FE_Poly &fe)'],['../classFE__Poly.html',1,'FE_Poly< dim, spacedim >']]], + ['fe_5fpoly_210',['FE_Poly',['../classFE__Poly.html',1,'FE_Poly< dim, spacedim >'],['../classFE__Poly.html#a0f7afbda20c71e4c0e9fd422137f9922',1,'FE_Poly::FE_Poly(const FE_Poly &fe)'],['../classFE__Poly.html#a3e3707af821b633b0938fc25af8e1d4e',1,'FE_Poly::FE_Poly(const ScalarPolynomialsBase< dim > &poly_space, const FiniteElementData< dim > &fe_data, const std::vector< bool > &restriction_is_additive_flags, const std::vector< ComponentMask > &nonzero_components)']]], ['fe_5fpoly_2ecc_211',['fe_poly.cc',['../fe__poly_8cc.html',1,'']]], ['fe_5fpoly_2eh_212',['fe_poly.h',['../fe__poly_8h.html',1,'']]], ['fe_5fpoly_3c_20dim_2c_20dim_20_3e_213',['FE_Poly< dim, dim >',['../classFE__Poly.html',1,'']]], @@ -226,463 +226,462 @@ ['fe_5fpolytensor_3c_20dim_2c_20spacedim_20_3e_223',['FE_PolyTensor< dim, spacedim >',['../classFE__PolyTensor.html',1,'']]], ['fe_5fpyramid_5fp_2ecc_224',['fe_pyramid_p.cc',['../fe__pyramid__p_8cc.html',1,'']]], ['fe_5fpyramid_5fp_2eh_225',['fe_pyramid_p.h',['../fe__pyramid__p_8h.html',1,'']]], - ['fe_5fpyramiddgp_226',['FE_PyramidDGP',['../classFE__PyramidDGP.html#ac2e6079eebe80fc15716298488dc5c63',1,'FE_PyramidDGP::FE_PyramidDGP()'],['../classFE__PyramidDGP.html',1,'FE_PyramidDGP< dim, spacedim >']]], - ['fe_5fpyramidp_227',['FE_PyramidP',['../classFE__PyramidP.html#a10d9a9af391aa277a6196a53bcbca360',1,'FE_PyramidP::FE_PyramidP()'],['../classFE__PyramidP.html',1,'FE_PyramidP< dim, spacedim >']]], - ['fe_5fpyramidpoly_228',['FE_PyramidPoly',['../classFE__PyramidPoly.html#a1b80a859611151754bfc1b1bfcdaaa78',1,'FE_PyramidPoly::FE_PyramidPoly()'],['../classFE__PyramidPoly.html',1,'FE_PyramidPoly< dim, spacedim >']]], + ['fe_5fpyramiddgp_226',['FE_PyramidDGP',['../classFE__PyramidDGP.html',1,'FE_PyramidDGP< dim, spacedim >'],['../classFE__PyramidDGP.html#ac2e6079eebe80fc15716298488dc5c63',1,'FE_PyramidDGP::FE_PyramidDGP()']]], + ['fe_5fpyramidp_227',['FE_PyramidP',['../classFE__PyramidP.html',1,'FE_PyramidP< dim, spacedim >'],['../classFE__PyramidP.html#a10d9a9af391aa277a6196a53bcbca360',1,'FE_PyramidP::FE_PyramidP()']]], + ['fe_5fpyramidpoly_228',['FE_PyramidPoly',['../classFE__PyramidPoly.html',1,'FE_PyramidPoly< dim, spacedim >'],['../classFE__PyramidPoly.html#a1b80a859611151754bfc1b1bfcdaaa78',1,'FE_PyramidPoly::FE_PyramidPoly()']]], ['fe_5fpyramidpoly_3c_20dim_2c_20dim_20_3e_229',['FE_PyramidPoly< dim, dim >',['../classFE__PyramidPoly.html',1,'']]], - ['fe_5fq_230',['FE_Q',['../classFE__Q.html#ac36967b6e5de1ff1f4d54e0fa779d876',1,'FE_Q::FE_Q(const unsigned int p)'],['../classFE__Q.html#a32ccedfe518cfe3fca02cdddf9e664f6',1,'FE_Q::FE_Q(const Quadrature< 1 > &points)']]], - ['fe_5fq_231',['fe_q',['../classFE__TraceQ.html#a06b7dd7e3735c4a2882c8c8ef1833380',1,'FE_TraceQ']]], - ['fe_5fq_232',['FE_Q',['../classFE__Q.html',1,'']]], - ['fe_5fq_2ecc_233',['fe_q.cc',['../fe__q_8cc.html',1,'']]], - ['fe_5fq_2eh_234',['fe_q.h',['../fe__q_8h.html',1,'']]], - ['fe_5fq_3c_20dim_2c_20dim_20_3e_235',['FE_Q< dim, dim >',['../classFE__Q.html',1,'']]], - ['fe_5fq_5fbase_236',['FE_Q_Base',['../classFE__Q__Base.html',1,'FE_Q_Base< dim, spacedim >'],['../classFE__Q__Base.html#afd1a4a4c6b1df7cd57de66f78fe8ebf2',1,'FE_Q_Base::FE_Q_Base()']]], - ['fe_5fq_5fbase_2ecc_237',['fe_q_base.cc',['../fe__q__base_8cc.html',1,'']]], - ['fe_5fq_5fbase_2eh_238',['fe_q_base.h',['../fe__q__base_8h.html',1,'']]], - ['fe_5fq_5fbase_3c_20dim_2c_20dim_20_3e_239',['FE_Q_Base< dim, dim >',['../classFE__Q__Base.html',1,'']]], - ['fe_5fq_5fbase_3c_20dim_2c_20spacedim_20_3e_240',['FE_Q_Base< dim, spacedim >',['../classFE__Q__Base.html',1,'']]], - ['fe_5fq_5fbubbles_241',['FE_Q_Bubbles',['../classFE__Q__Bubbles.html#a63dc7e8541e0e0f447167cb5f25a2df7',1,'FE_Q_Bubbles::FE_Q_Bubbles()'],['../classFE__Q__Bubbles.html',1,'FE_Q_Bubbles< dim, spacedim >'],['../classFE__Q__Bubbles.html#acf702171c9122ac2e4678b9789eb7ab5',1,'FE_Q_Bubbles::FE_Q_Bubbles()']]], - ['fe_5fq_5fbubbles_2ecc_242',['fe_q_bubbles.cc',['../fe__q__bubbles_8cc.html',1,'']]], - ['fe_5fq_5fbubbles_2eh_243',['fe_q_bubbles.h',['../fe__q__bubbles_8h.html',1,'']]], - ['fe_5fq_5fdg0_244',['FE_Q_DG0',['../classFE__Q__DG0.html#a3b48400953a225d0c489eadfa3682ce8',1,'FE_Q_DG0::FE_Q_DG0(const Quadrature< 1 > &points)'],['../classFE__Q__DG0.html#a6eb900705fd9dab7c55be04968ccb41b',1,'FE_Q_DG0::FE_Q_DG0(const unsigned int p)'],['../classFE__Q__DG0.html',1,'FE_Q_DG0< dim, spacedim >']]], - ['fe_5fq_5fdg0_2ecc_245',['fe_q_dg0.cc',['../fe__q__dg0_8cc.html',1,'']]], - ['fe_5fq_5fdg0_2eh_246',['fe_q_dg0.h',['../fe__q__dg0_8h.html',1,'']]], - ['fe_5fq_5fhierarchical_247',['FE_Q_Hierarchical',['../classFE__Q__Hierarchical.html#aad40d98a2231b45fe6a53be39614fa99',1,'FE_Q_Hierarchical::FE_Q_Hierarchical()'],['../classFE__Q__Hierarchical.html',1,'FE_Q_Hierarchical< dim >'],['../classFE__Q__Hierarchical.html#a4bb9e1107f87e3a2d60df4ce7b8725fa',1,'FE_Q_Hierarchical::FE_Q_Hierarchical()']]], - ['fe_5fq_5fhierarchical_2ecc_248',['fe_q_hierarchical.cc',['../fe__q__hierarchical_8cc.html',1,'']]], - ['fe_5fq_5fhierarchical_2eh_249',['fe_q_hierarchical.h',['../fe__q__hierarchical_8h.html',1,'']]], - ['fe_5fq_5fiso_5fq1_250',['FE_Q_iso_Q1',['../classFE__Q__iso__Q1.html#a917f8f0d90f3eaa78a96f60b4d1763b9',1,'FE_Q_iso_Q1::FE_Q_iso_Q1(const unsigned int n_subdivisions)'],['../classFE__Q__iso__Q1.html#afb43b1ec080db8ae9a34addca748d25c',1,'FE_Q_iso_Q1::FE_Q_iso_Q1(const std::vector< Point< 1 > > &support_points)'],['../classFE__Q__iso__Q1.html',1,'FE_Q_iso_Q1< dim, spacedim >']]], - ['fe_5fq_5fiso_5fq1_2ecc_251',['fe_q_iso_q1.cc',['../fe__q__iso__q1_8cc.html',1,'']]], - ['fe_5fq_5fiso_5fq1_2eh_252',['fe_q_iso_q1.h',['../fe__q__iso__q1_8h.html',1,'']]], - ['fe_5frannacher_5fturek_2ecc_253',['fe_rannacher_turek.cc',['../fe__rannacher__turek_8cc.html',1,'']]], - ['fe_5frannacher_5fturek_2eh_254',['fe_rannacher_turek.h',['../fe__rannacher__turek_8h.html',1,'']]], - ['fe_5frannacherturek_255',['FE_RannacherTurek',['../classFE__RannacherTurek.html',1,'FE_RannacherTurek< dim >'],['../classFE__RannacherTurek.html#a8e9cb8c3884bef4e0f7e2364779eae34',1,'FE_RannacherTurek::FE_RannacherTurek()']]], - ['fe_5fraviart_5fthomas_2ecc_256',['fe_raviart_thomas.cc',['../fe__raviart__thomas_8cc.html',1,'']]], - ['fe_5fraviart_5fthomas_2eh_257',['fe_raviart_thomas.h',['../fe__raviart__thomas_8h.html',1,'']]], - ['fe_5fraviart_5fthomas_5fnodal_2ecc_258',['fe_raviart_thomas_nodal.cc',['../fe__raviart__thomas__nodal_8cc.html',1,'']]], - ['fe_5fraviartthomas_259',['FE_RaviartThomas',['../classFE__RaviartThomas.html#adc8e64d0cdb38af6e29dc9ac0279f121',1,'FE_RaviartThomas::FE_RaviartThomas(const unsigned int p)'],['../classFE__RaviartThomas.html#aae331958fb05a41f6a3443ddb1a2560b',1,'FE_RaviartThomas::FE_RaviartThomas()'],['../classFE__RaviartThomas.html',1,'FE_RaviartThomas< dim >']]], - ['fe_5fraviartthomasnodal_260',['FE_RaviartThomasNodal',['../classFE__RaviartThomasNodal.html',1,'FE_RaviartThomasNodal< dim >'],['../classFE__RaviartThomasNodal.html#afe1466e920ba3082fa9d176b1ef858b9',1,'FE_RaviartThomasNodal::FE_RaviartThomasNodal()']]], - ['fe_5frt_5fbubbles_261',['FE_RT_Bubbles',['../classFE__RT__Bubbles.html#a27cbd336ef9001c65ee0c3aec18f5805',1,'FE_RT_Bubbles::FE_RT_Bubbles()'],['../classFE__RT__Bubbles.html',1,'FE_RT_Bubbles< dim >']]], - ['fe_5frt_5fbubbles_2ecc_262',['fe_rt_bubbles.cc',['../fe__rt__bubbles_8cc.html',1,'']]], - ['fe_5frt_5fbubbles_2eh_263',['fe_rt_bubbles.h',['../fe__rt__bubbles_8h.html',1,'']]], - ['fe_5fseries_2ecc_264',['fe_series.cc',['../fe__series_8cc.html',1,'']]], - ['fe_5fseries_2eh_265',['fe_series.h',['../fe__series_8h.html',1,'']]], - ['fe_5fseries_5ffourier_2ecc_266',['fe_series_fourier.cc',['../fe__series__fourier_8cc.html',1,'']]], - ['fe_5fseries_5flegendre_2ecc_267',['fe_series_legendre.cc',['../fe__series__legendre_8cc.html',1,'']]], - ['fe_5fsets_268',['fe_sets',['../structColorEnriched_1_1Helper.html#a316f866677048f17a21f1ecb299f0db6',1,'ColorEnriched::Helper']]], - ['fe_5fsimplex_5fp_2ecc_269',['fe_simplex_p.cc',['../fe__simplex__p_8cc.html',1,'']]], - ['fe_5fsimplex_5fp_2eh_270',['fe_simplex_p.h',['../fe__simplex__p_8h.html',1,'']]], - ['fe_5fsimplex_5fp_5fbubbles_2ecc_271',['fe_simplex_p_bubbles.cc',['../fe__simplex__p__bubbles_8cc.html',1,'']]], - ['fe_5fsimplex_5fp_5fbubbles_2eh_272',['fe_simplex_p_bubbles.h',['../fe__simplex__p__bubbles_8h.html',1,'']]], - ['fe_5fsimplexdgp_273',['FE_SimplexDGP',['../classFE__SimplexDGP.html',1,'FE_SimplexDGP< dim, spacedim >'],['../classFE__SimplexDGP.html#a669fda85ea6f32fc81a255f7785a1bcc',1,'FE_SimplexDGP::FE_SimplexDGP()']]], - ['fe_5fsimplexp_274',['FE_SimplexP',['../classFE__SimplexP.html',1,'FE_SimplexP< dim, spacedim >'],['../classFE__SimplexP.html#a6fe3fe16c25df1b363786df1bb6de98c',1,'FE_SimplexP::FE_SimplexP()']]], - ['fe_5fsimplexp_5fbubbles_275',['FE_SimplexP_Bubbles',['../classFE__SimplexP__Bubbles.html',1,'FE_SimplexP_Bubbles< dim, spacedim >'],['../classFE__SimplexP__Bubbles.html#a29c2891e4afc45e1560e8c3c3d088ef8',1,'FE_SimplexP_Bubbles::FE_SimplexP_Bubbles()']]], - ['fe_5fsimplexpoly_276',['FE_SimplexPoly',['../classFE__SimplexPoly.html#a5793648e468d5d90e833e0ffc8b36f4f',1,'FE_SimplexPoly::FE_SimplexPoly()'],['../classFE__SimplexPoly.html',1,'FE_SimplexPoly< dim, spacedim >']]], - ['fe_5fsimplexpoly_3c_20dim_2c_20dim_20_3e_277',['FE_SimplexPoly< dim, dim >',['../classFE__SimplexPoly.html',1,'']]], - ['fe_5fsubface_5fvalues_278',['fe_subface_values',['../classMeshWorker_1_1ScratchData.html#af60a5f4083d426430fa98c5d443ca63b',1,'MeshWorker::ScratchData']]], - ['fe_5fsystem_279',['fe_system',['../classFE__Enriched.html#aff941ea5b3cde27dee4dd9ddf458df7a',1,'FE_Enriched']]], - ['fe_5fsystem_2ecc_280',['fe_system.cc',['../fe__system_8cc.html',1,'']]], - ['fe_5fsystem_2eh_281',['fe_system.h',['../fe__system_8h.html',1,'']]], - ['fe_5fto_5freal_282',['fe_to_real',['../classMappingFEField.html#a0c43c059ea8cccbed3931b20f7a10696',1,'MappingFEField']]], - ['fe_5ftools_2ecc_283',['fe_tools.cc',['../fe__tools_8cc.html',1,'']]], - ['fe_5ftools_2eh_284',['fe_tools.h',['../fe__tools_8h.html',1,'']]], - ['fe_5ftools_5fextrapolate_285',['fe_tools_extrapolate',['../namespaceUtilities_1_1MPI_1_1internal_1_1Tags.html#a1c190e50dabbd9b60e230b843c6caa44a7128ae2e97c120a30d7e67922460b27e',1,'Utilities::MPI::internal::Tags']]], - ['fe_5ftools_5fextrapolate_2ecc_286',['fe_tools_extrapolate.cc',['../fe__tools__extrapolate_8cc.html',1,'']]], - ['fe_5ftools_5fextrapolate_5fend_287',['fe_tools_extrapolate_end',['../namespaceUtilities_1_1MPI_1_1internal_1_1Tags.html#a1c190e50dabbd9b60e230b843c6caa44a78dd601ba3a7657c91d0b8413a18f558',1,'Utilities::MPI::internal::Tags']]], - ['fe_5ftools_5finterpolate_2ecc_288',['fe_tools_interpolate.cc',['../fe__tools__interpolate_8cc.html',1,'']]], - ['fe_5ftrace_2ecc_289',['fe_trace.cc',['../fe__trace_8cc.html',1,'']]], - ['fe_5ftrace_2eh_290',['fe_trace.h',['../fe__trace_8h.html',1,'']]], - ['fe_5ftraceq_291',['FE_TraceQ',['../classFE__TraceQ.html',1,'FE_TraceQ< dim, spacedim >'],['../classFE__TraceQ.html#aece0869ab7f5c84faae9e7b0b8598370',1,'FE_TraceQ::FE_TraceQ()'],['../classFE__TraceQ_3_011_00_01spacedim_01_4.html#ab0cbe36ef1cc93a46049c9ba28687838',1,'FE_TraceQ< 1, spacedim >::FE_TraceQ()']]], - ['fe_5ftraceq_3c_201_2c_20spacedim_20_3e_292',['FE_TraceQ< 1, spacedim >',['../classFE__TraceQ_3_011_00_01spacedim_01_4.html',1,'']]], - ['fe_5fupdate_5fflags_2eh_293',['fe_update_flags.h',['../fe__update__flags_8h.html',1,'']]], - ['fe_5fvalues_294',['fe_values',['../classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html#ac862a820ea9acc504e988c49d40f077e',1,'internal::MatrixFreeFunctions::MappingDataOnTheFly::fe_values()'],['../classMeshWorker_1_1IntegrationInfo.html#a1bc001a6c78e81ebefd105288f239c16',1,'MeshWorker::IntegrationInfo::fe_values()'],['../classMeshWorker_1_1ScratchData.html#a4a71e4edb4ba4ea635d7be256247d854',1,'MeshWorker::ScratchData::fe_values()'],['../classMeshWorker_1_1IntegrationInfo.html#a32fa7363be71ba320bcdc94f6d677843',1,'MeshWorker::IntegrationInfo::fe_values()'],['../classFEPointEvaluation.html#ad5a23c127688e0d2503fe37e26bf3df7',1,'FEPointEvaluation::fe_values()'],['../classGridTools_1_1MarchingCubeAlgorithm.html#a37fee30886e4c5727cf82f2c99ddd1fc',1,'GridTools::MarchingCubeAlgorithm::fe_values()'],['../classMappingQEulerian.html#a04443806065969209c5ab1348b6b04ee',1,'MappingQEulerian::fe_values()'],['../classMappingFEField.html#af779241e66a9b294590887f424e20991',1,'MappingFEField::fe_values()'],['../classFEValuesViews_1_1Tensor_3_012_00_01dim_00_01spacedim_01_4.html#a4834167e1b51028d5b300ce3defc2833',1,'FEValuesViews::Tensor< 2, dim, spacedim >::fe_values()'],['../classFEValuesViews_1_1SymmetricTensor_3_012_00_01dim_00_01spacedim_01_4.html#a83b50003df5a105bb6dff25ff13df052',1,'FEValuesViews::SymmetricTensor< 2, dim, spacedim >::fe_values()'],['../classFEValuesViews_1_1Vector.html#a4cb1df386dd20b952d75e257a46a63e5',1,'FEValuesViews::Vector::fe_values()'],['../classFEValuesViews_1_1Scalar.html#aa2b062760a643f967bda6c6f540422dc',1,'FEValuesViews::Scalar::fe_values()']]], - ['fe_5fvalues_2ecc_295',['fe_values.cc',['../fe_2fe__values_8cc.html',1,'(Global Namespace)'],['../hp_2fe__values_8cc.html',1,'(Global Namespace)'],['../non__matching_2fe__values_8cc.html',1,'(Global Namespace)']]], - ['fe_5fvalues_2eh_296',['fe_values.h',['../hp_2fe__values_8h.html',1,'(Global Namespace)'],['../non__matching_2fe__values_8h.html',1,'(Global Namespace)'],['../fe_2fe__values_8h.html',1,'(Global Namespace)']]], - ['fe_5fvalues_5fextractors_2ecc_297',['fe_values_extractors.cc',['../fe__values__extractors_8cc.html',1,'']]], - ['fe_5fvalues_5fextractors_2eh_298',['fe_values_extractors.h',['../fe__values__extractors_8h.html',1,'']]], - ['fe_5fvalues_5finside_299',['fe_values_inside',['../classNonMatching_1_1FEValues.html#ae834e212add93e7680ee972806cbff60',1,'NonMatching::FEValues::fe_values_inside()'],['../classNonMatching_1_1FEInterfaceValues.html#a539e909abd7fb17731a696f76d38bc7e',1,'NonMatching::FEInterfaceValues::fe_values_inside()']]], - ['fe_5fvalues_5finside_5ffull_5fquadrature_300',['fe_values_inside_full_quadrature',['../classNonMatching_1_1FEInterfaceValues.html#a33a8158018b295759fa4b1e53eafe3ac',1,'NonMatching::FEInterfaceValues::fe_values_inside_full_quadrature()'],['../classNonMatching_1_1FEValues.html#a061fa6b29582c606a7ba0c9da160266c',1,'NonMatching::FEValues::fe_values_inside_full_quadrature()']]], - ['fe_5fvalues_5finst2_2ecc_301',['fe_values_inst2.cc',['../fe__values__inst2_8cc.html',1,'']]], - ['fe_5fvalues_5finst3_2ecc_302',['fe_values_inst3.cc',['../fe__values__inst3_8cc.html',1,'']]], - ['fe_5fvalues_5finst4_2ecc_303',['fe_values_inst4.cc',['../fe__values__inst4_8cc.html',1,'']]], - ['fe_5fvalues_5finst5_2ecc_304',['fe_values_inst5.cc',['../fe__values__inst5_8cc.html',1,'']]], - ['fe_5fvalues_5finst6_2ecc_305',['fe_values_inst6.cc',['../fe__values__inst6_8cc.html',1,'']]], - ['fe_5fvalues_5fmutex_306',['fe_values_mutex',['../classMappingQEulerian.html#a6afedf25e37bf90c28d883739f5ce994',1,'MappingQEulerian::fe_values_mutex()'],['../classMappingFEField.html#ac8f484f4d29e88848a8f2d29e98e2e15',1,'MappingFEField::fe_values_mutex()']]], - ['fe_5fvalues_5foutside_307',['fe_values_outside',['../classNonMatching_1_1FEInterfaceValues.html#aa661d21c9c6ee422daa31b5d7a722625',1,'NonMatching::FEInterfaceValues::fe_values_outside()'],['../classNonMatching_1_1FEValues.html#aa5778beccc9ffc6d098fa6c878ae0138',1,'NonMatching::FEValues::fe_values_outside()']]], - ['fe_5fvalues_5foutside_5ffull_5fquadrature_308',['fe_values_outside_full_quadrature',['../classNonMatching_1_1FEInterfaceValues.html#a5ac674ff16f2ff3e42384a16e515a974',1,'NonMatching::FEInterfaceValues::fe_values_outside_full_quadrature()'],['../classNonMatching_1_1FEValues.html#a53cbfd4863a963a2befda0ad0d9c85b4',1,'NonMatching::FEValues::fe_values_outside_full_quadrature()']]], - ['fe_5fvalues_5fsurface_309',['fe_values_surface',['../classNonMatching_1_1FEValues.html#a91fa51b9ad2caca9ee7422e943ff292c',1,'NonMatching::FEValues']]], - ['fe_5fvalues_5ftable_310',['fe_values_table',['../classhp_1_1FEValuesBase.html#ab0c9630e18577d7dea2130e9ee51f36a',1,'hp::FEValuesBase']]], - ['fe_5fvalues_5fviews_5fcache_311',['fe_values_views_cache',['../classFEValuesBase.html#a22ef3bdf25af1cc1b3299556533da667',1,'FEValuesBase']]], - ['fe_5fvs_5fmapping_5fvs_5ffevalues_2eh_312',['fe_vs_mapping_vs_fevalues.h',['../fe__vs__mapping__vs__fevalues_8h.html',1,'']]], - ['fe_5fwedge_5fp_2ecc_313',['fe_wedge_p.cc',['../fe__wedge__p_8cc.html',1,'']]], - ['fe_5fwedge_5fp_2eh_314',['fe_wedge_p.h',['../fe__wedge__p_8h.html',1,'']]], - ['fe_5fwedgedgp_315',['FE_WedgeDGP',['../classFE__WedgeDGP.html',1,'FE_WedgeDGP< dim, spacedim >'],['../classFE__WedgeDGP.html#adc02bdf588283c6e94e961e66ae1994c',1,'FE_WedgeDGP::FE_WedgeDGP()']]], - ['fe_5fwedgep_316',['FE_WedgeP',['../classFE__WedgeP.html#a822f9cc00406c6f6012001073715525b',1,'FE_WedgeP::FE_WedgeP()'],['../classFE__WedgeP.html',1,'FE_WedgeP< dim, spacedim >']]], - ['fe_5fwedgepoly_317',['FE_WedgePoly',['../classFE__WedgePoly.html#a8550c7936f48a510dba374c127e39c09',1,'FE_WedgePoly::FE_WedgePoly()'],['../classFE__WedgePoly.html',1,'FE_WedgePoly< dim, spacedim >']]], - ['fe_5fwedgepoly_3c_20dim_2c_20dim_20_3e_318',['FE_WedgePoly< dim, dim >',['../classFE__WedgePoly.html',1,'']]], - ['fecollection_319',['FECollection',['../classhp_1_1FECollection.html#a19007fa91f9d36582dced84c5da191b1',1,'hp::FECollection::FECollection(const std::vector< const FiniteElement< dim, spacedim > * > &fes)'],['../classhp_1_1FECollection.html#ad8f7b4ccf64ce616f22e046fabd215e6',1,'hp::FECollection::FECollection(const FECollection< dim, spacedim > &)=default'],['../classhp_1_1FECollection.html#af94bc4d5c944da27c3e0189cd92e979c',1,'hp::FECollection::FECollection()'],['../classhp_1_1FECollection.html#a6b557e20b5abc09c7be5158c3f034955',1,'hp::FECollection::FECollection(const FiniteElement< dim, spacedim > &fe)'],['../classhp_1_1FECollection.html#a451b4589792e0b1d3f4f2c2a80831c1f',1,'hp::FECollection::FECollection(const FETypes &...fes)'],['../classhp_1_1FECollection.html#a94e1d345ab26a5276b64ae8d8adf764b',1,'hp::FECollection::FECollection(FECollection< dim, spacedim > &&) noexcept(std::is_nothrow_move_constructible< std::vector< std::shared_ptr< const FiniteElement< dim, spacedim > > > >::value &&std::is_nothrow_move_constructible< std::function< unsigned int(const typename hp::FECollection< dim, spacedim > &, const unsigned int)> >::value)=default'],['../classhp_1_1FECollection.html',1,'hp::FECollection< dim, spacedim >']]], - ['fecollection_3c_20dim_2c_20dim_20_3e_320',['FECollection< dim, dim >',['../classhp_1_1FECollection.html',1,'hp']]], - ['fecollection_3c_20dim_2c_20fevaluestype_3a_3aspace_5fdimension_20_3e_321',['FECollection< dim, FEValuesType::space_dimension >',['../classhp_1_1FECollection.html',1,'hp']]], - ['fecollection_3c_20dim_2c_20spacedim_20_3e_322',['FECollection< dim, spacedim >',['../classhp_1_1FECollection.html',1,'hp']]], - ['feevaluation_323',['FEEvaluation',['../classCUDAWrappers_1_1FEEvaluation.html',1,'CUDAWrappers::FEEvaluation< dim, fe_degree, n_q_points_1d, n_components_, Number >'],['../classFEEvaluation.html#a06293ee7aac4f62c80be6862aa1ae101',1,'FEEvaluation::FEEvaluation()'],['../classFEEvaluationData.html#a23897beb0abef628653e437d6cb69f8a',1,'FEEvaluationData::FEEvaluation()'],['../classCUDAWrappers_1_1FEEvaluation.html#a2bb4edef80927ee611573eca1772da77',1,'CUDAWrappers::FEEvaluation::FEEvaluation()'],['../classFEEvaluation.html#ade40e452949cbefd4f7e6d5580af81c8',1,'FEEvaluation::FEEvaluation(const MatrixFree< dim, Number, VectorizedArrayType > &matrix_free, const unsigned int dof_no=0, const unsigned int quad_no=0, const unsigned int first_selected_component=0, const unsigned int active_fe_index=numbers::invalid_unsigned_int, const unsigned int active_quad_index=numbers::invalid_unsigned_int)'],['../classFEEvaluation.html#a1b0dc3f17c28f2db5fd4237b1bf04342',1,'FEEvaluation::FEEvaluation(const Mapping< dim > &mapping, const FiniteElement< dim > &fe, const Quadrature< 1 > &quadrature, const UpdateFlags update_flags, const unsigned int first_selected_component=0)'],['../classFEEvaluation.html#a43079434f0a4acc8907e7a6b2d9b541f',1,'FEEvaluation::FEEvaluation(const FiniteElement< dim > &fe, const Quadrature< 1 > &quadrature, const UpdateFlags update_flags, const unsigned int first_selected_component=0)'],['../classFEEvaluation.html#a5f2f32070ca17d5e9ad58b8f75ff608f',1,'FEEvaluation::FEEvaluation(const FiniteElement< dim > &fe, const FEEvaluationData< dim, VectorizedArrayType, false > &other, const unsigned int first_selected_component=0)'],['../classFEEvaluation.html#ae94191b8afd866e461d5ea241d59548d',1,'FEEvaluation::FEEvaluation(const FEEvaluation &other)'],['../classFEEvaluation.html',1,'FEEvaluation< dim, fe_degree, n_q_points_1d, n_components_, Number, VectorizedArrayType >']]], - ['feevaluationaccess_324',['FEEvaluationAccess',['../classFEEvaluationAccess_3_01dim_00_01dim_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html#a2af9de080cbb0668ddd9023adbd951c0',1,'FEEvaluationAccess< dim, dim, Number, is_face, VectorizedArrayType >::FEEvaluationAccess()'],['../classFEEvaluationAccess_3_01dim_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html#a8ad17777ee5435789c40a2fee19ff855',1,'FEEvaluationAccess< dim, 1, Number, is_face, VectorizedArrayType >::FEEvaluationAccess()'],['../classFEEvaluationAccess_3_01dim_00_01dim_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html#a1e00264f354972125c87cbed620aed20',1,'FEEvaluationAccess< dim, dim, Number, is_face, VectorizedArrayType >::FEEvaluationAccess()'],['../classFEEvaluationAccess.html',1,'FEEvaluationAccess< dim, n_components_, Number, is_face, VectorizedArrayType >'],['../classFEEvaluationAccess_3_011_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html#ae34681906d2b628676857c84f7b3c7a1',1,'FEEvaluationAccess< 1, 1, Number, is_face, VectorizedArrayType >::FEEvaluationAccess()'],['../classFEEvaluationAccess_3_01dim_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html#a60f73240dedb649ffbf0290120855e5f',1,'FEEvaluationAccess< dim, 1, Number, is_face, VectorizedArrayType >::FEEvaluationAccess(const MatrixFree< dim, Number, VectorizedArrayType > &matrix_free, const unsigned int dof_no, const unsigned int first_selected_component, const unsigned int quad_no, const unsigned int fe_degree, const unsigned int n_q_points, const bool is_interior_face=true, const unsigned int active_fe_index=numbers::invalid_unsigned_int, const unsigned int active_quad_index=numbers::invalid_unsigned_int, const unsigned int face_type=numbers::invalid_unsigned_int)'],['../classFEEvaluationAccess_3_01dim_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html#a52bcd8e3a8e6fed428b9fdb78183c2ef',1,'FEEvaluationAccess< dim, 1, Number, is_face, VectorizedArrayType >::FEEvaluationAccess(const FEEvaluationAccess &other)'],['../classFEEvaluationAccess.html#ad3e5c743c4ed762d16b012a9e3ad5f5f',1,'FEEvaluationAccess::FEEvaluationAccess(const FEEvaluationAccess &other)'],['../classFEEvaluationAccess.html#a3d48e356bca3b522fbe619ec32eb091e',1,'FEEvaluationAccess::FEEvaluationAccess(const Mapping< dim > &mapping, const FiniteElement< dim > &fe, const Quadrature< 1 > &quadrature, const UpdateFlags update_flags, const unsigned int first_selected_component, const FEEvaluationData< dim, VectorizedArrayType, is_face > *other)'],['../classFEEvaluationAccess.html#abc1acf6880266c78ec59c7d94b1819d0',1,'FEEvaluationAccess::FEEvaluationAccess(const MatrixFree< dim, Number, VectorizedArrayType > &matrix_free, const unsigned int dof_no, const unsigned int first_selected_component, const unsigned int quad_no, const unsigned int fe_degree, const unsigned int n_q_points, const bool is_interior_face=true, const unsigned int active_fe_index=numbers::invalid_unsigned_int, const unsigned int active_quad_index=numbers::invalid_unsigned_int, const unsigned int face_type=numbers::invalid_unsigned_int)'],['../classFEEvaluationAccess_3_011_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html#a12f5729c4e4fb2142b2655473472abac',1,'FEEvaluationAccess< 1, 1, Number, is_face, VectorizedArrayType >::FEEvaluationAccess(const FEEvaluationAccess &other)'],['../classFEEvaluationAccess_3_011_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html#ad75696e0361acf802b7d5b4bf3550a24',1,'FEEvaluationAccess< 1, 1, Number, is_face, VectorizedArrayType >::FEEvaluationAccess(const Mapping< 1 > &mapping, const FiniteElement< 1 > &fe, const Quadrature< 1 > &quadrature, const UpdateFlags update_flags, const unsigned int first_selected_component, const FEEvaluationData< 1, VectorizedArrayType, is_face > *other)'],['../classFEEvaluationAccess_3_01dim_00_01dim_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html#a5c8a5edbda60acb19b381f55a0a2a1d7',1,'FEEvaluationAccess< dim, dim, Number, is_face, VectorizedArrayType >::FEEvaluationAccess()']]], - ['feevaluationaccess_3c_201_2c_201_2c_20number_2c_20is_5fface_2c_20vectorizedarraytype_20_3e_325',['FEEvaluationAccess< 1, 1, Number, is_face, VectorizedArrayType >',['../classFEEvaluationAccess_3_011_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html',1,'']]], - ['feevaluationaccess_3c_20dim_2c_201_2c_20double_2c_20true_2c_20vectorizedarray_3c_20double_20_3e_20_3e_326',['FEEvaluationAccess< dim, 1, double, true, VectorizedArray< double > >',['../classFEEvaluationAccess.html',1,'']]], - ['feevaluationaccess_3c_20dim_2c_201_2c_20number_2c_20is_5fface_2c_20vectorizedarraytype_20_3e_327',['FEEvaluationAccess< dim, 1, Number, is_face, VectorizedArrayType >',['../classFEEvaluationAccess_3_01dim_00_011_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html',1,'']]], - ['feevaluationaccess_3c_20dim_2c_20dim_2c_20number_2c_20is_5fface_2c_20vectorizedarraytype_20_3e_328',['FEEvaluationAccess< dim, dim, Number, is_face, VectorizedArrayType >',['../classFEEvaluationAccess_3_01dim_00_01dim_00_01Number_00_01is__face_00_01VectorizedArrayType_01_4.html',1,'']]], - ['feevaluationaccess_3c_20dim_2c_20n_5fcomponents_5f_2c_20number_2c_20false_2c_20vectorizedarraytype_20_3e_329',['FEEvaluationAccess< dim, n_components_, Number, false, VectorizedArrayType >',['../classFEEvaluationAccess.html',1,'']]], - ['feevaluationbase_330',['FEEvaluationBase',['../classFEEvaluationBase.html#a913a638fc51bf06284b2ec0e2ef4eecf',1,'FEEvaluationBase::FEEvaluationBase(const Mapping< dim > &mapping, const FiniteElement< dim > &fe, const Quadrature< 1 > &quadrature, const UpdateFlags update_flags, const unsigned int first_selected_component, const FEEvaluationData< dim, VectorizedArrayType, is_face > *other)'],['../classFEEvaluationBase.html#adc4401003cd075b72f8b308defb2aa8b',1,'FEEvaluationBase::FEEvaluationBase(const FEEvaluationBase &other)'],['../classFEEvaluationBase.html#ad5a4f965f1159ecfdcac3b73d0757c63',1,'FEEvaluationBase::FEEvaluationBase(const MatrixFree< dim, Number, VectorizedArrayType > &matrix_free, const unsigned int dof_no, const unsigned int first_selected_component, const unsigned int quad_no, const unsigned int fe_degree, const unsigned int n_q_points, const bool is_interior_face, const unsigned int active_fe_index, const unsigned int active_quad_index, const unsigned int face_type)'],['../classFEEvaluationData.html#a88f812ed680748c1e386337a68677d8c',1,'FEEvaluationData::FEEvaluationBase()'],['../classFEEvaluationBase.html',1,'FEEvaluationBase< dim, n_components_, Number, is_face, VectorizedArrayType >']]], - ['feevaluationbase_3c_201_2c_201_2c_20number_2c_20is_5fface_2c_20vectorizedarraytype_20_3e_331',['FEEvaluationBase< 1, 1, Number, is_face, VectorizedArrayType >',['../classFEEvaluationBase.html',1,'']]], - ['feevaluationbase_3c_20dim_2c_201_2c_20double_2c_20false_2c_20vectorizedarray_3c_20double_20_3e_20_3e_332',['FEEvaluationBase< dim, 1, double, false, VectorizedArray< double > >',['../classFEEvaluationBase.html',1,'']]], - ['feevaluationbase_3c_20dim_2c_201_2c_20number_2c_20is_5fface_2c_20vectorizedarraytype_20_3e_333',['FEEvaluationBase< dim, 1, Number, is_face, VectorizedArrayType >',['../classFEEvaluationBase.html',1,'']]], - ['feevaluationbase_3c_20dim_2c_20dim_2c_20number_2c_20is_5fface_2c_20vectorizedarraytype_20_3e_334',['FEEvaluationBase< dim, dim, Number, is_face, VectorizedArrayType >',['../classFEEvaluationBase.html',1,'']]], - ['feevaluationbase_3c_20dim_2c_20n_5fcomponents_5f_2c_20double_2c_20is_5fface_2c_20vectorizedarray_3c_20double_20_3e_20_3e_335',['FEEvaluationBase< dim, n_components_, double, is_face, VectorizedArray< double > >',['../classFEEvaluationBase.html',1,'']]], - ['feevaluationbase_3c_20dim_2c_20n_5fcomponents_5f_2c_20number_2c_20is_5fface_2c_20vectorizedarray_3c_20number_20_3e_20_3e_336',['FEEvaluationBase< dim, n_components_, Number, is_face, VectorizedArray< Number > >',['../classFEEvaluationBase.html',1,'']]], - ['feevaluationbasedata_337',['FEEvaluationBaseData',['../fe__evaluation__data_8h.html#aa2d0940ddee5d91ec68fd27e2cb84320',1,'fe_evaluation_data.h']]], - ['feevaluationdata_338',['FEEvaluationData',['../classFEEvaluationData.html',1,'FEEvaluationData< dim, Number, is_face >'],['../classFEEvaluationData.html#abdc68bdb2a7546fa8362823697beb0dd',1,'FEEvaluationData::FEEvaluationData(const std::shared_ptr< internal::MatrixFreeFunctions::MappingDataOnTheFly< dim, Number > > &mapping_data, const unsigned int n_fe_components, const unsigned int first_selected_component)'],['../classFEEvaluationData.html#ae428f4fc00212ee84f29946be8d43b8f',1,'FEEvaluationData::FEEvaluationData(const InitializationData &initialization_data, const bool is_interior_face, const unsigned int quad_no, const unsigned int first_selected_component)'],['../classFEEvaluationData.html#a342c8e490d3dc4eb35fa8f13f4f178fd',1,'FEEvaluationData::FEEvaluationData(const FEEvaluationData &other)=default'],['../classFEEvaluationData.html#ac52ce729b40fb062d0e8ab6bc9b64039',1,'FEEvaluationData::FEEvaluationData(const ShapeInfoType &shape_info, const bool is_interior_face=true)']]], - ['feevaluationdata_3c_20dim_2c_20vectorizedarray_3c_20double_20_3e_2c_20is_5fface_20_3e_339',['FEEvaluationData< dim, VectorizedArray< double >, is_face >',['../classFEEvaluationData.html',1,'']]], - ['feevaluationdata_3c_20dim_2c_20vectorizedarray_3c_20number_20_3e_2c_20is_5fface_20_3e_340',['FEEvaluationData< dim, VectorizedArray< Number >, is_face >',['../classFEEvaluationData.html',1,'']]], - ['feevaluationdata_3c_20dim_2c_20vectorizedarraytype_2c_20is_5fface_20_3e_341',['FEEvaluationData< dim, VectorizedArrayType, is_face >',['../classFEEvaluationData.html',1,'']]], - ['feevaluationfactory_342',['FEEvaluationFactory',['../structinternal_1_1FEEvaluationFactory.html',1,'internal']]], - ['feevaluationhangingnodesfactory_343',['FEEvaluationHangingNodesFactory',['../structinternal_1_1FEEvaluationHangingNodesFactory.html',1,'internal']]], - ['feevaluationimpl_344',['FEEvaluationImpl',['../structinternal_1_1FEEvaluationImpl.html',1,'internal']]], - ['feevaluationimpl_3c_20matrixfreefunctions_3a_3atensor_5fnone_2c_20dim_2c_20fe_5fdegree_2c_20n_5fq_5fpoints_5f1d_2c_20number_20_3e_345',['FEEvaluationImpl< MatrixFreeFunctions::tensor_none, dim, fe_degree, n_q_points_1d, Number >',['../structinternal_1_1FEEvaluationImpl_3_01MatrixFreeFunctions_1_1tensor__none_00_01dim_00_01fe__deg6a6536f4027b362e81e07ce933d2208d.html',1,'internal']]], - ['feevaluationimpl_3c_20matrixfreefunctions_3a_3atensor_5fraviart_5fthomas_2c_20dim_2c_20fe_5fdegree_2c_20n_5fq_5fpoints_5f1d_2c_20number_20_3e_346',['FEEvaluationImpl< MatrixFreeFunctions::tensor_raviart_thomas, dim, fe_degree, n_q_points_1d, Number >',['../structinternal_1_1FEEvaluationImpl_3_01MatrixFreeFunctions_1_1tensor__raviart__thomas_00_01dim_083641d0d7a8be0c8c46c0e6d946a598b.html',1,'internal']]], - ['feevaluationimplbasischange_347',['FEEvaluationImplBasisChange',['../structinternal_1_1FEEvaluationImplBasisChange.html',1,'internal']]], - ['feevaluationimplcollocation_348',['FEEvaluationImplCollocation',['../structinternal_1_1FEEvaluationImplCollocation.html',1,'internal']]], - ['feevaluationimplhangingnodes_349',['FEEvaluationImplHangingNodes',['../structinternal_1_1FEEvaluationImplHangingNodes.html',1,'internal']]], - ['feevaluationimplhangingnodesrunner_350',['FEEvaluationImplHangingNodesRunner',['../classinternal_1_1FEEvaluationImplHangingNodesRunner.html',1,'internal']]], - ['feevaluationimplhangingnodesrunner_3c_20feevaluationimplhangingnodesrunnertypes_3a_3ascalar_2c_20dim_2c_20fe_5fdegree_2c_20number_20_3e_351',['FEEvaluationImplHangingNodesRunner< FEEvaluationImplHangingNodesRunnerTypes::scalar, dim, fe_degree, Number >',['../classinternal_1_1FEEvaluationImplHangingNodesRunner_3_01FEEvaluationImplHangingNodesRunnerTypes_00966c5775d96ae2fc40b13af2d17791.html',1,'internal']]], - ['feevaluationimplhangingnodesrunner_3c_20feevaluationimplhangingnodesrunnertypes_3a_3avectorized_2c_20dim_2c_20fe_5fdegree_2c_20number_20_3e_352',['FEEvaluationImplHangingNodesRunner< FEEvaluationImplHangingNodesRunnerTypes::vectorized, dim, fe_degree, Number >',['../classinternal_1_1FEEvaluationImplHangingNodesRunner_3_01FEEvaluationImplHangingNodesRunnerTypes_c1031c798c74e42da3548d1dbac7fe26.html',1,'internal']]], - ['feevaluationimplhangingnodesrunnertypes_353',['FEEvaluationImplHangingNodesRunnerTypes',['../namespaceinternal.html#ada777fe0783c39ba1d4ca2aa043b7261',1,'internal']]], - ['feevaluationimplselector_354',['FEEvaluationImplSelector',['../structinternal_1_1FEEvaluationImplSelector.html',1,'internal']]], - ['feevaluationimpltransformtocollocation_355',['FEEvaluationImplTransformToCollocation',['../structinternal_1_1FEEvaluationImplTransformToCollocation.html',1,'internal']]], - ['fefaceevaluation_356',['FEFaceEvaluation',['../classFEFaceEvaluation.html#a9fedfdec25287e183f1fb3d625a08cd6',1,'FEFaceEvaluation::FEFaceEvaluation(const MatrixFree< dim, Number, VectorizedArrayType > &matrix_free, const std::pair< unsigned int, unsigned int > &range, const bool is_interior_face=true, const unsigned int dof_no=0, const unsigned int quad_no=0, const unsigned int first_selected_component=0)'],['../classFEFaceEvaluation.html#acdaaf051d3f8f8ada47520efb0811acb',1,'FEFaceEvaluation::FEFaceEvaluation(const MatrixFree< dim, Number, VectorizedArrayType > &matrix_free, const bool is_interior_face=true, const unsigned int dof_no=0, const unsigned int quad_no=0, const unsigned int first_selected_component=0, const unsigned int active_fe_index=numbers::invalid_unsigned_int, const unsigned int active_quad_index=numbers::invalid_unsigned_int, const unsigned int face_type=numbers::invalid_unsigned_int)'],['../classFEFaceEvaluation.html',1,'FEFaceEvaluation< dim, fe_degree, n_q_points_1d, n_components_, Number, VectorizedArrayType >']]], - ['fefaceevaluationfactory_357',['FEFaceEvaluationFactory',['../structinternal_1_1FEFaceEvaluationFactory.html',1,'internal']]], - ['fefaceevaluationgatherfactory_358',['FEFaceEvaluationGatherFactory',['../structinternal_1_1FEFaceEvaluationGatherFactory.html',1,'internal']]], - ['fefaceevaluationimpl_359',['FEFaceEvaluationImpl',['../structinternal_1_1FEFaceEvaluationImpl.html',1,'internal']]], - ['fefaceevaluationimplevaluateselector_360',['FEFaceEvaluationImplEvaluateSelector',['../structinternal_1_1FEFaceEvaluationImplEvaluateSelector.html',1,'internal']]], - ['fefaceevaluationimplgatherevaluateselector_361',['FEFaceEvaluationImplGatherEvaluateSelector',['../structinternal_1_1FEFaceEvaluationImplGatherEvaluateSelector.html',1,'internal']]], - ['fefaceevaluationimplintegratescatterselector_362',['FEFaceEvaluationImplIntegrateScatterSelector',['../structinternal_1_1FEFaceEvaluationImplIntegrateScatterSelector.html',1,'internal']]], - ['fefaceevaluationimplintegrateselector_363',['FEFaceEvaluationImplIntegrateSelector',['../structinternal_1_1FEFaceEvaluationImplIntegrateSelector.html',1,'internal']]], - ['fefaceevaluationimplraviartthomas_364',['FEFaceEvaluationImplRaviartThomas',['../structinternal_1_1FEFaceEvaluationImplRaviartThomas.html',1,'internal']]], - ['fefacenormalevaluationimpl_365',['FEFaceNormalEvaluationImpl',['../structinternal_1_1FEFaceNormalEvaluationImpl.html',1,'internal']]], - ['fefacevalues_366',['FEFaceValues',['../classhp_1_1FEFaceValues.html#aece25ce3af0dbb63e08d9e74b947cc6b',1,'hp::FEFaceValues::FEFaceValues(const hp::MappingCollection< dim, spacedim > &mapping_collection, const hp::FECollection< dim, spacedim > &fe_collection, const std::vector< hp::QCollection< dim - 1 > > &q_collections, const UpdateFlags update_flags)'],['../classhp_1_1FEFaceValues.html#a04201d625edfd550cdc20e6ae2c674a0',1,'hp::FEFaceValues::FEFaceValues(const hp::FECollection< dim, spacedim > &fe_collection, const hp::QCollection< dim - 1 > &q_collection, const UpdateFlags update_flags)'],['../classhp_1_1FEFaceValues.html#a00504071c19f8e3b018317f7b40844b2',1,'hp::FEFaceValues::FEFaceValues(const hp::FECollection< dim, spacedim > &fe_collection, const std::vector< hp::QCollection< dim - 1 > > &q_collections, const UpdateFlags update_flags)'],['../classhp_1_1FEFaceValues.html#ace56530911651f0f28ba00ffd89c945c',1,'hp::FEFaceValues::FEFaceValues(const hp::MappingCollection< dim, spacedim > &mapping_collection, const hp::FECollection< dim, spacedim > &fe_collection, const hp::QCollection< dim - 1 > &q_collection, const UpdateFlags update_flags)'],['../classFEFaceValues.html#af2ab8538308210d688aed98079137fa7',1,'FEFaceValues::FEFaceValues(const FiniteElement< dim, spacedim > &fe, const hp::QCollection< dim - 1 > &quadrature, const UpdateFlags update_flags)'],['../classFEFaceValues.html#aed42896401c2891bb1035fe75ee8459a',1,'FEFaceValues::FEFaceValues(const Mapping< dim, spacedim > &mapping, const FiniteElement< dim, spacedim > &fe, const hp::QCollection< dim - 1 > &quadrature, const UpdateFlags update_flags)'],['../classFEFaceValues.html#abcfcb8ef81bb6f01c4b287f31526d953',1,'FEFaceValues::FEFaceValues(const Mapping< dim, spacedim > &mapping, const FiniteElement< dim, spacedim > &fe, const Quadrature< dim - 1 > &quadrature, const UpdateFlags update_flags)'],['../classFEFaceValues.html#a6ce740654d9732d36af87cd0eedc19be',1,'FEFaceValues::FEFaceValues(const FiniteElement< dim, spacedim > &fe, const Quadrature< dim - 1 > &quadrature, const UpdateFlags update_flags)'],['../classFEFaceValues.html',1,'FEFaceValues< dim, spacedim >'],['../classhp_1_1FEFaceValues.html',1,'hp::FEFaceValues< dim, spacedim >']]], - ['fefacevalues_3c_20dim_2c_20dim_20_3e_367',['FEFaceValues< dim, dim >',['../classFEFaceValues.html',1,'']]], - ['fefacevalues_3c_20dim_2c_20spacedim_20_3e_368',['FEFaceValues< dim, spacedim >',['../classFEFaceValues.html',1,'FEFaceValues< dim, spacedim >'],['../classFiniteElement.html#a65a2ae7b2d193590c89e5a5f23d31f81',1,'FiniteElement::FEFaceValues< dim, spacedim >()'],['../classMapping.html#a65a2ae7b2d193590c89e5a5f23d31f81',1,'Mapping::FEFaceValues< dim, spacedim >()']]], - ['fefacevaluesbase_369',['FEFaceValuesBase',['../classFEFaceValuesBase.html',1,'FEFaceValuesBase< dim, spacedim >'],['../classFEFaceValuesBase.html#ac4c2a4d2146f80654a710f0407616912',1,'FEFaceValuesBase::FEFaceValuesBase(const unsigned int dofs_per_cell, const UpdateFlags update_flags, const Mapping< dim, spacedim > &mapping, const FiniteElement< dim, spacedim > &fe, const Quadrature< dim - 1 > &quadrature)'],['../classFEFaceValuesBase.html#aba75d5c7d31b92a8c1cd23a591adf930',1,'FEFaceValuesBase::FEFaceValuesBase(const unsigned int dofs_per_cell, const UpdateFlags update_flags, const Mapping< dim, spacedim > &mapping, const FiniteElement< dim, spacedim > &fe, const hp::QCollection< dim - 1 > &quadrature)']]], - ['fefacevaluesbase_3c_20dim_2c_20dim_20_3e_370',['FEFaceValuesBase< dim, dim >',['../classFEFaceValuesBase.html',1,'']]], - ['fefacevaluesbase_3c_20dim_2c_20spacedim_20_3e_371',['FEFaceValuesBase< dim, spacedim >',['../classFEFaceValuesBase.html',1,'']]], - ['fefactory_372',['FEFactory',['../classFETools_1_1FEFactory.html',1,'FETools']]], - ['fefactorybase_373',['FEFactoryBase',['../classFETools_1_1FEFactoryBase.html',1,'FETools']]], - ['fefactorybase_3c_20fe_3a_3adimension_2c_20fe_3a_3aspace_5fdimension_20_3e_374',['FEFactoryBase< FE::dimension, FE::space_dimension >',['../classFETools_1_1FEFactoryBase.html',1,'FETools']]], - ['fefieldfunction_375',['FEFieldFunction',['../classFunctions_1_1FEFieldFunction.html#ac25d965867c71d1139262cf383f9f593',1,'Functions::FEFieldFunction::FEFieldFunction()'],['../classFunctions_1_1FEFieldFunction.html',1,'Functions::FEFieldFunction< dim, VectorType, spacedim >']]], - ['fehlberg_376',['FEHLBERG',['../namespaceTimeStepping.html#abff97b5326e452552f108a379dd6cff4a617cb06295ff4fd24ebc9d2c3228da6e',1,'TimeStepping']]], - ['feimmersedsurfacevalues_377',['FEImmersedSurfaceValues',['../classNonMatching_1_1FEImmersedSurfaceValues.html#ad0c498d43d99b9620f77b48b23aac74c',1,'NonMatching::FEImmersedSurfaceValues::FEImmersedSurfaceValues()'],['../classNonMatching_1_1FEImmersedSurfaceValues.html',1,'NonMatching::FEImmersedSurfaceValues< dim >']]], - ['feinterfacevalues_378',['FEInterfaceValues',['../classFEInterfaceValues.html#a7752eee5bae62bdc70deefee21019dea',1,'FEInterfaceValues::FEInterfaceValues()'],['../classFEInterfaceValues.html',1,'FEInterfaceValues< dim, spacedim >'],['../classFEInterfaceValues.html#a3a79e1b34087e4d1177cad7f6330e101',1,'FEInterfaceValues::FEInterfaceValues(const Mapping< dim, spacedim > &mapping, const FiniteElement< dim, spacedim > &fe, const Quadrature< dim - 1 > &quadrature, const UpdateFlags update_flags)'],['../classFEInterfaceValues.html#a8555d96ffb320d0ebc4c6a46b64339e4',1,'FEInterfaceValues::FEInterfaceValues(const Mapping< dim, spacedim > &mapping, const FiniteElement< dim, spacedim > &fe, const hp::QCollection< dim - 1 > &quadrature, const UpdateFlags update_flags)'],['../classFEInterfaceValues.html#ad2e6710bcd7f59b0c904b21a617fafc8',1,'FEInterfaceValues::FEInterfaceValues(const FiniteElement< dim, spacedim > &fe, const Quadrature< dim - 1 > &quadrature, const UpdateFlags update_flags)'],['../classFEInterfaceValues.html#a40d2b1785ac3d6290f2d9e56cc98779c',1,'FEInterfaceValues::FEInterfaceValues(const hp::MappingCollection< dim, spacedim > &mapping_collection, const hp::FECollection< dim, spacedim > &fe_collection, const hp::QCollection< dim - 1 > &quadrature_collection, const UpdateFlags update_flags)'],['../classNonMatching_1_1FEInterfaceValues.html#aa0193e922c90db4ece186a2277ed6dcc',1,'NonMatching::FEInterfaceValues::FEInterfaceValues(const hp::MappingCollection< dim > &mapping_collection, const hp::FECollection< dim > &fe_collection, const hp::QCollection< dim - 1 > &q_collection, const hp::QCollection< 1 > &q_collection_1d, const RegionUpdateFlags region_update_flags, const MeshClassifier< dim > &mesh_classifier, const DoFHandler< dim > &dof_handler, const VectorType &level_set, const AdditionalData &additional_data=AdditionalData())'],['../classNonMatching_1_1FEInterfaceValues.html#a944ad04419222d78961f148b70c81233',1,'NonMatching::FEInterfaceValues::FEInterfaceValues(const hp::FECollection< dim > &fe_collection, const Quadrature< 1 > &quadrature, const RegionUpdateFlags region_update_flags, const MeshClassifier< dim > &mesh_classifier, const DoFHandler< dim > &dof_handler, const VectorType &level_set, const AdditionalData &additional_data=AdditionalData())'],['../classNonMatching_1_1FEInterfaceValues.html',1,'NonMatching::FEInterfaceValues< dim >']]], - ['feinterfacevalues_3c_20dim_2c_20dim_20_3e_379',['FEInterfaceValues< dim, dim >',['../classFEInterfaceValues.html',1,'']]], - ['feinterfacevalues_3c_20dim_2c_20spacedim_20_3e_380',['FEInterfaceValues< dim, spacedim >',['../classFEInterfaceValues.html',1,'']]], - ['feinterfaceviews_381',['FEInterfaceViews',['../namespaceFEInterfaceViews.html',1,'']]], - ['fepointevaluation_382',['FEPointEvaluation',['../classFEPointEvaluation.html',1,'FEPointEvaluation< n_components_, dim, spacedim, Number >'],['../classFEPointEvaluation.html#a49d0f88c61bc89c45a8def38f6089459',1,'FEPointEvaluation::FEPointEvaluation(NonMatching::MappingInfo< dim, spacedim, Number > &mapping_info, const FiniteElement< dim > &fe, const unsigned int first_selected_component=0)'],['../classFEPointEvaluation.html#a8a06005cbe7c5c3092566c72fe60fde5',1,'FEPointEvaluation::FEPointEvaluation(FEPointEvaluation &&other) noexcept'],['../classFEPointEvaluation.html#aa0cf0e7ea60f1afd42069e5dc1084dd8',1,'FEPointEvaluation::FEPointEvaluation(FEPointEvaluation &other) noexcept'],['../classFEPointEvaluation.html#ada90d6f72f7a6ac207a2445cfa4f1474',1,'FEPointEvaluation::FEPointEvaluation(const Mapping< dim > &mapping, const FiniteElement< dim > &fe, const UpdateFlags update_flags, const unsigned int first_selected_component=0)']]], /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_17.js differs (ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_17.js 2023-07-22 00:00:00.000000000 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_17.js 2023-07-22 00:00:00.000000000 +0000 @@ -88,673 +88,674 @@ ['manifold_5fid_85',['manifold_id',['../structCellData.html#a1ae07c17fa1bab7900bdb8085d536a8a',1,'CellData::manifold_id()'],['../structTriangulationDescription_1_1CellData.html#a4567bd6b158738b747c6e14904a6af88',1,'TriangulationDescription::CellData::manifold_id()'],['../classinternal_1_1TriangulationImplementation_1_1TriaObjects.html#a02d9ecc047410c287cfa75489452432d',1,'internal::TriangulationImplementation::TriaObjects::manifold_id()'],['../namespacetypes.html#a24c02646474836ad4f37ca167e191276',1,'types::manifold_id()'],['../classInvalidAccessor.html#ab9f225fad65e0406b5af8c5028b3cebc',1,'InvalidAccessor::manifold_id()'],['../classTriaAccessor.html#a6c28dbcfefe0ffe1e51fe315c3565f94',1,'TriaAccessor::manifold_id()'],['../classTriaAccessor_3_010_00_011_00_01spacedim_01_4.html#ac152475456458f66d3030317aed09f93',1,'TriaAccessor< 0, 1, spacedim >::manifold_id()']]], ['manifold_5fids_86',['manifold_ids',['../classIteratorFilters_1_1ManifoldIdEqualTo.html#adf3db41d75ade0bb2cc6f9082a5223b7',1,'IteratorFilters::ManifoldIdEqualTo']]], ['manifold_5flib_2ecc_87',['manifold_lib.cc',['../grid_2manifold__lib_8cc.html',1,'(Global Namespace)'],['../opencascade_2manifold__lib_8cc.html',1,'(Global Namespace)']]], - ['manifold_5flib_2eh_88',['manifold_lib.h',['../opencascade_2manifold__lib_8h.html',1,'(Global Namespace)'],['../grid_2manifold__lib_8h.html',1,'(Global Namespace)']]], + ['manifold_5flib_2eh_88',['manifold_lib.h',['../grid_2manifold__lib_8h.html',1,'(Global Namespace)'],['../opencascade_2manifold__lib_8h.html',1,'(Global Namespace)']]], ['manifold_5fline_5fids_89',['manifold_line_ids',['../structTriangulationDescription_1_1CellData.html#a4e1c877d1fde32864e5afbfe9078de7e',1,'TriangulationDescription::CellData']]], ['manifold_5fquad_5fids_90',['manifold_quad_ids',['../structTriangulationDescription_1_1CellData.html#a3f34c6d80c604bda92c033467da1a10c',1,'TriangulationDescription::CellData']]], ['manifoldidequalto_91',['ManifoldIdEqualTo',['../classIteratorFilters_1_1ManifoldIdEqualTo.html',1,'IteratorFilters::ManifoldIdEqualTo'],['../classIteratorFilters_1_1ManifoldIdEqualTo.html#aade6621feb1c2730a7124c74c5a2a0ff',1,'IteratorFilters::ManifoldIdEqualTo::ManifoldIdEqualTo(const types::manifold_id manifold_id)'],['../classIteratorFilters_1_1ManifoldIdEqualTo.html#ac5005d838771382fd20145aa91adf621',1,'IteratorFilters::ManifoldIdEqualTo::ManifoldIdEqualTo(const std::set< types::manifold_id > &manifold_ids)']]], ['manifolds_92',['Manifolds',['../namespaceManifolds.html',1,'']]], ['manifolds_93',['manifolds',['../classTriangulation.html#ac35085f49c868d9ad4088363abf0e407',1,'Triangulation']]], - ['map_94',['map',['../classCellDataStorage.html#aeb7c0bc3dec7b996f440b1f6bb47f9af',1,'CellDataStorage']]], - ['map_95',['Map',['../classPatterns_1_1Map.html#a4b7162da71988e0f63ad889570cd3e3b',1,'Patterns::Map::Map(const PatternBase &key_pattern, const PatternBase &value_pattern, const unsigned int min_elements=0, const unsigned int max_elements=max_int_value, const std::string &separator=",", const std::string &key_value_separator=":")'],['../classPatterns_1_1Map.html#aa7f99c476d1a1f10a91c7a95647bebce',1,'Patterns::Map::Map(const Map &other)'],['../classPatterns_1_1Map.html',1,'Patterns::Map']]], - ['map3dpoint_96',['Map3DPoint',['../classDataOutBase_1_1DataOutFilter.html#a367d9ba2a636e166faec768e7978a33b',1,'DataOutBase::DataOutFilter']]], - ['map_5fboundary_5fto_5fmanifold_5fids_97',['map_boundary_to_manifold_ids',['../group__manifold.html#ga5861f4e358367a1e12221a7e6832755f',1,'GridTools']]], - ['map_5fdep_5fexpr_5fvec_5fentry_98',['map_dep_expr_vec_entry',['../classDifferentiation_1_1SD_1_1BatchOptimizer.html#af82512a11e74236f22ec9182d39fd02e',1,'Differentiation::SD::BatchOptimizer']]], - ['map_5fdependent_5fexpression_5fto_5fvector_5fentry_5ft_99',['map_dependent_expression_to_vector_entry_t',['../classDifferentiation_1_1SD_1_1BatchOptimizer.html#abd06a786061be85a54e2b13de2c93e1c',1,'Differentiation::SD::BatchOptimizer']]], - ['map_5fdof_5fto_5fboundary_5findices_100',['map_dof_to_boundary_indices',['../namespaceDoFTools.html#aa243d4c45775077c674ef6800e5ce215',1,'DoFTools::map_dof_to_boundary_indices(const DoFHandler< dim, spacedim > &dof_handler, std::vector< types::global_dof_index > &mapping)'],['../namespaceDoFTools.html#a2e367cf4d8590470cc136bec082b216b',1,'DoFTools::map_dof_to_boundary_indices(const DoFHandler< dim, spacedim > &dof_handler, const std::set< types::boundary_id > &boundary_ids, std::vector< types::global_dof_index > &mapping)']]], - ['map_5fdofs_5fto_5fsupport_5fpoints_101',['map_dofs_to_support_points',['../namespaceDoFTools.html#ad5a662af655769da570994d206e5e6d1',1,'DoFTools::map_dofs_to_support_points(const hp::MappingCollection< dim, spacedim > &mapping, const DoFHandler< dim, spacedim > &dof_handler, const ComponentMask &mask=ComponentMask())'],['../namespaceDoFTools.html#ad43f7f70ebb2598e749d11b9576c2ca5',1,'DoFTools::map_dofs_to_support_points(const hp::MappingCollection< dim, spacedim > &mapping, const DoFHandler< dim, spacedim > &dof_handler, std::map< types::global_dof_index, Point< spacedim > > &support_points, const ComponentMask &mask=ComponentMask())'],['../namespaceDoFTools.html#a6416e83755aa630a9e52f61972edcc92',1,'DoFTools::map_dofs_to_support_points(const Mapping< dim, spacedim > &mapping, const DoFHandler< dim, spacedim > &dof_handler, std::map< types::global_dof_index, Point< spacedim > > &support_points, const ComponentMask &mask=ComponentMask())'],['../namespaceDoFTools.html#ab2cd1823e0209438c76372bacbfbda5f',1,'DoFTools::map_dofs_to_support_points(const Mapping< dim, spacedim > &mapping, const DoFHandler< dim, spacedim > &dof_handler, const ComponentMask &mask=ComponentMask())'],['../namespaceDoFTools.html#add68c5a7aa18c2f20a716d42e6db2ff8',1,'DoFTools::map_dofs_to_support_points(const hp::MappingCollection< dim, spacedim > &mapping, const DoFHandler< dim, spacedim > &dof_handler, std::vector< Point< spacedim > > &support_points, const ComponentMask &mask=ComponentMask())'],['../namespaceDoFTools.html#a294a1f1cf2c3e437bf889cd1e963c7b7',1,'DoFTools::map_dofs_to_support_points(const Mapping< dim, spacedim > &mapping, const DoFHandler< dim, spacedim > &dof_handler, std::vector< Point< spacedim > > &support_points, const ComponentMask &mask=ComponentMask())']]], - ['map_5fiterator_102',['map_iterator',['../classSubscriptor.html#acebdc2d11f8522e4d9e8b7d73ac3f491',1,'Subscriptor']]], - ['map_5fquadrature_5fto_5fbox_103',['map_quadrature_to_box',['../namespaceNonMatching_1_1internal_1_1QuadratureGeneratorImplementation.html#a8a8cb7a85c9fae611e798d770cb74fc6',1,'NonMatching::internal::QuadratureGeneratorImplementation']]], - ['map_5frank_104',['map_rank',['../structPatterns_1_1Tools_1_1internal_1_1RankInfo_3_01Tensor_3_01rank_00_01dim_00_01Number_01_4_01_4.html#a41ffb66ee3c5d52abdc2da3714e93433',1,'Patterns::Tools::internal::RankInfo< Tensor< rank, dim, Number > >::map_rank()'],['../structPatterns_1_1Tools_1_1internal_1_1RankInfo.html#ae0394cc32e85093729d1da5fdafa0d46',1,'Patterns::Tools::internal::RankInfo::map_rank()'],['../structPatterns_1_1Tools_1_1internal_1_1RankInfo_3_01std_1_1complex_3_01Number_01_4_01_4.html#a992691e077d7072551eca79feaf7295c',1,'Patterns::Tools::internal::RankInfo< std::complex< Number > >::map_rank()'],['../structPatterns_1_1Tools_1_1internal_1_1RankInfo_3_01std_1_1unique__ptr_3_01FunctionParser_3_01dim_01_4_01_4_01_4.html#afb70057362e58620254bf841671addc2',1,'Patterns::Tools::internal::RankInfo< std::unique_ptr< FunctionParser< dim > > >::map_rank()'],['../structPatterns_1_1Tools_1_1internal_1_1RankInfo_3_01ComponentMask_01_4.html#a4bf7d6bba585561a6d81edc6dc3616e7',1,'Patterns::Tools::internal::RankInfo< ComponentMask >::map_rank()'],['../structPatterns_1_1Tools_1_1internal_1_1RankInfo_3_01std_1_1pair_3_01Key_00_01Value_01_4_01_4.html#a1bb07cff78cc51305027296d196c866e',1,'Patterns::Tools::internal::RankInfo< std::pair< Key, Value > >::map_rank()'],['../structPatterns_1_1Tools_1_1internal_1_1RankInfo_3_01std_1_1tuple_3_01Types_8_8_8_01_4_01_4.html#a8f559d33b8708ad101507a884fbc6f4a',1,'Patterns::Tools::internal::RankInfo< std::tuple< Types... > >::map_rank()'],['../structPatterns_1_1Tools_1_1internal_1_1RankInfo_3_01std_1_1array_3_01T_00_01N_01_4_01_4.html#afc0ad2b505954063fe7a1ccd045b708a',1,'Patterns::Tools::internal::RankInfo< std::array< T, N > >::map_rank()'],['../structPatterns_1_1Tools_1_1internal_1_1RankInfo_3_01T_00_01std_1_1enable__if__t_3_01is__list__co8fe07b504102b7cb8d7ad95765e8a00e.html#a3e102f06cd40de596ce91e5a1934de61',1,'Patterns::Tools::internal::RankInfo< T, std::enable_if_t< is_list_compatible< T >::value > >::map_rank()'],['../structPatterns_1_1Tools_1_1internal_1_1RankInfo_3_01T_00_01std_1_1enable__if__t_3_01is__map__comdefaaaf5a4df04236c69b1cbed3c9674.html#ab44d9f3690ccc4f2d3a07d83ed5d1381',1,'Patterns::Tools::internal::RankInfo< T, std::enable_if_t< is_map_compatible< T >::value > >::map_rank()']]], - ['map_5fsupport_5fpoints_5fto_5fdofs_105',['map_support_points_to_dofs',['../namespaceDoFTools.html#a3540ceb577e65414bde1b6b14808da2c',1,'DoFTools']]], - ['map_5ftype_106',['map_type',['../classPathSearch.html#ad2e4f6d9e51f092f47daf25285cc0daa',1,'PathSearch']]], - ['map_5fvalue_5ftype_107',['map_value_type',['../classSubscriptor.html#aeb9ac67567aa7d837f25debd33cd4ce5',1,'Subscriptor']]], - ['mapped_5fgeometry_108',['mapped_geometry',['../classFEEvaluationData.html#a508570e266a7ea6eee77d6c4f2b1ed9d',1,'FEEvaluationData']]], - ['mapped_5fquadrature_109',['mapped_quadrature',['../classQSimplex.html#a8ffaffdc5afd8a9dbba119b01492fe55',1,'QSimplex']]], - ['mapping_110',['mapping',['../classFEValuesBase.html#a5502d4cd55c37491d1f89e41285fc7e5',1,'FEValuesBase::mapping()'],['../classUtilities_1_1MPI_1_1RemotePointEvaluation.html#a6881c06a2e282d184f3fc975c103316f',1,'Utilities::MPI::RemotePointEvaluation::mapping()'],['../structStaticMappingQ1.html#a98ab35af832f316b5b441b4402560d16',1,'StaticMappingQ1::mapping()'],['../classGridTools_1_1Cache.html#a49d56c1dc787c556615637e401b005e7',1,'GridTools::Cache::mapping()'],['../classInterGridMap.html#ac0f1ac3f8fc09aff8dc40032e98fb9f8',1,'InterGridMap::mapping()'],['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfo.html#ab6a5213bb17feca4d9a6abeb7232910f',1,'internal::MatrixFreeFunctions::MappingInfo::mapping()'],['../classMeshWorker_1_1ScratchData.html#aa78cc14beed4fdc11e6f0601ebc0b0a8',1,'MeshWorker::ScratchData::mapping()'],['../classNonMatching_1_1MappingInfo.html#a49b202fe3760598cf35ab6d6cd910f93',1,'NonMatching::MappingInfo::mapping()'],['../classDataOutResample.html#aa324e79ff4edeebd91a9244fecfcbb6c',1,'DataOutResample::mapping()'],['../classFunctions_1_1FEFieldFunction.html#a83e5b937b784cfbb0ca1cfae9af85ea7',1,'Functions::FEFieldFunction::mapping()'],['../classParticles_1_1ParticleHandler.html#aed73d58005f8ccfafa56cf2bcb4ab4c1',1,'Particles::ParticleHandler::mapping()'],['../classFEPointEvaluation.html#afb21118fe3db2ca03cb4b17610f507e2',1,'FEPointEvaluation::mapping()']]], - ['mapping_111',['Mapping',['../classMapping.html',1,'']]], - ['mapping_2ecc_112',['mapping.cc',['../mapping_8cc.html',1,'']]], - ['mapping_2eh_113',['mapping.h',['../mapping_8h.html',1,'']]], - ['mapping_3c_20dim_2c_20dim_20_3e_114',['Mapping< dim, dim >',['../classMapping.html',1,'']]], - ['mapping_3c_20dim_2c_20spacedim_20_3e_115',['Mapping< dim, spacedim >',['../classMapping.html',1,'']]], - ['mapping_3c_20patch_5fdim_2c_20spacedim_20_3e_116',['Mapping< patch_dim, spacedim >',['../classMapping.html',1,'']]], - ['mapping_5fbdm_117',['mapping_bdm',['../group__mapping.html#ggac6eaf900d562c52002dbccc6bdd89275ae28667bfbd4686bcf19fe386cb0e6c5a',1,'mapping.h']]], - ['mapping_5fc1_2ecc_118',['mapping_c1.cc',['../mapping__c1_8cc.html',1,'']]], - ['mapping_5fc1_2eh_119',['mapping_c1.h',['../mapping__c1_8h.html',1,'']]], - ['mapping_5fcartesian_2ecc_120',['mapping_cartesian.cc',['../mapping__cartesian_8cc.html',1,'']]], - ['mapping_5fcartesian_2eh_121',['mapping_cartesian.h',['../mapping__cartesian_8h.html',1,'']]], - ['mapping_5fcollection_122',['mapping_collection',['../classhp_1_1FEValuesBase.html#ad9f1401f812ea55cf669ca69d51c94d3',1,'hp::FEValuesBase::mapping_collection()'],['../structhp_1_1StaticMappingQ1.html#a3951f29e14b906691298a07c932fe809',1,'hp::StaticMappingQ1::mapping_collection()'],['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfo.html#a24569ada47ded0761d8bcd39856dd228',1,'internal::MatrixFreeFunctions::MappingInfo::mapping_collection()'],['../classMeshWorker_1_1ScratchData.html#a8267f473b7f61d82096323316de71809',1,'MeshWorker::ScratchData::mapping_collection()'],['../classNonMatching_1_1FEValues.html#ac43ca3fb25aacb417aec02a895ee9698',1,'NonMatching::FEValues::mapping_collection()'],['../classNonMatching_1_1FEInterfaceValues.html#a2041d35d4b0d7748e9e7673a5fa9f522',1,'NonMatching::FEInterfaceValues::mapping_collection()'],['../structinternal_1_1DataOutImplementation_1_1ParallelDataBase.html#a90dae9d69f0324c1f4bfb3a8f4616056',1,'internal::DataOutImplementation::ParallelDataBase::mapping_collection()']]], - ['mapping_5fcollection_2ecc_123',['mapping_collection.cc',['../mapping__collection_8cc.html',1,'']]], - ['mapping_5fcollection_2eh_124',['mapping_collection.h',['../mapping__collection_8h.html',1,'']]], - ['mapping_5fcontravariant_125',['mapping_contravariant',['../group__mapping.html#ggac6eaf900d562c52002dbccc6bdd89275a661444faabcc79cb0177def2bc905a3b',1,'mapping.h']]], - ['mapping_5fcontravariant_5fgradient_126',['mapping_contravariant_gradient',['../group__mapping.html#ggac6eaf900d562c52002dbccc6bdd89275aca3e2da4109641c29ac99050e2e6b8c1',1,'mapping.h']]], - ['mapping_5fcontravariant_5fhessian_127',['mapping_contravariant_hessian',['../group__mapping.html#ggac6eaf900d562c52002dbccc6bdd89275aa6a1de84f93b971399c1829cac0d2511',1,'mapping.h']]], - ['mapping_5fcovariant_128',['mapping_covariant',['../group__mapping.html#ggac6eaf900d562c52002dbccc6bdd89275a35d1e9fba325e2d103c1fea732fc05b1',1,'mapping.h']]], - ['mapping_5fcovariant_5fgradient_129',['mapping_covariant_gradient',['../group__mapping.html#ggac6eaf900d562c52002dbccc6bdd89275a2c91c679c0e69f01985c12ffa01c7c5c',1,'mapping.h']]], - ['mapping_5fcovariant_5fhessian_130',['mapping_covariant_hessian',['../group__mapping.html#ggac6eaf900d562c52002dbccc6bdd89275aca177cc2e28f92fee319cfb4784e1772',1,'mapping.h']]], - ['mapping_5fdata_131',['mapping_data',['../classFEValuesBase.html#aa2786d839ac016cd2181c1a2acf7b755',1,'FEValuesBase::mapping_data()'],['../structFEEvaluationData_1_1InitializationData.html#a6dbc1451df17e3b1fd7deea881988580',1,'FEEvaluationData::InitializationData::mapping_data()'],['../classFEEvaluationData.html#a16babce9637ec2a38b6d089a70263df0',1,'FEEvaluationData::mapping_data()']]], - ['mapping_5fdata_5fon_5fthe_5ffly_2eh_132',['mapping_data_on_the_fly.h',['../mapping__data__on__the__fly_8h.html',1,'']]], - ['mapping_5ffe_2ecc_133',['mapping_fe.cc',['../mapping__fe_8cc.html',1,'']]], - ['mapping_5ffe_2eh_134',['mapping_fe.h',['../mapping__fe_8h.html',1,'']]], - ['mapping_5ffe_5ffield_2ecc_135',['mapping_fe_field.cc',['../mapping__fe__field_8cc.html',1,'']]], - ['mapping_5ffe_5ffield_2eh_136',['mapping_fe_field.h',['../mapping__fe__field_8h.html',1,'']]], - ['mapping_5ffe_5ffield_5finst2_2ecc_137',['mapping_fe_field_inst2.cc',['../mapping__fe__field__inst2_8cc.html',1,'']]], - ['mapping_5finfo_138',['mapping_info',['../classFEPointEvaluation.html#afe9e185af4df31eb168421b463be2768',1,'FEPointEvaluation::mapping_info()'],['../classMatrixFree.html#a0819d60614c996f43079cc20e0d63933',1,'MatrixFree::mapping_info()'],['../classMGTwoLevelTransferNonNested_3_01dim_00_01LinearAlgebra_1_1distributed_1_1Vector_3_01Number_01_4_01_4.html#a0e2eb0e2ee8c2660406f6cddabd4c64b',1,'MGTwoLevelTransferNonNested< dim, LinearAlgebra::distributed::Vector< Number > >::mapping_info()']]], - ['mapping_5finfo_2ecc_139',['mapping_info.cc',['../mapping__info_8cc.html',1,'']]], - ['mapping_5finfo_2eh_140',['mapping_info.h',['../non__matching_2mapping__info_8h.html',1,'(Global Namespace)'],['../matrix__free_2mapping__info_8h.html',1,'(Global Namespace)']]], - ['mapping_5finfo_5finst2_2ecc_141',['mapping_info_inst2.cc',['../mapping__info__inst2_8cc.html',1,'']]], - ['mapping_5finfo_5finst3_2ecc_142',['mapping_info_inst3.cc',['../mapping__info__inst3_8cc.html',1,'']]], - ['mapping_5finfo_5fon_5fthe_5ffly_143',['mapping_info_on_the_fly',['../classFEPointEvaluation.html#a329614d2376b1c00aab1922643aacef5',1,'FEPointEvaluation']]], - ['mapping_5finfo_5fstorage_144',['mapping_info_storage',['../classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html#acbf11dd80464eda7ce7b6f0706154e9f',1,'internal::MatrixFreeFunctions::MappingDataOnTheFly']]], - ['mapping_5finfo_5fstorage_2eh_145',['mapping_info_storage.h',['../mapping__info__storage_8h.html',1,'']]], - ['mapping_5finitialized_146',['mapping_initialized',['../classMatrixFree.html#a2b95d23ac163726460a536e76513ac13',1,'MatrixFree']]], - ['mapping_5fis_5finitialized_147',['mapping_is_initialized',['../classMatrixFree.html#a60d4bcec742b46e930fc6d3ad1854f35',1,'MatrixFree']]], - ['mapping_5fkind_148',['mapping_kind',['../classFE__NedelecSZ.html#af7e8a43a6118472a75100cc1c5f3f3de',1,'FE_NedelecSZ::mapping_kind()'],['../classFE__PolyTensor.html#abeecf4df065ca5f5701ba1190a190631',1,'FE_PolyTensor::mapping_kind()']]], - ['mapping_5fmanifold_2ecc_149',['mapping_manifold.cc',['../mapping__manifold_8cc.html',1,'']]], - ['mapping_5fmanifold_2eh_150',['mapping_manifold.h',['../mapping__manifold_8h.html',1,'']]], - ['mapping_5fnedelec_151',['mapping_nedelec',['../group__mapping.html#ggac6eaf900d562c52002dbccc6bdd89275a390147bcf65b6a4d1da9134fa1a6271b',1,'mapping.h']]], - ['mapping_5fnone_152',['mapping_none',['../group__mapping.html#ggac6eaf900d562c52002dbccc6bdd89275adf1d77147c4674d6a8e5f79e0c2ef6f7',1,'mapping.h']]], - ['mapping_5foutput_153',['mapping_output',['../classFEValuesBase.html#a44f12540e0b7897c4ecebd33f7664bd8',1,'FEValuesBase']]], - ['mapping_5fpiola_154',['mapping_piola',['../group__mapping.html#ggac6eaf900d562c52002dbccc6bdd89275a151b5953ea721a4ae52322c661d47ae5',1,'mapping.h']]], - ['mapping_5fpiola_5fgradient_155',['mapping_piola_gradient',['../group__mapping.html#ggac6eaf900d562c52002dbccc6bdd89275af53b8991a433c146c8ae5f5f991b56c0',1,'mapping.h']]], - ['mapping_5fpiola_5fhessian_156',['mapping_piola_hessian',['../group__mapping.html#ggac6eaf900d562c52002dbccc6bdd89275aff151face0205747953d22a75af0f9ba',1,'mapping.h']]], - ['mapping_5fq_2ecc_157',['mapping_q.cc',['../mapping__q_8cc.html',1,'']]], - ['mapping_5fq_2eh_158',['mapping_q.h',['../mapping__q_8h.html',1,'']]], - ['mapping_5fq1_2ecc_159',['mapping_q1.cc',['../mapping__q1_8cc.html',1,'']]], - ['mapping_5fq1_2eh_160',['mapping_q1.h',['../mapping__q1_8h.html',1,'']]], - ['mapping_5fq1_5feulerian_2ecc_161',['mapping_q1_eulerian.cc',['../mapping__q1__eulerian_8cc.html',1,'']]], - ['mapping_5fq1_5feulerian_2eh_162',['mapping_q1_eulerian.h',['../mapping__q1__eulerian_8h.html',1,'']]], - ['mapping_5fq_5fcache_2ecc_163',['mapping_q_cache.cc',['../mapping__q__cache_8cc.html',1,'']]], - ['mapping_5fq_5fcache_2eh_164',['mapping_q_cache.h',['../mapping__q__cache_8h.html',1,'']]], - ['mapping_5fq_5feulerian_2ecc_165',['mapping_q_eulerian.cc',['../mapping__q__eulerian_8cc.html',1,'']]], - ['mapping_5fq_5feulerian_2eh_166',['mapping_q_eulerian.h',['../mapping__q__eulerian_8h.html',1,'']]], - ['mapping_5fq_5fgeneric_2eh_167',['mapping_q_generic.h',['../mapping__q__generic_8h.html',1,'']]], - ['mapping_5fq_5finternal_2eh_168',['mapping_q_internal.h',['../mapping__q__internal_8h.html',1,'']]], - ['mapping_5fraviart_5fthomas_169',['mapping_raviart_thomas',['../group__mapping.html#ggac6eaf900d562c52002dbccc6bdd89275a7102924e4ddcdc9bd3c133e3e153e0c4',1,'mapping.h']]], - ['mapping_5frelated_5fdata_2ecc_170',['mapping_related_data.cc',['../mapping__related__data_8cc.html',1,'']]], - ['mapping_5frelated_5fdata_2eh_171',['mapping_related_data.h',['../mapping__related__data_8h.html',1,'']]], - ['mapping_5fsupport_5fpoint_5fweights_172',['mapping_support_point_weights',['../classMappingFE.html#a5089ac2996aba5176014e43d0a99ed27',1,'MappingFE']]], - ['mapping_5fsupport_5fpoints_173',['mapping_support_points',['../classMappingQ_1_1InternalData.html#a668ce98d0bf0528ce8d8ce8c198942b7',1,'MappingQ::InternalData::mapping_support_points()'],['../classMappingFE_1_1InternalData.html#a1772d156d76dfcdd7651027dfa6021a2',1,'MappingFE::InternalData::mapping_support_points()']]], - ['mapping_5fupdate_5fflags_174',['mapping_update_flags',['../structMatrixFree_1_1AdditionalData.html#aa5d597e6c4441d273f4100b6139a2552',1,'MatrixFree::AdditionalData::mapping_update_flags()'],['../structCUDAWrappers_1_1MatrixFree_1_1AdditionalData.html#a4fc9f434f93f40a8c1dff4ed6b9fd509',1,'CUDAWrappers::MatrixFree::AdditionalData::mapping_update_flags()']]], - ['mapping_5fupdate_5fflags_5fboundary_5ffaces_175',['mapping_update_flags_boundary_faces',['../structMatrixFree_1_1AdditionalData.html#aa326b1a098e1c037334cc05bdc2decc6',1,'MatrixFree::AdditionalData']]], - ['mapping_5fupdate_5fflags_5ffaces_5fby_5fcells_176',['mapping_update_flags_faces_by_cells',['../structMatrixFree_1_1AdditionalData.html#aae675b9c61c8b1515f297d41595740d7',1,'MatrixFree::AdditionalData']]], - ['mapping_5fupdate_5fflags_5finner_5ffaces_177',['mapping_update_flags_inner_faces',['../structMatrixFree_1_1AdditionalData.html#a5c25759917955940e0b2b74a6704012c',1,'MatrixFree::AdditionalData']]], - ['mappingc1_178',['MappingC1',['../classMappingC1.html',1,'MappingC1< dim, spacedim >'],['../classMappingC1.html#a833031a3846c67f6b8a1de2e120fce8b',1,'MappingC1::MappingC1()']]], - ['mappingcartesian_179',['MappingCartesian',['../classMappingCartesian.html',1,'']]], - ['mappingcollection_180',['MappingCollection',['../classhp_1_1MappingCollection.html',1,'hp::MappingCollection< dim, spacedim >'],['../classhp_1_1MappingCollection.html#a7d586bc800e5969dbad4cb7e5f7e3629',1,'hp::MappingCollection::MappingCollection()=default'],['../classhp_1_1MappingCollection.html#a25dffbc4954c26dd19e6185ac67d124a',1,'hp::MappingCollection::MappingCollection(const Mapping< dim, spacedim > &mapping)'],['../classhp_1_1MappingCollection.html#a1f3dd74392937e13524735d21e847a23',1,'hp::MappingCollection::MappingCollection(const MappingTypes &...mappings)'],['../classhp_1_1MappingCollection.html#a98491b535c6612fb8647c3b24724921d',1,'hp::MappingCollection::MappingCollection(const MappingCollection< dim, spacedim > &mapping_collection)'],['../classhp_1_1MappingCollection.html#a110957f9714b543e572d1209c6697065',1,'hp::MappingCollection::MappingCollection(MappingCollection< dim, spacedim > &&) noexcept(std::is_nothrow_move_constructible< std::vector< std::shared_ptr< const Mapping< dim, spacedim > > > >::value &&std::is_nothrow_move_constructible< std::function< unsigned int(const typename hp::MappingCollection< dim, spacedim > &, const unsigned int)> >::value)=default']]], - ['mappingcollection_3c_20dim_2c_20dim_20_3e_181',['MappingCollection< dim, dim >',['../classhp_1_1MappingCollection.html',1,'hp']]], - ['mappingcollection_3c_20dim_2c_20fevaluestype_3a_3aspace_5fdimension_20_3e_182',['MappingCollection< dim, FEValuesType::space_dimension >',['../classhp_1_1MappingCollection.html',1,'hp']]], - ['mappingcollection_3c_20dim_2c_20spacedim_20_3e_183',['MappingCollection< dim, spacedim >',['../classhp_1_1MappingCollection.html',1,'hp']]], - ['mappingdata_184',['MappingData',['../classNonMatching_1_1internal_1_1ComputeMappingDataHelper.html#a5f28b3c57e1e2175a2dfbcd802bfde14',1,'NonMatching::internal::ComputeMappingDataHelper::MappingData()'],['../classNonMatching_1_1MappingInfo.html#a12bd441c92df128fb9b7e955be433804',1,'NonMatching::MappingInfo::MappingData()']]], - ['mappingdataonthefly_185',['MappingDataOnTheFly',['../classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html',1,'internal::MatrixFreeFunctions::MappingDataOnTheFly< dim, Number >'],['../classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html#a41f1b71720a06213f28f80f10da99381',1,'internal::MatrixFreeFunctions::MappingDataOnTheFly::MappingDataOnTheFly(const Quadrature< 1 > &quadrature, const UpdateFlags update_flags)'],['../classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html#ac19a052df9c9f09251846d93106011f9',1,'internal::MatrixFreeFunctions::MappingDataOnTheFly::MappingDataOnTheFly(const Mapping< dim > &mapping, const Quadrature< 1 > &quadrature, const UpdateFlags update_flags)'],['../classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html#a989a68bb5fc29cbf17b0d20c87374fb0',1,'internal::MatrixFreeFunctions::MappingDataOnTheFly::MappingDataOnTheFly()=default']]], - ['mappingdataonthefly_3c_20dim_2c_20vectorizedarray_3c_20double_20_3e_20_3e_186',['MappingDataOnTheFly< dim, VectorizedArray< double > >',['../classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html',1,'internal::MatrixFreeFunctions']]], - ['mappingdataonthefly_3c_20dim_2c_20vectorizedarray_3c_20number_20_3e_20_3e_187',['MappingDataOnTheFly< dim, VectorizedArray< Number > >',['../classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html',1,'internal::MatrixFreeFunctions']]], - ['mappingdataonthefly_3c_20dim_2c_20vectorizedarraytype_20_3e_188',['MappingDataOnTheFly< dim, VectorizedArrayType >',['../classinternal_1_1MatrixFreeFunctions_1_1MappingDataOnTheFly.html',1,'internal::MatrixFreeFunctions']]], - ['mappingfe_189',['MappingFE',['../classMappingFE.html#a6aecb288e6c5a96b43103ebb6cd39b23',1,'MappingFE::MappingFE()'],['../classMappingFE.html',1,'MappingFE< dim, spacedim >'],['../classMappingFE.html#a18a9e14a1500023e4e5b4b50091c81e1',1,'MappingFE::MappingFE()']]], - ['mappingfefield_190',['MappingFEField',['../classMappingFEField.html#a2bda487e1bf5b4950a12a8eb7845611f',1,'MappingFEField::MappingFEField(const MappingFEField< dim, spacedim, VectorType > &mapping)'],['../classMappingFEField.html#a5834f34677f5ffa549eb661428208c85',1,'MappingFEField::MappingFEField()'],['../classMappingFEField.html#ae3510f5254ef86d3d35e5aed062d4011',1,'MappingFEField::MappingFEField(const DoFHandler< dim, spacedim > &euler_dof_handler, const VectorType &euler_vector, const ComponentMask &mask=ComponentMask())'],['../classMappingFEField.html#a53581fb7a57e5f1b6eb36ce0a8da6cee',1,'MappingFEField::MappingFEField(const DoFHandler< dim, spacedim > &euler_dof_handler, const std::vector< VectorType > &euler_vector, const ComponentMask &mask=ComponentMask())'],['../classMappingFEField.html#a0a43ea0b9498b6f992981b9e4b279be8',1,'MappingFEField::MappingFEField(const DoFHandler< dim, spacedim > &euler_dof_handler, const MGLevelObject< VectorType > &euler_vector, const ComponentMask &mask=ComponentMask())'],['../classMappingFEField.html',1,'MappingFEField< dim, spacedim, VectorType >']]], - ['mappinginfo_191',['MappingInfo',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfo.html',1,'internal::MatrixFreeFunctions::MappingInfo< dim, Number, VectorizedArrayType >'],['../classNonMatching_1_1MappingInfo.html#a48fc8ee03423f929a6a7fe99c1f974f3',1,'NonMatching::MappingInfo::MappingInfo()'],['../classNonMatching_1_1MappingInfo.html',1,'NonMatching::MappingInfo< dim, spacedim, Number >']]], - ['mappinginfo_3c_20dim_2c_20dim_2c_20double_20_3e_192',['MappingInfo< dim, dim, double >',['../classNonMatching_1_1MappingInfo.html',1,'NonMatching']]], - ['mappinginfo_3c_20dim_2c_20dim_2c_20number_20_3e_193',['MappingInfo< dim, dim, Number >',['../classNonMatching_1_1MappingInfo.html',1,'NonMatching']]], - ['mappinginfo_3c_20dim_2c_20double_2c_20vectorizedarray_3c_20double_20_3e_20_3e_194',['MappingInfo< dim, double, VectorizedArray< double > >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfo.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfo_3c_20dim_2c_20number_2c_20vectorizedarray_3c_20number_20_3e_20_3e_195',['MappingInfo< dim, Number, VectorizedArray< Number > >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfo.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfo_3c_20dim_2c_20value_5ftype_2c_20vectorizedarray_3c_20typename_20vectortype_3a_3avalue_5ftype_20_3e_20_3e_196',['MappingInfo< dim, value_type, VectorizedArray< typename VectorType::value_type > >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfo.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfocellsorfaces_197',['MappingInfoCellsOrFaces',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfoCellsOrFaces.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfocellsorfaces_3c_20dim_2c_20number_2c_20false_2c_20vectorizedarraytype_20_3e_198',['MappingInfoCellsOrFaces< dim, Number, false, VectorizedArrayType >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfoCellsOrFaces_3_01dim_00_01Number_00_01false_00_01VectorizedArrayType_01_4.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfocellsorfaces_3c_20dim_2c_20number_2c_20true_2c_20vectorizedarraytype_20_3e_199',['MappingInfoCellsOrFaces< dim, Number, true, VectorizedArrayType >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfoCellsOrFaces_3_01dim_00_01Number_00_01true_00_01VectorizedArrayType_01_4.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfostorage_200',['MappingInfoStorage',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfoStorage.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfostorage_3c_20dim_20_2d_201_2c_20dim_2c_20vectorizedarray_3c_20double_20_3e_20_3e_201',['MappingInfoStorage< dim - 1, dim, VectorizedArray< double > >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfoStorage.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfostorage_3c_20dim_20_2d_201_2c_20dim_2c_20vectorizedarray_3c_20number_20_3e_20_3e_202',['MappingInfoStorage< dim - 1, dim, VectorizedArray< Number > >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfoStorage.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfostorage_3c_20dim_20_2d_201_2c_20dim_2c_20vectorizedarray_3c_20typename_20vectortype_3a_3avalue_5ftype_20_3e_20_3e_203',['MappingInfoStorage< dim - 1, dim, VectorizedArray< typename VectorType::value_type > >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfoStorage.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfostorage_3c_20dim_20_2d_201_2c_20dim_2c_20vectorizedarraytype_20_3e_204',['MappingInfoStorage< dim - 1, dim, VectorizedArrayType >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfoStorage.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfostorage_3c_20dim_2c_20dim_2c_20number_20_3e_205',['MappingInfoStorage< dim, dim, Number >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfoStorage.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfostorage_3c_20dim_2c_20dim_2c_20vectorizedarray_3c_20double_20_3e_20_3e_206',['MappingInfoStorage< dim, dim, VectorizedArray< double > >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfoStorage.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfostorage_3c_20dim_2c_20dim_2c_20vectorizedarray_3c_20number_20_3e_20_3e_207',['MappingInfoStorage< dim, dim, VectorizedArray< Number > >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfoStorage.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfostorage_3c_20dim_2c_20dim_2c_20vectorizedarray_3c_20typename_20vectortype_3a_3avalue_5ftype_20_3e_20_3e_208',['MappingInfoStorage< dim, dim, VectorizedArray< typename VectorType::value_type > >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfoStorage.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfostorage_3c_20dim_2c_20dim_2c_20vectorizedarraytype_20_3e_209',['MappingInfoStorage< dim, dim, VectorizedArrayType >',['../structinternal_1_1MatrixFreeFunctions_1_1MappingInfoStorage.html',1,'internal::MatrixFreeFunctions']]], - ['mappinginfostoragetype_210',['MappingInfoStorageType',['../classFEEvaluationData.html#a2937bc4d03c9ba36b5cfeae671a324bf',1,'FEEvaluationData']]], - ['mappingkind_211',['MappingKind',['../group__mapping.html#gac6eaf900d562c52002dbccc6bdd89275',1,'mapping.h']]], - ['mappingmanifold_212',['MappingManifold',['../classMappingManifold.html',1,'MappingManifold< dim, spacedim >'],['../classMappingManifold.html#a2f53694fa758a5c6f982ea0faa2c6799',1,'MappingManifold::MappingManifold()=default'],['../classMappingManifold.html#a0f798ba358581b95f9b7849a14ee8293',1,'MappingManifold::MappingManifold(const MappingManifold< dim, spacedim > &mapping)']]], - ['mappingmanifold_3c_203_2c_204_20_3e_213',['MappingManifold< 3, 4 >',['../classMappingManifold_3_013_00_014_01_4.html',1,'']]], - ['mappingq_214',['MappingQ',['../classMappingQ.html',1,'MappingQ< dim, spacedim >'],['../classMappingQ.html#a9b1f93d2845588f4c821a19f3f245088',1,'MappingQ::MappingQ(const MappingQ< dim, spacedim > &mapping)'],['../classMappingQ.html#a9b34a7f2ec00aa65e73402865ac2887d',1,'MappingQ::MappingQ(const unsigned int polynomial_degree, const bool use_mapping_q_on_all_cells)'],['../classMappingQ.html#ad76fbeba8c88293133371cfd5b2d4085',1,'MappingQ::MappingQ(const unsigned int polynomial_degree)'],['../classFE__DGQ.html#a42293d07f83fabc8a6891ef5fc8d7f36',1,'FE_DGQ::MappingQ()']]], - ['mappingq1_215',['MappingQ1',['../classMappingQ1.html',1,'MappingQ1< dim, spacedim >'],['../classMappingQ1.html#a51e5f4fd665b98dca2175dfdc08e4daf',1,'MappingQ1::MappingQ1()']]], - ['mappingq1eulerian_216',['MappingQ1Eulerian',['../classMappingQ1Eulerian.html',1,'MappingQ1Eulerian< dim, VectorType, spacedim >'],['../classMappingQ1Eulerian.html#ae6de3656a5d48d9fb41eeb2935a72d8c',1,'MappingQ1Eulerian::MappingQ1Eulerian()']]], - ['mappingq_3c_203_2c_204_20_3e_217',['MappingQ< 3, 4 >',['../classMappingQ_3_013_00_014_01_4.html',1,'']]], - ['mappingq_3c_20dim_2c_20dim_20_3e_218',['MappingQ< dim, dim >',['../classMappingQ.html',1,'']]], - ['mappingqcache_219',['MappingQCache',['../classMappingQCache.html#a1d935c3b1791a878b0d9f1517e1404a0',1,'MappingQCache::MappingQCache()'],['../classMappingQCache.html',1,'MappingQCache< dim, spacedim >'],['../classMappingQ.html#a4ac07c8d2d04671cb1273cf028b27115',1,'MappingQ::MappingQCache()'],['../classMappingQCache.html#a90e57f54c9d59928a232452c9783a480',1,'MappingQCache::MappingQCache()']]], - ['mappingqeulerian_220',['MappingQEulerian',['../classMappingQEulerian.html#a3239b058a6f4f7e356c2b4e964bd6395',1,'MappingQEulerian::MappingQEulerian()'],['../classMappingQEulerian.html',1,'MappingQEulerian< dim, VectorType, spacedim >']]], - ['mappingqgeneric_221',['MappingQGeneric',['../group__mapping.html#ga707ed00adeca71df2f3f44a102b53e3a',1,'mapping_q.h']]], - ['mappingrelateddata_222',['MappingRelatedData',['../classinternal_1_1FEValuesImplementation_1_1MappingRelatedData.html',1,'internal::FEValuesImplementation']]], - ['mappingrelateddata_3c_20dim_2c_20spacedim_20_3e_223',['MappingRelatedData< dim, spacedim >',['../classinternal_1_1FEValuesImplementation_1_1MappingRelatedData.html',1,'internal::FEValuesImplementation']]], - ['mappings_20between_20reference_20and_20real_20cell_224',['Mappings between reference and real cell',['../group__mapping.html',1,'']]], - ['marchingcubealgorithm_225',['MarchingCubeAlgorithm',['../classGridTools_1_1MarchingCubeAlgorithm.html',1,'GridTools::MarchingCubeAlgorithm< dim, VectorType >'],['../classGridTools_1_1MarchingCubeAlgorithm.html#ab29b812b67e5aa185c0f5966163f40fa',1,'GridTools::MarchingCubeAlgorithm::MarchingCubeAlgorithm()']]], - ['margin_226',['margin',['../structDataOutBase_1_1SvgFlags.html#a8697453be9012d91f416b11381e5e2a7',1,'DataOutBase::SvgFlags::margin()'],['../structGridOutFlags_1_1Svg.html#a23496c5be2fbf5522c243b0a08248fb6',1,'GridOutFlags::Svg::margin()']]], - ['mark_5fdomains_227',['mark_domains',['../namespaceCGALWrappers_1_1internal.html#a657caa4336a2db451dfc93e47beb4bd6',1,'CGALWrappers::internal::mark_domains(CDT &ct, Face_handle start, int index, std::list< CDT::Edge > &border)'],['../namespaceCGALWrappers_1_1internal.html#a19f9f3e6cb3dcb7da476f20507cb6d95',1,'CGALWrappers::internal::mark_domains(CDT &cdt)']]], - ['mark_5ffor_5fupdate_228',['mark_for_update',['../classGridTools_1_1Cache.html#af20a8cf1d32644907e7e9eb573594dfc',1,'GridTools::Cache']]], - ['mark_5findependent_5fvariable_229',['mark_independent_variable',['../classDifferentiation_1_1AD_1_1HelperBase.html#a46cca0a2ae58ac6021b011c00ee46725',1,'Differentiation::AD::HelperBase']]], - ['mark_5flocally_5factive_5fvertices_5fon_5flevel_230',['mark_locally_active_vertices_on_level',['../classparallel_1_1distributed_1_1Triangulation.html#a9c5a374eae5fb78508395822ce66c6ae',1,'parallel::distributed::Triangulation::mark_locally_active_vertices_on_level()'],['../classparallel_1_1distributed_1_1Triangulation_3_011_00_01spacedim_01_4.html#af85aa7c2bcd4bac177901b88ebc4ae07',1,'parallel::distributed::Triangulation< 1, spacedim >::mark_locally_active_vertices_on_level()']]], - ['mark_5fsupport_5flocations_231',['mark_support_locations',['../classPointValueHistory.html#a5215083277dfb44a6446a235e862d53c',1,'PointValueHistory']]], - ['marked_5fvertices_232',['marked_vertices',['../classUtilities_1_1MPI_1_1RemotePointEvaluation.html#aaebca398b896b80981093a3d779a8899',1,'Utilities::MPI::RemotePointEvaluation']]], - ['marking_233',['Marking',['../structDifferentiation_1_1AD_1_1internal_1_1Marking.html',1,'Differentiation::AD::internal']]], - ['mask_234',['mask',['../namespaceinternal.html#aa1c66592673b9ca3c1f4adecdc7897ceaf2ce11ebf110993621bedd8e747d7b1b',1,'internal::mask()'],['../classMappingFEField_1_1InternalData.html#ad735398b851264abb9f1a3b3f45446cf',1,'MappingFEField::InternalData::mask()'],['../structFloatingPointComparator.html#a4b47614887196ca5f95d4b598cc22ed4',1,'FloatingPointComparator::mask()']]], - ['masked_5fvector_5fbin_5fop_235',['masked_vector_bin_op',['../group__CUDAWrappers.html#ga46f01546f308a53a2adfbbc202fa7118',1,'LinearAlgebra::CUDAWrappers::kernel']]], - ['masked_5fvector_5fbin_5fop_3c_20double_2c_20binop_5faddition_20_3e_236',['masked_vector_bin_op< double, Binop_Addition >',['../namespaceLinearAlgebra_1_1CUDAWrappers_1_1kernel.html#a840a88e81c7cd03b2acbcfb74c1f67dd',1,'LinearAlgebra::CUDAWrappers::kernel']]], - ['masked_5fvector_5fbin_5fop_3c_20double_2c_20binop_5fsubtraction_20_3e_237',['masked_vector_bin_op< double, Binop_Subtraction >',['../namespaceLinearAlgebra_1_1CUDAWrappers_1_1kernel.html#a3d229d0b618d1b1622fdaea32bf36052',1,'LinearAlgebra::CUDAWrappers::kernel']]], - ['masked_5fvector_5fbin_5fop_3c_20float_2c_20binop_5faddition_20_3e_238',['masked_vector_bin_op< float, Binop_Addition >',['../namespaceLinearAlgebra_1_1CUDAWrappers_1_1kernel.html#ab4fb28ad03308a526ccc872e7c8f3ff0',1,'LinearAlgebra::CUDAWrappers::kernel']]], - ['masked_5fvector_5fbin_5fop_3c_20float_2c_20binop_5fsubtraction_20_3e_239',['masked_vector_bin_op< float, Binop_Subtraction >',['../namespaceLinearAlgebra_1_1CUDAWrappers_1_1kernel.html#a815c042b67651452d9f638f9f7e044aa',1,'LinearAlgebra::CUDAWrappers::kernel']]], - ['mass_5fand_5fderivative_5fmatrices_240',['mass_and_derivative_matrices',['../classTensorProductMatrixSymmetricSumCollection.html#a57ca41cf00b3cda7325b2fc39d298f40',1,'TensorProductMatrixSymmetricSumCollection']]], - ['mass_5fis_5ftime_5findependent_241',['mass_is_time_independent',['../classSUNDIALS_1_1ARKode_1_1AdditionalData.html#a61fbd7b7dc1a7240534b99acc8aeeae8',1,'SUNDIALS::ARKode::AdditionalData']]], - ['mass_5fmatrices_242',['mass_matrices',['../classTensorProductMatrixSymmetricSumCollection.html#a062994c27381c27a9d5b0c55d17ee62f',1,'TensorProductMatrixSymmetricSumCollection']]], - ['mass_5fmatrix_243',['mass_matrix',['../classTensorProductMatrixSymmetricSum.html#aad97876f4d0d2d6d431034e435c6e28a',1,'TensorProductMatrixSymmetricSum::mass_matrix()'],['../namespaceLocalIntegrators_1_1L2.html#a1c15243765304a803037988b5561627d',1,'LocalIntegrators::L2::mass_matrix()']]], - ['mass_5fpreconditioner_5fsetup_244',['mass_preconditioner_setup',['../classSUNDIALS_1_1ARKode.html#a04917d79304e77f5894c10f6b45f94f7',1,'SUNDIALS::ARKode']]], - ['mass_5fpreconditioner_5fsolve_245',['mass_preconditioner_solve',['../classSUNDIALS_1_1ARKode.html#ac5d7e6535bdd6706d1ffee95f59014c4',1,'SUNDIALS::ARKode']]], - ['mass_5fsolver_246',['mass_solver',['../classSUNDIALS_1_1ARKode.html#a7884fd6cdfbd98186e4ca97da177db94',1,'SUNDIALS::ARKode']]], - ['mass_5ftimes_5fsetup_247',['mass_times_setup',['../classSUNDIALS_1_1ARKode.html#aadf81a9f005d80a9467a33a1a64500ba',1,'SUNDIALS::ARKode']]], - ['mass_5ftimes_5fvector_248',['mass_times_vector',['../classSUNDIALS_1_1ARKode.html#ac25674d94b09546052bde6cbb47a3fe8',1,'SUNDIALS::ARKode']]], - ['massoperator_249',['MassOperator',['../classMatrixFreeOperators_1_1MassOperator.html#ac196c262be6804e314393b721e0c9ce2',1,'MatrixFreeOperators::MassOperator::MassOperator()'],['../classMatrixFreeOperators_1_1MassOperator.html',1,'MatrixFreeOperators::MassOperator< dim, fe_degree, n_q_points_1d, n_components, VectorType, VectorizedArrayType >']]], - ['match_250',['match',['../classPatterns_1_1PatternBase.html#ad47d15347ce93408f57c7e9d1c42ba68',1,'Patterns::PatternBase::match()'],['../classPatterns_1_1DirectoryName.html#ac141efc448bae5c6013438f662c0f5d4',1,'Patterns::DirectoryName::match()'],['../classPatterns_1_1FileName.html#a2780a2e3d34d5f631cac0054283ad473',1,'Patterns::FileName::match()'],['../classPatterns_1_1Anything.html#a456511a0bac354152b15f4327a9a7980',1,'Patterns::Anything::match()'],['../classPatterns_1_1MultipleSelection.html#a6f2f1dd20d574e17a0e4df0cac3928fd',1,'Patterns::MultipleSelection::match()'],['../classPatterns_1_1Tuple.html#a00ea4143a1e5b013bb56267f37467c93',1,'Patterns::Tuple::match()'],['../classPatterns_1_1Map.html#a3c372c4b5807d9d0b7fe3db02b12116a',1,'Patterns::Map::match()'],['../classPatterns_1_1List.html#aa6ef375ac4365fe63bbcd6a383d48802',1,'Patterns::List::match()'],['../classPatterns_1_1Selection.html#a69541dde5c608b19fe8da06967e389bd',1,'Patterns::Selection::match()'],['../classPatterns_1_1Double.html#ad37e92eb57daa6520d9c23bd0a6fa2a9',1,'Patterns::Double::match()'],['../classPatterns_1_1Integer.html#af5def98223840cf13d99c02c99981cac',1,'Patterns::Integer::match()']]], - ['match_5fat_5fstring_5fstart_251',['match_at_string_start',['../namespaceUtilities.html#a6b37ad8cfa930cb1ff91d68562553fec',1,'Utilities']]], - ['match_5fperiodic_5fface_5fpairs_252',['match_periodic_face_pairs',['../namespaceGridTools.html#aeb929fb0b689bd28136e869c0bda0068',1,'GridTools']]], - ['match_5fstep_253',['match_step',['../classPETScWrappers_1_1TimeStepperData.html#acbf982a67059f67865cc8f1784909933',1,'PETScWrappers::TimeStepperData']]], - ['match_5ft_254',['MATCH_T',['../structGridTools_1_1OrientationLookupTable_3_011_01_4.html#a920d6764e35951b31e2c91c8e0171eda',1,'GridTools::OrientationLookupTable< 1 >::MATCH_T()'],['../structGridTools_1_1OrientationLookupTable_3_012_01_4.html#a47dc455838f1ba1a5a9befb4ff7d1012',1,'GridTools::OrientationLookupTable< 2 >::MATCH_T()'],['../structGridTools_1_1OrientationLookupTable_3_013_01_4.html#ab031bbefbe3c8a15dec80d961c08bea5',1,'GridTools::OrientationLookupTable< 3 >::MATCH_T()']]], - ['material_5fid_255',['material_id',['../structGridOutFlags_1_1XFig.html#aaecb4a86f4ec075b39a2a23f117e84b1a2be3b925134b8c1eb5eb595ec13d2ceb',1,'GridOutFlags::XFig::material_id()'],['../structGridOutFlags_1_1Svg.html#acfa7a0ae88e7fe6f5a7cd7582bc4ca04ab9d45ec585bb5a6e20edf863d5876d91',1,'GridOutFlags::Svg::material_id()'],['../structCellData.html#a7d4a093cec27f2f8c947dd97d3aab290',1,'CellData::material_id()'],['../structinternal_1_1TriangulationImplementation_1_1TriaObjects_1_1BoundaryOrMaterialId.html#acda9afe21b71ee9ef6c4b5ad44285748',1,'internal::TriangulationImplementation::TriaObjects::BoundaryOrMaterialId::material_id()'],['../classCellAccessor.html#ae4769702cd7ab67a61b25778ea3021b2',1,'CellAccessor::material_id()'],['../namespacetypes.html#ae22a1b4da339109d8dc9cc2a112b1a69',1,'types::material_id()']]], - ['material_5fids_256',['material_ids',['../classIteratorFilters_1_1MaterialIdEqualTo.html#ad92205f873c6dfd52e65796144fda4c7',1,'IteratorFilters::MaterialIdEqualTo']]], - ['materialidequalto_257',['MaterialIdEqualTo',['../classIteratorFilters_1_1MaterialIdEqualTo.html',1,'IteratorFilters::MaterialIdEqualTo'],['../classIteratorFilters_1_1MaterialIdEqualTo.html#a1138396d34485980c5bfc796270dc8ea',1,'IteratorFilters::MaterialIdEqualTo::MaterialIdEqualTo(const std::set< types::material_id > &material_ids, const bool only_locally_owned=false)'],['../classIteratorFilters_1_1MaterialIdEqualTo.html#a9895d5d02a2fa5919db16de4a4fcc5eb',1,'IteratorFilters::MaterialIdEqualTo::MaterialIdEqualTo(const types::material_id material_id, const bool only_locally_owned=false)']]], - ['mathgl_258',['MathGL',['../structGridOutFlags_1_1MathGL.html',1,'GridOutFlags::MathGL'],['../structGridOutFlags_1_1MathGL.html#a3cb400029e64c3a53a9bef3ef64a08fd',1,'GridOutFlags::MathGL::MathGL()']]], - ['mathgl_259',['mathgl',['../classGridOut.html#af24aadcd00f93b7f428f44ecd40c44d9aac99c6da0bb41464fc09fe56e9edb52c',1,'GridOut']]], - ['mathgl_5fflags_260',['mathgl_flags',['../classGridOut.html#af8c043c4f05e3c64dda762abb92fc602',1,'GridOut']]], - ['matrices_261',['matrices',['../classMGSmootherPrecondition.html#ad3ece23c3ea2736e6b6c0e8c4e11192a',1,'MGSmootherPrecondition::matrices()'],['../classMGSmootherRelaxation.html#a1e5daea1d879c3fac61a9c6a5c99f04b',1,'MGSmootherRelaxation::matrices()'],['../classmg_1_1Matrix.html#a9cb6fe5c28590273e9fceb06ceb16033',1,'mg::Matrix::matrices()'],['../classMGSmootherBlock.html#afadaf89e2e66c0733be62778f526247e',1,'MGSmootherBlock::matrices()'],['../structMeshWorker_1_1CopyData.html#a52de1dfaaa5975b2b10241c15a7c8f66',1,'MeshWorker::CopyData::matrices()'],['../classMeshWorker_1_1Assembler_1_1MGMatrixLocalBlocksToGlobalBlocks.html#a13ccc561c22e31a953ac16147012469e',1,'MeshWorker::Assembler::MGMatrixLocalBlocksToGlobalBlocks::matrices()'],['../classMeshWorker_1_1Assembler_1_1MatrixLocalBlocksToGlobalBlocks.html#a27c3d1134703aacc6c1d7095a062a0f0',1,'MeshWorker::Assembler::MatrixLocalBlocksToGlobalBlocks::matrices()'],['../classMGMatrixBlockVector.html#abcdb4921c7d449544bfe7dbb10fe8d7f',1,'MGMatrixBlockVector::matrices()']]], - ['matrices_2eh_262',['matrices.h',['../matrices_8h.html',1,'']]], - ['matrices_5fin_263',['matrices_in',['../classMGMatrixBlockVector.html#addb3d25355653011f61ab9934eae6316',1,'MGMatrixBlockVector']]], - ['matrices_5fout_264',['matrices_out',['../classMGMatrixBlockVector.html#a549d39995ca7ad446c4f2f9404c7615b',1,'MGMatrixBlockVector']]], - ['matrix_265',['matrix',['../classPreconditionBlockJacobi_1_1const__iterator_1_1Accessor.html#a3cef14f57e8589b44fac436cd241c8c1',1,'PreconditionBlockJacobi::const_iterator::Accessor::matrix()'],['../classPETScWrappers_1_1MatrixIterators_1_1const__iterator_1_1Accessor.html#a13e2b9b5690e582e8393d571fc8e4124',1,'PETScWrappers::MatrixIterators::const_iterator::Accessor::matrix()'],['../classPreconditionUseMatrix.html#a748f7564ff371a3361d82d47e224219d',1,'PreconditionUseMatrix::matrix()'],['../classPETScWrappers_1_1MatrixBase.html#abfce46e53089351cc7fe6b9ea44e167f',1,'PETScWrappers::MatrixBase::matrix()'],['../classMatrixBlock.html#a33610e6dfbd57d6ff0aa23e8582676bf',1,'MatrixBlock::matrix()'],['../classPreconditionLU.html#a544b1669d12074529935a79b9248c059',1,'PreconditionLU::matrix()'],['../classChunkSparseMatrixIterators_1_1Accessor_3_01number_00_01false_01_4.html#abfcc6d627dea5c5f7af780756bb5a3a1',1,'ChunkSparseMatrixIterators::Accessor< number, false >::matrix()'],['../classChunkSparseMatrixIterators_1_1Accessor_3_01number_00_01true_01_4.html#a0d8e7c7f488383f1ac27c01efcfc22f7',1,'ChunkSparseMatrixIterators::Accessor< number, true >::matrix()'],['../classBlockMatrixIterators_1_1Accessor_3_01BlockMatrixType_00_01true_01_4.html#a8f7c00159d7ddd5aa43bbcd5c45b1309',1,'BlockMatrixIterators::Accessor< BlockMatrixType, true >::matrix()'],['../classBlockMatrixIterators_1_1Accessor_3_01BlockMatrixType_00_01false_01_4.html#a83710fb68c9054d0310fbaea03e80c7b',1,'BlockMatrixIterators::Accessor< BlockMatrixType, false >::matrix()'],['../structGridTools_1_1PeriodicFacePair.html#a54ce9023e2a3586892b5d6a67604222e',1,'GridTools::PeriodicFacePair::matrix()']]], - ['matrix_266',['Matrix',['../classmg_1_1Matrix.html#ae6afc9bcbcf4900c4229ed1cd99444b7',1,'mg::Matrix::Matrix(const MGLevelObject< MatrixType > &M)'],['../classmg_1_1Matrix.html#ab928de28e163a0427a3d840810e9193f',1,'mg::Matrix::Matrix()=default'],['../structinternal_1_1MatrixSelector_3_1_1PETScWrappers_1_1MPI_1_1Vector_01_4.html#a529d2463f17be62b69407fc419d8fc69',1,'internal::MatrixSelector<::PETScWrappers::MPI::Vector >::Matrix()'],['../structinternal_1_1MatrixSelector_3_1_1LinearAlgebra_1_1EpetraWrappers_1_1Vector_01_4.html#ada8ca20ff6f64badb86c40a7ad515d87',1,'internal::MatrixSelector<::LinearAlgebra::EpetraWrappers::Vector >::Matrix()'],['../structinternal_1_1MatrixSelector_3_1_1LinearAlgebra_1_1TpetraWrappers_1_1Vector_3_01Number_01_4_01_4.html#a23a62494194fb9800948cc78e2bf4ede',1,'internal::MatrixSelector<::LinearAlgebra::TpetraWrappers::Vector< Number > >::Matrix()']]], - ['matrix_267',['matrix',['../namespaceLAPACKSupport.html#a1a9009db0d9a77923a7031b549b9b638a5bc7c54a9c20485772672825c6a73003',1,'LAPACKSupport']]], - ['matrix_268',['Matrix',['../structinternal_1_1MatrixSelector_3_1_1TrilinosWrappers_1_1MPI_1_1Vector_01_4.html#a1455c06c40ad7f7def94dcd3510549d8',1,'internal::MatrixSelector<::TrilinosWrappers::MPI::Vector >::Matrix()'],['../structinternal_1_1MatrixSelector_3_01LinearAlgebra_1_1distributed_1_1Vector_3_01Number_01_4_01_4.html#a3846992037082476a91ef98b405a7169',1,'internal::MatrixSelector< LinearAlgebra::distributed::Vector< Number > >::Matrix()'],['../structinternal_1_1MatrixSelector.html#a9430f1c6e4fa1c76dddd9637c08dfc6d',1,'internal::MatrixSelector::Matrix()']]], - ['matrix_269',['matrix',['../classSparseMatrixIterators_1_1Accessor_3_01number_00_01false_01_4.html#a27461953245ca5486473d475d29a8e6f',1,'SparseMatrixIterators::Accessor< number, false >::matrix()'],['../classMeshWorker_1_1LocalResults.html#a6592ecbdca645720efdd6c157fec2e0b',1,'MeshWorker::LocalResults::matrix(const unsigned int i, const bool external=false) const'],['../classMeshWorker_1_1LocalResults.html#a06c5d817ce47a4c26966df1cdcebeac4',1,'MeshWorker::LocalResults::matrix(const unsigned int i, const bool external=false)'],['../classMatrixBlockVector.html#ae6439447897ca2c7d2dca52a2edadb5b',1,'MatrixBlockVector::matrix()'],['../classmg_1_1SparseMatrixCollection.html#aa686991c6cfe190a42ea1483920a0f87',1,'mg::SparseMatrixCollection::matrix()'],['../classMultigrid.html#a5031b0db85f6554cf747a3300647fe24',1,'Multigrid::matrix()'],['../classMGMatrixSelect.html#a80d72ad9bce8bb9f2b4efdeb8c1138e6',1,'MGMatrixSelect::matrix()'],['../classMGCoarseGridSVD.html#a4f687c81abb53d340d7345f636152e49',1,'MGCoarseGridSVD::matrix()'],['../classMGCoarseGridIterativeSolver.html#a1f3fad551ab1b9f4ee69d41fd3af33ca',1,'MGCoarseGridIterativeSolver::matrix()'],['../classMeshWorker_1_1Assembler_1_1MGMatrixSimple.html#a67a6b6ac5efdf7e28404b625c2ea5875',1,'MeshWorker::Assembler::MGMatrixSimple::matrix()'],['../classTrilinosWrappers_1_1SparseMatrix.html#a1f3f26ae4997382b25a2eb9604200a75',1,'TrilinosWrappers::SparseMatrix::matrix()'],['../classSparseMatrixIterators_1_1Accessor_3_01number_00_01true_01_4.html#a08847ee756580936dada22b257187289',1,'SparseMatrixIterators::Accessor< number, true >::matrix()'],['../classSparseMatrixEZ_1_1const__iterator_1_1Accessor.html#ae524ba35a20b5e1e38302a0f574797a5',1,'SparseMatrixEZ::const_iterator::Accessor::matrix()'],['../classSparseVanka.html#a1e8f09281aaf4fbfbf90093edbf02447',1,'SparseVanka::matrix()'],['../classTrilinosWrappers_1_1SparseMatrixIterators_1_1AccessorBase.html#a9815d042107261477f4d3b1749b99fdb',1,'TrilinosWrappers::SparseMatrixIterators::AccessorBase::matrix()'],['../classMeshWorker_1_1Assembler_1_1MatrixSimple.html#ada739bd357b4496deac6aeaa7b2b62a4',1,'MeshWorker::Assembler::MatrixSimple::matrix()']]], - ['matrix_270',['Matrix',['../classmg_1_1Matrix.html',1,'mg']]], - ['matrix_20classes_271',['Matrix classes',['../group__Matrices.html',1,'']]], - ['matrix_2dfree_20infrastructure_272',['Matrix-free infrastructure',['../group__matrixfree.html',1,'']]], - ['matrix_5fblock_2eh_273',['matrix_block.h',['../matrix__block_8h.html',1,'']]], - ['matrix_5fcreator_2ecc_274',['matrix_creator.cc',['../matrix__creator_8cc.html',1,'']]], - ['matrix_5fcreator_2eh_275',['matrix_creator.h',['../matrix__creator_8h.html',1,'']]], - ['matrix_5fcreator_5finst2_2ecc_276',['matrix_creator_inst2.cc',['../matrix__creator__inst2_8cc.html',1,'']]], - ['matrix_5fcreator_5finst3_2ecc_277',['matrix_creator_inst3.cc',['../matrix__creator__inst3_8cc.html',1,'']]], - ['matrix_5fdofs_278',['matrix_dofs',['../classparallel_1_1distributed_1_1ContinuousQuadratureDataTransfer.html#a7f603abf13b92611fd0176cfb02de33b',1,'parallel::distributed::ContinuousQuadratureDataTransfer']]], - ['matrix_5fdofs_5fchild_279',['matrix_dofs_child',['../classparallel_1_1distributed_1_1ContinuousQuadratureDataTransfer.html#ad6e8520841f638f06b72260812474fc0',1,'parallel::distributed::ContinuousQuadratureDataTransfer']]], - ['matrix_5fdown_280',['matrix_down',['../classmg_1_1SparseMatrixCollection.html#af47bb6ba820641cace970a68958a9599',1,'mg::SparseMatrixCollection']]], /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_d.js differs (ASCII text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_d.js 2023-07-22 00:00:00.000000000 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/all_d.js 2023-07-22 00:00:00.000000000 +0000 @@ -73,17 +73,17 @@ ['cell_5findex_70',['cell_index',['../grid__tools_8cc.html#aff11e57deb99b39b7d7d26cf866798f2',1,'grid_tools.cc']]], ['cell_5findex_5foffset_71',['cell_index_offset',['../classNonMatching_1_1MappingInfo.html#a4125347a69d0d936abdca278d5155979',1,'NonMatching::MappingInfo']]], ['cell_5findex_5fto_5fcompressed_5fcell_5findex_72',['cell_index_to_compressed_cell_index',['../classNonMatching_1_1MappingInfo.html#aa32e01647233849f826c54adce107826',1,'NonMatching::MappingInfo']]], - ['cell_5finfos_73',['cell_infos',['../structTriangulationDescription_1_1Description.html#a0115345a6214de7ca9b744409c674295',1,'TriangulationDescription::Description::cell_infos()'],['../tria__description_8cc.html#a89bd9bb4763625172ac11e4ded6bedc6',1,'cell_infos(): tria_description.cc']]], + ['cell_5finfos_73',['cell_infos',['../tria__description_8cc.html#a89bd9bb4763625172ac11e4ded6bedc6',1,'cell_infos(): tria_description.cc'],['../structTriangulationDescription_1_1Description.html#a0115345a6214de7ca9b744409c674295',1,'TriangulationDescription::Description::cell_infos()']]], ['cell_5finvalid_74',['CELL_INVALID',['../classTriangulation.html#a1f047c753e5299ed179b042b1d014ee2a77e3cf6150ed62cd551424de92cc880b',1,'Triangulation']]], ['cell_5fis_5fset_75',['cell_is_set',['../classNonMatching_1_1internal_1_1DiscreteQuadratureGeneratorImplementation_1_1RefSpaceFEFieldFunction.html#a4ba09d92b623f96c1d1ebfb3136e7249',1,'NonMatching::internal::DiscreteQuadratureGeneratorImplementation::RefSpaceFEFieldFunction']]], - ['cell_5fiterator_76',['cell_iterator',['../classDataOut.html#a994bb1dbfacf7c835f33efd0e75b079b',1,'DataOut::cell_iterator()'],['../structinternal_1_1DoFHandlerImplementation_1_1Iterators_3_013_00_01spacedim_00_01lda_01_4.html#ae010d4dcc8b5beb31eb13d285fa6492f',1,'internal::DoFHandlerImplementation::Iterators< 3, spacedim, lda >::cell_iterator()'],['../classInterGridMap.html#a3fe79b8f5344562b652fd152e7e4dd52',1,'InterGridMap::cell_iterator()'],['../classparallel_1_1fullydistributed_1_1Triangulation.html#a04043b4c8031c526783448969d01cf53',1,'parallel::fullydistributed::Triangulation::cell_iterator()'],['../classparallel_1_1shared_1_1Triangulation.html#a653dcbaa5ce9e8e8f11949bc3cab5b0c',1,'parallel::shared::Triangulation::cell_iterator()'],['../group__Iterators.html#ga48cef91f67c38d6ec17912922de00f90',1,'parallel::distributed::Triangulation::cell_iterator()'],['../classparallel_1_1DistributedTriangulationBase.html#acb254bd3c238056d5c44627167944253',1,'parallel::DistributedTriangulationBase::cell_iterator()'],['../group__Iterators.html#ga32b2a057d9abd2e1752bf8a3cb88e644',1,'DoFHandler::cell_iterator()'],['../structinternal_1_1DoFHandlerImplementation_1_1Iterators_3_011_00_01spacedim_00_01lda_01_4.html#aa840c9d3457150d12df4d96c405ed32d',1,'internal::DoFHandlerImplementation::Iterators< 1, spacedim, lda >::cell_iterator()'],['../structinternal_1_1DoFHandlerImplementation_1_1Iterators_3_012_00_01spacedim_00_01lda_01_4.html#ae45e41094689b63c542feaf18a8403cf',1,'internal::DoFHandlerImplementation::Iterators< 2, spacedim, lda >::cell_iterator()'],['../group__Iterators.html#ga997d61ac77777cdc2be3ae934b1f7cdb',1,'Triangulation::cell_iterator()'],['../classDataOut__DoFData.html#a8e258e00039c53ebb000c3de4a257fcf',1,'DataOut_DoFData::cell_iterator()'],['../classDataOutRotation.html#a51cc403c22f03c93f10f92c15f2ce0ed',1,'DataOutRotation::cell_iterator()'],['../classDataOutFaces.html#a2e21509efc66035d0edd456ee57af48b',1,'DataOutFaces::cell_iterator()']]], + ['cell_5fiterator_76',['cell_iterator',['../classDataOutRotation.html#a51cc403c22f03c93f10f92c15f2ce0ed',1,'DataOutRotation::cell_iterator()'],['../structinternal_1_1DoFHandlerImplementation_1_1Iterators_3_013_00_01spacedim_00_01lda_01_4.html#ae010d4dcc8b5beb31eb13d285fa6492f',1,'internal::DoFHandlerImplementation::Iterators< 3, spacedim, lda >::cell_iterator()'],['../classInterGridMap.html#a3fe79b8f5344562b652fd152e7e4dd52',1,'InterGridMap::cell_iterator()'],['../classparallel_1_1fullydistributed_1_1Triangulation.html#a04043b4c8031c526783448969d01cf53',1,'parallel::fullydistributed::Triangulation::cell_iterator()'],['../classparallel_1_1shared_1_1Triangulation.html#a653dcbaa5ce9e8e8f11949bc3cab5b0c',1,'parallel::shared::Triangulation::cell_iterator()'],['../group__Iterators.html#ga48cef91f67c38d6ec17912922de00f90',1,'parallel::distributed::Triangulation::cell_iterator()'],['../classparallel_1_1DistributedTriangulationBase.html#acb254bd3c238056d5c44627167944253',1,'parallel::DistributedTriangulationBase::cell_iterator()'],['../group__Iterators.html#ga32b2a057d9abd2e1752bf8a3cb88e644',1,'DoFHandler::cell_iterator()'],['../structinternal_1_1DoFHandlerImplementation_1_1Iterators_3_011_00_01spacedim_00_01lda_01_4.html#aa840c9d3457150d12df4d96c405ed32d',1,'internal::DoFHandlerImplementation::Iterators< 1, spacedim, lda >::cell_iterator()'],['../group__Iterators.html#ga997d61ac77777cdc2be3ae934b1f7cdb',1,'Triangulation::cell_iterator()'],['../classDataOut.html#a994bb1dbfacf7c835f33efd0e75b079b',1,'DataOut::cell_iterator()'],['../structinternal_1_1DoFHandlerImplementation_1_1Iterators_3_012_00_01spacedim_00_01lda_01_4.html#ae45e41094689b63c542feaf18a8403cf',1,'internal::DoFHandlerImplementation::Iterators< 2, spacedim, lda >::cell_iterator()'],['../classDataOutFaces.html#a2e21509efc66035d0edd456ee57af48b',1,'DataOutFaces::cell_iterator()'],['../classDataOut__DoFData.html#a8e258e00039c53ebb000c3de4a257fcf',1,'DataOut_DoFData::cell_iterator()']]], ['cell_5fiterator_5ffunction_77',['cell_iterator_function',['../structColorEnriched_1_1Helper.html#a92465c9194c84c70762b7391c0bab240',1,'ColorEnriched::Helper']]], ['cell_5fiterators_78',['cell_iterators',['../group__CPP11.html#ga88342d8dfa248643d37ae09ed34a4bb8',1,'DoFHandler::cell_iterators()'],['../group__CPP11.html#gac216dee8e3dc84da3dfe18028a21923e',1,'Triangulation::cell_iterators()']]], ['cell_5fiterators_5fon_5flevel_79',['cell_iterators_on_level',['../group__CPP11.html#ga3a2430c530494b0a95e06c99b51691d4',1,'DoFHandler::cell_iterators_on_level()'],['../group__CPP11.html#gaa2218771cb384a5c475f50cfe0a8b599',1,'Triangulation::cell_iterators_on_level()']]], ['cell_5flevel_5findex_80',['cell_level_index',['../classMatrixFree.html#a6ccb8c2689c4029ccf44dacf47c4d224',1,'MatrixFree']]], ['cell_5flevel_5findex_5fend_5flocal_81',['cell_level_index_end_local',['../classMatrixFree.html#aebd8b73ecd3843be97bc6c62a91550e8',1,'MatrixFree']]], ['cell_5flocations_82',['cell_locations',['../classNonMatching_1_1MeshClassifier.html#ad0ea17c7428187c1cdc675c915f81775',1,'NonMatching::MeshClassifier']]], - ['cell_5floop_83',['cell_loop',['../classCUDAWrappers_1_1MatrixFree.html#afe586445fc6483ed991167d80ce39120',1,'CUDAWrappers::MatrixFree::cell_loop()'],['../classMatrixFree.html#abc204ec41ead1b5060f47ef3a5a066d7',1,'MatrixFree::cell_loop(const std::function< void(const MatrixFree< dim, Number, VectorizedArrayType > &, OutVector &, const InVector &, const std::pair< unsigned int, unsigned int > &)> &cell_operation, OutVector &dst, const InVector &src, const bool zero_dst_vector=false) const'],['../classMatrixFree.html#aaa941c80d60b2cd987660d2d04587fde',1,'MatrixFree::cell_loop(void(CLASS::*cell_operation)(const MatrixFree &, OutVector &, const InVector &, const std::pair< unsigned int, unsigned int > &) const, const CLASS *owning_class, OutVector &dst, const InVector &src, const bool zero_dst_vector=false) const'],['../classMatrixFreeTools_1_1ElementActivationAndDeactivationMatrixFree.html#a5f20bf9fc143c27d6e726e29406196a0',1,'MatrixFreeTools::ElementActivationAndDeactivationMatrixFree::cell_loop()'],['../classMatrixFree.html#aca4e2ec1389ae3f7abd7c0552f782f47',1,'MatrixFree::cell_loop(void(CLASS::*cell_operation)(const MatrixFree &, OutVector &, const InVector &, const std::pair< unsigned int, unsigned int > &), CLASS *owning_class, OutVector &dst, const InVector &src, const bool zero_dst_vector=false) const'],['../classMatrixFree.html#a6a53b93080a15c49d5513f09fc6bbb5d',1,'MatrixFree::cell_loop(void(CLASS::*cell_operation)(const MatrixFree &, OutVector &, const InVector &, const std::pair< unsigned int, unsigned int > &) const, const CLASS *owning_class, OutVector &dst, const InVector &src, const std::function< void(const unsigned int, const unsigned int)> &operation_before_loop, const std::function< void(const unsigned int, const unsigned int)> &operation_after_loop, const unsigned int dof_handler_index_pre_post=0) const'],['../classMatrixFree.html#a2c3b0bd3cad76dc2e3957f205c6138ac',1,'MatrixFree::cell_loop(const std::function< void(const MatrixFree< dim, Number, VectorizedArrayType > &, OutVector &, const InVector &, const std::pair< unsigned int, unsigned int > &)> &cell_operation, OutVector &dst, const InVector &src, const std::function< void(const unsigned int, const unsigned int)> &operation_before_loop, const std::function< void(const unsigned int, const unsigned int)> &operation_after_loop, const unsigned int dof_handler_index_pre_post=0) const'],['../classMatrixFree.html#a4299fd60761d1be3cc6461d72c265577',1,'MatrixFree::cell_loop(void(CLASS::*cell_operation)(const MatrixFree &, OutVector &, const InVector &, const std::pair< unsigned int, unsigned int > &), CLASS *owning_class, OutVector &dst, const InVector &src, const std::function< void(const unsigned int, const unsigned int)> &operation_before_loop, const std::function< void(const unsigned int, const unsigned int)> &operation_after_loop, const unsigned int dof_handler_index_pre_post=0) const']]], + ['cell_5floop_83',['cell_loop',['../classCUDAWrappers_1_1MatrixFree.html#afe586445fc6483ed991167d80ce39120',1,'CUDAWrappers::MatrixFree::cell_loop()'],['../classMatrixFree.html#abc204ec41ead1b5060f47ef3a5a066d7',1,'MatrixFree::cell_loop(const std::function< void(const MatrixFree< dim, Number, VectorizedArrayType > &, OutVector &, const InVector &, const std::pair< unsigned int, unsigned int > &)> &cell_operation, OutVector &dst, const InVector &src, const bool zero_dst_vector=false) const'],['../classMatrixFree.html#aaa941c80d60b2cd987660d2d04587fde',1,'MatrixFree::cell_loop(void(CLASS::*cell_operation)(const MatrixFree &, OutVector &, const InVector &, const std::pair< unsigned int, unsigned int > &) const, const CLASS *owning_class, OutVector &dst, const InVector &src, const bool zero_dst_vector=false) const'],['../classMatrixFree.html#aca4e2ec1389ae3f7abd7c0552f782f47',1,'MatrixFree::cell_loop(void(CLASS::*cell_operation)(const MatrixFree &, OutVector &, const InVector &, const std::pair< unsigned int, unsigned int > &), CLASS *owning_class, OutVector &dst, const InVector &src, const bool zero_dst_vector=false) const'],['../classMatrixFree.html#a6a53b93080a15c49d5513f09fc6bbb5d',1,'MatrixFree::cell_loop(void(CLASS::*cell_operation)(const MatrixFree &, OutVector &, const InVector &, const std::pair< unsigned int, unsigned int > &) const, const CLASS *owning_class, OutVector &dst, const InVector &src, const std::function< void(const unsigned int, const unsigned int)> &operation_before_loop, const std::function< void(const unsigned int, const unsigned int)> &operation_after_loop, const unsigned int dof_handler_index_pre_post=0) const'],['../classMatrixFreeTools_1_1ElementActivationAndDeactivationMatrixFree.html#a5f20bf9fc143c27d6e726e29406196a0',1,'MatrixFreeTools::ElementActivationAndDeactivationMatrixFree::cell_loop()'],['../classMatrixFree.html#a2c3b0bd3cad76dc2e3957f205c6138ac',1,'MatrixFree::cell_loop(const std::function< void(const MatrixFree< dim, Number, VectorizedArrayType > &, OutVector &, const InVector &, const std::pair< unsigned int, unsigned int > &)> &cell_operation, OutVector &dst, const InVector &src, const std::function< void(const unsigned int, const unsigned int)> &operation_before_loop, const std::function< void(const unsigned int, const unsigned int)> &operation_after_loop, const unsigned int dof_handler_index_pre_post=0) const'],['../classMatrixFree.html#a4299fd60761d1be3cc6461d72c265577',1,'MatrixFree::cell_loop(void(CLASS::*cell_operation)(const MatrixFree &, OutVector &, const InVector &, const std::pair< unsigned int, unsigned int > &), CLASS *owning_class, OutVector &dst, const InVector &src, const std::function< void(const unsigned int, const unsigned int)> &operation_before_loop, const std::function< void(const unsigned int, const unsigned int)> &operation_after_loop, const unsigned int dof_handler_index_pre_post=0) const']]], ['cell_5floop_5fpost_5flist_84',['cell_loop_post_list',['../structinternal_1_1MatrixFreeFunctions_1_1DoFInfo.html#aef140efba60e6dc942773cef26a2ba9c',1,'internal::MatrixFreeFunctions::DoFInfo']]], ['cell_5floop_5fpost_5flist_5findex_85',['cell_loop_post_list_index',['../structinternal_1_1MatrixFreeFunctions_1_1DoFInfo.html#a3fab8413e642935ee3ce156d3d3c3fda',1,'internal::MatrixFreeFunctions::DoFInfo']]], ['cell_5floop_5fpost_5frange_86',['cell_loop_post_range',['../structinternal_1_1MFWorkerInterface.html#aba160091d94b4ac79b642c0c7ef59d05',1,'internal::MFWorkerInterface']]], @@ -271,17 +271,17 @@ ['check_5fcell_5fsimilarity_268',['check_cell_similarity',['../classFEValuesBase.html#a5c38a7d7c3a6b384ad5b46f38248524d',1,'FEValuesBase']]], ['check_5fconsistency_269',['check_consistency',['../structSubCellData.html#ab203a11bd16ffe2e7f252fdfd8e31ed9',1,'SubCellData']]], ['check_5fequality_270',['check_equality',['../namespaceAdaptationStrategies_1_1Coarsening.html#a1a0efe1afd282f131df6acf0f9a94066',1,'AdaptationStrategies::Coarsening']]], - ['check_5fexception_271',['check_exception',['../namespaceHDF5_1_1internal_1_1HDF5ObjectImplementation.html#a363ced1c2ead1d3989de33ed64a622cf',1,'HDF5::internal::HDF5ObjectImplementation::check_exception()'],['../namespaceUtilities_1_1MPI_1_1internal_1_1CollectiveMutexImplementation.html#a2d8f92229e3fbe0bb4d6228ffd3e651d',1,'Utilities::MPI::internal::CollectiveMutexImplementation::check_exception()']]], + ['check_5fexception_271',['check_exception',['../namespaceUtilities_1_1MPI_1_1internal_1_1CollectiveMutexImplementation.html#a2d8f92229e3fbe0bb4d6228ffd3e651d',1,'Utilities::MPI::internal::CollectiveMutexImplementation::check_exception()'],['../namespaceHDF5_1_1internal_1_1HDF5ObjectImplementation.html#a363ced1c2ead1d3989de33ed64a622cf',1,'HDF5::internal::HDF5ObjectImplementation::check_exception()']]], ['check_5ffailure_272',['check_failure',['../classSolverControl.html#a8aeac25becebcd520b163cdc4cd78a23',1,'SolverControl']]], ['check_5ffor_5fdistorted_5fcells_273',['check_for_distorted_cells',['../classTriangulation.html#a5c55287cc4c709190b521fd98a4f5e02',1,'Triangulation']]], ['check_5fiteration_5fstatus_274',['check_iteration_status',['../classTrilinosWrappers_1_1NOXSolver.html#ad78d3ef4cb170f356058104e0180bfbc',1,'TrilinosWrappers::NOXSolver']]], ['check_5fno_5fsubscribers_275',['check_no_subscribers',['../classSubscriptor.html#a300c593ea0f9422dcbce1445903e6c12',1,'Subscriptor']]], ['check_5ftemplate_5farguments_276',['check_template_arguments',['../classFEEvaluation.html#afc33f44fa5f8894cef597acdae4a0940',1,'FEEvaluation']]], ['check_5fvector_5fcompatibility_277',['check_vector_compatibility',['../namespaceinternal.html#a34c5fb12892625b30ac573fd71f64686',1,'internal']]], - ['check_5fvector_5fmap_5fequality_278',['check_vector_map_equality',['../namespaceTrilinosWrappers_1_1internal.html#abd7357ee5a7b1e3e40745fd95c6cb24c',1,'TrilinosWrappers::internal::check_vector_map_equality()'],['../namespaceTrilinosWrappers_1_1internal_1_1SparseMatrixImplementation.html#a20049485ea0ad53ec57ce05eea02fcc5',1,'TrilinosWrappers::internal::SparseMatrixImplementation::check_vector_map_equality(const Epetra_CrsMatrix &, const VectorType &, const VectorType &)'],['../namespaceTrilinosWrappers_1_1internal_1_1SparseMatrixImplementation.html#af20357a78d8fa1b8df2cd7671baa604b',1,'TrilinosWrappers::internal::SparseMatrixImplementation::check_vector_map_equality(const Epetra_CrsMatrix &m, const TrilinosWrappers::MPI::Vector &in, const TrilinosWrappers::MPI::Vector &out)'],['../namespaceTrilinosWrappers_1_1internal.html#ad62c5e86494d81997e742ecb8c9c36d7',1,'TrilinosWrappers::internal::check_vector_map_equality()']]], + ['check_5fvector_5fmap_5fequality_278',['check_vector_map_equality',['../namespaceTrilinosWrappers_1_1internal_1_1SparseMatrixImplementation.html#a20049485ea0ad53ec57ce05eea02fcc5',1,'TrilinosWrappers::internal::SparseMatrixImplementation::check_vector_map_equality()'],['../namespaceTrilinosWrappers_1_1internal.html#ad62c5e86494d81997e742ecb8c9c36d7',1,'TrilinosWrappers::internal::check_vector_map_equality(const Epetra_Operator &op, const Epetra_MultiVector &src, const Epetra_MultiVector &dst, const bool transpose)'],['../namespaceTrilinosWrappers_1_1internal.html#abd7357ee5a7b1e3e40745fd95c6cb24c',1,'TrilinosWrappers::internal::check_vector_map_equality(const Epetra_CrsMatrix &mtrx, const Epetra_MultiVector &src, const Epetra_MultiVector &dst, const bool transpose)'],['../namespaceTrilinosWrappers_1_1internal_1_1SparseMatrixImplementation.html#af20357a78d8fa1b8df2cd7671baa604b',1,'TrilinosWrappers::internal::SparseMatrixImplementation::check_vector_map_equality()']]], ['checksum_279',['checksum',['../structinternal_1_1p4est_1_1functions_3_013_01_4.html#a3afefbc22ae9712583e3cd6725986c64',1,'internal::p4est::functions< 3 >::checksum()'],['../structinternal_1_1p4est_1_1functions_3_012_01_4.html#a6c0e1a1e0a20d16e2c0a58881eda53e5',1,'internal::p4est::functions< 2 >::checksum()']]], ['cheese_280',['cheese',['../namespaceGridGenerator.html#a76c54698f4666a44ac3982ee62f87ee9',1,'GridGenerator']]], - ['child_281',['child',['../classDoFAccessor.html#a46d132109f1a1bcab13f83077d3d986f',1,'DoFAccessor::child()'],['../classDoFAccessor_3_010_00_011_00_01spacedim_00_01level__dof__access_01_4.html#ad4d4b519987ef5c3982ec7361a4a47fa',1,'DoFAccessor< 0, 1, spacedim, level_dof_access >::child()'],['../classBoundingBox.html#aa17acb87b18e334f0462c2c029b6eb2e',1,'BoundingBox::child()'],['../classDoFCellAccessor.html#a2d99c7f8b643fa032649a887aa0287b4',1,'DoFCellAccessor::child()'],['../classTriaAccessor.html#a5b7f9b9ff5f86b3bcf50336dcbe09955',1,'TriaAccessor::child()'],['../classTriaAccessor_3_010_00_01dim_00_01spacedim_01_4.html#a4121ee3defb1d11b7c80fd3a74186468',1,'TriaAccessor< 0, dim, spacedim >::child()'],['../classTriaAccessor_3_010_00_011_00_01spacedim_01_4.html#a5ca94009a45e86365ac63e0ca443445b',1,'TriaAccessor< 0, 1, spacedim >::child()'],['../classCellAccessor.html#a593a63d70458ee00925677e33f78ea7c',1,'CellAccessor::child()']]], + ['child_281',['child',['../classBoundingBox.html#aa17acb87b18e334f0462c2c029b6eb2e',1,'BoundingBox::child()'],['../classDoFAccessor.html#a46d132109f1a1bcab13f83077d3d986f',1,'DoFAccessor::child()'],['../classDoFAccessor_3_010_00_011_00_01spacedim_00_01level__dof__access_01_4.html#ad4d4b519987ef5c3982ec7361a4a47fa',1,'DoFAccessor< 0, 1, spacedim, level_dof_access >::child()'],['../classDoFCellAccessor.html#a2d99c7f8b643fa032649a887aa0287b4',1,'DoFCellAccessor::child()'],['../classTriaAccessor.html#a5b7f9b9ff5f86b3bcf50336dcbe09955',1,'TriaAccessor::child()'],['../classTriaAccessor_3_010_00_01dim_00_01spacedim_01_4.html#a4121ee3defb1d11b7c80fd3a74186468',1,'TriaAccessor< 0, dim, spacedim >::child()'],['../classTriaAccessor_3_010_00_011_00_01spacedim_01_4.html#a5ca94009a45e86365ac63e0ca443445b',1,'TriaAccessor< 0, 1, spacedim >::child()'],['../classCellAccessor.html#a593a63d70458ee00925677e33f78ea7c',1,'CellAccessor::child()']]], ['child_5fcell_5ffrom_5fpoint_282',['child_cell_from_point',['../structGeometryInfo.html#a0102b28ec69c4bc6b2b0337715c09bc8',1,'GeometryInfo']]], ['child_5fcell_5fon_5fface_283',['child_cell_on_face',['../classReferenceCell.html#a0ec5f8daa7a3f09a3d1a018df00b9374',1,'ReferenceCell::child_cell_on_face()'],['../structGeometryInfo.html#a1263120c3a820d6b17b4055e6e0ef9f1',1,'GeometryInfo::child_cell_on_face()']]], ['child_5findex_284',['child_index',['../classTriaAccessor.html#acd7551fc85831a3fd4d5cd339b81d8c6',1,'TriaAccessor::child_index()'],['../classTriaAccessor_3_010_00_011_00_01spacedim_01_4.html#abcf3dcfe8b0bffe2d10a6e0a0e110633',1,'TriaAccessor< 0, 1, spacedim >::child_index()'],['../classTriaAccessor_3_010_00_01dim_00_01spacedim_01_4.html#a5284451f25682f4c96b651b077c202c5',1,'TriaAccessor< 0, dim, spacedim >::child_index()']]], @@ -454,7 +454,7 @@ ['combiner_5ftype_451',['combiner_type',['../classTriangulation_1_1Signals_1_1LegacySignal.html#a84bd6e3e654cd07b461aaccf4a29b490',1,'Triangulation::Signals::LegacySignal']]], ['comm_452',['comm',['../tria__description_8cc.html#a6f32780aff3305d96aef06c2a769ba0b',1,'comm(): tria_description.cc'],['../classinternal_1_1MatrixFreeFunctions_1_1VectorDataExchange_1_1Full.html#ac4ece5fcf64b1128b80238400ee97933',1,'internal::MatrixFreeFunctions::VectorDataExchange::Full::comm()'],['../classLinearAlgebra_1_1TpetraWrappers_1_1CommunicationPattern.html#a5d700df1f6ccf0d24c9650aecfa16030',1,'LinearAlgebra::TpetraWrappers::CommunicationPattern::comm()'],['../classLinearAlgebra_1_1EpetraWrappers_1_1CommunicationPattern.html#aa84c417fe8a924d12948250f62e2721a',1,'LinearAlgebra::EpetraWrappers::CommunicationPattern::comm()'],['../structTriangulationDescription_1_1Description.html#a104402495aed2ffe73a56972c76ae8dd',1,'TriangulationDescription::Description::comm()'],['../classUtilities_1_1MPI_1_1ConsensusAlgorithms_1_1Interface.html#a00d9e8227c97bbe1e4a851e819b1d6a2',1,'Utilities::MPI::ConsensusAlgorithms::Interface::comm()'],['../classUtilities_1_1MPI_1_1internal_1_1ComputeIndexOwner_1_1ConsensusAlgorithmsPayload.html#a78fb4c1571bf31a2df3a253026a11844',1,'Utilities::MPI::internal::ComputeIndexOwner::ConsensusAlgorithmsPayload::comm()'],['../classUtilities_1_1MPI_1_1CollectiveMutex_1_1ScopedLock.html#a0908ddede5990b91b17df4d08417e540',1,'Utilities::MPI::CollectiveMutex::ScopedLock::comm()'],['../classUtilities_1_1MPI_1_1DuplicatedCommunicator.html#a861856004c691db91f4c79389dcb9328',1,'Utilities::MPI::DuplicatedCommunicator::comm()']]], ['comm_453',['Comm',['../classTrilinosWrappers_1_1internal_1_1LinearOperatorImplementation_1_1TrilinosPayload.html#aa9204ed2500991f8e14fb59526f5d98c',1,'TrilinosWrappers::internal::LinearOperatorImplementation::TrilinosPayload']]], - ['comm_5ffind_5fowner_454',['comm_find_owner',['../structinternal_1_1p4est_1_1functions_3_012_01_4.html#a753682ce317f14e5894d61ef4d4154df',1,'internal::p4est::functions< 2 >::comm_find_owner()'],['../structinternal_1_1p4est_1_1functions_3_013_01_4.html#a9eb8417a0e31b7a9872a0d41db636bcc',1,'internal::p4est::functions< 3 >::comm_find_owner()']]], + ['comm_5ffind_5fowner_454',['comm_find_owner',['../structinternal_1_1p4est_1_1functions_3_013_01_4.html#a9eb8417a0e31b7a9872a0d41db636bcc',1,'internal::p4est::functions< 3 >::comm_find_owner()'],['../structinternal_1_1p4est_1_1functions_3_012_01_4.html#a753682ce317f14e5894d61ef4d4154df',1,'internal::p4est::functions< 2 >::comm_find_owner()']]], ['comm_5fpattern_455',['comm_pattern',['../classLinearAlgebra_1_1ReadWriteVector.html#aede32a438077b03a579151b0f9175fbc',1,'LinearAlgebra::ReadWriteVector']]], ['comm_5fself_456',['comm_self',['../namespaceUtilities_1_1Trilinos.html#a5ef21cb4042888dbe0e9b30881e419fc',1,'Utilities::Trilinos']]], ['comm_5fsm_457',['comm_sm',['../classLinearAlgebra_1_1distributed_1_1Vector.html#a4d06704d2372317ea90b5e5bd9c1dc9f',1,'LinearAlgebra::distributed::Vector::comm_sm()'],['../classinternal_1_1MatrixFreeFunctions_1_1VectorDataExchange_1_1Full.html#a033753352612aa3c4b3d92d488084117',1,'internal::MatrixFreeFunctions::VectorDataExchange::Full::comm_sm()']]], @@ -473,7 +473,7 @@ ['communicator_5fsm_470',['communicator_sm',['../structMatrixFree_1_1AdditionalData.html#afdca3541da950e50d2e8dca2de4ceb90',1,'MatrixFree::AdditionalData::communicator_sm()'],['../structinternal_1_1MatrixFreeFunctions_1_1TaskInfo.html#a440f8be8a8e1651b26e123abe9723b66',1,'internal::MatrixFreeFunctions::TaskInfo::communicator_sm()']]], ['compare_471',['compare',['../structFloatingPointComparator.html#a63e4d8892741f5dc60d09dbcdaa6e6ed',1,'FloatingPointComparator::compare(const Tensor< rank, dim, T > &t1, const Tensor< rank, dim, T > &t2) const'],['../structFloatingPointComparator.html#ae0775620783fab28db1d99afc307f03f',1,'FloatingPointComparator::compare(const std::vector< T > &v1, const std::vector< T > &v2) const'],['../structFloatingPointComparator.html#ab3d9d64dfd4af1f8fb8e360e182b1989',1,'FloatingPointComparator::compare(const std::array< T, dim > &t1, const std::array< T, dim > &t2) const'],['../structFloatingPointComparator.html#a616981e5b30f42f35230f8386ca5b453',1,'FloatingPointComparator::compare(const Table< 2, T > &t1, const Table< 2, T > &t2) const'],['../structFloatingPointComparator.html#a8363b681179b8fd161514de25858a21a',1,'FloatingPointComparator::compare(const ScalarNumber s1, const ScalarNumber s2) const'],['../structFloatingPointComparator.html#ae99ba4b1a6d4cd2d917cbfb08490e9ee',1,'FloatingPointComparator::compare(const VectorizedArray< ScalarNumber, width > &v1, const VectorizedArray< ScalarNumber, width > &v2) const'],['../structDoFRenumbering_1_1internal_1_1ClockCells.html#a199490a833f07e0e45f4901bf77081c2',1,'DoFRenumbering::internal::ClockCells::compare(const DHCellIterator &c1, const DHCellIterator &c2, std::integral_constant< int, xdim >) const'],['../structDoFRenumbering_1_1internal_1_1ClockCells.html#a39659e387cdeb58213f295d04fb5f37d',1,'DoFRenumbering::internal::ClockCells::compare(const DHCellIterator &, const DHCellIterator &, std::integral_constant< int, 1 >) const']]], ['compare_5fand_5fapply_5fmask_472',['compare_and_apply_mask',['../vectorization_8h.html#af534b9bd6377854a3dc7580fb3072d0f',1,'compare_and_apply_mask(const VectorizedArray< Number, 1 > &left, const VectorizedArray< Number, 1 > &right, const VectorizedArray< Number, 1 > &true_value, const VectorizedArray< Number, 1 > &false_value): vectorization.h'],['../vectorization_8h.html#ac274b257ee3ff9666b2062b8ba56db8f',1,'compare_and_apply_mask(const Number &left, const Number &right, const Number &true_value, const Number &false_value): vectorization.h']]], - ['compare_5ffor_5fdomination_473',['compare_for_domination',['../classFESystem.html#a596cd1dbcdad862b8ee5611c961fc1c7',1,'FESystem::compare_for_domination()'],['../classFE__RaviartThomasNodal.html#ab64270ce4210bd3fdb149736d811478b',1,'FE_RaviartThomasNodal::compare_for_domination()'],['../classFE__DGPNonparametric.html#a7d221adc2e5f87f33e59856063192f90',1,'FE_DGPNonparametric::compare_for_domination()'],['../classFE__DGQ.html#a97ba20a01a35a3e96658b5c73791bac9',1,'FE_DGQ::compare_for_domination()'],['../classFE__Enriched.html#a464443089288286e5c63225b4e4a5d5e',1,'FE_Enriched::compare_for_domination()'],['../classFE__FaceQ.html#a2100bbca84401863a3d0ff884d029429',1,'FE_FaceQ::compare_for_domination()'],['../classFE__FaceP.html#a472b433e9a14f775f60250733ded637c',1,'FE_FaceP::compare_for_domination()'],['../classFE__Nedelec.html#ae28a16551e9e3bb1a7f58ce0474e1186',1,'FE_Nedelec::compare_for_domination()'],['../classFE__Nothing.html#ab629f287fe1a1feeed2e61a1b4773488',1,'FE_Nothing::compare_for_domination()'],['../classFE__PyramidP.html#aec8e80a12b0d54d4e346d64b82dddfcd',1,'FE_PyramidP::compare_for_domination()'],['../classFE__Q.html#ad496bc25467a4b54950f632ff90ad76c',1,'FE_Q::compare_for_domination()'],['../classFE__Q__Bubbles.html#a37a853bf18f58d35aef29e060cd35ed2',1,'FE_Q_Bubbles::compare_for_domination()'],['../classFE__Q__DG0.html#acc39c310b7d0861b99c58bb6cc7c1590',1,'FE_Q_DG0::compare_for_domination()'],['../classFE__Q__Hierarchical.html#a7c5d27b44991e5a2d8dae27fd14e2557',1,'FE_Q_Hierarchical::compare_for_domination()'],['../classFE__Q__iso__Q1.html#a067adf37b830b1c24826df387aca57f0',1,'FE_Q_iso_Q1::compare_for_domination()'],['../classFE__SimplexP.html#a7782c9d9917e45bd1a7dc94f7e982e8c',1,'FE_SimplexP::compare_for_domination()'],['../classFE__SimplexDGP.html#a0061240a4a03b33f83528620d9f14ab5',1,'FE_SimplexDGP::compare_for_domination()'],['../classFE__TraceQ.html#a5524715045fb491b741f8cc97a3bff65',1,'FE_TraceQ::compare_for_domination()'],['../classFE__WedgeP.html#ac371eb89e8a6bb7942c25df2b5ce66bd',1,'FE_WedgeP::compare_for_domination()'],['../classFE__DGPMonomial.html#aabc65792d604527d53f0c6f9efd12236',1,'FE_DGPMonomial::compare_for_domination()'],['../classFE__DGP.html#af2193761f38afb2a652b4eddbf300c4b',1,'FE_DGP::compare_for_domination()'],['../classFE__Bernstein.html#a48237f7b472fc49126bd5dc17eddeadd',1,'FE_Bernstein::compare_for_domination()'],['../classFiniteElement.html#a0acf7f396d861978209890fa268bdcbe',1,'FiniteElement::compare_for_domination()']]], + ['compare_5ffor_5fdomination_473',['compare_for_domination',['../classFESystem.html#a596cd1dbcdad862b8ee5611c961fc1c7',1,'FESystem::compare_for_domination()'],['../classFE__Q__iso__Q1.html#a067adf37b830b1c24826df387aca57f0',1,'FE_Q_iso_Q1::compare_for_domination()'],['../classFE__DGPNonparametric.html#a7d221adc2e5f87f33e59856063192f90',1,'FE_DGPNonparametric::compare_for_domination()'],['../classFE__DGQ.html#a97ba20a01a35a3e96658b5c73791bac9',1,'FE_DGQ::compare_for_domination()'],['../classFE__Enriched.html#a464443089288286e5c63225b4e4a5d5e',1,'FE_Enriched::compare_for_domination()'],['../classFE__FaceQ.html#a2100bbca84401863a3d0ff884d029429',1,'FE_FaceQ::compare_for_domination()'],['../classFE__FaceP.html#a472b433e9a14f775f60250733ded637c',1,'FE_FaceP::compare_for_domination()'],['../classFE__Nedelec.html#ae28a16551e9e3bb1a7f58ce0474e1186',1,'FE_Nedelec::compare_for_domination()'],['../classFE__Nothing.html#ab629f287fe1a1feeed2e61a1b4773488',1,'FE_Nothing::compare_for_domination()'],['../classFE__PyramidP.html#aec8e80a12b0d54d4e346d64b82dddfcd',1,'FE_PyramidP::compare_for_domination()'],['../classFE__DGPMonomial.html#aabc65792d604527d53f0c6f9efd12236',1,'FE_DGPMonomial::compare_for_domination()'],['../classFE__Q.html#ad496bc25467a4b54950f632ff90ad76c',1,'FE_Q::compare_for_domination()'],['../classFE__Q__Bubbles.html#a37a853bf18f58d35aef29e060cd35ed2',1,'FE_Q_Bubbles::compare_for_domination()'],['../classFE__Q__DG0.html#acc39c310b7d0861b99c58bb6cc7c1590',1,'FE_Q_DG0::compare_for_domination()'],['../classFE__Q__Hierarchical.html#a7c5d27b44991e5a2d8dae27fd14e2557',1,'FE_Q_Hierarchical::compare_for_domination()'],['../classFE__RaviartThomasNodal.html#ab64270ce4210bd3fdb149736d811478b',1,'FE_RaviartThomasNodal::compare_for_domination()'],['../classFE__SimplexP.html#a7782c9d9917e45bd1a7dc94f7e982e8c',1,'FE_SimplexP::compare_for_domination()'],['../classFE__SimplexDGP.html#a0061240a4a03b33f83528620d9f14ab5',1,'FE_SimplexDGP::compare_for_domination()'],['../classFE__TraceQ.html#a5524715045fb491b741f8cc97a3bff65',1,'FE_TraceQ::compare_for_domination()'],['../classFE__WedgeP.html#ac371eb89e8a6bb7942c25df2b5ce66bd',1,'FE_WedgeP::compare_for_domination()'],['../classFE__DGP.html#af2193761f38afb2a652b4eddbf300c4b',1,'FE_DGP::compare_for_domination()'],['../classFE__Bernstein.html#a48237f7b472fc49126bd5dc17eddeadd',1,'FE_Bernstein::compare_for_domination()'],['../classFiniteElement.html#a0acf7f396d861978209890fa268bdcbe',1,'FiniteElement::compare_for_domination()']]], ['compare_5ffor_5fequality_474',['compare_for_equality',['../namespacedeal__II__exceptions_1_1internals.html#a23dd83b69ab097fbc2f2f7be9d252fae',1,'deal_II_exceptions::internals']]], ['compare_5fless_5fthan_475',['compare_less_than',['../namespacedeal__II__exceptions_1_1internals.html#a09c94831a71bb8a5e21bcdf4b0b7a318',1,'deal_II_exceptions::internals']]], ['compare_5fpoint_5fassociation_476',['compare_point_association',['../namespaceGridTools_1_1internal.html#aa36584796eeca90733935fe5df5df2a7',1,'GridTools::internal']]], /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_15.js differs (ASCII text) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_15.js 2023-07-22 00:00:00.000000000 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_15.js 2023-07-22 00:00:00.000000000 +0000 @@ -4,7 +4,7 @@ ['main_2eh_1',['main.h',['../main_8h.html',1,'']]], ['manifold_2ecc_2',['manifold.cc',['../manifold_8cc.html',1,'']]], ['manifold_2eh_3',['manifold.h',['../doc_2doxygen_2headers_2manifold_8h.html',1,'(Global Namespace)'],['../include_2deal_8II_2grid_2manifold_8h.html',1,'(Global Namespace)']]], - ['manifold_5flib_2ecc_4',['manifold_lib.cc',['../grid_2manifold__lib_8cc.html',1,'(Global Namespace)'],['../opencascade_2manifold__lib_8cc.html',1,'(Global Namespace)']]], + ['manifold_5flib_2ecc_4',['manifold_lib.cc',['../opencascade_2manifold__lib_8cc.html',1,'(Global Namespace)'],['../grid_2manifold__lib_8cc.html',1,'(Global Namespace)']]], ['manifold_5flib_2eh_5',['manifold_lib.h',['../opencascade_2manifold__lib_8h.html',1,'(Global Namespace)'],['../grid_2manifold__lib_8h.html',1,'(Global Namespace)']]], ['mapping_2ecc_6',['mapping.cc',['../mapping_8cc.html',1,'']]], ['mapping_2eh_7',['mapping.h',['../mapping_8h.html',1,'']]], @@ -21,7 +21,7 @@ ['mapping_5ffe_5ffield_2eh_18',['mapping_fe_field.h',['../mapping__fe__field_8h.html',1,'']]], ['mapping_5ffe_5ffield_5finst2_2ecc_19',['mapping_fe_field_inst2.cc',['../mapping__fe__field__inst2_8cc.html',1,'']]], ['mapping_5finfo_2ecc_20',['mapping_info.cc',['../mapping__info_8cc.html',1,'']]], - ['mapping_5finfo_2eh_21',['mapping_info.h',['../matrix__free_2mapping__info_8h.html',1,'(Global Namespace)'],['../non__matching_2mapping__info_8h.html',1,'(Global Namespace)']]], + ['mapping_5finfo_2eh_21',['mapping_info.h',['../non__matching_2mapping__info_8h.html',1,'(Global Namespace)'],['../matrix__free_2mapping__info_8h.html',1,'(Global Namespace)']]], ['mapping_5finfo_5finst2_2ecc_22',['mapping_info_inst2.cc',['../mapping__info__inst2_8cc.html',1,'']]], ['mapping_5finfo_5finst3_2ecc_23',['mapping_info_inst3.cc',['../mapping__info__inst3_8cc.html',1,'']]], ['mapping_5finfo_5fstorage_2eh_24',['mapping_info_storage.h',['../mapping__info__storage_8h.html',1,'']]], @@ -57,7 +57,7 @@ ['matrix_5ftools_5fonce_2ecc_54',['matrix_tools_once.cc',['../matrix__tools__once_8cc.html',1,'']]], ['matrixfree_2eh_55',['matrixfree.h',['../matrixfree_8h.html',1,'']]], ['maxwell_2eh_56',['maxwell.h',['../maxwell_8h.html',1,'']]], - ['memory_2eh_57',['memory.h',['../doc_2doxygen_2headers_2memory_8h.html',1,'(Global Namespace)'],['../include_2deal_8II_2base_2std__cxx14_2memory_8h.html',1,'(Global Namespace)']]], + ['memory_2eh_57',['memory.h',['../include_2deal_8II_2base_2std__cxx14_2memory_8h.html',1,'(Global Namespace)'],['../doc_2doxygen_2headers_2memory_8h.html',1,'(Global Namespace)']]], ['memory_5fconsumption_2eh_58',['memory_consumption.h',['../memory__consumption_8h.html',1,'']]], ['memory_5fspace_2eh_59',['memory_space.h',['../memory__space_8h.html',1,'']]], ['memory_5fspace_5fdata_2eh_60',['memory_space_data.h',['../memory__space__data_8h.html',1,'']]], /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_b.js differs (ASCII text) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_b.js 2023-07-22 00:00:00.000000000 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_b.js 2023-07-22 00:00:00.000000000 +0000 @@ -17,7 +17,7 @@ ['code_2dgallery_2eh_14',['code-gallery.h',['../code-gallery_8h.html',1,'']]], ['coding_5fconventions_2eh_15',['coding_conventions.h',['../coding__conventions_8h.html',1,'']]], ['collection_2eh_16',['collection.h',['../collection_8h.html',1,'']]], - ['communication_5fpattern_5fbase_2eh_17',['communication_pattern_base.h',['../lac_2communication__pattern__base_8h.html',1,'(Global Namespace)'],['../base_2communication__pattern__base_8h.html',1,'(Global Namespace)']]], + ['communication_5fpattern_5fbase_2eh_17',['communication_pattern_base.h',['../base_2communication__pattern__base_8h.html',1,'(Global Namespace)'],['../lac_2communication__pattern__base_8h.html',1,'(Global Namespace)']]], ['complex_5foverloads_2eh_18',['complex_overloads.h',['../complex__overloads_8h.html',1,'']]], ['component_5fmask_2ecc_19',['component_mask.cc',['../component__mask_8cc.html',1,'']]], ['component_5fmask_2eh_20',['component_mask.h',['../component__mask_8h.html',1,'']]], /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_e.js differs (ASCII text) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_e.js 2023-07-22 00:00:00.000000000 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/search/files_e.js 2023-07-22 00:00:00.000000000 +0000 @@ -91,7 +91,7 @@ ['fe_5ftrace_2ecc_88',['fe_trace.cc',['../fe__trace_8cc.html',1,'']]], ['fe_5ftrace_2eh_89',['fe_trace.h',['../fe__trace_8h.html',1,'']]], ['fe_5fupdate_5fflags_2eh_90',['fe_update_flags.h',['../fe__update__flags_8h.html',1,'']]], - ['fe_5fvalues_2ecc_91',['fe_values.cc',['../non__matching_2fe__values_8cc.html',1,'(Global Namespace)'],['../fe_2fe__values_8cc.html',1,'(Global Namespace)'],['../hp_2fe__values_8cc.html',1,'(Global Namespace)']]], + ['fe_5fvalues_2ecc_91',['fe_values.cc',['../fe_2fe__values_8cc.html',1,'(Global Namespace)'],['../hp_2fe__values_8cc.html',1,'(Global Namespace)'],['../non__matching_2fe__values_8cc.html',1,'(Global Namespace)']]], ['fe_5fvalues_2eh_92',['fe_values.h',['../non__matching_2fe__values_8h.html',1,'(Global Namespace)'],['../hp_2fe__values_8h.html',1,'(Global Namespace)'],['../fe_2fe__values_8h.html',1,'(Global Namespace)']]], ['fe_5fvalues_5fextractors_2ecc_93',['fe_values_extractors.cc',['../fe__values__extractors_8cc.html',1,'']]], ['fe_5fvalues_5fextractors_2eh_94',['fe_values_extractors.h',['../fe__values__extractors_8h.html',1,'']]], /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_1.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_1.html 2023-08-09 23:38:58.354626014 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_1.html 2023-08-09 23:38:58.354626014 +0000 @@ -300,7 +300,7 @@

      This program obviously does not have a whole lot of functionality, but in particular the second_grid function has a bunch of places where you can play with it. For example, you could modify the criterion by which we decide which cells to refine. An example would be to change the condition to this:

      for (auto &cell: triangulation.active_cell_iterators())
      if (cell->center()[1] > 0)
      cell->set_refine_flag ();
      -

      This would refine all cells for which the $y$-coordinate of the cell's center is greater than zero (the TriaAccessor::center function that we call by dereferencing the cell iterator returns a Point<2> object; subscripting [0] would give the $x$-coordinate, subscripting [1] the $y$-coordinate). By looking at the functions that TriaAccessor provides, you can also use more complicated criteria for refinement.

      +

      This would refine all cells for which the $y$-coordinate of the cell's center is greater than zero (the TriaAccessor::center function that we call by dereferencing the cell iterator returns a Point<2> object; subscripting [0] would give the $x$-coordinate, subscripting [1] the $y$-coordinate). By looking at the functions that TriaAccessor provides, you can also use more complicated criteria for refinement.

      In general, what you can do with operations of the form cell->something() is a bit difficult to find in the documentation because cell is not a pointer but an iterator. The functions you can call on a cell can be found in the documentation of the classes TriaAccessor (which has functions that can also be called on faces of cells or, more generally, all sorts of geometric objects that appear in a triangulation), and CellAccessor (which adds a few functions that are specific to cells).

      A more thorough description of the whole iterator concept can be found in the Iterators on mesh-like containers documentation module.

      Different geometries

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_10.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_10.html 2023-08-09 23:38:58.382626223 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_10.html 2023-08-09 23:38:58.382626223 +0000 @@ -108,10 +108,10 @@
    • The plain program

      Introduction

      -

      This is a rather short example which only shows some aspects of using higher order mappings. By mapping we mean the transformation between the unit cell (i.e. the unit line, square, or cube) to the cells in real space. In all the previous examples, we have implicitly used linear or d-linear mappings; you will not have noticed this at all, since this is what happens if you do not do anything special. However, if your domain has curved boundaries, there are cases where the piecewise linear approximation of the boundary (i.e. by straight line segments) is not sufficient, and you want that your computational domain is an approximation to the real domain using curved boundaries as well. If the boundary approximation uses piecewise quadratic parabolas to approximate the true boundary, then we say that this is a quadratic or $Q_2$ approximation. If we use piecewise graphs of cubic polynomials, then this is a $Q_3$ approximation, and so on.

      -

      For some differential equations, it is known that piecewise linear approximations of the boundary, i.e. $Q_1$ mappings, are not sufficient if the boundary of the exact domain is curved. Examples are the biharmonic equation using $C^1$ elements, or the Euler equations of gas dynamics on domains with curved reflective boundaries. In these cases, it is necessary to compute the integrals using a higher order mapping. If we do not use such a higher order mapping, the order of approximation of the boundary dominates the order of convergence of the entire numerical scheme, irrespective of the order of convergence of the discretization in the interior of the domain.

      +

      This is a rather short example which only shows some aspects of using higher order mappings. By mapping we mean the transformation between the unit cell (i.e. the unit line, square, or cube) to the cells in real space. In all the previous examples, we have implicitly used linear or d-linear mappings; you will not have noticed this at all, since this is what happens if you do not do anything special. However, if your domain has curved boundaries, there are cases where the piecewise linear approximation of the boundary (i.e. by straight line segments) is not sufficient, and you want that your computational domain is an approximation to the real domain using curved boundaries as well. If the boundary approximation uses piecewise quadratic parabolas to approximate the true boundary, then we say that this is a quadratic or $Q_2$ approximation. If we use piecewise graphs of cubic polynomials, then this is a $Q_3$ approximation, and so on.

      +

      For some differential equations, it is known that piecewise linear approximations of the boundary, i.e. $Q_1$ mappings, are not sufficient if the boundary of the exact domain is curved. Examples are the biharmonic equation using $C^1$ elements, or the Euler equations of gas dynamics on domains with curved reflective boundaries. In these cases, it is necessary to compute the integrals using a higher order mapping. If we do not use such a higher order mapping, the order of approximation of the boundary dominates the order of convergence of the entire numerical scheme, irrespective of the order of convergence of the discretization in the interior of the domain.

      Rather than demonstrating the use of higher order mappings with one of these more complicated examples, we do only a brief computation: calculating the value of $\pi=3.141592653589793238462643\ldots$ by two different methods.

      -

      The first method uses a triangulated approximation of the circle with unit radius and integrates a unit magnitude constant function ( $f = 1$) over it. Of course, if the domain were the exact unit circle, then the area would be $\pi$, but since we only use an approximation by piecewise polynomial segments, the value of the area we integrate over is not exactly $\pi$. However, it is known that as we refine the triangulation, a $Q_p$ mapping approximates the boundary with an order $h^{p+1}$, where $h$ is the mesh size. We will check the values of the computed area of the circle and their convergence towards $\pi$ under mesh refinement for different mappings. We will also find a convergence behavior that is surprising at first, but has a good explanation.

      +

      The first method uses a triangulated approximation of the circle with unit radius and integrates a unit magnitude constant function ( $f = 1$) over it. Of course, if the domain were the exact unit circle, then the area would be $\pi$, but since we only use an approximation by piecewise polynomial segments, the value of the area we integrate over is not exactly $\pi$. However, it is known that as we refine the triangulation, a $Q_p$ mapping approximates the boundary with an order $h^{p+1}$, where $h$ is the mesh size. We will check the values of the computed area of the circle and their convergence towards $\pi$ under mesh refinement for different mappings. We will also find a convergence behavior that is surprising at first, but has a good explanation.

      The second method works similarly, but this time does not use the area of the triangulated unit circle, but rather its perimeter. $\pi$ is then approximated by half of the perimeter, as we choose the radius equal to one.

      Note
      This tutorial shows in essence how to choose a particular mapping for integrals, by attaching a particular geometry to the triangulation (as had already been done in step-1, for example) and then passing a mapping argument to the FEValues class that is used for all integrals in deal.II. The geometry we choose is a circle, for which deal.II already has a class (SphericalManifold) that can be used. If you want to define your own geometry, for example because it is complicated and cannot be described by the classes already available in deal.II, you will want to read through step-53.

      The commented program

      @@ -155,7 +155,7 @@
      void hyper_ball(Triangulation< dim > &tria, const Point< dim > &center=Point< dim >(), const double radius=1., const bool attach_spherical_manifold_on_boundary_cells=false)
      const ::parallel::distributed::Triangulation< dim, spacedim > * triangulation
      -
    • Then alternate between generating output on the current mesh for $Q_1$, $Q_2$, and $Q_3$ mappings, and (at the end of the loop body) refining the mesh once globally.

      +

      Then alternate between generating output on the current mesh for $Q_1$, $Q_2$, and $Q_3$ mappings, and (at the end of the loop body) refining the mesh once globally.

        for (unsigned int refinement = 0; refinement < 2; ++refinement)
        {
        std::cout << "Refinement level: " << refinement << std::endl;
      @@ -194,7 +194,7 @@
       

      Now we proceed with the main part of the code, the approximation of $\pi$. The area of a circle is of course given by $\pi r^2$, so having a circle of radius 1, the area represents just the number that is searched for. The numerical computation of the area is performed by integrating the constant function of value 1 over the whole computational domain, i.e. by computing the areas $\int_K 1 dx=\int_{\hat K} 1
    \ \textrm{det}\ J(\hat x) d\hat x \approx \sum_i \textrm{det}
-   \ J(\hat x_i)w(\hat x_i)$, where the sum extends over all quadrature points on all active cells in the triangulation, with $w(x_i)$ being the weight of quadrature point $x_i$. The integrals on each cell are approximated by numerical quadrature, hence the only additional ingredient we need is to set up a FEValues object that provides the corresponding JxW values of each cell. (Note that JxW is meant to abbreviate Jacobian determinant times weight; since in numerical quadrature the two factors always occur at the same places, we only offer the combined quantity, rather than two separate ones.) We note that here we won't use the FEValues object in its original purpose, i.e. for the computation of values of basis functions of a specific finite element at certain quadrature points. Rather, we use it only to gain the JxW at the quadrature points, irrespective of the (dummy) finite element we will give to the constructor of the FEValues object. The actual finite element given to the FEValues object is not used at all, so we could give any.

      + \ J(\hat x_i)w(\hat x_i)$" src="form_2751.png"/>, where the sum extends over all quadrature points on all active cells in the triangulation, with $w(x_i)$ being the weight of quadrature point $x_i$. The integrals on each cell are approximated by numerical quadrature, hence the only additional ingredient we need is to set up a FEValues object that provides the corresponding JxW values of each cell. (Note that JxW is meant to abbreviate Jacobian determinant times weight; since in numerical quadrature the two factors always occur at the same places, we only offer the combined quantity, rather than two separate ones.) We note that here we won't use the FEValues object in its original purpose, i.e. for the computation of values of basis functions of a specific finite element at certain quadrature points. Rather, we use it only to gain the JxW at the quadrature points, irrespective of the (dummy) finite element we will give to the constructor of the FEValues object. The actual finite element given to the FEValues object is not used at all, so we could give any.

        template <int dim>
        void compute_pi_by_area()
        {
      @@ -402,11 +402,11 @@
      unset ytics
      plot [-1:1][-1:1] "ball_0_mapping_q_1.dat" lw 4 lt rgb "black"

      or using one of the other filenames. The second line makes sure that the aspect ratio of the generated output is actually 1:1, i.e. a circle is drawn as a circle on your screen, rather than as an ellipse. The third line switches off the key in the graphic, as that will only print information (the filename) which is not that important right now. Similarly, the fourth and fifth disable tick marks. The plot is then generated with a specific line width ("lw", here set to 4) and line type ("lt", here chosen by saying that the line should be drawn using the RGB color "black").

      -

      The following table shows the triangulated computational domain for $Q_1$, $Q_2$, and $Q_3$ mappings, for the original coarse grid (left), and a once uniformly refined grid (right).

      +

      The following table shows the triangulated computational domain for $Q_1$, $Q_2$, and $Q_3$ mappings, for the original coarse grid (left), and a once uniformly refined grid (right).

      Five-cell discretization of the disk.
      20-cell discretization of the disk (i.e., five cells
               refined once).
      Five-cell discretization of the disk with quadratic edges. The
               boundary is nearly indistinguishable from the actual circle.
      20-cell discretization with quadratic edges.
      Five-cell discretization of the disk with cubic edges. The
-              boundary is nearly indistinguishable from the actual circle.
      20-cell discretization with cubic edges.

      These pictures show the obvious advantage of higher order mappings: they approximate the true boundary quite well also on rather coarse meshes. To demonstrate this a little further, here is part of the upper right quarter circle of the coarse meshes with $Q_2$ and $Q_3$ mappings, where the dashed red line marks the actual circle:

      + boundary is nearly indistinguishable from the actual circle." style="pointer-events: none;" width="400" height="400" class="inline"/>
    20-cell discretization with cubic edges.

    These pictures show the obvious advantage of higher order mappings: they approximate the true boundary quite well also on rather coarse meshes. To demonstrate this a little further, here is part of the upper right quarter circle of the coarse meshes with $Q_2$ and $Q_3$ mappings, where the dashed red line marks the actual circle:

    Close-up of quadratic discretization. The distance between the
          quadratic interpolant and the actual circle is small.
    Close-up of cubic discretization. The distance between the
          cubic interpolant and the actual circle is very small.

    Obviously the quadratic mapping approximates the boundary quite well, while for the cubic mapping the difference between approximated domain and true one is hardly visible already for the coarse grid. You can also see that the mapping only changes something at the outer boundaries of the triangulation. In the interior, all lines are still represented by linear functions, resulting in additional computations only on cells at the boundary. Higher order mappings are therefore usually not noticeably slower than lower order ones, because the additional computations are only performed on a small subset of all cells.

    @@ -499,8 +499,8 @@
    5120 3.1415926535897940 8.8818e-16 2.00
    unsigned int level
    Definition: grid_out.cc:4618
    Note
    Once the error reaches a level on the order of $10^{-13}$ to $10^{-15}$, it is essentially dominated by round-off and consequently dominated by what precisely the library is doing in internal computations. Since these things change, the precise values and errors change from release to release at these round-off levels, though the overall order of errors should of course remain the same. See also the comment below in the section on Possibilities for extensions about how to compute these results more accurately.
    -

    One of the immediate observations from the output above is that in all cases the values converge quickly to the true value of $\pi=3.141592653589793238462643$. Note that for the $Q_4$ mapping, we are already in the regime of roundoff errors and the convergence rate levels off, which is already quite a lot. However, also note that for the $Q_1$ mapping, even on the finest grid the accuracy is significantly worse than on the coarse grid for a $Q_3$ mapping!

    -

    The last column of the output shows the convergence order, in powers of the mesh width $h$. In the introduction, we had stated that the convergence order for a $Q_p$ mapping should be $h^{p+1}$. However, in the example shown, the order is rather $h^{2p}$! This at first surprising fact is explained by the properties of the $Q_p$ mapping. At order p, it uses support points that are based on the p+1 point Gauss-Lobatto quadrature rule that selects the support points in such a way that the quadrature rule converges at order 2p. Even though these points are here only used for interpolation of a pth order polynomial, we get a superconvergence effect when numerically evaluating the integral, resulting in the observed high order of convergence. (This effect is also discussed in detail in the following publication: A. Bonito, A. Demlow, and J. Owen: "A priori error +

    One of the immediate observations from the output above is that in all cases the values converge quickly to the true value of $\pi=3.141592653589793238462643$. Note that for the $Q_4$ mapping, we are already in the regime of roundoff errors and the convergence rate levels off, which is already quite a lot. However, also note that for the $Q_1$ mapping, even on the finest grid the accuracy is significantly worse than on the coarse grid for a $Q_3$ mapping!

    +

    The last column of the output shows the convergence order, in powers of the mesh width $h$. In the introduction, we had stated that the convergence order for a $Q_p$ mapping should be $h^{p+1}$. However, in the example shown, the order is rather $h^{2p}$! This at first surprising fact is explained by the properties of the $Q_p$ mapping. At order p, it uses support points that are based on the p+1 point Gauss-Lobatto quadrature rule that selects the support points in such a way that the quadrature rule converges at order 2p. Even though these points are here only used for interpolation of a pth order polynomial, we get a superconvergence effect when numerically evaluating the integral, resulting in the observed high order of convergence. (This effect is also discussed in detail in the following publication: A. Bonito, A. Demlow, and J. Owen: "A priori error estimates for finite element approximations to eigenvalues and eigenfunctions of the Laplace-Beltrami operator", submitted, 2018.)

    Possibilities for extensions

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_11.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_11.html 2023-08-09 23:38:58.414626462 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_11.html 2023-08-09 23:38:58.414626462 +0000 @@ -108,55 +108,55 @@

    Introduction

    The problem we will be considering is the solution of Laplace's problem with Neumann boundary conditions only:

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   -\Delta u &=& f \qquad \mathrm{in}\ \Omega,
   \\
   \partial_n u &=& g \qquad \mathrm{on}\ \partial\Omega.
-\end{eqnarray*} +\end{eqnarray*}" src="form_2760.png"/>

    It is well known that if this problem is to have a solution, then the forces need to satisfy the compatibility condition

    -\[
+<picture><source srcset=\[
   \int_\Omega f\; dx + \int_{\partial\Omega} g\; ds = 0.
-\] +\]" src="form_2761.png"/>

    -

    We will consider the special case that $\Omega$ is the circle of radius 1 around the origin, and $f=-2$, $g=1$. This choice satisfies the compatibility condition.

    +

    We will consider the special case that $\Omega$ is the circle of radius 1 around the origin, and $f=-2$, $g=1$. This choice satisfies the compatibility condition.

    The compatibility condition allows a solution of the above equation, but it nevertheless retains an ambiguity: since only derivatives of the solution appear in the equations, the solution is only determined up to a constant. For this reason, we have to pose another condition for the numerical solution, which fixes this constant.

    For this, there are various possibilities:

    1. -

      Fix one node of the discretization to zero or any other fixed value. This amounts to an additional condition $u_h(x_0)=0$. Although this is common practice, it is not necessarily a good idea, since we know that the solutions of Laplace's equation are only in $H^1$, which does not allow for the definition of point values because it is not a subset of the continuous functions. Therefore, even though fixing one node is allowed for discretized functions, it is not for continuous functions, and one can often see this in a resulting error spike at this point in the numerical solution.

      +

      Fix one node of the discretization to zero or any other fixed value. This amounts to an additional condition $u_h(x_0)=0$. Although this is common practice, it is not necessarily a good idea, since we know that the solutions of Laplace's equation are only in $H^1$, which does not allow for the definition of point values because it is not a subset of the continuous functions. Therefore, even though fixing one node is allowed for discretized functions, it is not for continuous functions, and one can often see this in a resulting error spike at this point in the numerical solution.

    2. -

      Fixing the mean value over the domain to zero or any other value. This is allowed on the continuous level, since $H^1(\Omega)\subset L^1(\Omega)$ by Sobolev's inequality, and thus also on the discrete level since we there only consider subsets of $H^1$.

      +

      Fixing the mean value over the domain to zero or any other value. This is allowed on the continuous level, since $H^1(\Omega)\subset L^1(\Omega)$ by Sobolev's inequality, and thus also on the discrete level since we there only consider subsets of $H^1$.

    3. -Fixing the mean value over the boundary of the domain to zero or any other value. This is also allowed on the continuous level, since $H^{1/2}(\partial\Omega)\subset L^1(\partial\Omega)$, again by Sobolev's inequality.
    4. +Fixing the mean value over the boundary of the domain to zero or any other value. This is also allowed on the continuous level, since $H^{1/2}(\partial\Omega)\subset L^1(\partial\Omega)$, again by Sobolev's inequality.

    We will choose the last possibility, since we want to demonstrate another technique with it.

    While this describes the problem to be solved, we still have to figure out how to implement it. Basically, except for the additional mean value constraint, we have solved this problem several times, using Dirichlet boundary values, and we only need to drop the treatment of Dirichlet boundary nodes. The use of higher order mappings is also rather trivial and will be explained at the various places where we use it; in almost all conceivable cases, you will only consider the objects describing mappings as a black box which you need not worry about, because their only uses seem to be to be passed to places deep inside the library where functions know how to handle them (i.e. in the FEValues classes and their descendants).

    The tricky point in this program is the use of the mean value constraint. Fortunately, there is a class in the library which knows how to handle such constraints, and we have used it quite often already, without mentioning its generality. Note that if we assume that the boundary nodes are spaced equally along the boundary, then the mean value constraint

    -\[
+<picture><source srcset=\[
   \int_{\partial \Omega} u(x) \; ds = 0
-\] +\]" src="form_2767.png"/>

    can be written as

    -\[
+<picture><source srcset=\[
   \sum_{i\in\partial\Omega_h} u_i = 0,
-\] +\]" src="form_2768.png"/>

    -

    where the sum shall run over all degree of freedom indices which are located on the boundary of the computational domain. Let us denote by $i_0$ that index on the boundary with the lowest number (or any other conveniently chosen index), then the constraint can also be represented by

    -\[
+<p> where the sum shall run over all degree of freedom indices which are located on the boundary of the computational domain. Let us denote by <picture><source srcset=$i_0$ that index on the boundary with the lowest number (or any other conveniently chosen index), then the constraint can also be represented by

    +\[
   u_{i_0} = \sum_{i\in\partial\Omega_h\backslash i_0} -u_i.
-\] +\]" src="form_2770.png"/>

    This, luckily, is exactly the form of constraints for which the AffineConstraints class was designed. Note that we have used this class in several previous examples for the representation of hanging nodes constraints, which also have this form: there, the middle vertex shall have the mean of the values of the adjacent vertices. In general, the AffineConstraints class is designed to handle affine constraints of the form

    -\[
+<picture><source srcset=\[
   CU = b
-\] +\]" src="form_2771.png"/>

    -

    where $C$ denotes a matrix, $b$ denotes a vector, and $U$ the vector of nodal values. In this case, since $C$ represents one homogeneous constraint, $b$ is the zero vector.

    -

    In this example, the mean value along the boundary allows just such a representation, with $C$ being a matrix with just one row (i.e. there is only one constraint). In the implementation, we will create an AffineConstraints object, add one constraint (i.e. add another row to the matrix) referring to the first boundary node $i_0$, and insert the weights with which all the other nodes contribute, which in this example happens to be just $-1$.

    +

    where $C$ denotes a matrix, $b$ denotes a vector, and $U$ the vector of nodal values. In this case, since $C$ represents one homogeneous constraint, $b$ is the zero vector.

    +

    In this example, the mean value along the boundary allows just such a representation, with $C$ being a matrix with just one row (i.e. there is only one constraint). In the implementation, we will create an AffineConstraints object, add one constraint (i.e. add another row to the matrix) referring to the first boundary node $i_0$, and insert the weights with which all the other nodes contribute, which in this example happens to be just $-1$.

    Later, we will use this object to eliminate the first boundary node from the linear system of equations, reducing it to one which has a solution without the ambiguity of the constant shift value. One of the problems of the implementation will be that the explicit elimination of this node results in a number of additional elements in the matrix, of which we do not know in advance where they are located and how many additional entries will be in each of the rows of the matrix. We will show how we can use an intermediate object to work around this problem.

    But now on to the implementation of the program solving this problem...

    The commented program

    @@ -322,8 +322,8 @@
    ::VectorizedArray< Number, width > max(const ::VectorizedArray< Number, width > &, const ::VectorizedArray< Number, width > &)

    That's quite simple, right?

    Two remarks are in order, though: First, these functions are used in a lot of contexts. Maybe you want to create a Laplace or mass matrix for a vector values finite element; or you want to use the default Q1 mapping; or you want to assembled the matrix with a coefficient in the Laplace operator. For this reason, there are quite a large number of variants of these functions in the MatrixCreator and MatrixTools namespaces. Whenever you need a slightly different version of these functions than the ones called above, it is certainly worthwhile to take a look at the documentation and to check whether something fits your needs.

    -

    The second remark concerns the quadrature formula we use: we want to integrate over bilinear shape functions, so we know that we have to use at least an order two Gauss quadrature formula. On the other hand, we want the quadrature rule to have at least the order of the boundary approximation. Since the order of Gauss rule with $r$ points is $2r -
-   1$, and the order of the boundary approximation using polynomials of degree $p$ is $p+1$, we know that $2r \geq p$. Since r has to be an integer and (as mentioned above) has to be at least $2$, this makes up for the formula above computing gauss_degree.

    +

    The second remark concerns the quadrature formula we use: we want to integrate over bilinear shape functions, so we know that we have to use at least an order two Gauss quadrature formula. On the other hand, we want the quadrature rule to have at least the order of the boundary approximation. Since the order of Gauss rule with $r$ points is $2r -
+   1$, and the order of the boundary approximation using polynomials of degree $p$ is $p+1$, we know that $2r \geq p$. Since r has to be an integer and (as mentioned above) has to be at least $2$, this makes up for the formula above computing gauss_degree.

    Since the generation of the body force contributions to the right hand side vector was so simple, we do that all over again for the boundary forces as well: allocate a vector of the right size and call the right function. The boundary function has constant values, so we can generate an object from the library on the fly, and we use the same quadrature formula as above, but this time of lower dimension since we integrate over faces now instead of cells:

      Vector<double> tmp(system_rhs.size());
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_12.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_12.html 2023-08-09 23:38:58.458626791 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_12.html 2023-08-09 23:38:58.458626791 +0000 @@ -134,50 +134,50 @@

    The particular concern of this program are the loops of DG methods. These turn out to be especially complex, primarily because for the face terms, we have to distinguish the cases of boundary, regular interior faces and interior faces with hanging nodes, respectively. The MeshWorker::mesh_loop() handles the complexity on iterating over cells and faces and allows specifying "workers" for the different cell and face terms. The integration of face terms itself, including on adaptively refined faces, is done using the FEInterfaceValues class.

    The equation

    The model problem solved in this example is the linear advection equation

    -\[
+<picture><source srcset=\[
   \nabla\cdot \left({\mathbf \beta} u\right)=0 \qquad\mbox{in }\Omega,
-\] +\]" src="form_2774.png"/>

    subject to the boundary conditions

    -\[
+<picture><source srcset=\[
 u=g\quad\mbox{on }\Gamma_-,
-\] +\]" src="form_2775.png"/>

    -

    on the inflow part $\Gamma_-$ of the boundary $\Gamma=\partial\Omega$ of the domain. Here, ${\mathbf \beta}={\mathbf \beta}({\bf x})$ denotes a vector field, $u$ the (scalar) solution function, $g$ a boundary value function,

    -\[
+<p> on the inflow part <picture><source srcset=$\Gamma_-$ of the boundary $\Gamma=\partial\Omega$ of the domain. Here, ${\mathbf \beta}={\mathbf \beta}({\bf x})$ denotes a vector field, $u$ the (scalar) solution function, $g$ a boundary value function,

    +\[
 \Gamma_- \dealcoloneq \{{\bf x}\in\Gamma, {\mathbf \beta}({\bf x})\cdot{\bf n}({\bf x})<0\}
-\] +\]" src="form_2779.png"/>

    -

    the inflow part of the boundary of the domain and ${\bf n}$ denotes the unit outward normal to the boundary $\Gamma$. This equation is the conservative version of the advection equation already considered in step-9 of this tutorial.

    -

    On each cell $T$, we multiply by a test function $v_h$ from the left and integrate by parts to get:

    -\[
+<p> the inflow part of the boundary of the domain and <picture><source srcset=${\bf n}$ denotes the unit outward normal to the boundary $\Gamma$. This equation is the conservative version of the advection equation already considered in step-9 of this tutorial.

    +

    On each cell $T$, we multiply by a test function $v_h$ from the left and integrate by parts to get:

    +\[
   \left( v_h, \nabla \cdot (\beta u_h) \right)_T
 = -(\nabla v_h, \beta u_h) + \int_{\partial T} v_h u_h \beta \cdot n
-\] +\]" src="form_2782.png"/>

    -

    When summing this expression over all cells $T$, the boundary integral is done over all internal and external faces and as such there are three cases:

      +

      When summing this expression over all cells $T$, the boundary integral is done over all internal and external faces and as such there are three cases:

      1. -outer boundary on the inflow (we replace $u_h$ by given $g$): $\int_{\Gamma_-} v_h g \beta \cdot n$
      2. +outer boundary on the inflow (we replace $u_h$ by given $g$): $\int_{\Gamma_-} v_h g \beta \cdot n$
      3. -outer boundary on the outflow: $\int_{\Gamma_+} v_h u_h \beta \cdot n$
      4. +outer boundary on the outflow: $\int_{\Gamma_+} v_h u_h \beta \cdot n$
      5. -inner faces (integral from two sides turns into jump, we use the upwind velocity): $\int_F [v_h] u_h^{\text{upwind}} \beta \cdot n$
      6. +inner faces (integral from two sides turns into jump, we use the upwind velocity): $\int_F [v_h] u_h^{\text{upwind}} \beta \cdot n$
      -

      Here, the jump is defined as $[v] = v^+ - v^-$, where the superscripts refer to the left ('+') and right ('-') values at the face. The upwind value $u^{\text{upwind}}$ is defined to be $u^+$ if $\beta \cdot n>0$ and $u^-$ otherwise.

      +

      Here, the jump is defined as $[v] = v^+ - v^-$, where the superscripts refer to the left ('+') and right ('-') values at the face. The upwind value $u^{\text{upwind}}$ is defined to be $u^+$ if $\beta \cdot n>0$ and $u^-$ otherwise.

      As a result, the mesh-dependent weak form reads:

      -\[
+<picture><source srcset=\[
 \sum_{T\in \mathbb T_h} -\bigl(\nabla \phi_i,{\mathbf \beta}\cdot \phi_j \bigr)_T +
 \sum_{F\in\mathbb F_h^i} \bigl< [\phi_i], \phi_j^{upwind} \beta\cdot \mathbf n\bigr>_{F} +
 \bigl<\phi_i, \phi_j \beta\cdot \mathbf n\bigr>_{\Gamma_+}
 = -\bigl<\phi_i, g \beta\cdot\mathbf n\bigr>_{\Gamma_-}.
-\] +\]" src="form_2791.png"/>

      -

      Here, $\mathbb T_h$ is the set of all active cells of the triangulation and $\mathbb F_h^i$ is the set of all active interior faces. This formulation is known as the upwind discontinuous Galerkin method.

      +

      Here, $\mathbb T_h$ is the set of all active cells of the triangulation and $\mathbb F_h^i$ is the set of all active interior faces. This formulation is known as the upwind discontinuous Galerkin method.

      In order to implement this bilinear form, we need to compute the cell terms (first sum) using the usual way to achieve integration on a cell, the interface terms (second sum) using FEInterfaceValues, and the boundary terms (the other two terms). The summation of all those is done by MeshWorker::mesh_loop().

      The test problem

      -

      We solve the advection equation on $\Omega=[0,1]^2$ with ${\mathbf \beta}=\frac{1}{|x|}(-x_2, x_1)$ representing a circular counterclockwise flow field, and $g=1$ on ${\bf x}\in\Gamma_-^1 := [0,0.5]\times\{0\}$ and $g=0$ on ${\bf x}\in
-\Gamma_-\setminus \Gamma_-^1$.

      -

      We solve on a sequence of meshes by refining the mesh adaptively by estimating the norm of the gradient on each cell. After solving on each mesh, we output the solution in vtk format and compute the $L^\infty$ norm of the solution. As the exact solution is either 0 or 1, we can measure the magnitude of the overshoot of the numerical solution with this.

      +

      We solve the advection equation on $\Omega=[0,1]^2$ with ${\mathbf \beta}=\frac{1}{|x|}(-x_2, x_1)$ representing a circular counterclockwise flow field, and $g=1$ on ${\bf x}\in\Gamma_-^1 := [0,0.5]\times\{0\}$ and $g=0$ on ${\bf x}\in
+\Gamma_-\setminus \Gamma_-^1$.

      +

      We solve on a sequence of meshes by refining the mesh adaptively by estimating the norm of the gradient on each cell. After solving on each mesh, we output the solution in vtk format and compute the $L^\infty$ norm of the solution. As the exact solution is either 0 or 1, we can measure the magnitude of the overshoot of the numerical solution with this.

      The commented program

      The first few files have already been covered in previous examples and will thus not be further commented on:

        #include <deal.II/base/quadrature_lib.h>
      @@ -254,7 +254,7 @@
       
      #define AssertDimension(dim1, dim2)
      Definition: exceptions.h:1787
      #define AssertIndexRange(index, range)
      Definition: exceptions.h:1855
      -

      Finally, a function that computes and returns the wind field $\beta=\beta(\mathbf x)$. As explained in the introduction, we will use a rotational field around the origin in 2d. In 3d, we simply leave the $z$-component unset (i.e., at zero), whereas the function can not be used in 1d in its current implementation:

      +

    Finally, a function that computes and returns the wind field $\beta=\beta(\mathbf x)$. As explained in the introduction, we will use a rotational field around the origin in 2d. In 3d, we simply leave the $z$-component unset (i.e., at zero), whereas the function can not be used in 1d in its current implementation:

      template <int dim>
      Tensor<1, dim> beta(const Point<dim> &p)
      {
    @@ -621,7 +621,7 @@
      }
     
     
    -

    We refine the grid according to a very simple refinement criterion, namely an approximation to the gradient of the solution. As here we consider the DG(1) method (i.e. we use piecewise bilinear shape functions) we could simply compute the gradients on each cell. But we do not want to base our refinement indicator on the gradients on each cell only, but want to base them also on jumps of the discontinuous solution function over faces between neighboring cells. The simplest way of doing that is to compute approximative gradients by difference quotients including the cell under consideration and its neighbors. This is done by the DerivativeApproximation class that computes the approximate gradients in a way similar to the GradientEstimation described in step-9 of this tutorial. In fact, the DerivativeApproximation class was developed following the GradientEstimation class of step-9. Relating to the discussion in step-9, here we consider $h^{1+d/2}|\nabla_h u_h|$. Furthermore we note that we do not consider approximate second derivatives because solutions to the linear advection equation are in general not in $H^2$ but only in $H^1$ (or, to be more precise: in $H^1_\beta$, i.e., the space of functions whose derivatives in direction $\beta$ are square integrable).

    +

    We refine the grid according to a very simple refinement criterion, namely an approximation to the gradient of the solution. As here we consider the DG(1) method (i.e. we use piecewise bilinear shape functions) we could simply compute the gradients on each cell. But we do not want to base our refinement indicator on the gradients on each cell only, but want to base them also on jumps of the discontinuous solution function over faces between neighboring cells. The simplest way of doing that is to compute approximative gradients by difference quotients including the cell under consideration and its neighbors. This is done by the DerivativeApproximation class that computes the approximate gradients in a way similar to the GradientEstimation described in step-9 of this tutorial. In fact, the DerivativeApproximation class was developed following the GradientEstimation class of step-9. Relating to the discussion in step-9, here we consider $h^{1+d/2}|\nabla_h u_h|$. Furthermore we note that we do not consider approximate second derivatives because solutions to the linear advection equation are in general not in $H^2$ but only in $H^1$ (or, to be more precise: in $H^1_\beta$, i.e., the space of functions whose derivatives in direction $\beta$ are square integrable).

      template <int dim>
      void AdvectionProblem<dim>::refine_grid()
      {
    @@ -822,7 +822,7 @@

    There are a number of strategies to stabilize the cG method, if one wants to use continuous elements for some reason. Discussing these methods is beyond the scope of this tutorial program; an interested reader could, for example, take a look at step-31.

    Possibilities for extensions

    Given that the exact solution is known in this case, one interesting avenue for further extensions would be to confirm the order of convergence for this program. In the current case, the solution is non-smooth, and so we can not expect to get a particularly high order of convergence, even if we used higher order elements. But even if the solution is smooth, the equation is not elliptic and so it is not immediately clear that we should obtain a convergence order that equals that of the optimal interpolation estimates (i.e. for example that we would get $h^3$ convergence in the $L^2$ norm by using quadratic elements).

    -

    In fact, for hyperbolic equations, theoretical predictions often indicate that the best one can hope for is an order one half below the interpolation estimate. For example, for the streamline diffusion method (an alternative method to the DG method used here to stabilize the solution of the transport equation), one can prove that for elements of degree $p$, the order of convergence is $p+\frac 12$ on arbitrary meshes. While the observed order is frequently $p+1$ on uniformly refined meshes, one can construct so-called Peterson meshes on which the worse theoretical bound is actually attained. This should be relatively simple to verify, for example using the VectorTools::integrate_difference function.

    +

    In fact, for hyperbolic equations, theoretical predictions often indicate that the best one can hope for is an order one half below the interpolation estimate. For example, for the streamline diffusion method (an alternative method to the DG method used here to stabilize the solution of the transport equation), one can prove that for elements of degree $p$, the order of convergence is $p+\frac 12$ on arbitrary meshes. While the observed order is frequently $p+1$ on uniformly refined meshes, one can construct so-called Peterson meshes on which the worse theoretical bound is actually attained. This should be relatively simple to verify, for example using the VectorTools::integrate_difference function.

    A different direction is to observe that the solution of transport problems often has discontinuities and that therefore a mesh in which we bisect every cell in every coordinate direction may not be optimal. Rather, a better strategy would be to only cut cells in the direction parallel to the discontinuity. This is called anisotropic mesh refinement and is the subject of step-30.

    The plain program

    /* ---------------------------------------------------------------------
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_12b.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_12b.html 2023-08-09 23:38:58.502627119 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_12b.html 2023-08-09 23:38:58.502627119 +0000 @@ -195,7 +195,7 @@
     
    #define AssertDimension(dim1, dim2)
    Definition: exceptions.h:1787
    #define AssertIndexRange(index, range)
    Definition: exceptions.h:1855
    -

    Finally, a function that computes and returns the wind field $\beta=\beta(\mathbf x)$. As explained in the introduction, we will use a rotational field around the origin in 2d. In 3d, we simply leave the $z$-component unset (i.e., at zero), whereas the function can not be used in 1d in its current implementation:

    +

    Finally, a function that computes and returns the wind field $\beta=\beta(\mathbf x)$. As explained in the introduction, we will use a rotational field around the origin in 2d. In 3d, we simply leave the $z$-component unset (i.e., at zero), whereas the function can not be used in 1d in its current implementation:

      template <int dim>
      Tensor<1, dim> beta(const Point<dim> &p)
      {
    @@ -521,7 +521,7 @@
      }
     
     
    -

    We refine the grid according to a very simple refinement criterion, namely an approximation to the gradient of the solution. As here we consider the DG(1) method (i.e. we use piecewise bilinear shape functions) we could simply compute the gradients on each cell. But we do not want to base our refinement indicator on the gradients on each cell only, but want to base them also on jumps of the discontinuous solution function over faces between neighboring cells. The simplest way of doing that is to compute approximative gradients by difference quotients including the cell under consideration and its neighbors. This is done by the DerivativeApproximation class that computes the approximate gradients in a way similar to the GradientEstimation described in step-9 of this tutorial. In fact, the DerivativeApproximation class was developed following the GradientEstimation class of step-9. Relating to the discussion in step-9, here we consider $h^{1+d/2}|\nabla_h u_h|$. Furthermore we note that we do not consider approximate second derivatives because solutions to the linear advection equation are in general not in $H^2$ but only in $H^1$ (or, to be more precise: in $H^1_\beta$, i.e., the space of functions whose derivatives in direction $\beta$ are square integrable).

    +

    We refine the grid according to a very simple refinement criterion, namely an approximation to the gradient of the solution. As here we consider the DG(1) method (i.e. we use piecewise bilinear shape functions) we could simply compute the gradients on each cell. But we do not want to base our refinement indicator on the gradients on each cell only, but want to base them also on jumps of the discontinuous solution function over faces between neighboring cells. The simplest way of doing that is to compute approximative gradients by difference quotients including the cell under consideration and its neighbors. This is done by the DerivativeApproximation class that computes the approximate gradients in a way similar to the GradientEstimation described in step-9 of this tutorial. In fact, the DerivativeApproximation class was developed following the GradientEstimation class of step-9. Relating to the discussion in step-9, here we consider $h^{1+d/2}|\nabla_h u_h|$. Furthermore we note that we do not consider approximate second derivatives because solutions to the linear advection equation are in general not in $H^2$ but only in $H^1$ (or, to be more precise: in $H^1_\beta$, i.e., the space of functions whose derivatives in direction $\beta$ are square integrable).

      template <int dim>
      void AdvectionProblem<dim>::refine_grid()
      {
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_14.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_14.html 2023-08-09 23:38:58.622628015 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_14.html 2023-08-09 23:38:58.622628015 +0000 @@ -161,30 +161,30 @@

    The Heidelberg group of Professor Rolf Rannacher, to which the three initial authors of the deal.II library belonged during their PhD time and partly also afterwards, has been involved with adaptivity and error estimation for finite element discretizations since the mid-1990ies. The main achievement is the development of error estimates for arbitrary functionals of the solution, and of optimal mesh refinement for its computation.

    We will not discuss the derivation of these concepts in too great detail, but will implement the main ideas in the present example program. For a thorough introduction into the general idea, we refer to the seminal work of Becker and Rannacher [BR95], [BR96r], and the overview article of the same authors in Acta Numerica [BR01]; the first introduces the concept of error estimation and adaptivity for general functional output for the Laplace equation, while the second gives many examples of applications of these concepts to a large number of other, more complicated equations. For applications to individual types of equations, see also the publications by Becker [Bec95], [Bec98], Kanschat [Kan96], [FK97], Suttmeier [Sut96], [RS97], [RS98c], [RS99], Bangerth [BR99b], [Ban00w], [BR01a], [Ban02], and Hartmann [Har02], [HH01], [HH01b]. All of these works, from the original introduction by Becker and Rannacher to individual contributions to particular equations, have later been summarized in a book by Bangerth and Rannacher that covers all of these topics, see [BR03].

    The basic idea is the following: in applications, one is not usually interested in the solution per se, but rather in certain aspects of it. For example, in simulations of flow problems, one may want to know the lift or drag of a body immersed in the fluid; it is this quantity that we want to know to best accuracy, and whether the rest of the solution of the describing equations is well resolved is not of primary interest. Likewise, in elasticity one might want to know about values of the stress at certain points to guess whether maximal load values of joints are safe, for example. Or, in radiative transfer problems, mean flux intensities are of interest.

    -

    In all the cases just listed, it is the evaluation of a functional $J(u)$ of the solution which we are interested in, rather than the values of $u$ everywhere. Since the exact solution $u$ is not available, but only its numerical approximation $u_h$, it is sensible to ask whether the computed value $J(u_h)$ is within certain limits of the exact value $J(u)$, i.e. we want to bound the error with respect to this functional, $J(u)-J(u_h)$.

    -

    For simplicity of exposition, we henceforth assume that both the quantity of interest $J$ as well as the equation are linear, and we will in particular show the derivation for the Laplace equation with homogeneous Dirichlet boundary conditions, although the concept is much more general. For this general case, we refer to the references listed above. The goal is to obtain bounds on the error, $J(e)=J(u)-J(u_h)$. For this, let us denote by $z$ the solution of a dual problem, defined as follows:

    -\[
+<p>In all the cases just listed, it is the evaluation of a functional <picture><source srcset=$J(u)$ of the solution which we are interested in, rather than the values of $u$ everywhere. Since the exact solution $u$ is not available, but only its numerical approximation $u_h$, it is sensible to ask whether the computed value $J(u_h)$ is within certain limits of the exact value $J(u)$, i.e. we want to bound the error with respect to this functional, $J(u)-J(u_h)$.

    +

    For simplicity of exposition, we henceforth assume that both the quantity of interest $J$ as well as the equation are linear, and we will in particular show the derivation for the Laplace equation with homogeneous Dirichlet boundary conditions, although the concept is much more general. For this general case, we refer to the references listed above. The goal is to obtain bounds on the error, $J(e)=J(u)-J(u_h)$. For this, let us denote by $z$ the solution of a dual problem, defined as follows:

    +\[
   a(\varphi,z) = J(\varphi) \qquad \forall \varphi,
-\] +\]" src="form_2820.png"/>

    -

    where $a(\cdot,\cdot)$ is the bilinear form associated with the differential equation, and the test functions are chosen from the corresponding solution space. Then, taking as special test function $\varphi=e$ the error, we have that

    -\[
+<p> where <picture><source srcset=$a(\cdot,\cdot)$ is the bilinear form associated with the differential equation, and the test functions are chosen from the corresponding solution space. Then, taking as special test function $\varphi=e$ the error, we have that

    +\[
   J(e) = a(e,z)
-\] +\]" src="form_2823.png"/>

    and we can, by Galerkin orthogonality, rewrite this as

    -\[
+<picture><source srcset=\[
   J(e) = a(e,z-\varphi_h)
-\] +\]" src="form_2824.png"/>

    -

    where $\varphi_h$ can be chosen from the discrete test space in whatever way we find convenient.

    +

    where $\varphi_h$ can be chosen from the discrete test space in whatever way we find convenient.

    Concretely, for Laplace's equation, the error identity reads

    -\[
+<picture><source srcset=\[
   J(e) = (\nabla e, \nabla(z-\varphi_h)).
-\] +\]" src="form_2826.png"/>

    Because we want to use this formula not only to compute error, but also to refine the mesh, we need to rewrite the expression above as a sum over cells where each cell's contribution can then be used as an error indicator for this cell. Thus, we split the scalar products into terms for each cell, and integrate by parts on each of them:

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   J(e)
   &=&
   \sum_K (\nabla (u-u_h), \nabla (z-\varphi_h))_K
@@ -192,54 +192,54 @@
   &=&
   \sum_K (-\Delta (u-u_h), z-\varphi_h)_K
   + (\partial_n (u-u_h), z-z_h)_{\partial K}.
-\end{eqnarray*} +\end{eqnarray*}" src="form_2827.png"/>

    -

    Next we use that $-\Delta u=f$, and that the solution of the Laplace equation is smooth enough that $\partial_n u$ is continuous almost everywhere – so the terms involving $\partial_n u$ on one cell cancels with that on its neighbor, where the normal vector has the opposite sign. (The same is not true for $\partial_n u_h$, though.) At the boundary of the domain, where there is no neighbor cell with which this term could cancel, the weight $z-\varphi_h$ can be chosen as zero, and the whole term disappears.

    +

    Next we use that $-\Delta u=f$, and that the solution of the Laplace equation is smooth enough that $\partial_n u$ is continuous almost everywhere – so the terms involving $\partial_n u$ on one cell cancels with that on its neighbor, where the normal vector has the opposite sign. (The same is not true for $\partial_n u_h$, though.) At the boundary of the domain, where there is no neighbor cell with which this term could cancel, the weight $z-\varphi_h$ can be chosen as zero, and the whole term disappears.

    Thus, we have

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   J(e)
   &=&
   \sum_K (f+\Delta u_h, z-\varphi_h)_K
   - (\partial_n u_h, z-\varphi_h)_{\partial K\backslash \partial\Omega}.
-\end{eqnarray*} +\end{eqnarray*}" src="form_2832.png"/>

    -

    In a final step, note that when taking the normal derivative of $u_h$, we mean the value of this quantity as taken from this side of the cell (for the usual Lagrange elements, derivatives are not continuous across edges). We then rewrite the above formula by exchanging half of the edge integral of cell $K$ with the neighbor cell $K'$, to obtain

    -\begin{eqnarray*}
+<p> In a final step, note that when taking the normal derivative of <picture><source srcset=$u_h$, we mean the value of this quantity as taken from this side of the cell (for the usual Lagrange elements, derivatives are not continuous across edges). We then rewrite the above formula by exchanging half of the edge integral of cell $K$ with the neighbor cell $K'$, to obtain

    +\begin{eqnarray*}
   J(e)
   &=&
   \sum_K (f+\Delta u_h, z-\varphi_h)_K
   - \frac 12 (\partial_n u_h|_K + \partial_{n'} u_h|_{K'},
               z-\varphi_h)_{\partial K\backslash \partial\Omega}.
-\end{eqnarray*} +\end{eqnarray*}" src="form_2833.png"/>

    -

    Using that for the normal vectors on adjacent cells we have $n'=-n$, we define the jump of the normal derivative by

    -\[
+<p> Using that for the normal vectors on adjacent cells we have <picture><source srcset=$n'=-n$, we define the jump of the normal derivative by

    +\[
   [\partial_n u_h] \dealcoloneq \partial_n u_h|_K + \partial_{n'} u_h|_{K'}
   =
   \partial_n u_h|_K - \partial_n u_h|_{K'},
-\] +\]" src="form_2835.png"/>

    -

    and get the final form after setting the discrete function $\varphi_h$, which is by now still arbitrary, to the point interpolation of the dual solution, $\varphi_h=I_h z$:

    -\begin{eqnarray*}
+<p> and get the final form after setting the discrete function <picture><source srcset=$\varphi_h$, which is by now still arbitrary, to the point interpolation of the dual solution, $\varphi_h=I_h z$:

    +\begin{eqnarray*}
   J(e)
   &=&
   \sum_K (f+\Delta u_h, z-I_h z)_K
   - \frac 12 ([\partial_n u_h],
               z-I_h z)_{\partial K\backslash \partial\Omega}.
-\end{eqnarray*} +\end{eqnarray*}" src="form_2837.png"/>

    -

    With this, we have obtained an exact representation of the error of the finite element discretization with respect to arbitrary (linear) functionals $J(\cdot)$. Its structure is a weighted form of a residual estimator, as both $f+\Delta u_h$ and $[\partial_n u_h]$ are cell and edge residuals that vanish on the exact solution, and $z-I_h z$ are weights indicating how important the residual on a certain cell is for the evaluation of the given functional. Furthermore, it is a cell-wise quantity, so we can use it as a mesh refinement criterion. The question is: how to evaluate it? After all, the evaluation requires knowledge of the dual solution $z$, which carries the information about the quantity we want to know to best accuracy.

    -

    In some, very special cases, this dual solution is known. For example, if the functional $J(\cdot)$ is the point evaluation, $J(\varphi)=\varphi(x_0)$, then the dual solution has to satisfy

    -\[
+<p>With this, we have obtained an exact representation of the error of the finite element discretization with respect to arbitrary (linear) functionals <picture><source srcset=$J(\cdot)$. Its structure is a weighted form of a residual estimator, as both $f+\Delta u_h$ and $[\partial_n u_h]$ are cell and edge residuals that vanish on the exact solution, and $z-I_h z$ are weights indicating how important the residual on a certain cell is for the evaluation of the given functional. Furthermore, it is a cell-wise quantity, so we can use it as a mesh refinement criterion. The question is: how to evaluate it? After all, the evaluation requires knowledge of the dual solution $z$, which carries the information about the quantity we want to know to best accuracy.

    +

    In some, very special cases, this dual solution is known. For example, if the functional $J(\cdot)$ is the point evaluation, $J(\varphi)=\varphi(x_0)$, then the dual solution has to satisfy

    +\[
   -\Delta z = \delta(x-x_0),
-\] +\]" src="form_2843.png"/>

    -

    with the Dirac delta function on the right hand side, and the dual solution is the Green's function with respect to the point $x_0$. For simple geometries, this function is analytically known, and we could insert it into the error representation formula.

    -

    However, we do not want to restrict ourselves to such special cases. Rather, we will compute the dual solution numerically, and approximate $z$ by some numerically obtained $\tilde z$. We note that it is not sufficient to compute this approximation $\tilde z$ using the same method as used for the primal solution $u_h$, since then $\tilde z-I_h \tilde z=0$, and the overall error estimate would be zero. Rather, the approximation $\tilde z$ has to be from a larger space than the primal finite element space. There are various ways to obtain such an approximation (see the cited literature), and we will choose to compute it with a higher order finite element space. While this is certainly not the most efficient way, it is simple since we already have all we need to do that in place, and it also allows for simple experimenting. For more efficient methods, again refer to the given literature, in particular [BR95], [BR03].

    +

    with the Dirac delta function on the right hand side, and the dual solution is the Green's function with respect to the point $x_0$. For simple geometries, this function is analytically known, and we could insert it into the error representation formula.

    +

    However, we do not want to restrict ourselves to such special cases. Rather, we will compute the dual solution numerically, and approximate $z$ by some numerically obtained $\tilde z$. We note that it is not sufficient to compute this approximation $\tilde z$ using the same method as used for the primal solution $u_h$, since then $\tilde z-I_h \tilde z=0$, and the overall error estimate would be zero. Rather, the approximation $\tilde z$ has to be from a larger space than the primal finite element space. There are various ways to obtain such an approximation (see the cited literature), and we will choose to compute it with a higher order finite element space. While this is certainly not the most efficient way, it is simple since we already have all we need to do that in place, and it also allows for simple experimenting. For more efficient methods, again refer to the given literature, in particular [BR95], [BR03].

    With this, we end the discussion of the mathematical side of this program and turn to the actual implementation.

    -
    Note
    There are two steps above that do not seem necessary if all you care about is computing the error: namely, (i) the subtraction of $\phi_h$ from $z$, and (ii) splitting the integral into a sum of cells and integrating by parts on each. Indeed, neither of these two steps change $J(e)$ at all, as we only ever consider identities above until the substitution of $z$ by $\tilde z$. In other words, if you care only about estimating the global error $J(e)$, then these steps are not necessary. On the other hand, if you want to use the error estimate also as a refinement criterion for each cell of the mesh, then it is necessary to (i) break the estimate into a sum of cells, and (ii) massage the formulas in such a way that each cell's contributions have something to do with the local error. (While the contortions above do not change the value of the sum $J(e)$, they change the values we compute for each cell $K$.) To this end, we want to write everything in the form "residual times dual weight" where a "residual" is something that goes to zero as the approximation becomes $u_h$ better and better. For example, the quantity $\partial_n
-u_h$ is not a residual, since it simply converges to the (normal component of) the gradient of the exact solution. On the other hand, $[\partial_n u_h]$ is a residual because it converges to $[\partial_n
-u]=0$. All of the steps we have taken above in developing the final form of $J(e)$ have indeed had the goal of bringing the final formula into a form where each term converges to zero as the discrete solution $u_h$ converges to $u$. This then allows considering each cell's contribution as an "error indicator" that also converges to zero – as it should as the mesh is refined.
    +
    Note
    There are two steps above that do not seem necessary if all you care about is computing the error: namely, (i) the subtraction of $\phi_h$ from $z$, and (ii) splitting the integral into a sum of cells and integrating by parts on each. Indeed, neither of these two steps change $J(e)$ at all, as we only ever consider identities above until the substitution of $z$ by $\tilde z$. In other words, if you care only about estimating the global error $J(e)$, then these steps are not necessary. On the other hand, if you want to use the error estimate also as a refinement criterion for each cell of the mesh, then it is necessary to (i) break the estimate into a sum of cells, and (ii) massage the formulas in such a way that each cell's contributions have something to do with the local error. (While the contortions above do not change the value of the sum $J(e)$, they change the values we compute for each cell $K$.) To this end, we want to write everything in the form "residual times dual weight" where a "residual" is something that goes to zero as the approximation becomes $u_h$ better and better. For example, the quantity $\partial_n
+u_h$ is not a residual, since it simply converges to the (normal component of) the gradient of the exact solution. On the other hand, $[\partial_n u_h]$ is a residual because it converges to $[\partial_n
+u]=0$. All of the steps we have taken above in developing the final form of $J(e)$ have indeed had the goal of bringing the final formula into a form where each term converges to zero as the discrete solution $u_h$ converges to $u$. This then allows considering each cell's contribution as an "error indicator" that also converges to zero – as it should as the mesh is refined.

    The software

    The step-14 example program builds heavily on the techniques already used in the step-13 program. Its implementation of the dual weighted residual error estimator explained above is done by deriving a second class, properly called DualSolver, from the Solver base class, and having a class (WeightedResidual) that joins the two again and controls the solution of the primal and dual problem, and then uses both to compute the error indicator for mesh refinement.

    The program continues the modular concept of the previous example, by implementing the dual functional, describing quantity of interest, by an abstract base class, and providing two different functionals which implement this interface. Adding a different quantity of interest is thus simple.

    @@ -2572,15 +2572,15 @@

    Note the subtle interplay between resolving the corner singularities, and resolving around the point of evaluation. It will be rather difficult to generate such a mesh by hand, as this would involve to judge quantitatively how much which of the four corner singularities should be resolved, and to set the weight compared to the vicinity of the evaluation point.

    The program prints the point value and the estimated error in this quantity. From extrapolating it, we can guess that the exact value is somewhere close to 0.0334473, plus or minus 0.0000001 (note that we get almost 6 valid digits from only 22,000 (primal) degrees of freedom. This number cannot be obtained from the value of the functional alone, but I have used the assumption that the error estimator is mostly exact, and extrapolated the computed value plus the estimated error, to get an approximation of the true value. Computing with more degrees of freedom shows that this assumption is indeed valid.

    -

    From the computed results, we can generate two graphs: one that shows the convergence of the error $J(u)-J(u_h)$ (taking the extrapolated value as correct) in the point value, and the value that we get by adding up computed value $J(u_h)$ and estimated error eta (if the error estimator $eta$ were exact, then the value $J(u_h)+\eta$ would equal the exact point value, and the error in this quantity would always be zero; however, since the error estimator is only a - good - approximation to the true error, we can by this only reduce the size of the error). In this graph, we also indicate the complexity ${\cal O}(1/N)$ to show that mesh refinement acts optimal in this case. The second chart compares true and estimated error, and shows that the two are actually very close to each other, even for such a complicated quantity as the point value:

    +

    From the computed results, we can generate two graphs: one that shows the convergence of the error $J(u)-J(u_h)$ (taking the extrapolated value as correct) in the point value, and the value that we get by adding up computed value $J(u_h)$ and estimated error eta (if the error estimator $eta$ were exact, then the value $J(u_h)+\eta$ would equal the exact point value, and the error in this quantity would always be zero; however, since the error estimator is only a - good - approximation to the true error, we can by this only reduce the size of the error). In this graph, we also indicate the complexity ${\cal O}(1/N)$ to show that mesh refinement acts optimal in this case. The second chart compares true and estimated error, and shows that the two are actually very close to each other, even for such a complicated quantity as the point value:

    Comparing refinement criteria

    -

    Since we have accepted quite some effort when using the mesh refinement driven by the dual weighted error estimator (for solving the dual problem, and for evaluating the error representation), it is worth while asking whether that effort was successful. To this end, we first compare the achieved error levels for different mesh refinement criteria. To generate this data, simply change the value of the mesh refinement criterion variable in the main program. The results are thus (for the weight in the Kelly indicator, we have chosen the function $1/(r^2+0.1^2)$, where $r$ is the distance to the evaluation point; it can be shown that this is the optimal weight if we neglect the effects of boundaries):

    +

    Since we have accepted quite some effort when using the mesh refinement driven by the dual weighted error estimator (for solving the dual problem, and for evaluating the error representation), it is worth while asking whether that effort was successful. To this end, we first compare the achieved error levels for different mesh refinement criteria. To generate this data, simply change the value of the mesh refinement criterion variable in the main program. The results are thus (for the weight in the Kelly indicator, we have chosen the function $1/(r^2+0.1^2)$, where $r$ is the distance to the evaluation point; it can be shown that this is the optimal weight if we neglect the effects of boundaries):

    -

    Checking these numbers, we see that for global refinement, the error is proportional to $O(1/(sqrt(N) log(N)))$, and for the dual estimator $O(1/N)$. Generally speaking, we see that the dual weighted error estimator is better than the other refinement indicators, at least when compared with those that have a similarly regular behavior. The Kelly indicator produces smaller errors, but jumps about the picture rather irregularly, with the error also changing signs sometimes. Therefore, its behavior does not allow to extrapolate the results to larger values of N. Furthermore, if we trust the error estimates of the dual weighted error estimator, the results can be improved by adding the estimated error to the computed values. In terms of reliability, the weighted estimator is thus better than the Kelly indicator, although the latter sometimes produces smaller errors.

    +

    Checking these numbers, we see that for global refinement, the error is proportional to $O(1/(sqrt(N) log(N)))$, and for the dual estimator $O(1/N)$. Generally speaking, we see that the dual weighted error estimator is better than the other refinement indicators, at least when compared with those that have a similarly regular behavior. The Kelly indicator produces smaller errors, but jumps about the picture rather irregularly, with the error also changing signs sometimes. Therefore, its behavior does not allow to extrapolate the results to larger values of N. Furthermore, if we trust the error estimates of the dual weighted error estimator, the results can be improved by adding the estimated error to the computed values. In terms of reliability, the weighted estimator is thus better than the Kelly indicator, although the latter sometimes produces smaller errors.

    Evaluation of point stresses

    Besides evaluating the values of the solution at a certain point, the program also offers the possibility to evaluate the x-derivatives at a certain point, and also to tailor mesh refinement for this. To let the program compute these quantities, simply replace the two occurrences of PointValueEvaluation in the main function by PointXDerivativeEvaluation, and let the program run:

    Refinement cycle: 0
    Number of degrees of freedom=72
    @@ -2632,16 +2632,16 @@ -

    Note the asymmetry of the grids compared with those we obtained for the point evaluation. This is due to the fact that the domain and the primal solution may be symmetric about the diagonal, but the $x$-derivative is not, and the latter enters the refinement criterion.

    -

    Then, it is interesting to compare actually computed values of the quantity of interest (i.e. the x-derivative of the solution at one point) with a reference value of -0.0528223... plus or minus 0.0000005. We get this reference value by computing on finer grid after some more mesh refinements, with approximately 130,000 cells. Recall that if the error is $O(1/N)$ in the optimal case, then taking a mesh with ten times more cells gives us one additional digit in the result.

    +

    Note the asymmetry of the grids compared with those we obtained for the point evaluation. This is due to the fact that the domain and the primal solution may be symmetric about the diagonal, but the $x$-derivative is not, and the latter enters the refinement criterion.

    +

    Then, it is interesting to compare actually computed values of the quantity of interest (i.e. the x-derivative of the solution at one point) with a reference value of -0.0528223... plus or minus 0.0000005. We get this reference value by computing on finer grid after some more mesh refinements, with approximately 130,000 cells. Recall that if the error is $O(1/N)$ in the optimal case, then taking a mesh with ten times more cells gives us one additional digit in the result.

    In the left part of the following chart, you again see the convergence of the error towards this extrapolated value, while on the right you see a comparison of true and estimated error:

    -

    After an initial phase where the true error changes its sign, the estimated error matches it quite well, again. Also note the dramatic improvement in the error when using the estimated error to correct the computed value of $J(u_h)$.

    +

    After an initial phase where the true error changes its sign, the estimated error matches it quite well, again. Also note the dramatic improvement in the error when using the estimated error to correct the computed value of $J(u_h)$.

    step-13 revisited

    -

    If instead of the Exercise_2_3 data set, we choose CurvedRidges in the main function, and choose $(0.5,0.5)$ as the evaluation point, then we can redo the computations of the previous example program, to compare whether the results obtained with the help of the dual weighted error estimator are better than those we had previously.

    +

    If instead of the Exercise_2_3 data set, we choose CurvedRidges in the main function, and choose $(0.5,0.5)$ as the evaluation point, then we can redo the computations of the previous example program, to compare whether the results obtained with the help of the dual weighted error estimator are better than those we had previously.

    First, the meshes after 9 adaptive refinement cycles obtained with the point evaluation and derivative evaluation refinement criteria, respectively, look like this:

    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_15.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_15.html 2023-08-09 23:38:58.678628433 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_15.html 2023-08-09 23:38:58.678628433 +0000 @@ -142,41 +142,41 @@

    Introduction

    Foreword

    -

    This program deals with an example of a non-linear elliptic partial differential equation, the minimal surface equation. You can imagine the solution of this equation to describe the surface spanned by a soap film that is enclosed by a closed wire loop. We imagine the wire to not just be a planar loop, but in fact curved. The surface tension of the soap film will then reduce the surface to have minimal surface. The solution of the minimal surface equation describes this shape with the wire's vertical displacement as a boundary condition. For simplicity, we will here assume that the surface can be written as a graph $u=u(x,y)$ although it is clear that it is not very hard to construct cases where the wire is bent in such a way that the surface can only locally be constructed as a graph but not globally.

    +

    This program deals with an example of a non-linear elliptic partial differential equation, the minimal surface equation. You can imagine the solution of this equation to describe the surface spanned by a soap film that is enclosed by a closed wire loop. We imagine the wire to not just be a planar loop, but in fact curved. The surface tension of the soap film will then reduce the surface to have minimal surface. The solution of the minimal surface equation describes this shape with the wire's vertical displacement as a boundary condition. For simplicity, we will here assume that the surface can be written as a graph $u=u(x,y)$ although it is clear that it is not very hard to construct cases where the wire is bent in such a way that the surface can only locally be constructed as a graph but not globally.

    Because the equation is non-linear, we can't solve it directly. Rather, we have to use Newton's method to compute the solution iteratively.

    Note
    The material presented here is also discussed in video lecture 31.5, video lecture 31.55, video lecture 31.6. (All video lectures are also available here.) (See also video lecture 31.65, video lecture 31.7.)

    Classical formulation

    In a classical sense, the problem is given in the following form:

    -\begin{align*}
+<picture><source srcset=\begin{align*}
     -\nabla \cdot \left( \frac{1}{\sqrt{1+|\nabla u|^{2}}}\nabla u \right) &= 0 \qquad
     \qquad &&\textrm{in} ~ \Omega
     \\
     u&=g \qquad\qquad &&\textrm{on} ~ \partial \Omega.
-  \end{align*} + \end{align*}" src="form_2858.png"/>

    -

    $\Omega$ is the domain we get by projecting the wire's positions into $x-y$ space. In this example, we choose $\Omega$ as the unit disk.

    -

    As described above, we solve this equation using Newton's method in which we compute the $n$th approximate solution from the $(n-1)$th one, and use a damping parameter $\alpha^n$ to get better global convergence behavior:

    -\begin{align*}
+<p><picture><source srcset=$\Omega$ is the domain we get by projecting the wire's positions into $x-y$ space. In this example, we choose $\Omega$ as the unit disk.

    +

    As described above, we solve this equation using Newton's method in which we compute the $n$th approximate solution from the $(n-1)$th one, and use a damping parameter $\alpha^n$ to get better global convergence behavior:

    +\begin{align*}
     F'(u^{n},\delta u^{n})&=- F(u^{n})
     \\
     u^{n+1}&=u^{n}+\alpha^n \delta u^{n}
-  \end{align*} + \end{align*}" src="form_2862.png"/>

    with

    -\[
+<picture><source srcset=\[
     F(u) \dealcoloneq -\nabla \cdot \left( \frac{1}{\sqrt{1+|\nabla u|^{2}}}\nabla u \right)
-  \] + \]" src="form_2863.png"/>

    -

    and $F'(u,\delta u)$ the derivative of F in direction of $\delta u$:

    -\[
+<p> and <picture><source srcset=$F'(u,\delta u)$ the derivative of F in direction of $\delta u$:

    +\[
   F'(u,\delta u)=\lim \limits_{\epsilon \rightarrow 0}{\frac{F(u+\epsilon \delta u)-
   F(u)}{\epsilon}}.
-\] +\]" src="form_2866.png"/>

    -

    Going through the motions to find out what $F'(u,\delta u)$ is, we find that we have to solve a linear elliptic PDE in every Newton step, with $\delta u^n$ as the solution of:

    +

    Going through the motions to find out what $F'(u,\delta u)$ is, we find that we have to solve a linear elliptic PDE in every Newton step, with $\delta u^n$ as the solution of:

    -\[
+<picture><source srcset=\[
   - \nabla \cdot \left( \frac{1}{\left(1+|\nabla u^{n}|^{2}\right)^{\frac{1}{2}}}\nabla
   \delta u^{n} \right) +
   \nabla \cdot \left( \frac{\nabla u^{n} \cdot
@@ -184,62 +184,62 @@
   \right)  =
   -\left( - \nabla \cdot \left( \frac{1}{\left(1+|\nabla u^{n}|^{2}\right)^{\frac{1}{2}}}
   \nabla u^{n} \right) \right)
-  \] + \]" src="form_2868.png"/>

    -

    In order to solve the minimal surface equation, we have to solve this equation repeatedly, once per Newton step. To solve this, we have to take a look at the boundary condition of this problem. Assuming that $u^{n}$ already has the right boundary values, the Newton update $\delta u^{n}$ should have zero boundary conditions, in order to have the right boundary condition after adding both. In the first Newton step, we are starting with the solution $u^{0}\equiv 0$, the Newton update still has to deliver the right boundary condition to the solution $u^{1}$.

    -

    Summing up, we have to solve the PDE above with the boundary condition $\delta
-u^{0}=g$ in the first step and with $\delta u^{n}=0$ in all the following steps.

    -
    Note
    In some sense, one may argue that if the program already implements $F(u)$, it is duplicative to also have to implement $F'(u,\delta)$. As always, duplication tempts bugs and we would like to avoid it. While we do not explore this issue in this program, we will come back to it at the end of the Possibilities for extensions section below, and specifically in step-72.
    +

    In order to solve the minimal surface equation, we have to solve this equation repeatedly, once per Newton step. To solve this, we have to take a look at the boundary condition of this problem. Assuming that $u^{n}$ already has the right boundary values, the Newton update $\delta u^{n}$ should have zero boundary conditions, in order to have the right boundary condition after adding both. In the first Newton step, we are starting with the solution $u^{0}\equiv 0$, the Newton update still has to deliver the right boundary condition to the solution $u^{1}$.

    +

    Summing up, we have to solve the PDE above with the boundary condition $\delta
+u^{0}=g$ in the first step and with $\delta u^{n}=0$ in all the following steps.

    +
    Note
    In some sense, one may argue that if the program already implements $F(u)$, it is duplicative to also have to implement $F'(u,\delta)$. As always, duplication tempts bugs and we would like to avoid it. While we do not explore this issue in this program, we will come back to it at the end of the Possibilities for extensions section below, and specifically in step-72.

    Weak formulation of the problem

    -

    Starting with the strong formulation above, we get the weak formulation by multiplying both sides of the PDE with a test function $\varphi$ and integrating by parts on both sides:

    -\[
+<p>Starting with the strong formulation above, we get the weak formulation by multiplying both sides of the PDE with a test function <picture><source srcset=$\varphi$ and integrating by parts on both sides:

    +\[
   \left( \nabla \varphi , \frac{1}{\left(1+|\nabla u^{n}|^{2}\right)^{\frac{1}{2}}}\nabla
   \delta u^{n} \right)-\left(\nabla \varphi ,\frac{\nabla u^{n} \cdot \nabla
   \delta u^{n}}{\left(1+|\nabla u^{n}|^{2}\right)^{\frac{3}{2}}}\nabla u^{n}  \right)
   = -\left(\nabla \varphi , \frac{1}{\left(1+|\nabla u^{n}|^{2}\right)^{\frac{1}{2}}} \nabla u^{n}
    \right).
-  \] + \]" src="form_2876.png"/>

    -

    Here the solution $\delta u^{n}$ is a function in $H^{1}(\Omega)$, subject to the boundary conditions discussed above. Reducing this space to a finite dimensional space with basis $\left\{
-\varphi_{0},\dots , \varphi_{N-1}\right\}$, we can write the solution:

    +

    Here the solution $\delta u^{n}$ is a function in $H^{1}(\Omega)$, subject to the boundary conditions discussed above. Reducing this space to a finite dimensional space with basis $\left\{
+\varphi_{0},\dots , \varphi_{N-1}\right\}$, we can write the solution:

    -\[
+<picture><source srcset=\[
   \delta u^{n}=\sum_{j=0}^{N-1} \delta U_{j} \varphi_{j}.
-\] +\]" src="form_2879.png"/>

    -

    Using the basis functions as test functions and defining $a_{n} \dealcoloneq \frac{1}
-{\sqrt{1+|\nabla u^{n}|^{2}}}$, we can rewrite the weak formulation:

    +

    Using the basis functions as test functions and defining $a_{n} \dealcoloneq \frac{1}
+{\sqrt{1+|\nabla u^{n}|^{2}}}$, we can rewrite the weak formulation:

    -\[
+<picture><source srcset=\[
   \sum_{j=0}^{N-1}\left[ \left( \nabla \varphi_{i} , a_{n} \nabla \varphi_{j} \right) -
   \left(\nabla u^{n}\cdot \nabla \varphi_{i} , a_{n}^{3} \nabla u^{n} \cdot \nabla
   \varphi_{j} \right) \right] \cdot \delta U_{j}=-\left( \nabla \varphi_{i} , a_{n}
   \nabla u^{n}\right) \qquad \forall i=0,\dots ,N-1,
-\] +\]" src="form_2881.png"/>

    -

    where the solution $\delta u^{n}$ is given by the coefficients $\delta U^{n}_{j}$. This linear system of equations can be rewritten as:

    +

    where the solution $\delta u^{n}$ is given by the coefficients $\delta U^{n}_{j}$. This linear system of equations can be rewritten as:

    -\[
+<picture><source srcset=\[
   A^{n}\; \delta U^{n}=b^{n},
-\] +\]" src="form_2883.png"/>

    -

    where the entries of the matrix $A^{n}$ are given by:

    +

    where the entries of the matrix $A^{n}$ are given by:

    -\[
+<picture><source srcset=\[
   A^{n}_{ij} \dealcoloneq \left( \nabla \varphi_{i} , a_{n} \nabla \varphi_{j} \right) -
   \left(\nabla u^{n}\cdot \nabla \varphi_{i} , a_{n}^{3} \nabla u^{n} \cdot \nabla
   \varphi_{j} \right),
-\] +\]" src="form_2885.png"/>

    -

    and the right hand side $b^{n}$ is given by:

    +

    and the right hand side $b^{n}$ is given by:

    -\[
+<picture><source srcset=\[
   b^{n}_{i} \dealcoloneq -\left( \nabla \varphi_{i} , a_{n} \nabla u^{n}\right).
-\] +\]" src="form_2887.png"/>

    Questions about the appropriate solver

    The matrix that corresponds to the Newton step above can be reformulated to show its structure a bit better. Rewriting it slightly, we get that it has the form

    -\[
+<picture><source srcset=\[
   A_{ij}
   =
   \left(
@@ -247,10 +247,10 @@
     B
     \nabla \varphi_j
   \right),
-\] +\]" src="form_2888.png"/>

    -

    where the matrix $B$ (of size $d \times d$ in $d$ space dimensions) is given by the following expression:

    -\[
+<p> where the matrix <picture><source srcset=$B$ (of size $d \times d$ in $d$ space dimensions) is given by the following expression:

    +\[
   B
   =
   a_n \left\{
@@ -265,44 +265,44 @@
   \frac{\nabla u_n}{\sqrt{1+|\nabla u^{n}|^{2}}} \otimes
   \frac{\nabla u_n}{\sqrt{1+|\nabla u^{n}|^{2}}}
   \right\}.
-\] +\]" src="form_2890.png"/>

    -

    From this expression, it is obvious that $B$ is symmetric, and so $A$ is symmetric as well. On the other hand, $B$ is also positive definite, which confers the same property onto $A$. This can be seen by noting that the vector $v_1 =
-\frac{\nabla u^n}{|\nabla u^n|}$ is an eigenvector of $B$ with eigenvalue $\lambda_1=a_n \left(1-\frac{|\nabla u^n|^2}{1+|\nabla u^n|^2}\right) > 0$ while all vectors $v_2\ldots v_d$ that are perpendicular to $v_1$ and each other are eigenvectors with eigenvalue $a_n$. Since all eigenvalues are positive, $B$ is positive definite and so is $A$. We can thus use the CG method for solving the Newton steps. (The fact that the matrix $A$ is symmetric and positive definite should not come as a surprise. It results from taking the derivative of an operator that results from taking the derivative of an energy functional: the minimal surface equation simply minimizes some non-quadratic energy. Consequently, the Newton matrix, as the matrix of second derivatives of a scalar energy, must be symmetric since the derivative with regard to the $i$th and $j$th degree of freedom should clearly commute. Likewise, if the energy functional is convex, then the matrix of second derivatives must be positive definite, and the direct calculation above simply reaffirms this.)

    -

    It is worth noting, however, that the positive definiteness degenerates for problems where $\nabla u$ becomes large. In other words, if we simply multiply all boundary values by 2, then to first order $u$ and $\nabla u$ will also be multiplied by two, but as a consequence the smallest eigenvalue of $B$ will become smaller and the matrix will become more ill-conditioned. (More specifically, for $|\nabla u^n|\rightarrow\infty$ we have that $\lambda_1 \propto a_n \frac{1}{|\nabla u^n|^2}$ whereas $\lambda_2\ldots \lambda_d=a_n$; thus, the condition number of $B$, which is a multiplicative factor in the condition number of $A$ grows like ${\cal O}(|\nabla u^n|^2)$.) It is simple to verify with the current program that indeed multiplying the boundary values used in the current program by larger and larger values results in a problem that will ultimately no longer be solvable using the simple preconditioned CG method we use here.

    +

    From this expression, it is obvious that $B$ is symmetric, and so $A$ is symmetric as well. On the other hand, $B$ is also positive definite, which confers the same property onto $A$. This can be seen by noting that the vector $v_1 =
+\frac{\nabla u^n}{|\nabla u^n|}$ is an eigenvector of $B$ with eigenvalue $\lambda_1=a_n \left(1-\frac{|\nabla u^n|^2}{1+|\nabla u^n|^2}\right) > 0$ while all vectors $v_2\ldots v_d$ that are perpendicular to $v_1$ and each other are eigenvectors with eigenvalue $a_n$. Since all eigenvalues are positive, $B$ is positive definite and so is $A$. We can thus use the CG method for solving the Newton steps. (The fact that the matrix $A$ is symmetric and positive definite should not come as a surprise. It results from taking the derivative of an operator that results from taking the derivative of an energy functional: the minimal surface equation simply minimizes some non-quadratic energy. Consequently, the Newton matrix, as the matrix of second derivatives of a scalar energy, must be symmetric since the derivative with regard to the $i$th and $j$th degree of freedom should clearly commute. Likewise, if the energy functional is convex, then the matrix of second derivatives must be positive definite, and the direct calculation above simply reaffirms this.)

    +

    It is worth noting, however, that the positive definiteness degenerates for problems where $\nabla u$ becomes large. In other words, if we simply multiply all boundary values by 2, then to first order $u$ and $\nabla u$ will also be multiplied by two, but as a consequence the smallest eigenvalue of $B$ will become smaller and the matrix will become more ill-conditioned. (More specifically, for $|\nabla u^n|\rightarrow\infty$ we have that $\lambda_1 \propto a_n \frac{1}{|\nabla u^n|^2}$ whereas $\lambda_2\ldots \lambda_d=a_n$; thus, the condition number of $B$, which is a multiplicative factor in the condition number of $A$ grows like ${\cal O}(|\nabla u^n|^2)$.) It is simple to verify with the current program that indeed multiplying the boundary values used in the current program by larger and larger values results in a problem that will ultimately no longer be solvable using the simple preconditioned CG method we use here.

    Choice of step length and globalization

    -

    As stated above, Newton's method works by computing a direction $\delta u^n$ and then performing the update $u^{n+1} = u^{n}+\alpha^n
-\delta u^{n}$ with a step length $0 < \alpha^n \le 1$. It is a common observation that for strongly nonlinear models, Newton's method does not converge if we always choose $\alpha^n=1$ unless one starts with an initial guess $u^0$ that is sufficiently close to the solution $u$ of the nonlinear problem. In practice, we don't always have such an initial guess, and consequently taking full Newton steps (i.e., using $\alpha=1$) does frequently not work.

    -

    A common strategy therefore is to use a smaller step length for the first few steps while the iterate $u^n$ is still far away from the solution $u$ and as we get closer use larger values for $\alpha^n$ until we can finally start to use full steps $\alpha^n=1$ as we are close enough to the solution. The question is of course how to choose $\alpha^n$. There are basically two widely used approaches: line search and trust region methods.

    +

    As stated above, Newton's method works by computing a direction $\delta u^n$ and then performing the update $u^{n+1} = u^{n}+\alpha^n
+\delta u^{n}$ with a step length $0 < \alpha^n \le 1$. It is a common observation that for strongly nonlinear models, Newton's method does not converge if we always choose $\alpha^n=1$ unless one starts with an initial guess $u^0$ that is sufficiently close to the solution $u$ of the nonlinear problem. In practice, we don't always have such an initial guess, and consequently taking full Newton steps (i.e., using $\alpha=1$) does frequently not work.

    +

    A common strategy therefore is to use a smaller step length for the first few steps while the iterate $u^n$ is still far away from the solution $u$ and as we get closer use larger values for $\alpha^n$ until we can finally start to use full steps $\alpha^n=1$ as we are close enough to the solution. The question is of course how to choose $\alpha^n$. There are basically two widely used approaches: line search and trust region methods.

    In this program, we simply always choose the step length equal to 0.1. This makes sure that for the testcase at hand we do get convergence although it is clear that by not eventually reverting to full step lengths we forego the rapid, quadratic convergence that makes Newton's method so appealing. Obviously, this is a point one eventually has to address if the program was made into one that is meant to solve more realistic problems. We will comment on this issue some more in the results section, and use an even better approach in step-77.

    Summary of the algorithm and testcase

    Overall, the program we have here is not unlike step-6 in many regards. The layout of the main class is essentially the same. On the other hand, the driving algorithm in the run() function is different and works as follows:

    1. -

      Start with the function $u^{0}\equiv 0$ and modify it in such a way that the values of $u^0$ along the boundary equal the correct boundary values $g$ (this happens in MinimalSurfaceProblem::set_boundary_values). Set $n=0$.

      +

      Start with the function $u^{0}\equiv 0$ and modify it in such a way that the values of $u^0$ along the boundary equal the correct boundary values $g$ (this happens in MinimalSurfaceProblem::set_boundary_values). Set $n=0$.

    2. -

      Compute the Newton update by solving the system $A^{n}\;\delta
-  U^{n}=b^{n}$ with boundary condition $\delta u^{n}=0$ on $\partial \Omega$.

      +

      Compute the Newton update by solving the system $A^{n}\;\delta
+  U^{n}=b^{n}$ with boundary condition $\delta u^{n}=0$ on $\partial \Omega$.

    3. -

      Compute a step length $\alpha^n$. In this program, we always set $\alpha^n=0.1$. To make things easier to extend later on, this happens in a function of its own, namely in MinimalSurfaceProblem::determine_step_length. (The strategy of always choosing $\alpha^n=0.1$ is of course not optimal – we should choose a step length that works for a given search direction – but it requires a bit of work to do that. In the end, we leave these sorts of things to external packages: step-77 does that.)

      +

      Compute a step length $\alpha^n$. In this program, we always set $\alpha^n=0.1$. To make things easier to extend later on, this happens in a function of its own, namely in MinimalSurfaceProblem::determine_step_length. (The strategy of always choosing $\alpha^n=0.1$ is of course not optimal – we should choose a step length that works for a given search direction – but it requires a bit of work to do that. In the end, we leave these sorts of things to external packages: step-77 does that.)

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_16.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_16.html 2023-08-09 23:38:58.722628762 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_16.html 2023-08-09 23:38:58.722628762 +0000 @@ -139,7 +139,7 @@
      -

      The fine level in this mesh consists only of the degrees of freedom that are defined on the refined cells, but does not extend to that part of the domain that is not refined. While this guarantees that the overall effort grows as ${\cal O}(N)$ as necessary for optimal multigrid complexity, it leads to problems when defining where to smooth and what boundary conditions to pose for the operators defined on individual levels if the level boundary is not an external boundary. These questions are discussed in detail in the article cited above.

      +

      The fine level in this mesh consists only of the degrees of freedom that are defined on the refined cells, but does not extend to that part of the domain that is not refined. While this guarantees that the overall effort grows as ${\cal O}(N)$ as necessary for optimal multigrid complexity, it leads to problems when defining where to smooth and what boundary conditions to pose for the operators defined on individual levels if the level boundary is not an external boundary. These questions are discussed in detail in the article cited above.

      The testcase

      The problem we solve here is similar to step-6, with two main differences: first, the multigrid preconditioner, obviously. We also change the discontinuity of the coefficients such that the local assembler does not look more complicated than necessary.

      The commented program

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_18.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_18.html 2023-08-09 23:38:58.802629359 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_18.html 2023-08-09 23:38:58.802629359 +0000 @@ -152,23 +152,23 @@

      Quasistatic elastic deformation

      Motivation of the model

      In general, time-dependent small elastic deformations are described by the elastic wave equation

      -\[
+<picture><source srcset=\[
   \rho \frac{\partial^2 \mathbf{u}}{\partial t^2}
   + c \frac{\partial \mathbf{u}}{\partial t}
   - \textrm{div}\  ( C \varepsilon(\mathbf{u})) = \mathbf{f}
   \qquad
   \textrm{in}\ \Omega,
-\] +\]" src="form_2939.png"/>

      -

      where $\mathbf{u}=\mathbf{u} (\mathbf{x},t)$ is the deformation of the body, $\rho$ and $c$ the density and attenuation coefficient, and $\mathbf{f}$ external forces. In addition, initial conditions

      -\[
+<p> where <picture><source srcset=$\mathbf{u}=\mathbf{u} (\mathbf{x},t)$ is the deformation of the body, $\rho$ and $c$ the density and attenuation coefficient, and $\mathbf{f}$ external forces. In addition, initial conditions

      +\[
   \mathbf{u}(\cdot, 0) = \mathbf{u}_0(\cdot)
   \qquad
   \textrm{on}\ \Omega,
-\] +\]" src="form_2942.png"/>

      and Dirichlet (displacement) or Neumann (traction) boundary conditions need to be specified for a unique solution:

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   \mathbf{u}(\mathbf{x},t) &=& \mathbf{d}(\mathbf{x},t)
   \qquad
   \textrm{on}\ \Gamma_D\subset\partial\Omega,
@@ -176,12 +176,12 @@
   \mathbf{n} \ C \varepsilon(\mathbf{u}(\mathbf{x},t)) &=& \mathbf{b}(\mathbf{x},t)
   \qquad
   \textrm{on}\ \Gamma_N=\partial\Omega\backslash\Gamma_D.
-\end{eqnarray*} +\end{eqnarray*}" src="form_2943.png"/>

      -

      In above formulation, $\varepsilon(\mathbf{u})= \frac 12 (\nabla \mathbf{u} + \nabla
-\mathbf{u}^T)$ is the symmetric gradient of the displacement, also called the strain. $C$ is a tensor of rank 4, called the stress-strain tensor (the inverse of the compliance tensor) that contains knowledge of the elastic strength of the material; its symmetry properties make sure that it maps symmetric tensors of rank 2 (“matrices” of dimension $d$, where $d$ is the spatial dimensionality) onto symmetric tensors of the same rank. We will comment on the roles of the strain and stress tensors more below. For the moment it suffices to say that we interpret the term $\textrm{div}\  ( C \varepsilon(\mathbf{u}))$ as the vector with components $\frac \partial{\partial x_j} C_{ijkl} \varepsilon(\mathbf{u})_{kl}$, where summation over indices $j,k,l$ is implied.

      -

      The quasistatic limit of this equation is motivated as follows: each small perturbation of the body, for example by changes in boundary condition or the forcing function, will result in a corresponding change in the configuration of the body. In general, this will be in the form of waves radiating away from the location of the disturbance. Due to the presence of the damping term, these waves will be attenuated on a time scale of, say, $\tau$. Now, assume that all changes in external forcing happen on times scales that are much larger than $\tau$. In that case, the dynamic nature of the change is unimportant: we can consider the body to always be in static equilibrium, i.e. we can assume that at all times the body satisfies

      -\begin{eqnarray*}
+<p> In above formulation, <picture><source srcset=$\varepsilon(\mathbf{u})= \frac 12 (\nabla \mathbf{u} + \nabla
+\mathbf{u}^T)$ is the symmetric gradient of the displacement, also called the strain. $C$ is a tensor of rank 4, called the stress-strain tensor (the inverse of the compliance tensor) that contains knowledge of the elastic strength of the material; its symmetry properties make sure that it maps symmetric tensors of rank 2 (“matrices” of dimension $d$, where $d$ is the spatial dimensionality) onto symmetric tensors of the same rank. We will comment on the roles of the strain and stress tensors more below. For the moment it suffices to say that we interpret the term $\textrm{div}\  ( C \varepsilon(\mathbf{u}))$ as the vector with components $\frac \partial{\partial x_j} C_{ijkl} \varepsilon(\mathbf{u})_{kl}$, where summation over indices $j,k,l$ is implied.

      +

      The quasistatic limit of this equation is motivated as follows: each small perturbation of the body, for example by changes in boundary condition or the forcing function, will result in a corresponding change in the configuration of the body. In general, this will be in the form of waves radiating away from the location of the disturbance. Due to the presence of the damping term, these waves will be attenuated on a time scale of, say, $\tau$. Now, assume that all changes in external forcing happen on times scales that are much larger than $\tau$. In that case, the dynamic nature of the change is unimportant: we can consider the body to always be in static equilibrium, i.e. we can assume that at all times the body satisfies

      +\begin{eqnarray*}
   - \textrm{div}\  ( C \varepsilon(\mathbf{u})) &=& \mathbf{f}(\mathbf{x},t)
   \qquad
   \textrm{in}\ \Omega,
@@ -193,13 +193,13 @@
   \mathbf{n} \ C \varepsilon(\mathbf{u}(\mathbf{x},t)) &=& \mathbf{b}(\mathbf{x},t)
   \qquad
   \textrm{on}\ \Gamma_N.
-\end{eqnarray*} +\end{eqnarray*}" src="form_2949.png"/>

      -

      Note that the differential equation does not contain any time derivatives any more – all time dependence is introduced through boundary conditions and a possibly time-varying force function $\mathbf{f}(\mathbf{x},t)$. The changes in configuration can therefore be considered as being stationary instantaneously. An alternative view of this is that $t$ is not really a time variable, but only a time-like parameter that governs the evolution of the problem.

      +

      Note that the differential equation does not contain any time derivatives any more – all time dependence is introduced through boundary conditions and a possibly time-varying force function $\mathbf{f}(\mathbf{x},t)$. The changes in configuration can therefore be considered as being stationary instantaneously. An alternative view of this is that $t$ is not really a time variable, but only a time-like parameter that governs the evolution of the problem.

      While these equations are sufficient to describe small deformations, computing large deformations is a little more complicated and, in general, leads to nonlinear equations such as those treated in step-44. In the following, let us consider some of the tools one would employ when simulating problems in which the deformation becomes large.

      Note
      The model we will consider below is not founded on anything that would be mathematically sound: we will consider a model in which we produce a small deformation, deform the physical coordinates of the body by this deformation, and then consider the next loading step again as a linear problem. This isn't consistent, since the assumption of linearity implies that deformations are infinitesimal and so moving around the vertices of our mesh by a finite amount before solving the next linear problem is an inconsistent approach. We should therefore note that it is not surprising that the equations discussed below can't be found in the literature: The model considered here has little to do with reality! On the other hand, the implementation techniques we consider are very much what one would need to use when implementing a real model, as we will see in step-44.
      -

      To come back to defining our "artificial" model, let us first introduce a tensorial stress variable $\sigma$, and write the differential equations in terms of the stress:

      -\begin{eqnarray*}
+<p>To come back to defining our $\sigma$, and write the differential equations in terms of the stress:

      +\begin{eqnarray*}
   - \textrm{div}\  \sigma &=& \mathbf{f}(\mathbf{x},t)
   \qquad
   \textrm{in}\ \Omega(t),
@@ -211,30 +211,30 @@
   \mathbf{n} \ C \varepsilon(\mathbf{u}(\mathbf{x},t)) &=& \mathbf{b}(\mathbf{x},t)
   \qquad
   \textrm{on}\ \Gamma_N=\partial\Omega(t)\backslash\Gamma_D.
-\end{eqnarray*} +\end{eqnarray*}" src="form_2951.png"/>

      -

      Note that these equations are posed on a domain $\Omega(t)$ that changes with time, with the boundary moving according to the displacements $\mathbf{u}(\mathbf{x},t)$ of the points on the boundary. To complete this system, we have to specify the incremental relationship between the stress and the strain, as follows:

      -\[
+<p> Note that these equations are posed on a domain <picture><source srcset=$\Omega(t)$ that changes with time, with the boundary moving according to the displacements $\mathbf{u}(\mathbf{x},t)$ of the points on the boundary. To complete this system, we have to specify the incremental relationship between the stress and the strain, as follows:

      +\[
   \dot\sigma = C \varepsilon (\dot{\mathbf{u}}),
   \qquad
   \qquad
   \textrm{[stress-strain]}
-\] +\]" src="form_2954.png"/>

      -

      where a dot indicates a time derivative. Both the stress $\sigma$ and the strain $\varepsilon(\mathbf{u})$ are symmetric tensors of rank 2.

      +

      where a dot indicates a time derivative. Both the stress $\sigma$ and the strain $\varepsilon(\mathbf{u})$ are symmetric tensors of rank 2.

      Time discretization

      -

      Numerically, this system is solved as follows: first, we discretize the time component using a backward Euler scheme. This leads to a discrete equilibrium of force at time step $n$:

      -\[
+<p>Numerically, this system is solved as follows: first, we discretize the time component using a backward Euler scheme. This leads to a discrete equilibrium of force at time step <picture><source srcset=$n$:

      +\[
   -\textrm{div}\  \sigma^n = f^n,
-\] +\]" src="form_2956.png"/>

      where

      -\[
+<picture><source srcset=\[
   \sigma^n = \sigma^{n-1} + C \varepsilon (\Delta \mathbf{u}^n),
-\] +\]" src="form_2957.png"/>

      -

      and $\Delta \mathbf{u}^n$ the incremental displacement for time step $n$. In addition, we have to specify initial data $\mathbf{u}(\cdot,0)=\mathbf{u}_0$. This way, if we want to solve for the displacement increment, we have to solve the following system:

      -\begin{align*}
+<p> and <picture><source srcset=$\Delta \mathbf{u}^n$ the incremental displacement for time step $n$. In addition, we have to specify initial data $\mathbf{u}(\cdot,0)=\mathbf{u}_0$. This way, if we want to solve for the displacement increment, we have to solve the following system:

      +\begin{align*}
   - \textrm{div}\   C \varepsilon(\Delta\mathbf{u}^n) &= \mathbf{f} + \textrm{div}\  \sigma^{n-1}
   \qquad
   &&\textrm{in}\ \Omega(t_{n-1}),
@@ -246,11 +246,11 @@
   \mathbf{n} \ C \varepsilon(\Delta \mathbf{u}^n(\mathbf{x},t)) &= \mathbf{b}(\mathbf{x},t_n)-\mathbf{b}(\mathbf{x},t_{n-1})
   \qquad
   &&\textrm{on}\ \Gamma_N=\partial\Omega(t_{n-1})\backslash\Gamma_D.
-\end{align*} +\end{align*}" src="form_2960.png"/>

      -

      The weak form of this set of equations, which as usual is the basis for the finite element formulation, reads as follows: find $\Delta \mathbf{u}^n \in
-\{v\in H^1(\Omega(t_{n-1}))^d: v|_{\Gamma_D}=\mathbf{d}(\cdot,t_n) - \mathbf{d}(\cdot,t_{n-1})\}$ such that

      -\begin{align*}
+<p> The weak form of this set of equations, which as usual is the basis for the finite element formulation, reads as follows: find <picture><source srcset=$\Delta \mathbf{u}^n \in
+\{v\in H^1(\Omega(t_{n-1}))^d: v|_{\Gamma_D}=\mathbf{d}(\cdot,t_n) - \mathbf{d}(\cdot,t_{n-1})\}$ such that

      +\begin{align*}
   (C \varepsilon(\Delta\mathbf{u}^n), \varepsilon(\varphi) )_{\Omega(t_{n-1})}
   &=
   (\mathbf{f}, \varphi)_{\Omega(t_{n-1})}
@@ -262,12 +262,12 @@
   \\
   &\qquad\qquad
   \forall \varphi \in \{\mathbf{v}\in H^1(\Omega(t_{n-1}))^d: \mathbf{v}|_{\Gamma_D}=0\}.
-\end{align*} +\end{align*}" src="form_2962.png"/>

      -

      Using that $\sigma^{n-1} \mathbf{n}
+<p> Using that <picture><source srcset=$\sigma^{n-1} \mathbf{n}
             = [C \varepsilon(\mathbf{u}^{n-1})] \mathbf{n}
-            = \mathbf{b}(\mathbf x, t_{n-1})$, these equations can be simplified to

      -\begin{align*}
+            = \mathbf{b}(\mathbf x, t_{n-1})$, these equations can be simplified to

      +\begin{align*}
   (C \varepsilon(\Delta\mathbf{u}^n), \varepsilon(\varphi) )_{\Omega(t_{n-1})}
   &=
   (\mathbf{f}, \varphi)_{\Omega(t_{n-1})}
@@ -279,32 +279,32 @@
   \qquad
   \qquad
   \textrm{[linear-system]}
-\end{align*} +\end{align*}" src="form_2964.png"/>

      -

      We note that, for simplicity, in the program we will always assume that there are no boundary forces, i.e. $\mathbf{b} = 0$, and that the deformation of the body is driven by body forces $\mathbf{f}$ and prescribed boundary displacements $\mathbf{d}$ alone. It is also worth noting that when integrating by parts, we would get terms of the form $(C \varepsilon(\Delta\mathbf{u}^n), \nabla \varphi
-)_{\Omega(t_{n-1})}$, but that we replace them with the term involving the symmetric gradient $\varepsilon(\varphi)$ instead of $\nabla\varphi$. Due to the symmetry of $C$, the two terms are mathematically equivalent, but the symmetric version avoids the potential for round-off errors making the resulting matrix slightly non-symmetric.

      -

      The system at time step $n$, to be solved on the old domain $\Omega(t_{n-1})$, has exactly the form of a stationary elastic problem, and is therefore similar to what we have already implemented in previous example programs. We will therefore not comment on the space discretization beyond saying that we again use lowest order continuous finite elements.

      +

      We note that, for simplicity, in the program we will always assume that there are no boundary forces, i.e. $\mathbf{b} = 0$, and that the deformation of the body is driven by body forces $\mathbf{f}$ and prescribed boundary displacements $\mathbf{d}$ alone. It is also worth noting that when integrating by parts, we would get terms of the form $(C \varepsilon(\Delta\mathbf{u}^n), \nabla \varphi
+)_{\Omega(t_{n-1})}$, but that we replace them with the term involving the symmetric gradient $\varepsilon(\varphi)$ instead of $\nabla\varphi$. Due to the symmetry of $C$, the two terms are mathematically equivalent, but the symmetric version avoids the potential for round-off errors making the resulting matrix slightly non-symmetric.

      +

      The system at time step $n$, to be solved on the old domain $\Omega(t_{n-1})$, has exactly the form of a stationary elastic problem, and is therefore similar to what we have already implemented in previous example programs. We will therefore not comment on the space discretization beyond saying that we again use lowest order continuous finite elements.

      There are differences, however:

      1. We have to move (update) the mesh after each time step, in order to be able to solve the next time step on a new domain;

      2. -We need to know $\sigma^{n-1}$ to compute the next incremental displacement, i.e. we need to compute it at the end of the time step to make sure it is available for the next time step. Essentially, the stress variable is our window to the history of deformation of the body.
      3. +We need to know $\sigma^{n-1}$ to compute the next incremental displacement, i.e. we need to compute it at the end of the time step to make sure it is available for the next time step. Essentially, the stress variable is our window to the history of deformation of the body.

      These two operations are done in the functions move_mesh and update_quadrature_point_history in the program. While moving the mesh is only a technicality, updating the stress is a little more complicated and will be discussed in the next section.

      Updating the stress variable

      -

      As indicated above, we need to have the stress variable $\sigma^n$ available when computing time step $n+1$, and we can compute it using

      -\[
+<p>As indicated above, we need to have the stress variable <picture><source srcset=$\sigma^n$ available when computing time step $n+1$, and we can compute it using

      +\[
   \sigma^n = \sigma^{n-1} + C \varepsilon (\Delta \mathbf{u}^n).
   \qquad
   \qquad
   \textrm{[stress-update]}
-\] +\]" src="form_2973.png"/>

      -

      There are, despite the apparent simplicity of this equation, two questions that we need to discuss. The first concerns the way we store $\sigma^n$: even if we compute the incremental updates $\Delta\mathbf{u}^n$ using lowest-order finite elements, then its symmetric gradient $\varepsilon(\Delta\mathbf{u}^n)$ is in general still a function that is not easy to describe. In particular, it is not a piecewise constant function, and on general meshes (with cells that are not rectangles parallel to the coordinate axes) or with non-constant stress-strain tensors $C$ it is not even a bi- or trilinear function. Thus, it is a priori not clear how to store $\sigma^n$ in a computer program.

      -

      To decide this, we have to see where it is used. The only place where we require the stress is in the term $(\sigma^{n-1},\varepsilon(\varphi))_{\Omega(t_{n-1})}$. In practice, we of course replace this term by numerical quadrature:

      -\[
+<p> There are, despite the apparent simplicity of this equation, two questions that we need to discuss. The first concerns the way we store <picture><source srcset=$\sigma^n$: even if we compute the incremental updates $\Delta\mathbf{u}^n$ using lowest-order finite elements, then its symmetric gradient $\varepsilon(\Delta\mathbf{u}^n)$ is in general still a function that is not easy to describe. In particular, it is not a piecewise constant function, and on general meshes (with cells that are not rectangles parallel to the coordinate axes) or with non-constant stress-strain tensors $C$ it is not even a bi- or trilinear function. Thus, it is a priori not clear how to store $\sigma^n$ in a computer program.

      +

      To decide this, we have to see where it is used. The only place where we require the stress is in the term $(\sigma^{n-1},\varepsilon(\varphi))_{\Omega(t_{n-1})}$. In practice, we of course replace this term by numerical quadrature:

      +\[
   (\sigma^{n-1},\varepsilon(\varphi))_{\Omega(t_{n-1})}
   =
   \sum_{K\subset {T}}
@@ -313,12 +313,12 @@
   \sum_{K\subset {T}}
   \sum_q
   w_q \ \sigma^{n-1}(\mathbf{x}_q) : \varepsilon(\varphi(\mathbf{x}_q),
-\] +\]" src="form_2977.png"/>

      -

      where $w_q$ are the quadrature weights and $\mathbf{x}_q$ the quadrature points on cell $K$. This should make clear that what we really need is not the stress $\sigma^{n-1}$ in itself, but only the values of the stress in the quadrature points on all cells. This, however, is a simpler task: we only have to provide a data structure that is able to hold one symmetric tensor of rank 2 for each quadrature point on all cells (or, since we compute in parallel, all quadrature points of all cells that the present MPI process “owns”). At the end of each time step we then only have to evaluate $\varepsilon(\Delta \mathbf{u}^n(\mathbf{x}_q))$, multiply it by the stress-strain tensor $C$, and use the result to update the stress $\sigma^n(\mathbf{x}_q)$ at quadrature point $q$.

      -

      The second complication is not visible in our notation as chosen above. It is due to the fact that we compute $\Delta u^n$ on the domain $\Omega(t_{n-1})$, and then use this displacement increment to both update the stress as well as move the mesh nodes around to get to $\Omega(t_n)$ on which the next increment is computed. What we have to make sure, in this context, is that moving the mesh does not only involve moving around the nodes, but also making corresponding changes to the stress variable: the updated stress is a variable that is defined with respect to the coordinate system of the material in the old domain, and has to be transferred to the new domain. The reason for this can be understood as follows: locally, the incremental deformation $\Delta\mathbf{u}$ can be decomposed into three parts, a linear translation (the constant part of the displacement increment field in the neighborhood of a point), a dilational component (that part of the gradient of the displacement field that has a nonzero divergence), and a rotation. A linear translation of the material does not affect the stresses that are frozen into it – the stress values are simply translated along. The dilational or compressional change produces a corresponding stress update. However, the rotational component does not necessarily induce a nonzero stress update (think, in 2d, for example of the situation where $\Delta\mathbf{u}=(y, -x)^T$, with which $\varepsilon(\Delta
-\mathbf{u})=0$). Nevertheless, if the material was prestressed in a certain direction, then this direction will be rotated along with the material. To this end, we have to define a rotation matrix $R(\Delta \mathbf{u}^n)$ that describes, in each point the rotation due to the displacement increments. It is not hard to see that the actual dependence of $R$ on $\Delta \mathbf{u}^n$ can only be through the curl of the displacement, rather than the displacement itself or its full gradient (as mentioned above, the constant components of the increment describe translations, its divergence the dilational modes, and the curl the rotational modes). Since the exact form of $R$ is cumbersome, we only state it in the program code, and note that the correct updating formula for the stress variable is then

      -\[
+<p> where <picture><source srcset=$w_q$ are the quadrature weights and $\mathbf{x}_q$ the quadrature points on cell $K$. This should make clear that what we really need is not the stress $\sigma^{n-1}$ in itself, but only the values of the stress in the quadrature points on all cells. This, however, is a simpler task: we only have to provide a data structure that is able to hold one symmetric tensor of rank 2 for each quadrature point on all cells (or, since we compute in parallel, all quadrature points of all cells that the present MPI process “owns”). At the end of each time step we then only have to evaluate $\varepsilon(\Delta \mathbf{u}^n(\mathbf{x}_q))$, multiply it by the stress-strain tensor $C$, and use the result to update the stress $\sigma^n(\mathbf{x}_q)$ at quadrature point $q$.

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_19.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_19.html 2023-08-09 23:38:58.874629897 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_19.html 2023-08-09 23:38:58.874629897 +0000 @@ -146,135 +146,135 @@

      The finite element method in general, and deal.II in particular, were invented to solve partial differential equations – in other words, to solve continuum mechanics problems. On the other hand, sometimes one wants to solve problems in which it is useful to track individual objects ("particles") and how their positions evolve. If this simply leads to a set of ordinary differential equations, for example if you want to track the positions of the planets in the solar system over time, then deal.II is clearly not the right tool. On the other hand, if this evolution is due to the interaction with the solution of partial differential equations, or if having a mesh to determine which particles interact with others (such as in the smoothed particle hydrodynamics (SPH) method), then deal.II has support for you.

      The case we will consider here is how electrically charged particles move through an electric field. As motivation, we will consider cathode rays: Electrons emitted by a heated piece of metal that is negatively charged (the "cathode"), and that are then accelerated by an electric field towards the positively charged electrode (the "anode"). The anode is typically ring-shaped so that the majority of electrons can fly through the hole in the form of an electron beam. In the olden times, they might then have illuminated the screen of a TV built from a cathode ray tube. Today, instead, electron beams are useful in X-ray machines, electron beam lithography, electron beam welding, and a number of other areas.

      The equations we will then consider are as follows: First, we need to describe the electric field. This is most easily accomplished by noting that the electric potential $V$ satisfied the equation

      -\[
+<picture><source srcset=\[
   -\epsilon_0 \Delta V = \rho
-\] +\]" src="form_3008.png"/>

      -

      where $\epsilon_0$ is the dielectric constant of vacuum, and $\rho$ is the charge density. This is augmented by boundary conditions that we will choose as follows:

      -\begin{align*}
+<p> where <picture><source srcset=$\epsilon_0$ is the dielectric constant of vacuum, and $\rho$ is the charge density. This is augmented by boundary conditions that we will choose as follows:

      +\begin{align*}
   V &= -V_0 && \text{on}\; \Gamma_\text{cathode}\subset\partial\Omega \\
   V &= +V_0 && \text{on}\; \Gamma_\text{anode}\subset\partial\Omega \\
   \epsilon\frac{\partial V}{\partial n} &= 0
    && \text{on}\; \partial\Omega\setminus\Gamma_\text{cathode}\setminus\Gamma_\text{anode}.
-\end{align*} +\end{align*}" src="form_3010.png"/>

      -

      In other words, we prescribe voltages $+V_0$ and $-V_0$ at the two electrodes and insulating (Neumann) boundary conditions elsewhere. Since the dynamics of the particles are purely due to the electric field $\mathbf E=\nabla V$, we could as well have prescribed $2V_0$ and $0$ at the two electrodes – all that matters is the voltage difference at the two electrodes.

      -

      Given this electric potential $V$ and the electric field $\mathbf E=\nabla V$, we can describe the trajectory of the $i$th particle using the differential equation

      -\[
+<p> In other words, we prescribe voltages <picture><source srcset=$+V_0$ and $-V_0$ at the two electrodes and insulating (Neumann) boundary conditions elsewhere. Since the dynamics of the particles are purely due to the electric field $\mathbf E=\nabla V$, we could as well have prescribed $2V_0$ and $0$ at the two electrodes – all that matters is the voltage difference at the two electrodes.

      +

      Given this electric potential $V$ and the electric field $\mathbf E=\nabla V$, we can describe the trajectory of the $i$th particle using the differential equation

      +\[
   m {\ddot {\mathbf x}}_i = e\mathbf E,
-\] +\]" src="form_3015.png"/>

      -

      where $m,e$ are the mass and electric charge of each particle. In practice, it is convenient to write this as a system of first-order differential equations in the position $\mathbf x$ and velocity $\mathbf v$:

      -\begin{align*}
+<p> where <picture><source srcset=$m,e$ are the mass and electric charge of each particle. In practice, it is convenient to write this as a system of first-order differential equations in the position $\mathbf x$ and velocity $\mathbf v$:

      +\begin{align*}
   {\dot {\mathbf v}}_i &= \frac{e\mathbf E}{m}, \\
   {\dot {\mathbf x}}_i &= {\mathbf v}_i.
-\end{align*} +\end{align*}" src="form_3017.png"/>

      -

      The deal.II class we will use to deal with particles, Particles::ParticleHandler, stores particles in a way so that the position $\mathbf x_i$ is part of the Particles::ParticleHandler data structures. (It stores particles sorted by cell they are in, and consequently needs to know where each particle is.) The velocity $\mathbf v_i$, on the other hand, is of no concern to Particles::ParticleHandler and consequently we will store it as a "property" of each particle that we will update in each time step. Properties can also be used to store any other quantity we might care about each particle: its charge, or if they were larger than just an electron, its color, mass, attitude in space, chemical composition, etc.

      +

      The deal.II class we will use to deal with particles, Particles::ParticleHandler, stores particles in a way so that the position $\mathbf x_i$ is part of the Particles::ParticleHandler data structures. (It stores particles sorted by cell they are in, and consequently needs to know where each particle is.) The velocity $\mathbf v_i$, on the other hand, is of no concern to Particles::ParticleHandler and consequently we will store it as a "property" of each particle that we will update in each time step. Properties can also be used to store any other quantity we might care about each particle: its charge, or if they were larger than just an electron, its color, mass, attitude in space, chemical composition, etc.

      There remain two things to discuss to complete the model: Where particles start and what the charge density $\rho$ is.

      -

      First, historically, cathode rays used very large electric fields to pull electrons out of the metal. This produces only a relatively small current. One can do better by heating the cathode: a statistical fraction of electrons in that case have enough thermal energy to leave the metal; the electric field then just has to be strong enough to pull them away from the attraction of their host body. We will model this in the following way: We will create a new particle if (i) the electric field points away from the electrode, i.e., if $\mathbf E \cdot \mathbf n < 0$ where $\mathbf n$ is the normal vector at a face pointing out of the domain (into the electrode), and (ii) the electric field exceeds a threshold value $|\mathbf E|\ge E_\text{threshold}$. This is surely not a sufficiently accurate model for what really happens, but is good enough for our current tutorial program.

      +

      First, historically, cathode rays used very large electric fields to pull electrons out of the metal. This produces only a relatively small current. One can do better by heating the cathode: a statistical fraction of electrons in that case have enough thermal energy to leave the metal; the electric field then just has to be strong enough to pull them away from the attraction of their host body. We will model this in the following way: We will create a new particle if (i) the electric field points away from the electrode, i.e., if $\mathbf E \cdot \mathbf n < 0$ where $\mathbf n$ is the normal vector at a face pointing out of the domain (into the electrode), and (ii) the electric field exceeds a threshold value $|\mathbf E|\ge E_\text{threshold}$. This is surely not a sufficiently accurate model for what really happens, but is good enough for our current tutorial program.

      Second, in principle we would have to model the charge density via

      -\[
+<picture><source srcset=\[
   \rho(\mathbf x) = \sum_i e\delta(\mathbf x-\mathbf x_i).
-\] +\]" src="form_3022.png"/>

      -

      The issue now is that in reality, a cathode ray tube in an old television yields a current of somewhere around a few milli-Amperes. In the much higher energy beams of particle accelerators, the current may only be a few nano-Ampere. But an Ampere is $6\times 10^{18}$ electrons flowing per second. Now, as you will see in the results section, we really only simulate a few microseconds ( $10^{-6}$ seconds), but that still results in very very large numbers of electrons – far more than we can hope to simulate with a program as small as the current one. As a consequence, let us presume that each particle represents $N$ electrons. Then the particle mass and charge are also $Nm$ and $Ne$ and the equations we have to solve are

      -\[
+<p> The issue now is that in reality, a cathode ray tube in an old television yields a current of somewhere around a few milli-Amperes. In the much higher energy beams of particle accelerators, the current may only be a few nano-Ampere. But an Ampere is <picture><source srcset=$6\times 10^{18}$ electrons flowing per second. Now, as you will see in the results section, we really only simulate a few microseconds ( $10^{-6}$ seconds), but that still results in very very large numbers of electrons – far more than we can hope to simulate with a program as small as the current one. As a consequence, let us presume that each particle represents $N$ electrons. Then the particle mass and charge are also $Nm$ and $Ne$ and the equations we have to solve are

      +\[
   (Nm) {\ddot {\mathbf x}}_i = (Ne)\mathbf E,
-\] +\]" src="form_3026.png"/>

      -

      which is of course exactly the same as above after dividing both sides by $N$. On the other hand, the charge density for these "clumps" of electrons is given by

      -\[
+<p> which is of course exactly the same as above after dividing both sides by <picture><source srcset=$N$. On the other hand, the charge density for these "clumps" of electrons is given by

      +\[
   \rho(\mathbf x) = \sum_i (Ne)\delta(\mathbf x-\mathbf x_i).
-\] +\]" src="form_3027.png"/>

      -

      It is this form that we will implement in the program, where $N$ is chosen rather large in the program to ensure that the particles actually affect the electric field. (This may not be realistic in practice: In most cases, there are just not enough electrons to actually affect the overall electric field. But realism is not our goal here.)

      -

      As a final thought about the model, one may wonder why the equation for the electric field (or, rather, the electric potential) has no time derivative whereas the equations for the electron positions do. In essence, this is a modeling assumption: We assume that the particles move so slowly that at any given time the electric field is in equilibrium. This is saying, in other words, that the velocity of the electrons is much less than the speed of light. In yet other words, we can rephrase this in terms of the electrode voltage $V_0$: Since every volt of electric potential accelerates electrons by approximately 600 km/s (neglecting relativistic effects), requiring $|\mathbf v_i\|\ll c$ is equivalent to saying that $2V_0 \ll 500 \text{V}$. Under this assumption (and the assumption that the total number of electrons is small), one can also neglect the creation of magnetic fields by the moving charges, which would otherwise also affect the movement of the electrons.

      +

      It is this form that we will implement in the program, where $N$ is chosen rather large in the program to ensure that the particles actually affect the electric field. (This may not be realistic in practice: In most cases, there are just not enough electrons to actually affect the overall electric field. But realism is not our goal here.)

      +

      As a final thought about the model, one may wonder why the equation for the electric field (or, rather, the electric potential) has no time derivative whereas the equations for the electron positions do. In essence, this is a modeling assumption: We assume that the particles move so slowly that at any given time the electric field is in equilibrium. This is saying, in other words, that the velocity of the electrons is much less than the speed of light. In yet other words, we can rephrase this in terms of the electrode voltage $V_0$: Since every volt of electric potential accelerates electrons by approximately 600 km/s (neglecting relativistic effects), requiring $|\mathbf v_i\|\ll c$ is equivalent to saying that $2V_0 \ll 500 \text{V}$. Under this assumption (and the assumption that the total number of electrons is small), one can also neglect the creation of magnetic fields by the moving charges, which would otherwise also affect the movement of the electrons.

      Time discretization

      The equations outlined above then form a set of coupled differential equations. Let us bring them all together in one place again to make that clear:

      -\begin{align*}
+<picture><source srcset=\begin{align*}
   -\epsilon_0 \Delta V &= \sum_i e\delta(\mathbf x-\mathbf x_i)
   \\
   {\dot {\mathbf x}}_i &= {\mathbf v}_i,
   \\
   {\dot {\mathbf v}}_i &= \frac{e\mathbf E}{m} = \frac{e\mathbf \nabla V}{m}.
-\end{align*} +\end{align*}" src="form_3031.png"/>

      Because of the awkward dependence of the electric potential on the particle locations, we don't want to solve this as a coupled system but instead use a decoupled approach where we first solve for the potential in each time step and then the particle locations. (One could also do it the other way around, of course.) This is very much in the same spirit as we do in step-21, step-31, and step-32, to name just a few, and can all be understood in the context of the operator splitting methods discussed in step-58.

      -

      So, if we denote by an upper index $n$ the time step, and if we use a simple time discretization for the ODE, then this means that we have to solve the following set of equations in each time step:

      -\begin{align*}
+<p>So, if we denote by an upper index <picture><source srcset=$n$ the time step, and if we use a simple time discretization for the ODE, then this means that we have to solve the following set of equations in each time step:

      +\begin{align*}
   -\epsilon_0 \Delta V^{(n)} &= \sum_i e\delta(\mathbf x-\mathbf x_i^{(n-1)})
   \\
   \frac{{\mathbf v}_i^{(n)}-{\mathbf v}_i^{(n-1)}}{\Delta t} &= \frac{e\nabla V^{(n)}}{m}
   \\
   \frac{{\mathbf x}_i^{(n)}-{\mathbf x}_i^{(n-1)}}{\Delta t} &= {\mathbf v}_i^{(n)}.
-\end{align*} +\end{align*}" src="form_3032.png"/>

      -

      This scheme can be understood in the framework of operator splitting methods (specifically, the "Lie splitting" method) wherein a coupled system is solved by updating one variable at a time, using either the old values of other variables (e.g., using $\mathbf x_i^{(n-1)}$ in the first equation) or the values of variables that have already been updated in a previous sub-step (e.g., using $V^{(n)}$ in the second equation). There are of course many better ways to do a time discretization (for example the simple leapfrog scheme when updating the velocity, or more general Strang splitting methods for the coupled system) but this isn't the point of the tutorial program, and so we will be content with what we have here. (We will comment on a piece of this puzzle in the possibilities for extensions section of this program, however.)

      +

      This scheme can be understood in the framework of operator splitting methods (specifically, the "Lie splitting" method) wherein a coupled system is solved by updating one variable at a time, using either the old values of other variables (e.g., using $\mathbf x_i^{(n-1)}$ in the first equation) or the values of variables that have already been updated in a previous sub-step (e.g., using $V^{(n)}$ in the second equation). There are of course many better ways to do a time discretization (for example the simple leapfrog scheme when updating the velocity, or more general Strang splitting methods for the coupled system) but this isn't the point of the tutorial program, and so we will be content with what we have here. (We will comment on a piece of this puzzle in the possibilities for extensions section of this program, however.)

      There remains the question of how we should choose the time step size $\Delta t$. The limitation here is that the Particles::ParticleHandler class needs to keep track of which cell each particle is in. This is particularly an issue if we are running computations in parallel (say, in step-70) because in that case every process only stores those cells it owns plus one layer of "ghost cells". That's not relevant here, but in general we should make sure that over the course of each time step, a particle moves only from one cell to any of its immediate neighbors (face, edge, or vertex neighbors). If we can ensure that, then Particles::ParticleHandler is guaranteed to be able to figure out which cell a particle ends up in. To do this, a useful rule of thumb is that we should choose the time step so that for all particles the expected distance the particle moves by is less than one cell diameter:

      -\[
+<picture><source srcset=\[
   \Delta t \le \frac{h_i}{\|\mathbf v_i\|} \qquad\qquad \forall i,
-\] +\]" src="form_3035.png"/>

      or equivalently

      -\[
+<picture><source srcset=\[
   \Delta t \le \min_i \frac{h_i}{\|\mathbf v_i\|}.
-\] +\]" src="form_3036.png"/>

      -

      Here, $h_i$ is the length of the shortest edge of the cell on which particle $i$ is located – in essence, a measure of the size of a cell.

      +

      Here, $h_i$ is the length of the shortest edge of the cell on which particle $i$ is located – in essence, a measure of the size of a cell.

      On the other hand, a particle might already be at the boundary of one cell and the neighboring cell might be once further refined. So then the time to cross that neighboring cell would actually be half the amount above, suggesting

      -\[
+<picture><source srcset=\[
   \Delta t \le \min_i \frac{\tfrac 12 h_i}{\|\mathbf v_i\|}.
-\] +\]" src="form_3037.png"/>

      But even that is not good enough: The formula above updates the particle positions in each time using the formula

      -\[
+<picture><source srcset=\[
 \frac{{\mathbf x}_i^{(n)}-{\mathbf x}_i^{(n-1)}}{\Delta t} = {\mathbf v}_i^{(n)},
-\] +\]" src="form_3038.png"/>

      -

      that is, using the current velocity ${\mathbf v}_i^{n}$. But we don't have the current velocity yet at the time when we need to choose $\Delta t$ – which is after we have updated the potential $V^{(n)}$ but before we update the velocity from ${\mathbf v}_i^{(n-1)}$ to ${\mathbf v}_i^{(n)}$. All we have is ${\mathbf v}_i^{(n-1)}$. So we need an additional safety factor for our final choice:

      -\[
+<p> that is, using the <em>current</em> velocity <picture><source srcset=${\mathbf v}_i^{n}$. But we don't have the current velocity yet at the time when we need to choose $\Delta t$ – which is after we have updated the potential $V^{(n)}$ but before we update the velocity from ${\mathbf v}_i^{(n-1)}$ to ${\mathbf v}_i^{(n)}$. All we have is ${\mathbf v}_i^{(n-1)}$. So we need an additional safety factor for our final choice:

      +\[
   \Delta t^{(n)} =
   c_\text{safety} \min_i \frac{\tfrac 12 h_i}{\|\mathbf v_i^{(n-1)}\|}.
-\] +\]" src="form_3042.png"/>

      -

      How large should $c_\text{safety}$ be? That depends on how much of underestimate $\|\mathbf v_i^{(n-1)}\|$ might be compared to $\|\mathbf v_i^{(n)}\|$, and that is actually quite easy to assess: A particle created in one time step with zero velocity will roughly pick up equal velocity increments in each successive time step if the electric field it encounters along the way were roughly constant. So the maximal difference between $\|\mathbf v_i^{(n-1)}\|$ and $\|\mathbf v_i^{(n)}\|$ would be a factor of two. As a consequence, we will choose $c_\text{safety}=0.5$.

      +

      How large should $c_\text{safety}$ be? That depends on how much of underestimate $\|\mathbf v_i^{(n-1)}\|$ might be compared to $\|\mathbf v_i^{(n)}\|$, and that is actually quite easy to assess: A particle created in one time step with zero velocity will roughly pick up equal velocity increments in each successive time step if the electric field it encounters along the way were roughly constant. So the maximal difference between $\|\mathbf v_i^{(n-1)}\|$ and $\|\mathbf v_i^{(n)}\|$ would be a factor of two. As a consequence, we will choose $c_\text{safety}=0.5$.

      There is only one other case we ought to consider: What happens in the very first time step? There, any particles to be moved along have just been created, but they have a zero velocity. So we don't know what velocity we should choose for them. Of course, in all other time steps there are also particles that have just been created, but in general, the particles with the highest velocity limit the time step size and so the newly created particles with their zero velocity don't matter. But if we only have such particles?

      -

      In that case, we can use the following approximation: If a particle starts at $\mathbf v^{(0)}=0$, then the update formula tells us that

      -\[
+<p>In that case, we can use the following approximation: If a particle starts at <picture><source srcset=$\mathbf v^{(0)}=0$, then the update formula tells us that

      +\[
   {\mathbf v}_i^{(1)} = \frac{e\nabla V^{(1)}}{m} \Delta t,
-\] +\]" src="form_3048.png"/>

      and consequently

      -\[
+<picture><source srcset=\[
     \frac{{\mathbf x}_i^{(1)}-{\mathbf x}_i^{(0)}}{\Delta t} = {\mathbf v}_i^{(1)},
-\] +\]" src="form_3049.png"/>

      which we can write as

      -\[
+<picture><source srcset=\[
     {\mathbf x}_i^{(1)} - {\mathbf x}_i^{(0)} = \frac{e\nabla V^{(1)}}{m} \Delta t^2.
-\] +\]" src="form_3050.png"/>

      -

      Not wanting to move a particle by more than $\frac 12 h_i$ then implies that we should choose the time step as

      -\[
+<p> Not wanting to move a particle by more than <picture><source srcset=$\frac 12 h_i$ then implies that we should choose the time step as

      +\[
   \Delta t
   \le
   \min_i
   \sqrt{ \frac{h_i m}{e \|\nabla V^{(1)}\| }}.
-\] +\]" src="form_3052.png"/>

      Using the same argument about neighboring cells possibly being smaller by a factor of two then leads to the final formula for time step zero:

      -\[
+<picture><source srcset=\[
   \Delta t
   =
   \min_i
   \sqrt{ \frac{\frac 12 h_i m}{e \|\nabla V^{(1)}\| } }.
-\] +\]" src="form_3053.png"/>

      -

      Strictly speaking, we would have to evaluate the electric potential $V^{(1)}$ at the location of each particle, but a good enough approximation is to use the maximum of the values at the vertices of the respective cell. (Why the vertices and not the midpoint? Because the gradient of the solution of the Laplace equation, i.e., the electric field, is largest in corner singularities which are located at the vertices of cells.) This has the advantage that we can make good use of the FEValues functionality which can recycle pre-computed material as long as the quadrature points are the same from one cell to the next.

      -

      We could always run this kind of scheme to estimate the difference between $\mathbf v_i^{(n-1)}$ and $\mathbf v_i^{(n)}$, but it relies on evaluating the electric field $\mathbf E$ on each cell, and that is expensive. As a consequence, we will limit this approach to the very first time step.

      +

      Strictly speaking, we would have to evaluate the electric potential $V^{(1)}$ at the location of each particle, but a good enough approximation is to use the maximum of the values at the vertices of the respective cell. (Why the vertices and not the midpoint? Because the gradient of the solution of the Laplace equation, i.e., the electric field, is largest in corner singularities which are located at the vertices of cells.) This has the advantage that we can make good use of the FEValues functionality which can recycle pre-computed material as long as the quadrature points are the same from one cell to the next.

      +

      We could always run this kind of scheme to estimate the difference between $\mathbf v_i^{(n-1)}$ and $\mathbf v_i^{(n)}$, but it relies on evaluating the electric field $\mathbf E$ on each cell, and that is expensive. As a consequence, we will limit this approach to the very first time step.

      Spatial discretization

      -

      Having discussed the time discretization, the discussion of the spatial discretization is going to be short: We use quadratic finite elements, i.e., the space $Q_2$, to approximate the electric potential $V$. The mesh is adapted a couple of times during the initial time step. All of this is entirely standard if you have read step-6, and the implementation does not provide for any kind of surprise.

      +

      Having discussed the time discretization, the discussion of the spatial discretization is going to be short: We use quadratic finite elements, i.e., the space $Q_2$, to approximate the electric potential $V$. The mesh is adapted a couple of times during the initial time step. All of this is entirely standard if you have read step-6, and the implementation does not provide for any kind of surprise.

      Dealing with particles programmatically

      Adding and moving particles is, in practice, not very difficult in deal.II. To add one, the create_particles() function of this program simply uses a code snippet of the following form:

      new_particle.set_location(location);
      @@ -287,7 +287,7 @@
      void set_reference_location(const Point< dim > &new_reference_location)
      Definition: particle.h:542
      void set_id(const types::particle_index &new_id)
      Definition: particle.h:569
      void set_location(const Point< spacedim > &new_location)
      Definition: particle.h:524
      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_2.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_2.html 2023-08-09 23:38:58.906630136 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_2.html 2023-08-09 23:38:58.906630136 +0000 @@ -117,14 +117,14 @@

    Introduction

    Note
    The material presented here is also discussed in video lecture 9. (All video lectures are also available here.)
    -

    The finite element method is based on approximating the solution $u$ of a differential equation such as $-\Delta u=f$ by a function $u_h$ that is "piecewise" polynomial; that is, we subdivide the domain $\Omega$ on which the equation is posed into small cells that in the documentation we will generally denote by the symbol $K$. On each cell $K$, the approximating function $u_h$ we seek is then a polynomial. (Or, strictly speaking, a function that is the image of a polynomial from a "reference cell", but let us not make things more complicated than necessary for now.)

    -

    In the previous tutorial program (in step-1), we showed how we should think of the subdivision of the domain into cells as a "mesh" represented by the Triangulation class, and how this looks like in code. In the current tutorial program, we now show how one represents piecewise polynomial functions through the concept of degrees of freedom defined on this mesh. For this example, we will use the lowest order ( $Q_1$) finite elements, that is the approximating function $u_h$ we are looking for will be "bi-linear" on each quadrilateral cell $K$ of the mesh. (They would be linear if we would work on triangles.)

    -

    In practice, we represent the function as a linear combination of shape functions $\varphi_j(\mathbf x)$ with multipliers $U_j$ that we call the "degrees of freedom". For the bi-linear functions we consider here, each of these shape functions and degrees of freedom is associated with a vertex of the mesh. Later examples will demonstrate higher order elements where degrees of freedom are not necessarily associated with vertices any more, but can be associated with edges, faces, or cells.

    -

    The term "degree of freedom" is commonly used in the finite element community to indicate two slightly different, but related things. The first is that we'd like to represent the finite element solution as a linear combination of shape functions, in the form $u_h(\mathbf x) = \sum_{j=0}^{N-1} U_j \varphi_j(\mathbf
-x)$. Here, $U_j$ is a vector of expansion coefficients. Because we don't know their values yet (we will compute them as the solution of a linear or nonlinear system), they are called "unknowns" or "degrees of freedom". The second meaning of the term can be explained as follows: A mathematical description of finite element problems is often to say that we are looking for a finite dimensional function $u_h \in V_h$ that satisfies some set of equations (e.g. $a(u_h,\varphi_h)=(f,\varphi_h)$ for all test functions $\varphi_h\in
-V_h$). In other words, all we say here is that the solution needs to lie in some space $V_h$. However, to actually solve this problem on a computer we need to choose a basis of this space; this is the set of shape functions $\varphi_j(\mathbf x)$ we have used above in the expansion of $u_h(\mathbf x)$ with coefficients $U_j$. There are of course many bases of the space $V_h$, but we will specifically choose the one that is described by the finite element functions that are traditionally defined locally on the cells of the mesh.

    +

    The finite element method is based on approximating the solution $u$ of a differential equation such as $-\Delta u=f$ by a function $u_h$ that is "piecewise" polynomial; that is, we subdivide the domain $\Omega$ on which the equation is posed into small cells that in the documentation we will generally denote by the symbol $K$. On each cell $K$, the approximating function $u_h$ we seek is then a polynomial. (Or, strictly speaking, a function that is the image of a polynomial from a "reference cell", but let us not make things more complicated than necessary for now.)

    +

    In the previous tutorial program (in step-1), we showed how we should think of the subdivision of the domain into cells as a "mesh" represented by the Triangulation class, and how this looks like in code. In the current tutorial program, we now show how one represents piecewise polynomial functions through the concept of degrees of freedom defined on this mesh. For this example, we will use the lowest order ( $Q_1$) finite elements, that is the approximating function $u_h$ we are looking for will be "bi-linear" on each quadrilateral cell $K$ of the mesh. (They would be linear if we would work on triangles.)

    +

    In practice, we represent the function as a linear combination of shape functions $\varphi_j(\mathbf x)$ with multipliers $U_j$ that we call the "degrees of freedom". For the bi-linear functions we consider here, each of these shape functions and degrees of freedom is associated with a vertex of the mesh. Later examples will demonstrate higher order elements where degrees of freedom are not necessarily associated with vertices any more, but can be associated with edges, faces, or cells.

    +

    The term "degree of freedom" is commonly used in the finite element community to indicate two slightly different, but related things. The first is that we'd like to represent the finite element solution as a linear combination of shape functions, in the form $u_h(\mathbf x) = \sum_{j=0}^{N-1} U_j \varphi_j(\mathbf
+x)$. Here, $U_j$ is a vector of expansion coefficients. Because we don't know their values yet (we will compute them as the solution of a linear or nonlinear system), they are called "unknowns" or "degrees of freedom". The second meaning of the term can be explained as follows: A mathematical description of finite element problems is often to say that we are looking for a finite dimensional function $u_h \in V_h$ that satisfies some set of equations (e.g. $a(u_h,\varphi_h)=(f,\varphi_h)$ for all test functions $\varphi_h\in
+V_h$). In other words, all we say here is that the solution needs to lie in some space $V_h$. However, to actually solve this problem on a computer we need to choose a basis of this space; this is the set of shape functions $\varphi_j(\mathbf x)$ we have used above in the expansion of $u_h(\mathbf x)$ with coefficients $U_j$. There are of course many bases of the space $V_h$, but we will specifically choose the one that is described by the finite element functions that are traditionally defined locally on the cells of the mesh.

    Enumerating degrees of freedom

    -

    Describing "degrees of freedom" in this context requires us to simply enumerate the basis functions of the space $V_h$. For $Q_1$ elements this means simply enumerating the vertices of the mesh in some way, but for higher order elements, one also has to enumerate the shape functions that are associated with edges, faces, or cell interiors of the mesh. In other words, the enumeration of degrees of freedom is an entirely separate thing from the indices we use for vertices. The class that provides this enumeration of the basis functions of $V_h$ is called DoFHandler.

    +

    Describing "degrees of freedom" in this context requires us to simply enumerate the basis functions of the space $V_h$. For $Q_1$ elements this means simply enumerating the vertices of the mesh in some way, but for higher order elements, one also has to enumerate the shape functions that are associated with edges, faces, or cell interiors of the mesh. In other words, the enumeration of degrees of freedom is an entirely separate thing from the indices we use for vertices. The class that provides this enumeration of the basis functions of $V_h$ is called DoFHandler.

    Defining degrees of freedom ("DoF"s in short) on a mesh is, in practice, a rather simple task, since the library does all the work for you. Essentially, all you have to do is create a finite element object (from one of the many finite element classes deal.II already has, see for example the Finite element space descriptions documentation) and give it to a DoFHandler object through the DoFHandler::distribute_dofs() function ("distributing DoFs" is the term we use to describe the process of enumerating the basis functions as discussed above). The DoFHandler is a class that knows which degrees of freedom live where, i.e., it can answer questions like "how many degrees of freedom are there globally" and "on this cell, give me the global indices of the shape functions that live here". This is the sort of information you need when determining how big your system matrix should be, and when copying the contributions of a single cell into the global matrix.

    The first task of the current program is therefore to take a mesh and a finite element, and enumerate the degrees of freedom. In the current context, this means simply giving each vertex of the mesh a DoF index. Once that has happened, we will output in a picture which vertex ended up with which DoF index. You can find the corresponding pictures in the results section of this tutorial.

    @@ -133,11 +133,11 @@

    The next step would then be to compute a matrix and right hand side corresponding to a particular differential equation using this finite element and mesh. We will keep this step for the step-3 program and rather talk about one practical aspect of a finite element program, namely that finite element matrices are always very sparse: almost all entries in these matrices are zero.

    To be more precise, we say that a matrix is sparse if the number of nonzero entries per row in the matrix is bounded by a number that is independent of the overall number of degrees of freedom. For example, the simple 5-point stencil of a finite difference approximation of the Laplace equation leads to a sparse matrix since the number of nonzero entries per row is five, and therefore independent of the total size of the matrix. For more complicated problems – say, the Stokes problem of step-22 – and in particular in 3d, the number of entries per row may be several hundred. But the important point is that this number is independent of the overall size of the problem: If you refine the mesh, the maximal number of unknowns per row remains the same.

    Sparsity is one of the distinguishing feature of the finite element method compared to, say, approximating the solution of a partial differential equation using a Taylor expansion and matching coefficients, or using a Fourier basis.

    -

    In practical terms, it is the sparsity of matrices that enables us to solve problems with millions or billions of unknowns. To understand this, note that a matrix with $N$ rows, each with a fixed upper bound for the number of nonzero entries, requires ${\cal O}(N)$ memory locations for storage, and a matrix-vector multiplication also requires only ${\cal O}(N)$ operations. Consequently, if we had a linear solver that requires only a fixed number of matrix-vector multiplications to come up with the solution of a linear system with this matrix, then we would have a solver that can find the values of all $N$ unknowns with optimal complexity, i.e., with a total of ${\cal O}(N)$ operations. It is clear that this wouldn't be possible if the matrix were not sparse (because then the number of entries in the matrix would have to be ${\cal O}(N^s)$ with some $s>1$, and doing a fixed number of matrix-vector products would take ${\cal O}(N^s)$ operations), but it also requires very specialized solvers such as multigrid methods to satisfy the requirement that the solution requires only a fixed number of matrix-vector multiplications. We will frequently look at the question of what solver to use in the remaining programs of this tutorial.

    -

    The sparsity is generated by the fact that finite element shape functions are defined locally on individual cells, rather than globally, and that the local differential operators in the bilinear form only couple shape functions whose support overlaps. (The "support" of a function is the area where it is nonzero. For the finite element method, the support of a shape function is generally the cells adjacent to the vertex, edge, or face it is defined on.) In other words, degrees of freedom $i$ and $j$ that are not defined on the same cell do not overlap, and consequently the matrix entry $A_{ij}$ will be zero. (In some cases such as the Discontinuous Galerkin method, shape functions may also connect to neighboring cells through face integrals. But finite element methods do not generally couple shape functions beyond the immediate neighbors of a cell on which the function is defined.)

    +

    In practical terms, it is the sparsity of matrices that enables us to solve problems with millions or billions of unknowns. To understand this, note that a matrix with $N$ rows, each with a fixed upper bound for the number of nonzero entries, requires ${\cal O}(N)$ memory locations for storage, and a matrix-vector multiplication also requires only ${\cal O}(N)$ operations. Consequently, if we had a linear solver that requires only a fixed number of matrix-vector multiplications to come up with the solution of a linear system with this matrix, then we would have a solver that can find the values of all $N$ unknowns with optimal complexity, i.e., with a total of ${\cal O}(N)$ operations. It is clear that this wouldn't be possible if the matrix were not sparse (because then the number of entries in the matrix would have to be ${\cal O}(N^s)$ with some $s>1$, and doing a fixed number of matrix-vector products would take ${\cal O}(N^s)$ operations), but it also requires very specialized solvers such as multigrid methods to satisfy the requirement that the solution requires only a fixed number of matrix-vector multiplications. We will frequently look at the question of what solver to use in the remaining programs of this tutorial.

    +

    The sparsity is generated by the fact that finite element shape functions are defined locally on individual cells, rather than globally, and that the local differential operators in the bilinear form only couple shape functions whose support overlaps. (The "support" of a function is the area where it is nonzero. For the finite element method, the support of a shape function is generally the cells adjacent to the vertex, edge, or face it is defined on.) In other words, degrees of freedom $i$ and $j$ that are not defined on the same cell do not overlap, and consequently the matrix entry $A_{ij}$ will be zero. (In some cases such as the Discontinuous Galerkin method, shape functions may also connect to neighboring cells through face integrals. But finite element methods do not generally couple shape functions beyond the immediate neighbors of a cell on which the function is defined.)

    How degrees of freedom are enumerated

    By default, the DoFHandler class enumerates degrees of freedom on a mesh using an algorithm that is difficult to describe and leads to results that do look right if you know what it is doing but otherwise appears rather random; consequently, the sparsity pattern is also not optimized for any particular purpose. To show this, the code below will demonstrate a simple way to output the "sparsity pattern" that corresponds to a DoFHandler, i.e., an object that represents all of the potentially nonzero elements of a matrix one may build when discretizing a partial differential equation on a mesh and its DoFHandler. This lack of structure in the sparsity pattern will be apparent from the pictures we show below.

    -

    For most applications and algorithms, the exact way in which degrees of freedom are numbered does not matter. For example, the Conjugate Gradient method we use to solve linear systems does not care. On the other hand, some algorithms do care: in particular, some preconditioners such as SSOR will work better if they can walk through degrees of freedom in a particular order, and it would be nice if we could just sort them in such a way that SSOR can iterate through them from zero to $N$ in this order. Other examples include computing incomplete LU or Cholesky factorizations, or if we care about the block structure of matrices (see step-20 for an example). deal.II therefore has algorithms that can re-enumerate degrees of freedom in particular ways in namespace DoFRenumbering. Renumbering can be thought of as choosing a different, permuted basis of the finite element space. The sparsity pattern and matrices that result from this renumbering are therefore also simply a permutation of rows and columns compared to the ones we would get without explicit renumbering.

    +

    For most applications and algorithms, the exact way in which degrees of freedom are numbered does not matter. For example, the Conjugate Gradient method we use to solve linear systems does not care. On the other hand, some algorithms do care: in particular, some preconditioners such as SSOR will work better if they can walk through degrees of freedom in a particular order, and it would be nice if we could just sort them in such a way that SSOR can iterate through them from zero to $N$ in this order. Other examples include computing incomplete LU or Cholesky factorizations, or if we care about the block structure of matrices (see step-20 for an example). deal.II therefore has algorithms that can re-enumerate degrees of freedom in particular ways in namespace DoFRenumbering. Renumbering can be thought of as choosing a different, permuted basis of the finite element space. The sparsity pattern and matrices that result from this renumbering are therefore also simply a permutation of rows and columns compared to the ones we would get without explicit renumbering.

    In the program below, we will use the algorithm of Cuthill and McKee to do so. We will show the sparsity pattern for both the original enumeration of degrees of freedom and of the renumbered version below, in the results section.

    The commented program

    The first few includes are just like in the previous program, so do not require additional comments:

    @@ -275,7 +275,7 @@
     

    Renumbering of DoFs

    In the sparsity pattern produced above, the nonzero entries extended quite far off from the diagonal. For some algorithms, for example for incomplete LU decompositions or Gauss-Seidel preconditioners, this is unfavorable, and we will show a simple way how to improve this situation.

    -

    Remember that for an entry $(i,j)$ in the matrix to be nonzero, the supports of the shape functions i and j needed to intersect (otherwise in the integral, the integrand would be zero everywhere since either the one or the other shape function is zero at some point). However, the supports of shape functions intersected only if they were adjacent to each other, so in order to have the nonzero entries clustered around the diagonal (where $i$ equals $j$), we would like to have adjacent shape functions to be numbered with indices (DoF numbers) that differ not too much.

    +

    Remember that for an entry $(i,j)$ in the matrix to be nonzero, the supports of the shape functions i and j needed to intersect (otherwise in the integral, the integrand would be zero everywhere since either the one or the other shape function is zero at some point). However, the supports of shape functions intersected only if they were adjacent to each other, so in order to have the nonzero entries clustered around the diagonal (where $i$ equals $j$), we would like to have adjacent shape functions to be numbered with indices (DoF numbers) that differ not too much.

    This can be accomplished by a simple front marching algorithm, where one starts at a given vertex and gives it the index zero. Then, its neighbors are numbered successively, making their indices close to the original one. Then, their neighbors, if not yet numbered, are numbered, and so on.

    One algorithm that adds a little bit of sophistication along these lines is the one by Cuthill and McKee. We will use it in the following function to renumber the degrees of freedom such that the resulting sparsity pattern is more localized around the diagonal. The only interesting part of the function is the first call to DoFRenumbering::Cuthill_McKee, the rest is essentially as before:

      void renumber_dofs(DoFHandler<2> &dof_handler)
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_20.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_20.html 2023-08-09 23:38:58.970630614 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_20.html 2023-08-09 23:38:58.970630614 +0000 @@ -152,93 +152,93 @@ p &=& g \qquad {\textrm{on}\ }\partial\Omega. \end{eqnarray*}" src="form_3080.png"/>

    -

    $K({\mathbf x})$ is assumed to be uniformly positive definite, i.e., there is $\alpha>0$ such that the eigenvalues $\lambda_i({\mathbf x})$ of $K(x)$ satisfy $\lambda_i({\mathbf x})\ge \alpha$. The use of the symbol $p$ instead of the usual $u$ for the solution variable will become clear in the next section.

    +

    $K({\mathbf x})$ is assumed to be uniformly positive definite, i.e., there is $\alpha>0$ such that the eigenvalues $\lambda_i({\mathbf x})$ of $K(x)$ satisfy $\lambda_i({\mathbf x})\ge \alpha$. The use of the symbol $p$ instead of the usual $u$ for the solution variable will become clear in the next section.

    After discussing the equation and the formulation we are going to use to solve it, this introduction will cover the use of block matrices and vectors, the definition of solvers and preconditioners, and finally the actual test case we are going to solve.

    We are going to extend this tutorial program in step-21 to solve not only the mixed Laplace equation, but add another equation that describes the transport of a mixture of two fluids.

    The equations covered here fall into the class of vector-valued problems. A toplevel overview of this topic can be found in the Handling vector valued problems module.

    The equations

    In the form above, the Poisson equation (i.e., the Laplace equation with a nonzero right hand side) is generally considered a good model equation for fluid flow in porous media. Of course, one typically models fluid flow through the Navier-Stokes equations or, if fluid velocities are slow or the viscosity is large, the Stokes equations (which we cover in step-22). In the first of these two models, the forces that act are inertia and viscous friction, whereas in the second it is only viscous friction – i.e., forces that one fluid particle exerts on a nearby one. This is appropriate if you have free flow in a large domain, say a pipe, a river, or in the air. On the other hand, if the fluid is confined in pores, then friction forces exerted by the pore walls on the fluid become more and more important and internal viscous friction becomes less and less important. Modeling this then first leads to the Brinkman model if both effects are important, and in the limit of very small pores to the Darcy equations. The latter is just a different name for the Poisson or Laplace equation, connotating it with the area to which one wants to apply it: slow flow in a porous medium. In essence it says that the velocity is proportional to the negative pressure gradient that drives the fluid through the porous medium.

    -

    The Darcy equation models this pressure that drives the flow. (Because the solution variable is a pressure, we here use the name $p$ instead of the name $u$ more commonly used for the solution of partial differential equations.) Typical applications of this view of the Laplace equation are then modeling groundwater flow, or the flow of hydrocarbons in oil reservoirs. In these applications, $K$ is the permeability tensor, i.e., a measure for how much resistance the soil or rock matrix asserts on the fluid flow.

    +

    The Darcy equation models this pressure that drives the flow. (Because the solution variable is a pressure, we here use the name $p$ instead of the name $u$ more commonly used for the solution of partial differential equations.) Typical applications of this view of the Laplace equation are then modeling groundwater flow, or the flow of hydrocarbons in oil reservoirs. In these applications, $K$ is the permeability tensor, i.e., a measure for how much resistance the soil or rock matrix asserts on the fluid flow.

    In the applications named above, a desirable feature for a numerical scheme is that it should be locally conservative, i.e., that whatever flows into a cell also flows out of it (or the difference is equal to the integral over the source terms over each cell, if the sources are nonzero). However, as it turns out, the usual discretizations of the Laplace equation (such as those used in step-3, step-4, or step-6) do not satisfy this property. But, one can achieve this by choosing a different formulation of the problem and a particular combination of finite element spaces.

    Formulation, weak form, and discrete problem

    -

    To this end, one first introduces a second variable, called the velocity, ${\mathbf u}=-K\nabla p$. By its definition, the velocity is a vector in the negative direction of the pressure gradient, multiplied by the permeability tensor. If the permeability tensor is proportional to the unit matrix, this equation is easy to understand and intuitive: the higher the permeability, the higher the velocity; and the velocity is proportional to the gradient of the pressure, going from areas of high pressure to areas of low pressure (thus the negative sign).

    +

    To this end, one first introduces a second variable, called the velocity, ${\mathbf u}=-K\nabla p$. By its definition, the velocity is a vector in the negative direction of the pressure gradient, multiplied by the permeability tensor. If the permeability tensor is proportional to the unit matrix, this equation is easy to understand and intuitive: the higher the permeability, the higher the velocity; and the velocity is proportional to the gradient of the pressure, going from areas of high pressure to areas of low pressure (thus the negative sign).

    With this second variable, one then finds an alternative version of the Laplace equation, called the mixed formulation:

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   K^{-1} {\mathbf u} + \nabla p &=& 0 \qquad {\textrm{in}\ } \Omega, \\
   -{\textrm{div}}\ {\mathbf u} &=& -f \qquad {\textrm{in}\ }\Omega, \\
   p &=& g \qquad {\textrm{on}\ } \partial\Omega.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3087.png"/>

    -

    Here, we have multiplied the equation defining the velocity ${\mathbf
-u}$ by $K^{-1}$ because this makes the set of equations symmetric: one of the equations has the gradient, the second the negative divergence, and these two are of course adjoints of each other, resulting in a symmetric bilinear form and a consequently symmetric system matrix under the common assumption that $K$ is a symmetric tensor.

    +

    Here, we have multiplied the equation defining the velocity ${\mathbf
+u}$ by $K^{-1}$ because this makes the set of equations symmetric: one of the equations has the gradient, the second the negative divergence, and these two are of course adjoints of each other, resulting in a symmetric bilinear form and a consequently symmetric system matrix under the common assumption that $K$ is a symmetric tensor.

    The weak formulation of this problem is found by multiplying the two equations with test functions and integrating some terms by parts:

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   A(\{{\mathbf u},p\},\{{\mathbf v},q\}) = F(\{{\mathbf v},q\}),
-\end{eqnarray*} +\end{eqnarray*}" src="form_3090.png"/>

    where

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   A(\{{\mathbf u},p\},\{{\mathbf v},q\})
   &=&
   ({\mathbf v}, K^{-1}{\mathbf u})_\Omega - ({\textrm{div}}\ {\mathbf v}, p)_\Omega
   - (q,{\textrm{div}}\ {\mathbf u})_\Omega
   \\
   F(\{{\mathbf v},q\}) &=& -(g,{\mathbf v}\cdot {\mathbf n})_{\partial\Omega} - (f,q)_\Omega.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3091.png"/>

    -

    Here, ${\mathbf n}$ is the outward normal vector at the boundary. Note how in this formulation, Dirichlet boundary values of the original problem are incorporated in the weak form.

    -

    To be well-posed, we have to look for solutions and test functions in the space $H({\textrm{div}})=\{{\mathbf w}\in L^2(\Omega)^d:\ {\textrm{div}}\ {\mathbf w}\in L^2\}$ for $\mathbf u$, $\mathbf v$, and $L^2$ for $p,q$. It is a well-known fact stated in almost every book on finite element theory that if one chooses discrete finite element spaces for the approximation of ${\mathbf u},p$ inappropriately, then the resulting discrete problem is instable and the discrete solution will not converge to the exact solution. (Some details on the problem considered here – which falls in the class of "saddle-point problems" – can be found on the Wikipedia page on the Ladyzhenskaya-Babuska-Brezzi (LBB) condition.)

    -

    To overcome this, a number of different finite element pairs for ${\mathbf u},p$ have been developed that lead to a stable discrete problem. One such pair is to use the Raviart-Thomas spaces $RT(k)$ for the velocity ${\mathbf u}$ and discontinuous elements of class $DQ(k)$ for the pressure $p$. For details about these spaces, we refer in particular to the book on mixed finite element methods by Brezzi and Fortin, but many other books on the theory of finite elements, for example the classic book by Brenner and Scott, also state the relevant results. In any case, with appropriate choices of function spaces, the discrete formulation reads as follows: Find ${\mathbf
-u}_h,p_h$ so that

    -\begin{eqnarray*}
+<p> Here, <picture><source srcset=${\mathbf n}$ is the outward normal vector at the boundary. Note how in this formulation, Dirichlet boundary values of the original problem are incorporated in the weak form.

    +

    To be well-posed, we have to look for solutions and test functions in the space $H({\textrm{div}})=\{{\mathbf w}\in L^2(\Omega)^d:\ {\textrm{div}}\ {\mathbf w}\in L^2\}$ for $\mathbf u$, $\mathbf v$, and $L^2$ for $p,q$. It is a well-known fact stated in almost every book on finite element theory that if one chooses discrete finite element spaces for the approximation of ${\mathbf u},p$ inappropriately, then the resulting discrete problem is instable and the discrete solution will not converge to the exact solution. (Some details on the problem considered here – which falls in the class of "saddle-point problems" – can be found on the Wikipedia page on the Ladyzhenskaya-Babuska-Brezzi (LBB) condition.)

    +

    To overcome this, a number of different finite element pairs for ${\mathbf u},p$ have been developed that lead to a stable discrete problem. One such pair is to use the Raviart-Thomas spaces $RT(k)$ for the velocity ${\mathbf u}$ and discontinuous elements of class $DQ(k)$ for the pressure $p$. For details about these spaces, we refer in particular to the book on mixed finite element methods by Brezzi and Fortin, but many other books on the theory of finite elements, for example the classic book by Brenner and Scott, also state the relevant results. In any case, with appropriate choices of function spaces, the discrete formulation reads as follows: Find ${\mathbf
+u}_h,p_h$ so that

    +\begin{eqnarray*}
   A(\{{\mathbf u}_h,p_h\},\{{\mathbf v}_h,q_h\}) = F(\{{\mathbf v}_h,q_h\})
   \qquad\qquad \forall {\mathbf v}_h,q_h.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3099.png"/>

    -

    Before continuing, let us briefly pause and show that the choice of function spaces above provides us with the desired local conservation property. In particular, because the pressure space consists of discontinuous piecewise polynomials, we can choose the test function $q$ as the function that is equal to one on any given cell $K$ and zero everywhere else. If we also choose ${\mathbf v}=0$ everywhere (remember that the weak form above has to hold for all discrete test functions $q,v$), then putting these choices of test functions into the weak formulation above implies in particular that

    -\begin{eqnarray*}
+<p>Before continuing, let us briefly pause and show that the choice of function spaces above provides us with the desired local conservation property. In particular, because the pressure space consists of discontinuous piecewise polynomials, we can choose the test function <picture><source srcset=$q$ as the function that is equal to one on any given cell $K$ and zero everywhere else. If we also choose ${\mathbf v}=0$ everywhere (remember that the weak form above has to hold for all discrete test functions $q,v$), then putting these choices of test functions into the weak formulation above implies in particular that

    +\begin{eqnarray*}
   - (1,{\textrm{div}}\ {\mathbf u}_h)_K
   =
   -(1,f)_K,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3102.png"/>

    which we can of course write in more explicit form as

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   \int_K {\textrm{div}}\ {\mathbf u}_h
  =
   \int_K f.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3103.png"/>

    -

    Applying the divergence theorem results in the fact that ${\mathbf
-u}_h$ has to satisfy, for every choice of cell $K$, the relationship

    -\begin{eqnarray*}
+<p> Applying the divergence theorem results in the fact that <picture><source srcset=${\mathbf
+u}_h$ has to satisfy, for every choice of cell $K$, the relationship

    +\begin{eqnarray*}
   \int_{\partial K} {\mathbf u}_h\cdot{\mathbf n}
   =
   \int_K f.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3105.png"/>

    -

    If you now recall that ${\mathbf u}$ was the velocity, then the integral on the left is exactly the (discrete) flux across the boundary of the cell $K$. The statement is then that the flux must be equal to the integral over the sources within $K$. In particular, if there are no sources (i.e., $f=0$ in $K$), then the statement is that total flux is zero, i.e., whatever flows into a cell must flow out of it through some other part of the cell boundary. This is what we call local conservation because it holds for every cell.

    -

    On the other hand, the usual continuous $Q_k$ elements would not result in this kind of property when used for the pressure (as, for example, we do in step-43) because one can not choose a discrete test function $q_h$ that is one on a cell $K$ and zero everywhere else: It would be discontinuous and consequently not in the finite element space. (Strictly speaking, all we can say is that the proof above would not work for continuous elements. Whether these elements might still result in local conservation is a different question as one could think that a different kind of proof might still work; in reality, however, the property really does not hold.)

    +

    If you now recall that ${\mathbf u}$ was the velocity, then the integral on the left is exactly the (discrete) flux across the boundary of the cell $K$. The statement is then that the flux must be equal to the integral over the sources within $K$. In particular, if there are no sources (i.e., $f=0$ in $K$), then the statement is that total flux is zero, i.e., whatever flows into a cell must flow out of it through some other part of the cell boundary. This is what we call local conservation because it holds for every cell.

    +

    On the other hand, the usual continuous $Q_k$ elements would not result in this kind of property when used for the pressure (as, for example, we do in step-43) because one can not choose a discrete test function $q_h$ that is one on a cell $K$ and zero everywhere else: It would be discontinuous and consequently not in the finite element space. (Strictly speaking, all we can say is that the proof above would not work for continuous elements. Whether these elements might still result in local conservation is a different question as one could think that a different kind of proof might still work; in reality, however, the property really does not hold.)

    Assembling the linear system

    -

    The deal.II library (of course) implements Raviart-Thomas elements $RT(k)$ of arbitrary order $k$, as well as discontinuous elements $DG(k)$. If we forget about their particular properties for a second, we then have to solve a discrete problem

    -\begin{eqnarray*}
+<p>The deal.II library (of course) implements Raviart-Thomas elements <picture><source srcset=$RT(k)$ of arbitrary order $k$, as well as discontinuous elements $DG(k)$. If we forget about their particular properties for a second, we then have to solve a discrete problem

    +\begin{eqnarray*}
   A(x_h,w_h) = F(w_h),
-\end{eqnarray*} +\end{eqnarray*}" src="form_3109.png"/>

    -

    with the bilinear form and right hand side as stated above, and $x_h=\{{\mathbf u}_h,p_h\}$, $w_h=\{{\mathbf v}_h,q_h\}$. Both $x_h$ and $w_h$ are from the space $X_h=RT(k)\times DQ(k)$, where $RT(k)$ is itself a space of $dim$-dimensional functions to accommodate for the fact that the flow velocity is vector-valued. The necessary question then is: how do we do this in a program?

    -

    Vector-valued elements have already been discussed in previous tutorial programs, the first time and in detail in step-8. The main difference there was that the vector-valued space $V_h$ is uniform in all its components: the $dim$ components of the displacement vector are all equal and from the same function space. What we could therefore do was to build $V_h$ as the outer product of the $dim$ times the usual $Q(1)$ finite element space, and by this make sure that all our shape functions have only a single non-zero vector component. Instead of dealing with vector-valued shape functions, all we did in step-8 was therefore to look at the (scalar) only non-zero component and use the fe.system_to_component_index(i).first call to figure out which component this actually is.

    -

    This doesn't work with Raviart-Thomas elements: following from their construction to satisfy certain regularity properties of the space $H({\textrm{div}})$, the shape functions of $RT(k)$ are usually nonzero in all their vector components at once. For this reason, were fe.system_to_component_index(i).first applied to determine the only nonzero component of shape function $i$, an exception would be generated. What we really need to do is to get at all vector components of a shape function. In deal.II diction, we call such finite elements non-primitive, whereas finite elements that are either scalar or for which every vector-valued shape function is nonzero only in a single vector component are called primitive.

    +

    with the bilinear form and right hand side as stated above, and $x_h=\{{\mathbf u}_h,p_h\}$, $w_h=\{{\mathbf v}_h,q_h\}$. Both $x_h$ and $w_h$ are from the space $X_h=RT(k)\times DQ(k)$, where $RT(k)$ is itself a space of $dim$-dimensional functions to accommodate for the fact that the flow velocity is vector-valued. The necessary question then is: how do we do this in a program?

    +

    Vector-valued elements have already been discussed in previous tutorial programs, the first time and in detail in step-8. The main difference there was that the vector-valued space $V_h$ is uniform in all its components: the $dim$ components of the displacement vector are all equal and from the same function space. What we could therefore do was to build $V_h$ as the outer product of the $dim$ times the usual $Q(1)$ finite element space, and by this make sure that all our shape functions have only a single non-zero vector component. Instead of dealing with vector-valued shape functions, all we did in step-8 was therefore to look at the (scalar) only non-zero component and use the fe.system_to_component_index(i).first call to figure out which component this actually is.

    +

    This doesn't work with Raviart-Thomas elements: following from their construction to satisfy certain regularity properties of the space $H({\textrm{div}})$, the shape functions of $RT(k)$ are usually nonzero in all their vector components at once. For this reason, were fe.system_to_component_index(i).first applied to determine the only nonzero component of shape function $i$, an exception would be generated. What we really need to do is to get at all vector components of a shape function. In deal.II diction, we call such finite elements non-primitive, whereas finite elements that are either scalar or for which every vector-valued shape function is nonzero only in a single vector component are called primitive.

    So what do we have to do for non-primitive elements? To figure this out, let us go back in the tutorial programs, almost to the very beginnings. There, we learned that we use the FEValues class to determine the values and gradients of shape functions at quadrature points. For example, we would call fe_values.shape_value(i,q_point) to obtain the value of the ith shape function on the quadrature point with number q_point. Later, in step-8 and other tutorial programs, we learned that this function call also works for vector-valued shape functions (of primitive finite elements), and that it returned the value of the only non-zero component of shape function i at quadrature point q_point.

    -

    For non-primitive shape functions, this is clearly not going to work: there is no single non-zero vector component of shape function i, and the call to fe_values.shape_value(i,q_point) would consequently not make much sense. However, deal.II offers a second function call, fe_values.shape_value_component(i,q_point,comp) that returns the value of the compth vector component of shape function i at quadrature point q_point, where comp is an index between zero and the number of vector components of the present finite element; for example, the element we will use to describe velocities and pressures is going to have $dim+1$ components. It is worth noting that this function call can also be used for primitive shape functions: it will simply return zero for all components except one; for non-primitive shape functions, it will in general return a non-zero value for more than just one component.

    -

    We could now attempt to rewrite the bilinear form above in terms of vector components. For example, in 2d, the first term could be rewritten like this (note that $u_0=x_0, u_1=x_1, p=x_2$):

    -\begin{eqnarray*}
+<p>For non-primitive shape functions, this is clearly not going to work: there is no single non-zero vector component of shape function <code>i</code>, and the call to <code>fe_values.shape_value(i,q_point)</code> would consequently not make much sense. However, deal.II offers a second function call, <code>fe_values.shape_value_component(i,q_point,comp)</code> that returns the value of the <code>comp</code>th vector component of shape function <code>i</code> at quadrature point <code>q_point</code>, where <code>comp</code> is an index between zero and the number of vector components of the present finite element; for example, the element we will use to describe velocities and pressures is going to have <picture><source srcset=$dim+1$ components. It is worth noting that this function call can also be used for primitive shape functions: it will simply return zero for all components except one; for non-primitive shape functions, it will in general return a non-zero value for more than just one component.

    +

    We could now attempt to rewrite the bilinear form above in terms of vector components. For example, in 2d, the first term could be rewritten like this (note that $u_0=x_0, u_1=x_1, p=x_2$):

    +\begin{eqnarray*}
   ({\mathbf u}_h^i, K^{-1}{\mathbf u}_h^j)
   =
   &\left((x_h^i)_0, K^{-1}_{00} (x_h^j)_0\right) +
    \left((x_h^i)_0, K^{-1}_{01} (x_h^j)_1\right) + \\
   &\left((x_h^i)_1, K^{-1}_{10} (x_h^j)_0\right) +
    \left((x_h^i)_1, K^{-1}_{11} (x_h^j)_1\right).
-\end{eqnarray*} +\end{eqnarray*}" src="form_3119.png"/>

    If we implemented this, we would get code like this:

    for (unsigned int q=0; q<n_q_points; ++q)
    @@ -261,7 +261,7 @@
    fe_values.shape_value_component(j,q,1)
    ) *
    fe_values.JxW(q);
    -

    This is, at best, tedious, error prone, and not dimension independent. There are obvious ways to make things dimension independent, but in the end, the code is simply not pretty. What would be much nicer is if we could simply extract the ${\mathbf u}$ and $p$ components of a shape function $x_h^i$. In the program we do that in the following way:

    +

    This is, at best, tedious, error prone, and not dimension independent. There are obvious ways to make things dimension independent, but in the end, the code is simply not pretty. What would be much nicer is if we could simply extract the ${\mathbf u}$ and $p$ components of a shape function $x_h^i$. In the program we do that in the following way:

    This is, in fact, not only the first term of the bilinear form, but the whole thing (sans boundary contributions).

    -

    What this piece of code does is, given an fe_values object, to extract the values of the first $dim$ components of shape function i at quadrature points q, that is the velocity components of that shape function. Put differently, if we write shape functions $x_h^i$ as the tuple $\{{\mathbf u}_h^i,p_h^i\}$, then the function returns the velocity part of this tuple. Note that the velocity is of course a dim-dimensional tensor, and that the function returns a corresponding object. Similarly, where we subscript with the pressure extractor, we extract the scalar pressure component. The whole mechanism is described in more detail in the Handling vector valued problems module.

    +

    What this piece of code does is, given an fe_values object, to extract the values of the first $dim$ components of shape function i at quadrature points q, that is the velocity components of that shape function. Put differently, if we write shape functions $x_h^i$ as the tuple $\{{\mathbf u}_h^i,p_h^i\}$, then the function returns the velocity part of this tuple. Note that the velocity is of course a dim-dimensional tensor, and that the function returns a corresponding object. Similarly, where we subscript with the pressure extractor, we extract the scalar pressure component. The whole mechanism is described in more detail in the Handling vector valued problems module.

    In practice, it turns out that we can do a bit better if we evaluate the shape functions, their gradients and divergences only once per outermost loop, and store the result, as this saves us a few otherwise repeated computations (it is possible to save even more repeated operations by calculating all relevant quantities in advance and then only inserting the results in the actual loop, see step-22 for a realization of that approach). The final result then looks like this, working in every space dimension:

    for (const auto &cell : dof_handler.active_cell_iterators())
    {
    @@ -321,7 +321,7 @@
    }
    Definition: tensor.h:516

    This very closely resembles the form in which we have originally written down the bilinear form and right hand side.

    -

    There is one final term that we have to take care of: the right hand side contained the term $(g,{\mathbf v}\cdot {\mathbf n})_{\partial\Omega}$, constituting the weak enforcement of pressure boundary conditions. We have already seen in step-7 how to deal with face integrals: essentially exactly the same as with domain integrals, except that we have to use the FEFaceValues class instead of FEValues. To compute the boundary term we then simply have to loop over all boundary faces and integrate there. The mechanism works in the same way as above, i.e. the extractor classes also work on FEFaceValues objects:

    +

    There is one final term that we have to take care of: the right hand side contained the term $(g,{\mathbf v}\cdot {\mathbf n})_{\partial\Omega}$, constituting the weak enforcement of pressure boundary conditions. We have already seen in step-7 how to deal with face integrals: essentially exactly the same as with domain integrals, except that we have to use the FEFaceValues class instead of FEValues. To compute the boundary term we then simply have to loop over all boundary faces and integrate there. The mechanism works in the same way as above, i.e. the extractor classes also work on FEFaceValues objects:

    for (const auto &face : cell->face_iterators())
    if (face->at_boundary())
    {
    @@ -339,15 +339,15 @@

    You will find the exact same code as above in the sources for the present program. We will therefore not comment much on it below.

    Linear solvers and preconditioners

    After assembling the linear system we are faced with the task of solving it. The problem here is that the matrix possesses two undesirable properties:

      -
    • It is indefinite, i.e., it has both positive and negative eigenvalues. We don't want to prove this property here, but note that this is true for all matrices of the form $\left(\begin{array}{cc} M & B \\ B^T & 0 \end{array}\right)$ such as the one here where $M$ is positive definite.
    • -
    • The matrix has a zero block at the bottom right (there is no term in the bilinear form that couples the pressure $p$ with the pressure test function $q$).
    • +
    • It is indefinite, i.e., it has both positive and negative eigenvalues. We don't want to prove this property here, but note that this is true for all matrices of the form $\left(\begin{array}{cc} M & B \\ B^T & 0 \end{array}\right)$ such as the one here where $M$ is positive definite.
    • +
    • The matrix has a zero block at the bottom right (there is no term in the bilinear form that couples the pressure $p$ with the pressure test function $q$).

    At least it is symmetric, but the first issue above still means that the Conjugate Gradient method is not going to work since it is only applicable to problems in which the matrix is symmetric and positive definite. We would have to resort to other iterative solvers instead, such as MinRes, SymmLQ, or GMRES, that can deal with indefinite systems. However, then the next problem immediately surfaces: Due to the zero block, there are zeros on the diagonal and none of the usual, "simple" preconditioners (Jacobi, SSOR) will work as they require division by diagonal elements.

    For the matrix sizes we expect to run with this program, the by far simplest approach would be to just use a direct solver (in particular, the SparseDirectUMFPACK class that is bundled with deal.II). step-29 goes this route and shows that solving any linear system can be done in just 3 or 4 lines of code.

    But then, this is a tutorial: We teach how to do things. Consequently, in the following, we will introduce some techniques that can be used in cases like these. Namely, we will consider the linear system as not consisting of one large matrix and vectors, but we will want to decompose matrices into blocks that correspond to the individual operators that appear in the system. We note that the resulting solver is not optimal – there are much better ways to efficiently compute the system, for example those explained in the results section of step-22 or the one we use in step-43 for a problem similar to the current one. Here, our goal is simply to introduce new solution techniques and how they can be implemented in deal.II.

    Solving using the Schur complement

    -

    In view of the difficulties using standard solvers and preconditioners mentioned above, let us take another look at the matrix. If we sort our degrees of freedom so that all velocity come before all pressure variables, then we can subdivide the linear system $Ax=b$ into the following blocks:

    -\begin{eqnarray*}
+<p>In view of the difficulties using standard solvers and preconditioners mentioned above, let us take another look at the matrix. If we sort our degrees of freedom so that all velocity come before all pressure variables, then we can subdivide the linear system <picture><source srcset=$Ax=b$ into the following blocks:

    +\begin{eqnarray*}
   \left(\begin{array}{cc}
     M & B \\ B^T & 0
   \end{array}\right)
@@ -358,26 +358,26 @@
   \left(\begin{array}{cc}
     F \\ G
   \end{array}\right),
-\end{eqnarray*} +\end{eqnarray*}" src="form_3124.png"/>

    -

    where $U,P$ are the values of velocity and pressure degrees of freedom, respectively, $M$ is the mass matrix on the velocity space, $B^T$ corresponds to the negative divergence operator, and $B$ is its transpose and corresponds to the gradient.

    +

    where $U,P$ are the values of velocity and pressure degrees of freedom, respectively, $M$ is the mass matrix on the velocity space, $B^T$ corresponds to the negative divergence operator, and $B$ is its transpose and corresponds to the gradient.

    By block elimination, we can then re-order this system in the following way (multiply the first row of the system by $B^TM^{-1}$ and then subtract the second row from it):

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   B^TM^{-1}B P &=& B^TM^{-1} F - G, \\
   MU &=& F - BP.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3125.png"/>

    -

    Here, the matrix $S=B^TM^{-1}B$ (called the Schur complement of $A$) is obviously symmetric and, owing to the positive definiteness of $M$ and the fact that $B$ has full column rank, $S$ is also positive definite.

    -

    Consequently, if we could compute $S$, we could apply the Conjugate Gradient method to it. However, computing $S$ is expensive because it requires us to compute the inverse of the (possibly large) matrix $M$; and $S$ is in fact also a full matrix because even though $M$ is sparse, its inverse $M^{-1}$ will generally be a dense matrix. On the other hand, the CG algorithm doesn't require us to actually have a representation of $S$: It is sufficient to form matrix-vector products with it. We can do so in steps, using the fact that matrix products are associative (i.e., we can set parentheses in such a way that the product is more convenient to compute): To compute $Sv=(B^TM^{-1}B)v=B^T(M^{-1}(Bv))$, we

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_21.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_21.html 2023-08-09 23:38:59.046631181 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_21.html 2023-08-09 23:38:59.046631181 +0000 @@ -153,113 +153,113 @@

      The equations covered here are an extension of the material already covered in step-20. In particular, they fall into the class of vector-valued problems. A toplevel overview of this topic can be found in the Handling vector valued problems module.

      The two phase flow problem

      Modeling of two phase flow in porous media is important for both environmental remediation and the management of petroleum and groundwater reservoirs. Practical situations involving two phase flow include the dispersal of a nonaqueous phase liquid in an aquifer, or the joint movement of a mixture of fluids such as oil and water in a reservoir. Simulation models, if they are to provide realistic predictions, must accurately account for these effects.

      -

      To derive the governing equations, consider two phase flow in a reservoir $\Omega$ under the assumption that the movement of fluids is dominated by viscous effects; i.e. we neglect the effects of gravity, compressibility, and capillary pressure. Porosity will be considered to be constant. We will denote variables referring to either of the two phases using subscripts $w$ and $o$, short for water and oil. The derivation of the equations holds for other pairs of fluids as well, however.

      +

      To derive the governing equations, consider two phase flow in a reservoir $\Omega$ under the assumption that the movement of fluids is dominated by viscous effects; i.e. we neglect the effects of gravity, compressibility, and capillary pressure. Porosity will be considered to be constant. We will denote variables referring to either of the two phases using subscripts $w$ and $o$, short for water and oil. The derivation of the equations holds for other pairs of fluids as well, however.

      The velocity with which molecules of each of the two phases move is determined by Darcy's law that states that the velocity is proportional to the pressure gradient:

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   \mathbf{u}_{j}
   =
   -\frac{k_{rj}(S)}{\mu_{j}} \mathbf{K} \cdot \nabla p
-\end{eqnarray*} +\end{eqnarray*}" src="form_3156.png"/>

      -

      where $\mathbf{u}_{j}$ is the velocity of phase $j=o,w$, $K$ is the permeability tensor, $k_{rj}$ is the relative permeability of phase $j$, $p$ is the pressure and $\mu_{j}$ is the viscosity of phase $j$. Finally, $S$ is the saturation (volume fraction), i.e. a function with values between 0 and 1 indicating the composition of the mixture of fluids. In general, the coefficients $K, k_{rj}, \mu$ may be spatially dependent variables, and we will always treat them as non-constant functions in the following.

      +

      where $\mathbf{u}_{j}$ is the velocity of phase $j=o,w$, $K$ is the permeability tensor, $k_{rj}$ is the relative permeability of phase $j$, $p$ is the pressure and $\mu_{j}$ is the viscosity of phase $j$. Finally, $S$ is the saturation (volume fraction), i.e. a function with values between 0 and 1 indicating the composition of the mixture of fluids. In general, the coefficients $K, k_{rj}, \mu$ may be spatially dependent variables, and we will always treat them as non-constant functions in the following.

      We combine Darcy's law with the statement of conservation of mass for each phase,

      -\[
+<picture><source srcset=\[
   \textrm{div}\ \mathbf{u}_{j} = q_j,
-\] +\]" src="form_3162.png"/>

      with a source term for each phase. By summing over the two phases, we can express the governing equations in terms of the so-called pressure equation:

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
 - \nabla \cdot (\mathbf{K}\lambda(S) \nabla p)= q.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3163.png"/>

      -

      Here, $q$ is the sum source term, and

      -\[
+<p> Here, <picture><source srcset=$q$ is the sum source term, and

      +\[
   \lambda(S) = \frac{k_{rw}(S)}{\mu_{w}}+\frac{k_{ro}(S)}{\mu_{o}}
-\] +\]" src="form_3164.png"/>

      is the total mobility.

      So far, this looks like an ordinary stationary, Poisson-like equation that we can solve right away with the techniques of the first few tutorial programs (take a look at step-6, for example, for something very similar). However, we have not said anything yet about the saturation, which of course is going to change as the fluids move around.

      The second part of the equations is the description of the dynamics of the saturation, i.e., how the relative concentration of the two fluids changes with time. The saturation equation for the displacing fluid (water) is given by the following conservation law:

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   S_{t} + \nabla \cdot (F(S) \mathbf{u}) = q_{w},
-\end{eqnarray*} +\end{eqnarray*}" src="form_3165.png"/>

      which can be rewritten by using the product rule of the divergence operator in the previous equation:

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   S_{t} + F(S) \left[\nabla \cdot \mathbf{u}\right]
         + \mathbf{u} \cdot \left[ \nabla F(S)\right]
   = S_{t} + F(S) q + \mathbf{u} \cdot \nabla F(S) = q_{w}.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3166.png"/>

      -

      Here, $q=\nabla\cdot \mathbf{u}$ is the total influx introduced above, and $q_{w}$ is the flow rate of the displacing fluid (water). These two are related to the fractional flow $F(S)$ in the following way:

      -\[
+<p> Here, <picture><source srcset=$q=\nabla\cdot \mathbf{u}$ is the total influx introduced above, and $q_{w}$ is the flow rate of the displacing fluid (water). These two are related to the fractional flow $F(S)$ in the following way:

      +\[
   q_{w} = F(S) q,
-\] +\]" src="form_3170.png"/>

      where the fractional flow is often parameterized via the (heuristic) expression

      -\[
+<picture><source srcset=\[
   F(S)
   =
   \frac{k_{rw}(S)/\mu_{w}}{k_{rw}(S)/\mu_{w} + k_{ro}(S)/\mu_{o}}.
-\] +\]" src="form_3171.png"/>

      Putting it all together yields the saturation equation in the following, advected form:

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   S_{t} + \mathbf{u} \cdot \nabla F(S) = 0,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3172.png"/>

      where $\mathbf u$ is the total velocity

      -\[
+<picture><source srcset=\[
   \mathbf{u} =
   \mathbf{u}_{o} + \mathbf{u}_{w} = -\lambda(S) \mathbf{K}\cdot\nabla p.
-\] +\]" src="form_3173.png"/>

      -

      Note that the advection equation contains the term $\mathbf{u} \cdot \nabla
-F(S)$ rather than $\mathbf{u} \cdot \nabla S$ to indicate that the saturation is not simply transported along; rather, since the two phases move with different velocities, the saturation can actually change even in the advected coordinate system. To see this, rewrite $\mathbf{u} \cdot \nabla F(S)
-= \mathbf{u} F'(S) \cdot \nabla S$ to observe that the actual velocity with which the phase with saturation $S$ is transported is $\mathbf u F'(S)$ whereas the other phase is transported at velocity $\mathbf u (1-F'(S))$. $F(S)$ is consequently often referred to as the fractional flow.

      +

      Note that the advection equation contains the term $\mathbf{u} \cdot \nabla
+F(S)$ rather than $\mathbf{u} \cdot \nabla S$ to indicate that the saturation is not simply transported along; rather, since the two phases move with different velocities, the saturation can actually change even in the advected coordinate system. To see this, rewrite $\mathbf{u} \cdot \nabla F(S)
+= \mathbf{u} F'(S) \cdot \nabla S$ to observe that the actual velocity with which the phase with saturation $S$ is transported is $\mathbf u F'(S)$ whereas the other phase is transported at velocity $\mathbf u (1-F'(S))$. $F(S)$ is consequently often referred to as the fractional flow.

      In summary, what we get are the following two equations:

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   - \nabla \cdot (\mathbf{K}\lambda(S) \nabla p) &=& q
   \qquad \textrm{in}\ \Omega\times[0,T],
   \\
   S_{t} + \mathbf{u} \cdot \nabla F(S) &=& 0
   \qquad \textrm{in}\ \Omega\times[0,T].
-\end{eqnarray*} +\end{eqnarray*}" src="form_3179.png"/>

      -

      Here, $p=p(\mathbf x, t), S=S(\mathbf x, t)$ are now time dependent functions: while at every time instant the flow field is in equilibrium with the pressure (i.e. we neglect dynamic accelerations), the saturation is transported along with the flow and therefore changes over time, in turn affected the flow field again through the dependence of the first equation on $S$.

      +

      Here, $p=p(\mathbf x, t), S=S(\mathbf x, t)$ are now time dependent functions: while at every time instant the flow field is in equilibrium with the pressure (i.e. we neglect dynamic accelerations), the saturation is transported along with the flow and therefore changes over time, in turn affected the flow field again through the dependence of the first equation on $S$.

      This set of equations has a peculiar character: one of the two equations has a time derivative, the other one doesn't. This corresponds to the character that the pressure and velocities are coupled through an instantaneous constraint, whereas the saturation evolves over finite time scales.

      -

      Such systems of equations are called Differential Algebraic Equations (DAEs), since one of the equations is a differential equation, the other is not (at least not with respect to the time variable) and is therefore an "algebraic" equation. (The notation comes from the field of ordinary differential equations, where everything that does not have derivatives with respect to the time variable is necessarily an algebraic equation.) This class of equations contains pretty well-known cases: for example, the time dependent Stokes and Navier-Stokes equations (where the algebraic constraint is that the divergence of the flow field, $\textrm{div}\ \mathbf u$, must be zero) as well as the time dependent Maxwell equations (here, the algebraic constraint is that the divergence of the electric displacement field equals the charge density, $\textrm{div}\ \mathbf D = \rho$ and that the divergence of the magnetic flux density is zero: $\textrm{div}\ \mathbf
-B = 0$); even the quasistatic model of step-18 falls into this category. We will see that the different character of the two equations will inform our discretization strategy for the two equations.

      +

      Such systems of equations are called Differential Algebraic Equations (DAEs), since one of the equations is a differential equation, the other is not (at least not with respect to the time variable) and is therefore an "algebraic" equation. (The notation comes from the field of ordinary differential equations, where everything that does not have derivatives with respect to the time variable is necessarily an algebraic equation.) This class of equations contains pretty well-known cases: for example, the time dependent Stokes and Navier-Stokes equations (where the algebraic constraint is that the divergence of the flow field, $\textrm{div}\ \mathbf u$, must be zero) as well as the time dependent Maxwell equations (here, the algebraic constraint is that the divergence of the electric displacement field equals the charge density, $\textrm{div}\ \mathbf D = \rho$ and that the divergence of the magnetic flux density is zero: $\textrm{div}\ \mathbf
+B = 0$); even the quasistatic model of step-18 falls into this category. We will see that the different character of the two equations will inform our discretization strategy for the two equations.

      Time discretization

      In the reservoir simulation community, it is common to solve the equations derived above by going back to the first order, mixed formulation. To this end, we re-introduce the total velocity $\mathbf u$ and write the equations in the following form:

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   \mathbf{u}+\mathbf{K}\lambda(S) \nabla p&=&0 \\
   \nabla \cdot\mathbf{u} &=& q \\
   S_{t} + \mathbf{u} \cdot \nabla F(S) &=& 0.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3184.png"/>

      This formulation has the additional benefit that we do not have to express the total velocity $\mathbf u$ appearing in the transport equation as a function of the pressure, but can rather take the primary variable for it. Given the saddle point structure of the first two equations and their similarity to the mixed Laplace formulation we have introduced in step-20, it will come as no surprise that we will use a mixed discretization again.

      But let's postpone this for a moment. The first business we have with these equations is to think about the time discretization. In reservoir simulation, there is a rather standard algorithm that we will use here. It first solves the pressure using an implicit equation, then the saturation using an explicit time stepping scheme. The algorithm is called IMPES for IMplicit Pressure Explicit Saturation and was first proposed a long time ago: by Sheldon et al. in 1959 and Stone and Gardner in 1961 (J. W. Sheldon, B. Zondek and W. T. Cardwell: One-dimensional, incompressible, non-capillary, two-phase fluid flow in a porous medium, Trans. SPE AIME, 216 (1959), pp. 290-296; H. L. Stone and A. O. Gardner Jr: Analysis of gas-cap or dissolved-gas reservoirs, Trans. SPE AIME, 222 (1961), pp. 92-104). In a slightly modified form, this algorithm can be written as follows: for each time step, solve

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   \mathbf{u}^{n+1}+\mathbf{K}\lambda(S^n) \nabla p^{n+1}&=&0 \\
   \nabla \cdot\mathbf{u}^{n+1} &=& q^{n+1} \\
   \frac {S^{n+1}-S^n}{\triangle t} + \mathbf{u}^{n+1} \cdot \nabla F(S^n) &=& 0,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3185.png"/>

      -

      where $\triangle t$ is the length of a time step. Note how we solve the implicit pressure-velocity system that only depends on the previously computed saturation $S^n$, and then do an explicit time step for $S^{n+1}$ that only depends on the previously known $S^n$ and the just computed $\mathbf{u}^{n+1}$. This way, we never have to iterate for the nonlinearities of the system as we would have if we used a fully implicit method. (In a more modern perspective, this should be seen as an "operator +

      where $\triangle t$ is the length of a time step. Note how we solve the implicit pressure-velocity system that only depends on the previously computed saturation $S^n$, and then do an explicit time step for $S^{n+1}$ that only depends on the previously known $S^n$ and the just computed $\mathbf{u}^{n+1}$. This way, we never have to iterate for the nonlinearities of the system as we would have if we used a fully implicit method. (In a more modern perspective, this should be seen as an "operator splitting" method. step-58 has a long description of the idea behind this.)

      -

      We can then state the problem in weak form as follows, by multiplying each equation with test functions $\mathbf v$, $\phi$, and $\sigma$ and integrating terms by parts:

      -\begin{eqnarray*}
+<p>We can then state the problem in weak form as follows, by multiplying each equation with test functions <picture><source srcset=$\mathbf v$, $\phi$, and $\sigma$ and integrating terms by parts:

      +\begin{eqnarray*}
   \left((\mathbf{K}\lambda(S^n))^{-1} \mathbf{u}^{n+1},\mathbf v\right)_\Omega -
   (p^{n+1}, \nabla\cdot\mathbf v)_\Omega &=&
   - (p^{n+1}, \mathbf v)_{\partial\Omega}
   \\
   (\nabla \cdot\mathbf{u}^{n+1}, \phi)_\Omega &=& (q^{n+1},\phi)_\Omega
-\end{eqnarray*} +\end{eqnarray*}" src="form_3190.png"/>

      -

      Note that in the first term, we have to prescribe the pressure $p^{n+1}$ on the boundary $\partial\Omega$ as boundary values for our problem. $\mathbf n$ denotes the unit outward normal vector to $\partial K$, as usual.

      +

      Note that in the first term, we have to prescribe the pressure $p^{n+1}$ on the boundary $\partial\Omega$ as boundary values for our problem. $\mathbf n$ denotes the unit outward normal vector to $\partial K$, as usual.

      For the saturation equation, we obtain after integrating by parts

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   (S^{n+1}, \sigma)_\Omega
   -
   \triangle t
@@ -271,10 +271,10 @@
   \right\}
   &=&
   (S^n,\sigma)_\Omega.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3194.png"/>

      -

      Using the fact that $\nabla \cdot \mathbf{u}^{n+1}=q^{n+1}$, we can rewrite the cell term to get an equation as follows:

      -\begin{eqnarray*}
+<p> Using the fact that <picture><source srcset=$\nabla \cdot \mathbf{u}^{n+1}=q^{n+1}$, we can rewrite the cell term to get an equation as follows:

      +\begin{eqnarray*}
   (S^{n+1}, \sigma)_\Omega
   -
   \triangle t
@@ -287,26 +287,26 @@
   &=&
   (S^n,\sigma)_\Omega +
   \triangle t \sum_K  \left(F(S^n) q^{n+1}, \sigma\right)_K.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3196.png"/>

      We introduce an object of type DiscreteTime in order to keep track of the current value of time and time step in the code. This class encapsulates many complexities regarding adjusting time step size and stopping at a specified final time.

      Space discretization

      -

      In each time step, we then apply the mixed finite method of step-20 to the velocity and pressure. To be well-posed, we choose Raviart-Thomas spaces $RT_{k}$ for $\mathbf{u}$ and discontinuous elements of class $DGQ_{k}$ for $p$. For the saturation, we will also choose $DGQ_{k}$ spaces.

      +

      In each time step, we then apply the mixed finite method of step-20 to the velocity and pressure. To be well-posed, we choose Raviart-Thomas spaces $RT_{k}$ for $\mathbf{u}$ and discontinuous elements of class $DGQ_{k}$ for $p$. For the saturation, we will also choose $DGQ_{k}$ spaces.

      Since we have discontinuous spaces, we have to think about how to evaluate terms on the interfaces between cells, since discontinuous functions are not really defined there. In particular, we have to give a meaning to the last term on the left hand side of the saturation equation. To this end, let us define that we want to evaluate it in the following sense:

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   &&\left(F(S^n) (\mathbf n \cdot \mathbf{u}^{n+1}), \sigma\right)_{\partial K}
   \\
   &&\qquad =
   \left(F(S^n_+) (\mathbf n \cdot \mathbf{u}^{n+1}_+), \sigma\right)_{\partial K_+}
   +
   \left(F(S^n_-) (\mathbf n \cdot \mathbf{u}^{n+1}_-), \sigma\right)_{\partial K_-},
-\end{eqnarray*} +\end{eqnarray*}" src="form_3199.png"/>

      -

      where $\partial K_{-} \dealcoloneq \{x\in \partial K, \mathbf{u}(x) \cdot \mathbf{n}<0\}$ denotes the inflow boundary and $\partial K_{+} \dealcoloneq \{\partial K \setminus
-\partial K_{-}\}$ is the outflow part of the boundary. The quantities $S_+,\mathbf{u}_+$ then correspond to the values of these variables on the present cell, whereas $S_-,\mathbf{u}_-$ (needed on the inflow part of the boundary of $K$) are quantities taken from the neighboring cell. Some more context on discontinuous element techniques and evaluation of fluxes can also be found in step-12 and step-12b.

      +

      where $\partial K_{-} \dealcoloneq \{x\in \partial K, \mathbf{u}(x) \cdot \mathbf{n}<0\}$ denotes the inflow boundary and $\partial K_{+} \dealcoloneq \{\partial K \setminus
+\partial K_{-}\}$ is the outflow part of the boundary. The quantities $S_+,\mathbf{u}_+$ then correspond to the values of these variables on the present cell, whereas $S_-,\mathbf{u}_-$ (needed on the inflow part of the boundary of $K$) are quantities taken from the neighboring cell. Some more context on discontinuous element techniques and evaluation of fluxes can also be found in step-12 and step-12b.

      Linear solvers

      /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_22.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_22.html 2023-08-09 23:38:59.126631780 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_22.html 2023-08-09 23:38:59.126631780 +0000 @@ -165,36 +165,36 @@ This material is based upon work partly supported by the National Science Foundation under Award No. EAR-0426271 and The California Institute of Technology. Any opinions, findings, and conclusions or recommendations expressed in this publication are those of the author and do not necessarily reflect the views of the National Science Foundation or of The California Institute of Technology.

      Introduction

      This program deals with the Stokes system of equations which reads as follows in non-dimensionalized form:

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   -2\; \textrm{div}\; \varepsilon(\textbf{u}) + \nabla p &=& \textbf{f},
   \\
   -\textrm{div}\; \textbf{u} &=& 0,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3249.png"/>

      -

      where $\textbf u$ denotes the velocity of a fluid, $p$ is its pressure, $\textbf f$ are external forces, and $\varepsilon(\textbf{u})= \nabla^s{\textbf{u}}= \frac 12 \left[
-(\nabla \textbf{u}) + (\nabla \textbf{u})^T\right]$ is the rank-2 tensor of symmetrized gradients; a component-wise definition of it is $\varepsilon(\textbf{u})_{ij}=\frac
-12\left(\frac{\partial u_i}{\partial x_j} + \frac{\partial u_j}{\partial x_i}\right)$.

      +

      where $\textbf u$ denotes the velocity of a fluid, $p$ is its pressure, $\textbf f$ are external forces, and $\varepsilon(\textbf{u})= \nabla^s{\textbf{u}}= \frac 12 \left[
+(\nabla \textbf{u}) + (\nabla \textbf{u})^T\right]$ is the rank-2 tensor of symmetrized gradients; a component-wise definition of it is $\varepsilon(\textbf{u})_{ij}=\frac
+12\left(\frac{\partial u_i}{\partial x_j} + \frac{\partial u_j}{\partial x_i}\right)$.

      The Stokes equations describe the steady-state motion of a slow-moving, viscous fluid such as honey, rocks in the earth mantle, or other cases where inertia does not play a significant role. If a fluid is moving fast enough that inertia forces are significant compared to viscous friction, the Stokes equations are no longer valid; taking into account inertia effects then leads to the nonlinear Navier-Stokes equations. However, in this tutorial program, we will focus on the simpler Stokes system.

      Note that when deriving the more general compressible Navier-Stokes equations, the diffusion is modeled as the divergence of the stress tensor

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   \tau = - \mu \left(2\varepsilon(\textbf{u}) - \frac{2}{3}\nabla \cdot \textbf{u} I\right),
-\end{eqnarray*} +\end{eqnarray*}" src="form_3253.png"/>

      -

      where $\mu$ is the viscosity of the fluid. With the assumption of $\mu=1$ (assume constant viscosity and non-dimensionalize the equation by dividing out $\mu$) and assuming incompressibility ( $\textrm{div}\; \textbf{u}=0$), we arrive at the formulation from above:

      -\begin{eqnarray*}
+<p> where <picture><source srcset=$\mu$ is the viscosity of the fluid. With the assumption of $\mu=1$ (assume constant viscosity and non-dimensionalize the equation by dividing out $\mu$) and assuming incompressibility ( $\textrm{div}\; \textbf{u}=0$), we arrive at the formulation from above:

      +\begin{eqnarray*}
   \textrm{div}\; \tau = -2\textrm{div}\;\varepsilon(\textbf{u}).
-\end{eqnarray*} +\end{eqnarray*}" src="form_3256.png"/>

      -

      A different formulation uses the Laplace operator ( $-\triangle \textbf{u}$) instead of the symmetrized gradient. A big difference here is that the different components of the velocity do not couple. If you assume additional regularity of the solution $\textbf{u}$ (second partial derivatives exist and are continuous), the formulations are equivalent:

      -\begin{eqnarray*}
+<p> A different formulation uses the Laplace operator ( <picture><source srcset=$-\triangle \textbf{u}$) instead of the symmetrized gradient. A big difference here is that the different components of the velocity do not couple. If you assume additional regularity of the solution $\textbf{u}$ (second partial derivatives exist and are continuous), the formulations are equivalent:

      +\begin{eqnarray*}
   \textrm{div}\; \tau
   = -2\textrm{div}\;\varepsilon(\textbf{u})
   = -\triangle \textbf{u} - \nabla \cdot (\nabla\textbf{u})^T
   = -\triangle \textbf{u}.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3259.png"/>

      -

      This is because the $i$th entry of $\nabla \cdot (\nabla\textbf{u})^T$ is given by:

      -\begin{eqnarray*}
+<p> This is because the <picture><source srcset=$i$th entry of $\nabla \cdot (\nabla\textbf{u})^T$ is given by:

      +\begin{eqnarray*}
 [\nabla \cdot (\nabla\textbf{u})^T]_i
 = \sum_j \frac{\partial}{\partial x_j} [(\nabla\textbf{u})^T]_{i,j}
 = \sum_j \frac{\partial}{\partial x_j} [(\nabla\textbf{u})]_{j,i}
@@ -203,14 +203,14 @@
 = \frac{\partial}{\partial x_i}
   \underbrace{\textrm{div}\; \textbf{u}}_{=0}
 = 0.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3261.png"/>

      If you can not assume the above mentioned regularity, or if your viscosity is not a constant, the equivalence no longer holds. Therefore, we decided to stick with the more physically accurate symmetric tensor formulation in this tutorial.

      To be well-posed, we will have to add boundary conditions to the equations. What boundary conditions are readily possible here will become clear once we discuss the weak form of the equations.

      The equations covered here fall into the class of vector-valued problems. A toplevel overview of this topic can be found in the Handling vector valued problems module.

      Weak form

      The weak form of the equations is obtained by writing it in vector form as

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   \begin{pmatrix}
     {-2\; \textrm{div}\; \varepsilon(\textbf{u}) + \nabla p}
     \\
@@ -222,23 +222,23 @@
   \\
   0
   \end{pmatrix},
-\end{eqnarray*} +\end{eqnarray*}" src="form_3262.png"/>

      -

      forming the dot product from the left with a vector-valued test function $\phi = \begin{pmatrix}\textbf{v} \\ q\end{pmatrix}$ and integrating over the domain $\Omega$, yielding the following set of equations:

      -\begin{eqnarray*}
+<p> forming the dot product from the left with a vector-valued test function <picture><source srcset=$\phi = \begin{pmatrix}\textbf{v} \\ q\end{pmatrix}$ and integrating over the domain $\Omega$, yielding the following set of equations:

      +\begin{eqnarray*}
   (\mathrm v,
    -2\; \textrm{div}\; \varepsilon(\textbf{u}) + \nabla p)_{\Omega}
   -
   (q,\textrm{div}\; \textbf{u})_{\Omega}
   =
   (\textbf{v}, \textbf{f})_\Omega,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3264.png"/>

      -

      which has to hold for all test functions $\phi = \begin{pmatrix}\textbf{v}
-\\ q\end{pmatrix}$.

      +

      which has to hold for all test functions $\phi = \begin{pmatrix}\textbf{v}
+\\ q\end{pmatrix}$.

      A generally good rule of thumb is that if one can reduce how many derivatives are taken on any variable in the formulation, then one should in fact do that using integration by parts. (This is motivated by the theory of partial differential equations, and in particular the difference between strong and weak solutions.) We have already done that for the Laplace equation, where we have integrated the second derivative by parts to obtain the weak formulation that has only one derivative on both test and trial function.

      In the current context, we integrate by parts the second term:

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   (\textbf{v}, -2\; \textrm{div}\; \varepsilon(\textbf{u}))_{\Omega}
   - (\textrm{div}\; \textbf{v}, p)_{\Omega}
   + (\textbf{n}\cdot\textbf{v}, p)_{\partial\Omega}
@@ -246,10 +246,10 @@
   (q,\textrm{div}\; \textbf{u})_{\Omega}
   =
   (\textbf{v}, \textbf{f})_\Omega.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3266.png"/>

      Likewise, we integrate by parts the first term to obtain

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   (\nabla \textbf{v}, 2\; \varepsilon(\textbf{u}))_{\Omega}
   -
   (\textbf{n} \otimes \textbf{v}, 2\; \varepsilon(\textbf{u}))_{\partial\Omega}
@@ -259,19 +259,19 @@
   (q,\textrm{div}\; \textbf{u})_{\Omega}
   =
   (\textbf{v}, \textbf{f})_\Omega,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3267.png"/>

      where the scalar product between two tensor-valued quantities is here defined as

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   (\nabla \textbf{v}, 2\; \varepsilon(\textbf{u}))_{\Omega}
   =
   2 \int_\Omega \sum_{i,j=1}^d \frac{\partial v_j}{\partial x_i}
   \varepsilon(\textbf{u})_{ij} \ dx.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3268.png"/>

      -

      Using this, we have now reduced the requirements on our variables to first derivatives for $\mathbf u,\mathbf v$ and no derivatives at all for $p,q$.

      -

      Because the scalar product between a general tensor like $\nabla\textbf{v}$ and a symmetric tensor like $\varepsilon(\textbf{u})$ equals the scalar product between the symmetrized forms of the two, we can also write the bilinear form above as follows:

      -\begin{eqnarray*}
+<p> Using this, we have now reduced the requirements on our variables to first derivatives for <picture><source srcset=$\mathbf u,\mathbf v$ and no derivatives at all for $p,q$.

      +

      Because the scalar product between a general tensor like $\nabla\textbf{v}$ and a symmetric tensor like $\varepsilon(\textbf{u})$ equals the scalar product between the symmetrized forms of the two, we can also write the bilinear form above as follows:

      +\begin{eqnarray*}
   (\varepsilon(\textbf{v}), 2\; \varepsilon(\textbf{u}))_{\Omega}
   -
   (\textbf{n} \otimes \textbf{v}, 2\; \varepsilon(\textbf{u}))_{\partial\Omega}
@@ -281,43 +281,43 @@
   (q,\textrm{div}\; \textbf{u})_{\Omega}
   =
   (\textbf{v}, \textbf{f})_\Omega,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3272.png"/>

      We will deal with the boundary terms in the next section, but it is already clear from the domain terms

      -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   (\varepsilon(\textbf{v}), 2\; \varepsilon(\textbf{u}))_{\Omega}
   - (\textrm{div}\; \textbf{v}, p)_{\Omega}
   -
   (q,\textrm{div}\; \textbf{u})_{\Omega}
-\end{eqnarray*} +\end{eqnarray*}" src="form_3273.png"/>

      of the bilinear form that the Stokes equations yield a symmetric bilinear form, and consequently a symmetric (if indefinite) system matrix.

      Boundary conditions

      Note
      The material presented here is also discussed in video lecture 21.5. (All video lectures are also available here.) (See also video lecture 21.55, video lecture 21.6, video lecture 21.65.)

      The weak form just derived immediately presents us with different possibilities for imposing boundary conditions:

      1. -

        Dirichlet velocity boundary conditions: On a part $\Gamma_D\subset\partial\Omega$ we may impose Dirichlet conditions on the velocity $\textbf u$:

        +

        Dirichlet velocity boundary conditions: On a part $\Gamma_D\subset\partial\Omega$ we may impose Dirichlet conditions on the velocity $\textbf u$:

        -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
         \textbf u = \textbf g_D \qquad\qquad \textrm{on}\ \Gamma_D.
-    \end{eqnarray*} + \end{eqnarray*}" src="form_3275.png"/>

        -

        Because test functions $\textbf{v}$ come from the tangent space of the solution variable, we have that $\textbf{v}=0$ on $\Gamma_D$ and consequently that

        -\begin{eqnarray*}
+<p> Because test functions <picture><source srcset=$\textbf{v}$ come from the tangent space of the solution variable, we have that $\textbf{v}=0$ on $\Gamma_D$ and consequently that

        +\begin{eqnarray*}
       -(\textbf{n} \otimes \mathrm
         v, 2\; \varepsilon(\textbf{u}))_{\Gamma_D}
       +
       (\textbf{n}\cdot\textbf{v}, p)_{\Gamma_D}
       = 0.
-    \end{eqnarray*} + \end{eqnarray*}" src="form_3279.png"/>

        In other words, as usual, strongly imposed boundary values do not appear in the weak form.

        It is noteworthy that if we impose Dirichlet boundary values on the entire boundary, then the pressure is only determined up to a constant. An algorithmic realization of that would use similar tools as have been seen in step-11.

      2. -

        Neumann-type or natural boundary conditions: On the rest of the boundary $\Gamma_N=\partial\Omega\backslash\Gamma_D$, let us re-write the boundary terms as follows:

        -\begin{eqnarray*}
+<p class=Neumann-type or natural boundary conditions: On the rest of the boundary $\Gamma_N=\partial\Omega\backslash\Gamma_D$, let us re-write the boundary terms as follows:

        +\begin{eqnarray*}
       -(\textbf{n} \otimes \mathrm
         v, 2\; \varepsilon(\textbf{u}))_{\Gamma_N}
       +
@@ -347,17 +347,17 @@
       &=&
       (\textbf{v},
        \textbf{n}\cdot [p \textbf{I} - 2\; \varepsilon(\textbf{u})])_{\Gamma_N}.
/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_23.html differs (HTML document, UTF-8 Unicode text, with very long lines)
--- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_23.html	2023-08-09 23:38:59.174632137 +0000
+++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_23.html	2023-08-09 23:38:59.174632137 +0000
@@ -130,8 +130,8 @@
  <a class=

        Introduction

        Note
        The material presented here is also discussed in video lecture 28. (All video lectures are also available here.)

        This is the first of a number of tutorial programs that will finally cover "real" time-dependent problems, not the slightly odd form of time dependence found in step-18 or the DAE model of step-21. In particular, this program introduces the wave equation in a bounded domain. Later, step-24 will consider an example of absorbing boundary conditions, and step-25 a kind of nonlinear wave equation producing solutions called solitons.

        -

        The wave equation in its prototypical form reads as follows: find $u(x,t), x\in\Omega, t\in[0,T]$ that satisfies

        -\begin{eqnarray*}
+<p>The wave equation in its prototypical form reads as follows: find <picture><source srcset=$u(x,t), x\in\Omega, t\in[0,T]$ that satisfies

        +\begin{eqnarray*}
         \frac{\partial^2 u}{\partial t^2}
         -
         \Delta u &=& f
@@ -149,10 +149,10 @@
         \frac{\partial u(x,0)}{\partial t} &=& u_1(x)
         \qquad
         \textrm{in}\ \Omega.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3358.png"/>

        Note that since this is an equation with second-order time derivatives, we need to pose two initial conditions, one for the value and one for the time derivative of the solution.

        -

        Physically, the equation describes the motion of an elastic medium. In 2-d, one can think of how a membrane moves if subjected to a force. The Dirichlet boundary conditions above indicate that the membrane is clamped at the boundary at a height $g(x,t)$ (this height might be moving as well — think of people holding a blanket and shaking it up and down). The first initial condition equals the initial deflection of the membrane, whereas the second one gives its velocity. For example, one could think of pushing the membrane down with a finger and then letting it go at $t=0$ (nonzero deflection but zero initial velocity), or hitting it with a hammer at $t=0$ (zero deflection but nonzero velocity). Both cases would induce motion in the membrane.

        +

        Physically, the equation describes the motion of an elastic medium. In 2-d, one can think of how a membrane moves if subjected to a force. The Dirichlet boundary conditions above indicate that the membrane is clamped at the boundary at a height $g(x,t)$ (this height might be moving as well — think of people holding a blanket and shaking it up and down). The first initial condition equals the initial deflection of the membrane, whereas the second one gives its velocity. For example, one could think of pushing the membrane down with a finger and then letting it go at $t=0$ (nonzero deflection but zero initial velocity), or hitting it with a hammer at $t=0$ (zero deflection but nonzero velocity). Both cases would induce motion in the membrane.

        Time discretization

        Method of lines or Rothe's method?

        There is a long-standing debate in the numerical analysis community over whether a discretization of time dependent equations should involve first discretizing the time variable leading to a stationary PDE at each time step that is then solved using standard finite element techniques (this is called the Rothe method), or whether one should first discretize the spatial variables, leading to a large system of ordinary differential equations that can then be handled by one of the usual ODE solvers (this is called the method of lines).

        @@ -165,12 +165,12 @@

        Rothe's method!

        Given these considerations, here is how we will proceed: let us first define a simple time stepping method for this second order problem, and then in a second step do the spatial discretization, i.e. we will follow Rothe's approach.

        For the first step, let us take a little detour first: in order to discretize a second time derivative, we can either discretize it directly, or we can introduce an additional variable and transform the system into a first order system. In many cases, this turns out to be equivalent, but dealing with first order systems is often simpler. To this end, let us introduce

        -\[
+<picture><source srcset=\[
         v = \frac{\partial u}{\partial t},
-\] +\]" src="form_3360.png"/>

        and call this variable the velocity for obvious reasons. We can then reformulate the original wave equation as follows:

        -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
         \frac{\partial u}{\partial t}
         -
         v
@@ -195,37 +195,37 @@
         v(x,0) &=& u_1(x)
         \qquad
         \textrm{in}\ \Omega.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3361.png"/>

        -

        The advantage of this formulation is that it now only contains first time derivatives for both variables, for which it is simple to write down time stepping schemes. Note that we do not have boundary conditions for $v$ at first. However, we could enforce $v=\frac{\partial
-g}{\partial t}$ on the boundary. It turns out in numerical examples that this is actually necessary: without doing so the solution doesn't look particularly wrong, but the Crank-Nicolson scheme does not conserve energy if one doesn't enforce these boundary conditions.

        -

        With this formulation, let us introduce the following time discretization where a superscript $n$ indicates the number of a time step and $k=t_n-t_{n-1}$ is the length of the present time step:

        -\begin{eqnarray*}
+<p> The advantage of this formulation is that it now only contains first time derivatives for both variables, for which it is simple to write down time stepping schemes. Note that we do not have boundary conditions for <picture><source srcset=$v$ at first. However, we could enforce $v=\frac{\partial
+g}{\partial t}$ on the boundary. It turns out in numerical examples that this is actually necessary: without doing so the solution doesn't look particularly wrong, but the Crank-Nicolson scheme does not conserve energy if one doesn't enforce these boundary conditions.

        +

        With this formulation, let us introduce the following time discretization where a superscript $n$ indicates the number of a time step and $k=t_n-t_{n-1}$ is the length of the present time step:

        +\begin{eqnarray*}
   \frac{u^n - u^{n-1}}{k}
   - \left[\theta v^n + (1-\theta) v^{n-1}\right] &=& 0,
   \\
   \frac{v^n - v^{n-1}}{k}
   - \Delta\left[\theta u^n + (1-\theta) u^{n-1}\right]
   &=& \theta f^n + (1-\theta) f^{n-1}.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3364.png"/>

        -

        Note how we introduced a parameter $\theta$ here. If we chose $\theta=0$, for example, the first equation would reduce to $\frac{u^n - u^{n-1}}{k}  - v^{n-1} = 0$, which is well-known as the forward or explicit Euler method. On the other hand, if we set $\theta=1$, then we would get $\frac{u^n - u^{n-1}}{k}  - v^n = 0$, which corresponds to the backward or implicit Euler method. Both these methods are first order accurate methods. They are simple to implement, but they are not really very accurate.

        -

        The third case would be to choose $\theta=\frac 12$. The first of the equations above would then read $\frac{u^n - u^{n-1}}{k}
-- \frac 12 \left[v^n + v^{n-1}\right] = 0$. This method is known as the Crank-Nicolson method and has the advantage that it is second order accurate. In addition, it has the nice property that it preserves the energy in the solution (physically, the energy is the sum of the kinetic energy of the particles in the membrane plus the potential energy present due to the fact that it is locally stretched; this quantity is a conserved one in the continuous equation, but most time stepping schemes do not conserve it after time discretization). Since $v^n$ also appears in the equation for $u^n$, the Crank-Nicolson scheme is also implicit.

        -

        In the program, we will leave $\theta$ as a parameter, so that it will be easy to play with it. The results section will show some numerical evidence comparing the different schemes.

        -

        The equations above (called the semidiscretized equations because we have only discretized the time, but not space), can be simplified a bit by eliminating $v^n$ from the first equation and rearranging terms. We then get

        -\begin{eqnarray*}
+<p> Note how we introduced a parameter <picture><source srcset=$\theta$ here. If we chose $\theta=0$, for example, the first equation would reduce to $\frac{u^n - u^{n-1}}{k}  - v^{n-1} = 0$, which is well-known as the forward or explicit Euler method. On the other hand, if we set $\theta=1$, then we would get $\frac{u^n - u^{n-1}}{k}  - v^n = 0$, which corresponds to the backward or implicit Euler method. Both these methods are first order accurate methods. They are simple to implement, but they are not really very accurate.

        +

        The third case would be to choose $\theta=\frac 12$. The first of the equations above would then read $\frac{u^n - u^{n-1}}{k}
+- \frac 12 \left[v^n + v^{n-1}\right] = 0$. This method is known as the Crank-Nicolson method and has the advantage that it is second order accurate. In addition, it has the nice property that it preserves the energy in the solution (physically, the energy is the sum of the kinetic energy of the particles in the membrane plus the potential energy present due to the fact that it is locally stretched; this quantity is a conserved one in the continuous equation, but most time stepping schemes do not conserve it after time discretization). Since $v^n$ also appears in the equation for $u^n$, the Crank-Nicolson scheme is also implicit.

        +

        In the program, we will leave $\theta$ as a parameter, so that it will be easy to play with it. The results section will show some numerical evidence comparing the different schemes.

        +

        The equations above (called the semidiscretized equations because we have only discretized the time, but not space), can be simplified a bit by eliminating $v^n$ from the first equation and rearranging terms. We then get

        +\begin{eqnarray*}
   \left[ 1-k^2\theta^2\Delta \right] u^n &=&
          \left[ 1+k^2\theta(1-\theta)\Delta\right] u^{n-1} + k v^{n-1}
          + k^2\theta\left[\theta f^n + (1-\theta) f^{n-1}\right],\\
    v^n &=& v^{n-1} + k\Delta\left[ \theta u^n + (1-\theta) u^{n-1}\right]
    + k\left[\theta f^n + (1-\theta) f^{n-1}\right].
-\end{eqnarray*} +\end{eqnarray*}" src="form_3372.png"/>

        -

        In this form, we see that if we are given the solution $u^{n-1},v^{n-1}$ of the previous timestep, that we can then solve for the variables $u^n,v^n$ separately, i.e. one at a time. This is convenient. In addition, we recognize that the operator in the first equation is positive definite, and the second equation looks particularly simple.

        +

        In this form, we see that if we are given the solution $u^{n-1},v^{n-1}$ of the previous timestep, that we can then solve for the variables $u^n,v^n$ separately, i.e. one at a time. This is convenient. In addition, we recognize that the operator in the first equation is positive definite, and the second equation looks particularly simple.

        Space discretization

        -

        We have now derived equations that relate the approximate (semi-discrete) solution $u^n(x)$ and its time derivative $v^n(x)$ at time $t_n$ with the solutions $u^{n-1}(x),v^{n-1}(x)$ of the previous time step at $t_{n-1}$. The next step is to also discretize the spatial variable using the usual finite element methodology. To this end, we multiply each equation with a test function, integrate over the entire domain, and integrate by parts where necessary. This leads to

        -\begin{eqnarray*}
+<p>We have now derived equations that relate the approximate (semi-discrete) solution <picture><source srcset=$u^n(x)$ and its time derivative $v^n(x)$ at time $t_n$ with the solutions $u^{n-1}(x),v^{n-1}(x)$ of the previous time step at $t_{n-1}$. The next step is to also discretize the spatial variable using the usual finite element methodology. To this end, we multiply each equation with a test function, integrate over the entire domain, and integrate by parts where necessary. This leads to

        +\begin{eqnarray*}
   (u^n,\varphi) + k^2\theta^2(\nabla u^n,\nabla \varphi) &=&
   (u^{n-1},\varphi) - k^2\theta(1-\theta)(\nabla u^{n-1},\nabla \varphi)
   +
@@ -245,15 +245,15 @@
   \left[
   \theta (f^n,\varphi) + (1-\theta) (f^{n-1},\varphi)
   \right].
-\end{eqnarray*} +\end{eqnarray*}" src="form_3378.png"/>

        -

        It is then customary to approximate $u^n(x) \approx u^n_h(x) = \sum_i
-U_i^n\phi_i^n(x)$, where $\phi_i^n(x)$ are the shape functions used for the discretization of the $n$-th time step and $U_i^n$ are the unknown nodal values of the solution. Similarly, $v^n(x) \approx
-v^n_h(x) = \sum_i V_i^n\phi_i^n(x)$. Finally, we have the solutions of the previous time step, $u^{n-1}(x) \approx u^{n-1}_h(x) = \sum_i
-U_i^{n-1}\phi_i^{n-1}(x)$ and $v^{n-1}(x) \approx v^{n-1}_h(x) = \sum_i
-V_i^{n-1}\phi_i^{n-1}(x)$. Note that since the solution of the previous time step has already been computed by the time we get to time step $n$, $U^{n-1},V^{n-1}$ are known. Furthermore, note that the solutions of the previous step may have been computed on a different mesh, so we have to use shape functions $\phi^{n-1}_i(x)$.

        +

        It is then customary to approximate $u^n(x) \approx u^n_h(x) = \sum_i
+U_i^n\phi_i^n(x)$, where $\phi_i^n(x)$ are the shape functions used for the discretization of the $n$-th time step and $U_i^n$ are the unknown nodal values of the solution. Similarly, $v^n(x) \approx
+v^n_h(x) = \sum_i V_i^n\phi_i^n(x)$. Finally, we have the solutions of the previous time step, $u^{n-1}(x) \approx u^{n-1}_h(x) = \sum_i
+U_i^{n-1}\phi_i^{n-1}(x)$ and $v^{n-1}(x) \approx v^{n-1}_h(x) = \sum_i
+V_i^{n-1}\phi_i^{n-1}(x)$. Note that since the solution of the previous time step has already been computed by the time we get to time step $n$, $U^{n-1},V^{n-1}$ are known. Furthermore, note that the solutions of the previous step may have been computed on a different mesh, so we have to use shape functions $\phi^{n-1}_i(x)$.

        If we plug these expansions into above equations and test with the test functions from the present mesh, we get the following linear system:

        -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   (M^n + k^2\theta^2 A^n)U^n &=&
   M^{n,n-1}U^{n-1} - k^2\theta(1-\theta) A^{n,n-1}U^{n-1}
   +
@@ -273,10 +273,10 @@
   \left[
   \theta F^n + (1-\theta) F^{n-1}
   \right],
-\end{eqnarray*} +\end{eqnarray*}" src="form_3387.png"/>

        where

        -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
         M^n_{ij} &=& (\phi_i^n, \phi_j^n),
         \\
         A^n_{ij} &=& (\nabla\phi_i^n, \nabla\phi_j^n),
@@ -288,14 +288,14 @@
         F^n_{i} &=& (f^n,\phi_i^n),
         \\
         F^{n-1}_{i} &=& (f^{n-1},\phi_i^n).
-\end{eqnarray*} +\end{eqnarray*}" src="form_3388.png"/>

        If we solve these two equations, we can move the solution one step forward and go on to the next time step.

        -

        It is worth noting that if we choose the same mesh on each time step (as we will in fact do in the program below), then we have the same shape functions on time step $n$ and $n-1$, i.e. $\phi^n_i=\phi_i^{n-1}=\phi_i$. Consequently, we get $M^n=M^{n,n-1}=M$ and $A^n=A^{n,n-1}=A$. On the other hand, if we had used different shape functions, then we would have to compute integrals that contain shape functions defined on two meshes. This is a somewhat messy process that we omit here, but that is treated in some detail in step-28.

        +

        It is worth noting that if we choose the same mesh on each time step (as we will in fact do in the program below), then we have the same shape functions on time step $n$ and $n-1$, i.e. $\phi^n_i=\phi_i^{n-1}=\phi_i$. Consequently, we get $M^n=M^{n,n-1}=M$ and $A^n=A^{n,n-1}=A$. On the other hand, if we had used different shape functions, then we would have to compute integrals that contain shape functions defined on two meshes. This is a somewhat messy process that we omit here, but that is treated in some detail in step-28.

        Under these conditions (i.e. a mesh that doesn't change), one can optimize the solution procedure a bit by basically eliminating the solution of the second linear system. We will discuss this in the introduction of the step-25 program.

        Energy conservation

        -

        One way to compare the quality of a time stepping scheme is to see whether the numerical approximation preserves conservation properties of the continuous equation. For the wave equation, the natural quantity to look at is the energy. By multiplying the wave equation by $u_t$, integrating over $\Omega$, and integrating by parts where necessary, we find that

        -\[
+<p>One way to compare the quality of a time stepping scheme is to see whether the numerical approximation preserves conservation properties of the continuous equation. For the wave equation, the natural quantity to look at is the energy. By multiplying the wave equation by <picture><source srcset=$u_t$, integrating over $\Omega$, and integrating by parts where necessary, we find that

        +\[
         \frac{d}{d t}
         \left[\frac 12 \int_\Omega \left(\frac{\partial u}{\partial
         t}\right)^2 + (\nabla u)^2 \; dx\right]
@@ -304,34 +304,34 @@
         +
         \int_{\partial\Omega} n\cdot\nabla u
         \frac{\partial g}{\partial t} \; dx.
-\] +\]" src="form_3394.png"/>

        By consequence, in absence of body forces and constant boundary values, we get that

        -\[
+<picture><source srcset=\[
         E(t) = \frac 12 \int_\Omega \left(\frac{\partial u}{\partial
         t}\right)^2 + (\nabla u)^2 \; dx
-\] +\]" src="form_3395.png"/>

        -

        is a conserved quantity, i.e. one that doesn't change with time. We will compute this quantity after each time step. It is straightforward to see that if we replace $u$ by its finite element approximation, and $\frac{\partial u}{\partial t}$ by the finite element approximation of the velocity $v$, then

        -\[
+<p> is a conserved quantity, i.e. one that doesn't change with time. We will compute this quantity after each time step. It is straightforward to see that if we replace <picture><source srcset=$u$ by its finite element approximation, and $\frac{\partial u}{\partial t}$ by the finite element approximation of the velocity $v$, then

        +\[
         E(t_n) = \frac 12 \left<V^n, M^n V^n\right>
         +
         \frac 12 \left<U^n, A^n U^n\right>.
-\] +\]" src="form_3397.png"/>

        As we will see in the results section, the Crank-Nicolson scheme does indeed conserve the energy, whereas neither the forward nor the backward Euler scheme do.

        Who are Courant, Friedrichs, and Lewy?

        -

        One of the reasons why the wave equation is not easy to solve numerically is that explicit time discretizations are only stable if the time step is small enough. In particular, it is coupled to the spatial mesh width $h$. For the lowest order discretization we use here, the relationship reads

        -\[
+<p>One of the reasons why the wave equation is not easy to solve numerically is that explicit time discretizations are only stable if the time step is small enough. In particular, it is coupled to the spatial mesh width <picture><source srcset=$h$. For the lowest order discretization we use here, the relationship reads

        +\[
         k\le \frac hc
-\] +\]" src="form_3398.png"/>

        -

        where $c$ is the wave speed, which in our formulation of the wave equation has been normalized to one. Consequently, unless we use the implicit schemes with $\theta>0$, our solutions will not be numerically stable if we violate this restriction. Implicit schemes do not have this restriction for stability, but they become inaccurate if the time step is too large.

        +

        where $c$ is the wave speed, which in our formulation of the wave equation has been normalized to one. Consequently, unless we use the implicit schemes with $\theta>0$, our solutions will not be numerically stable if we violate this restriction. Implicit schemes do not have this restriction for stability, but they become inaccurate if the time step is too large.

        This condition was first recognized by Courant, Friedrichs, and Lewy — in 1928, long before computers became available for numerical computations! (This result appeared in the German language article R. Courant, K. Friedrichs and H. Lewy: Über die partiellen Differenzengleichungen der mathematischen Physik, Mathematische Annalen, vol. 100, no. 1, pages 32-74, 1928.) This condition on the time step is most frequently just referred to as the CFL condition. Intuitively, the CFL condition says that the time step must not be larger than the time it takes a wave to cross a single cell.

        -

        In the program, we will refine the square $[-1,1]^2$ seven times uniformly, giving a mesh size of $h=\frac 1{64}$, which is what we set the time step to. The fact that we set the time step and mesh size individually in two different places is error prone: it is too easy to refine the mesh once more but forget to also adjust the time step. step-24 shows a better way how to keep these things in sync.

        +

        In the program, we will refine the square $[-1,1]^2$ seven times uniformly, giving a mesh size of $h=\frac 1{64}$, which is what we set the time step to. The fact that we set the time step and mesh size individually in two different places is error prone: it is too easy to refine the mesh once more but forget to also adjust the time step. step-24 shows a better way how to keep these things in sync.

        The test case

        -

        Although the program has all the hooks to deal with nonzero initial and boundary conditions and body forces, we take a simple case where the domain is a square $[-1,1]^2$ and

        -\begin{eqnarray*}
+<p>Although the program has all the hooks to deal with nonzero initial and boundary conditions and body forces, we take a simple case where the domain is a square <picture><source srcset=$[-1,1]^2$ and

        +\begin{eqnarray*}
         f &=& 0,
         \\
         u_0 &=& 0,
@@ -345,7 +345,7 @@
/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_24.html differs (HTML document, UTF-8 Unicode text, with very long lines)
--- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_24.html	2023-08-09 23:38:59.218632466 +0000
+++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_24.html	2023-08-09 23:38:59.218632466 +0000
@@ -129,101 +129,101 @@
 <p><a class=

        The problem

        The temperature at a given location, neglecting thermal diffusion, can be stated as

        -\[
+<picture><source srcset=\[
 \rho C_p \frac{\partial}{\partial t}T(t,\mathbf r) = H(t,\mathbf r)
-\] +\]" src="form_3429.png"/>

        -

        Here $\rho (\mathbf r) $ is the density; $C_p (\mathbf r) $ is the specific heat; $\frac{\partial T}{\partial t}(t,\mathbf r)$ is the temperature rise due to the delivered microwave energy; and $H(t,\mathbf r)$ is the heating function defined as the thermal energy per time and volume transformed from deposited microwave energy.

        -

        Let us assume that tissues have heterogeneous dielectric properties but homogeneous acoustic properties. The basic acoustic generation equation in an acoustically homogeneous medium can be described as follows: if $u$ is the vector-valued displacement, then tissue certainly reacts to changes in pressure by acceleration:

        -\[
+<p>Here <picture><source srcset=$\rho (\mathbf r) $ is the density; $C_p (\mathbf r) $ is the specific heat; $\frac{\partial T}{\partial t}(t,\mathbf r)$ is the temperature rise due to the delivered microwave energy; and $H(t,\mathbf r)$ is the heating function defined as the thermal energy per time and volume transformed from deposited microwave energy.

        +

        Let us assume that tissues have heterogeneous dielectric properties but homogeneous acoustic properties. The basic acoustic generation equation in an acoustically homogeneous medium can be described as follows: if $u$ is the vector-valued displacement, then tissue certainly reacts to changes in pressure by acceleration:

        +\[
 \rho \frac{\partial^2}{\partial t^2}u(t,\mathbf r) =
 -\nabla p(t,\mathbf r).
-\] +\]" src="form_3434.png"/>

        Furthermore, it contracts due to excess pressure and expands based on changes in temperature:

        -\[
+<picture><source srcset=\[
 \nabla \cdot u(t,\mathbf r) = -\frac{p(t,\mathbf r)}{\rho c_0^2}+\beta T(t,\mathbf r) .
-\] +\]" src="form_3435.png"/>

        Here, $\beta$ is a thermoexpansion coefficient.

        -

        Let us now make the assumption that heating only happens on a time scale much shorter than wave propagation through tissue (i.e. the temporal length of the microwave pulse that heats the tissue is much shorter than the time it takes a wave to cross the domain). In that case, the heating rate $H(t,\mathbf r)$ can be written as $H(t,\mathbf r) = a(\mathbf
-r)\delta(t)$ (where $a(\mathbf r)$ is a map of absorption strengths for microwave energy and $\delta(t)$ is the Dirac delta function), which together with the first equation above will yield an instantaneous jump in the temperature $T(\mathbf r)$ at time $t=0$. Using this assumption, and taking all equations together, we can rewrite and combine the above as follows:

        -\[
+<p>Let us now make the assumption that heating only happens on a time scale much shorter than wave propagation through tissue (i.e. the temporal length of the microwave pulse that heats the tissue is much shorter than the time it takes a wave to cross the domain). In that case, the heating rate <picture><source srcset=$H(t,\mathbf r)$ can be written as $H(t,\mathbf r) = a(\mathbf
+r)\delta(t)$ (where $a(\mathbf r)$ is a map of absorption strengths for microwave energy and $\delta(t)$ is the Dirac delta function), which together with the first equation above will yield an instantaneous jump in the temperature $T(\mathbf r)$ at time $t=0$. Using this assumption, and taking all equations together, we can rewrite and combine the above as follows:

        +\[
 \Delta p-\frac{1}{c_0^2} \frac{\partial^2 p}{\partial t^2} = \lambda
 a(\mathbf r)\frac{d\delta(t)}{dt}
-\] +\]" src="form_3440.png"/>

        -

        where $\lambda = - \frac{\beta}{C_p}$.

        +

        where $\lambda = - \frac{\beta}{C_p}$.

        This somewhat strange equation with the derivative of a Dirac delta function on the right hand side can be rewritten as an initial value problem as follows:

        -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
 \Delta \bar{p}- \frac{1}{c_0^2} \frac{\partial^2 \bar{p}}{\partial t^2} & = &
 0 \\
 \bar{p}(0,\mathbf r) &=& c_0^2 \lambda a(\mathbf r) = b(\mathbf r)  \\
 \frac{\partial\bar{p}(0,\mathbf r)}{\partial t} &=& 0.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3442.png"/>

        (A derivation of this transformation into an initial value problem is given at the end of this introduction as an appendix.)

        -

        In the inverse problem, it is the initial condition $b(\mathbf r) = c_0^2 \lambda a(\mathbf r)$ that one would like to recover, since it is a map of absorption strengths for microwave energy, and therefore presumably an indicator to discern healthy from diseased tissue.

        +

        In the inverse problem, it is the initial condition $b(\mathbf r) = c_0^2 \lambda a(\mathbf r)$ that one would like to recover, since it is a map of absorption strengths for microwave energy, and therefore presumably an indicator to discern healthy from diseased tissue.

        In real application, the thermoacoustic source is very small as compared to the medium. The propagation path of the thermoacoustic waves can then be approximated as from the source to the infinity. Furthermore, detectors are only a limited distance from the source. One only needs to evaluate the values when the thermoacoustic waves pass through the detectors, although they do continue beyond. This is therefore a problem where we are only interested in a small part of an infinite medium, and we do not want waves generated somewhere to be reflected at the boundary of the domain which we consider interesting. Rather, we would like to simulate only that part of the wave field that is contained inside the domain of interest, and waves that hit the boundary of that domain to simply pass undisturbed through the boundary. In other words, we would like the boundary to absorb any waves that hit it.

        In general, this is a hard problem: Good absorbing boundary conditions are nonlinear and/or numerically very expensive. We therefore opt for a simple first order approximation to absorbing boundary conditions that reads

        -\[
+<picture><source srcset=\[
 \frac{\partial\bar{p}}{\partial\mathbf n} =
 -\frac{1}{c_0} \frac{\partial\bar{p}}{\partial t}
-\] +\]" src="form_3444.png"/>

        -

        Here, $\frac{\partial\bar{p}}{\partial\mathbf n}$ is the normal derivative at the boundary. It should be noted that this is not a particularly good boundary condition, but it is one of the very few that are reasonably simple to implement.

        +

        Here, $\frac{\partial\bar{p}}{\partial\mathbf n}$ is the normal derivative at the boundary. It should be noted that this is not a particularly good boundary condition, but it is one of the very few that are reasonably simple to implement.

        Weak form and discretization

        As in step-23, one first introduces a second variable, which is defined as the derivative of the pressure potential:

        -\[
+<picture><source srcset=\[
 v = \frac{\partial\bar{p}}{\partial t}
-\] +\]" src="form_3446.png"/>

        With the second variable, one then transforms the forward problem into two separate equations:

        -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
 \bar{p}_{t} - v & = & 0 \\
 \Delta\bar{p} - \frac{1}{c_0^2}\,v_{t} & = & f
-\end{eqnarray*} +\end{eqnarray*}" src="form_3447.png"/>

        with initial conditions:

        -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
 \bar{p}(0,\mathbf r) & = & b(r) \\
 v(0,\mathbf r)=\bar{p}_t(0,\mathbf r) & = & 0.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3448.png"/>

        -

        Note that we have introduced a right hand side $f(t,\mathbf r)$ here to show how to derive these formulas in the general case, although in the application to the thermoacoustic problem $f=0$.

        -

        The semi-discretized, weak version of this model, using the general $\theta$ scheme introduced in step-23 is then:

        -\begin{eqnarray*}
+<p> Note that we have introduced a right hand side <picture><source srcset=$f(t,\mathbf r)$ here to show how to derive these formulas in the general case, although in the application to the thermoacoustic problem $f=0$.

        +

        The semi-discretized, weak version of this model, using the general $\theta$ scheme introduced in step-23 is then:

        +\begin{eqnarray*}
 \left(\frac{\bar{p}^n-\bar{p}^{n-1}}{k},\phi\right)_\Omega-
 \left(\theta v^{n}+(1-\theta)v^{n-1},\phi\right)_\Omega & = & 0   \\
 -\left(\nabla((\theta\bar{p}^n+(1-\theta)\bar{p}^{n-1})),\nabla\phi\right)_\Omega-
 \frac{1}{c_0}\left(\frac{\bar{p}^n-\bar{p}^{n-1}}{k},\phi\right)_{\partial\Omega} -
 \frac{1}{c_0^2}\left(\frac{v^n-v^{n-1}}{k},\phi\right)_\Omega & =
 & \left(\theta f^{n}+(1-\theta)f^{n-1}, \phi\right)_\Omega,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3450.png"/>

        -

        where $\phi$ is an arbitrary test function, and where we have used the absorbing boundary condition to integrate by parts: absorbing boundary conditions are incorporated into the weak form by using

        -\[
+<p> where <picture><source srcset=$\phi$ is an arbitrary test function, and where we have used the absorbing boundary condition to integrate by parts: absorbing boundary conditions are incorporated into the weak form by using

        +\[
 \int_\Omega\varphi \, \Delta p\; dx =
 -\int_\Omega\nabla \varphi \cdot \nabla p dx +
 \int_{\partial\Omega}\varphi \frac{\partial p}{\partial {\mathbf n}}ds.
-\] +\]" src="form_3451.png"/>

        From this we obtain the discrete model by introducing a finite number of shape functions, and get

        -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
 M\bar{p}^{n}-k \theta M v^n & = & M\bar{p}^{n-1}+k (1-\theta)Mv^{n-1},\\
 
 (-c_0^2k \theta A-c_0 B)\bar{p}^n-Mv^{n} & = &
 (c_0^2k(1-\theta)A-c_0B)\bar{p}^{n-1}-Mv^{n-1}+c_0^2k(\theta F^{n}+(1-\theta)F^{n-1}).
-\end{eqnarray*} +\end{eqnarray*}" src="form_3452.png"/>

        -

        The matrices $M$ and $A$ are here as in step-23, and the boundary mass matrix

        -\[
+<p> The matrices <picture><source srcset=$M$ and $A$ are here as in step-23, and the boundary mass matrix

        +\[
         B_{ij} = \left(\varphi_i,\varphi_j\right)_{\partial\Omega}
-\] +\]" src="form_3453.png"/>

        results from the use of absorbing boundary conditions.

        Above two equations can be rewritten in a matrix form with the pressure and its derivative as an unknown vector:

        -\[
+<picture><source srcset=\[
 \left(\begin{array}{cc}
  M         &       -k\theta M \\
 c_0^2\,k\,\theta\,A+c_0\,B  &  M   \\
@@ -236,10 +236,10 @@
  G_1  \\
  G_2 -(\theta F^{n}+(1-\theta)F ^{n-1})c_{0}^{2}k \\
                 \end{array}\right)
-\] +\]" src="form_3454.png"/>

        where

        -\[
+<picture><source srcset=\[
 \left(\begin{array}{c}
 G_1 \\
 G_2 \\
@@ -248,115 +248,115 @@
  M\bar{p}^{n-1}+k(1-\theta)Mv^{n-1}\\
  (-c_{0}^{2}k (1-\theta)A+c_0 B)\bar{p}^{n-1} +Mv^{n-1}
                 \end{array}\right)
-\] +\]" src="form_3455.png"/>

        By simple transformations, one then obtains two equations for the pressure potential and its derivative, just as in the previous tutorial program:

        -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
 (M+(k\,\theta\,c_{0})^{2}A+c_0k\theta B)\bar{p}^{n} & = &
 G_{1}+(k\, \theta)G_{2}-(c_0k)^2\theta (\theta F^{n}+(1-\theta)F^{n-1}) \\
 Mv^n & = & -(c_0^2\,k\, \theta\, A+c_0B)\bar{p}^{n}+ G_2 -
 c_0^2k(\theta F^{n}+(1-\theta)F^{n-1})
-\end{eqnarray*} +\end{eqnarray*}" src="form_3456.png"/>

        What the program does

        Compared to step-23, this programs adds the treatment of a simple absorbing boundary conditions. In addition, it deals with data obtained from actual experimental measurements. To this end, we need to evaluate the solution at points at which the experiment also evaluates a real pressure field. We will see how to do that using the VectorTools::point_value function further down below.

        Appendix: PDEs with Dirac delta functions as right hand side and their transformation to an initial value problem

        In the derivation of the initial value problem for the wave equation, we initially found that the equation had the derivative of a Dirac delta function as a right hand side:

        -\[
+<picture><source srcset=\[
 \Delta p-\frac{1}{c_0^2} \frac{\partial^2 p}{\partial t^2} = \lambda
 a(\mathbf r)\frac{d\delta(t)}{dt}.
-\] +\]" src="form_3457.png"/>

        -

        In order to see how to transform this single equation into the usual statement of a PDE with initial conditions, let us make the assumption that the physically quite reasonable medium is at rest initially, i.e. $p(t,\mathbf
-r)=\frac{\partial p(t,\mathbf r)}{\partial t}=0$ for $t<0$. Next, let us form the indefinite integral with respect to time of both sides:

        -\[
+<p> In order to see how to transform this single equation into the usual statement of a PDE with initial conditions, let us make the assumption that the physically quite reasonable medium is at rest initially, i.e. <picture><source srcset=$p(t,\mathbf
+r)=\frac{\partial p(t,\mathbf r)}{\partial t}=0$ for $t<0$. Next, let us form the indefinite integral with respect to time of both sides:

        +\[
 \int^t \Delta p\; dt -\int^t \frac{1}{c_0^2} \frac{\partial^2 p}{\partial t^2}
 \; dt
 =
 \int^t \lambda a(\mathbf r)\frac{d\delta(t)}{dt} \;dt.
-\] +\]" src="form_3460.png"/>

        This immediately leads to the statement

        -\[
+<picture><source srcset=\[
 P(t,\mathbf r) - \frac{1}{c_0^2} \frac{\partial p}{\partial t}
/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_25.html differs (HTML document, UTF-8 Unicode text, with very long lines)
--- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_25.html	2023-08-09 23:38:59.270632854 +0000
+++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_25.html	2023-08-09 23:38:59.270632854 +0000
@@ -151,14 +151,14 @@
 \end{eqnarray*}

        Discretization of the equations in time

        -

        Now, we can discretize the split formulation in time using the $\theta$-method, which has a stencil of only two time steps. By choosing a $\theta\in [0,1]$, the latter discretization allows us to choose from a continuum of schemes. In particular, if we pick $\theta=0$ or $\theta=1$, we obtain the first-order accurate explicit or implicit Euler method, respectively. Another important choice is $\theta=\frac{1}{2}$, which gives the second-order accurate Crank-Nicolson scheme. Henceforth, a superscript $n$ denotes the values of the variables at the $n^{\mathrm{th}}$ time step, i.e. at $t=t_n \dealcoloneq n k$, where $k$ is the (fixed) time step size. Thus, the split formulation of the time-discretized sine-Gordon equation becomes

        +

        Now, we can discretize the split formulation in time using the $\theta$-method, which has a stencil of only two time steps. By choosing a $\theta\in [0,1]$, the latter discretization allows us to choose from a continuum of schemes. In particular, if we pick $\theta=0$ or $\theta=1$, we obtain the first-order accurate explicit or implicit Euler method, respectively. Another important choice is $\theta=\frac{1}{2}$, which gives the second-order accurate Crank-Nicolson scheme. Henceforth, a superscript $n$ denotes the values of the variables at the $n^{\mathrm{th}}$ time step, i.e. at $t=t_n \dealcoloneq n k$, where $k$ is the (fixed) time step size. Thus, the split formulation of the time-discretized sine-Gordon equation becomes

        \begin{eqnarray*}
   \frac{u^n - u^{n-1}}{k} - \left[\theta v^n + (1-\theta) v^{n-1}\right] &=& 0,\\
   \frac{v^n - v^{n-1}}{k} - \Delta\left[\theta u^n + (1-\theta) u^{n-1}\right]
   &=& -\sin\left[\theta u^n + (1-\theta) u^{n-1}\right].
 \end{eqnarray*}

        -

        We can simplify the latter via a bit of algebra. Eliminating $v^n$ from the first equation and rearranging, we obtain

        +

        We can simplify the latter via a bit of algebra. Eliminating $v^n$ from the first equation and rearranging, we obtain

        \begin{eqnarray*}
   \left[ 1-k^2\theta^2\Delta \right] u^n &=&
          \left[ 1+k^2\theta(1-\theta)\Delta\right] u^{n-1} + k v^{n-1}
@@ -167,8 +167,8 @@
          - k\sin\left[ \theta u^n + (1-\theta) u^{n-1} \right].
 \end{eqnarray*}

        -

        It may seem as though we can just proceed to discretize the equations in space at this point. While this is true for the second equation (which is linear in $v^n$), this would not work for all $\theta$ since the first equation above is nonlinear. Therefore, a nonlinear solver must be implemented, then the equations can be discretized in space and solved.

        -

        To this end, we can use Newton's method. Given the nonlinear equation $F(u^n) = 0$, we produce successive approximations to $u^n$ as follows:

        +

        It may seem as though we can just proceed to discretize the equations in space at this point. While this is true for the second equation (which is linear in $v^n$), this would not work for all $\theta$ since the first equation above is nonlinear. Therefore, a nonlinear solver must be implemented, then the equations can be discretized in space and solved.

        +

        To this end, we can use Newton's method. Given the nonlinear equation $F(u^n) = 0$, we produce successive approximations to $u^n$ as follows:

        \begin{eqnarray*}
   \mbox{ Find } \delta u^n_l \mbox{ s.t. } F'(u^n_l)\delta u^n_l = -F(u^n_l)
   \mbox{, set }  u^n_{l+1} = u^n_l + \delta u^n_l.
@@ -185,7 +185,7 @@
 </p>
 <p> Notice that while <picture><source srcset=$F(u^n_l)$ is a function, $F'(u^n_l)$ is an operator.

        Weak formulation of the time-discretized equations

        -

        With hindsight, we choose both the solution and the test space to be $H^1(\Omega)$. Hence, multiplying by a test function $\varphi$ and integrating, we obtain the following variational (or weak) formulation of the split formulation (including the nonlinear solver for the first equation) at each time step:

        +

        With hindsight, we choose both the solution and the test space to be $H^1(\Omega)$. Hence, multiplying by a test function $\varphi$ and integrating, we obtain the following variational (or weak) formulation of the split formulation (including the nonlinear solver for the first equation) at each time step:

        \begin{eqnarray*}
   &\mbox{ Find}& \delta u^n_l \in H^1(\Omega) \mbox{ s.t. }
   \left( F'(u^n_l)\delta u^n_l, \varphi \right)_{\Omega}
@@ -199,10 +199,10 @@
          \varphi \right)_{\Omega} \;\forall\varphi\in H^1(\Omega).
 \end{eqnarray*}

        -

        Note that the we have used integration by parts and the zero Neumann boundary conditions on all terms involving the Laplacian operator. Moreover, $F(\cdot)$ and $F'(\cdot)$ are as defined above, and $(\cdot,\cdot)_{\Omega}$ denotes the usual $L^2$ inner product over the domain $\Omega$, i.e. $(f,g)_{\Omega} = \int_\Omega fg
+<p> Note that the we have used integration by parts and the zero Neumann boundary conditions on all terms involving the Laplacian operator. Moreover, <picture><source srcset=$F(\cdot)$ and $F'(\cdot)$ are as defined above, and $(\cdot,\cdot)_{\Omega}$ denotes the usual $L^2$ inner product over the domain $\Omega$, i.e. $(f,g)_{\Omega} = \int_\Omega fg
 \,\mathrm{d}x$. Finally, notice that the first equation is, in fact, the definition of an iterative procedure, so it is solved multiple times during each time step until a stopping criterion is met.

        Discretization of the weak formulation in space

        -

        Using the Finite Element Method, we discretize the variational formulation in space. To this end, let $V_h$ be a finite-dimensional $H^1(\Omega)$-conforming finite element space ( $\mathrm{dim}\, V_h = N
+<p>Using the Finite Element Method, we discretize the variational formulation in space. To this end, let <picture><source srcset=$V_h$ be a finite-dimensional $H^1(\Omega)$-conforming finite element space ( $\mathrm{dim}\, V_h = N
 < \infty$) with nodal basis $\{\varphi_1,\ldots,\varphi_N\}$. Now, we can expand all functions in the weak formulation (see above) in terms of the nodal basis. Henceforth, we shall denote by a capital letter the vector of coefficients (in the nodal basis) of a function denoted by the same letter in lower case; e.g., $u^n = \sum_{i=1}^N
 U^n_i \varphi_i$ where $U^n \in {R}^N$ and $u^n \in
 H^1(\Omega)$. Thus, the finite-dimensional version of the variational formulation requires that we solve the following matrix equations at each time step:

        @@ -221,9 +221,9 @@ + k^2\theta^2N(u^n_l,u^{n-1}) \end{eqnarray*}" src="form_3524.png"/>

        -

        Again, note that the first matrix equation above is, in fact, the definition of an iterative procedure, so it is solved multiple times until a stopping criterion is met. Moreover, $M$ is the mass matrix, i.e. $M_{ij} = \left( \varphi_i,\varphi_j \right)_{\Omega}$, $A$ is the Laplace matrix, i.e. $A_{ij} = \left( \nabla \varphi_i, \nabla
+<p> Again, note that the first matrix equation above is, in fact, the definition of an iterative procedure, so it is solved multiple times until a stopping criterion is met. Moreover, <picture><source srcset=$M$ is the mass matrix, i.e. $M_{ij} = \left( \varphi_i,\varphi_j \right)_{\Omega}$, $A$ is the Laplace matrix, i.e. $A_{ij} = \left( \nabla \varphi_i, \nabla
 \varphi_j \right)_{\Omega}$, $S$ is the nonlinear term in the equation that defines our auxiliary velocity variable, i.e. $S_j(f,g) = \left(
-  \sin\left[ \theta f + (1-\theta) g\right], \varphi_j \right)_{\Omega}$, and $N$ is the nonlinear term in the Jacobian matrix of $F(\cdot)$, i.e. $N_{ij}(f,g) = \left( \cos\left[ \theta f + (1-\theta) g\right]\varphi_i,
+  \sin\left[ \theta f + (1-\theta) g\right], \varphi_j \right)_{\Omega}$, and $N$ is the nonlinear term in the Jacobian matrix of $F(\cdot)$, i.e. $N_{ij}(f,g) = \left( \cos\left[ \theta f + (1-\theta) g\right]\varphi_i,
   \varphi_j \right)_{\Omega}$.

        What solvers can we use for the first equation? Let's look at the matrix we have to invert:

        \[
@@ -233,12 +233,12 @@
   + k^2 \theta^2 \int_\Omega \nabla\varphi_i\nabla\varphi_j \; dx,
 \]

        -

        for some $\alpha$ that depends on the present and previous solution. First, note that the matrix is symmetric. In addition, if the time step $k$ is small enough, i.e. if $k\theta<1$, then the matrix is also going to be positive definite. In the program below, this will always be the case, so we will use the Conjugate Gradient method together with the SSOR method as preconditioner. We should keep in mind, however, that this will fail if we happen to use a bigger time step. Fortunately, in that case the solver will just throw an exception indicating a failure to converge, rather than silently producing a wrong result. If that happens, then we can simply replace the CG method by something that can handle indefinite symmetric systems. The GMRES solver is typically the standard method for all "bad" linear systems, but it is also a slow one. Possibly better would be a solver that utilizes the symmetry, such as, for example, SymmLQ, which is also implemented in deal.II.

        -

        This program uses a clever optimization over step-23 and step-24: If you read the above formulas closely, it becomes clear that the velocity $V$ only ever appears in products with the mass matrix. In step-23 and step-24, we were, therefore, a bit wasteful: in each time step, we would solve a linear system with the mass matrix, only to multiply the solution of that system by $M$ again in the next time step. This can, of course, be avoided, and we do so in this program.

        +

        for some $\alpha$ that depends on the present and previous solution. First, note that the matrix is symmetric. In addition, if the time step $k$ is small enough, i.e. if $k\theta<1$, then the matrix is also going to be positive definite. In the program below, this will always be the case, so we will use the Conjugate Gradient method together with the SSOR method as preconditioner. We should keep in mind, however, that this will fail if we happen to use a bigger time step. Fortunately, in that case the solver will just throw an exception indicating a failure to converge, rather than silently producing a wrong result. If that happens, then we can simply replace the CG method by something that can handle indefinite symmetric systems. The GMRES solver is typically the standard method for all "bad" linear systems, but it is also a slow one. Possibly better would be a solver that utilizes the symmetry, such as, for example, SymmLQ, which is also implemented in deal.II.

        +

        This program uses a clever optimization over step-23 and step-24: If you read the above formulas closely, it becomes clear that the velocity $V$ only ever appears in products with the mass matrix. In step-23 and step-24, we were, therefore, a bit wasteful: in each time step, we would solve a linear system with the mass matrix, only to multiply the solution of that system by $M$ again in the next time step. This can, of course, be avoided, and we do so in this program.

        The test case

        There are a few analytical solutions for the sine-Gordon equation, both in 1D and 2D. In particular, the program as is computes the solution to a problem with a single kink-like solitary wave initial condition. This solution is given by Leibbrandt in Phys. Rev. Lett. 41(7), and is implemented in the ExactSolution class.

        It should be noted that this closed-form solution, strictly speaking, only holds for the infinite-space initial-value problem (not the Neumann initial-boundary-value problem under consideration here). However, given that we impose zero Neumann boundary conditions, we expect that the solution to our initial-boundary-value problem would be close to the solution of the infinite-space initial-value problem, if reflections of waves off the boundaries of our domain do not occur. In practice, this is of course not the case, but we can at least assume that this were so.

        -

        The constants $\vartheta$ and $\lambda$ in the 2D solution and $\vartheta$, $\phi$ and $\tau$ in the 3D solution are called the Bäcklund transformation parameters. They control such things as the orientation and steepness of the kink. For the purposes of testing the code against the exact solution, one should choose the parameters so that the kink is aligned with the grid.

        +

        The constants $\vartheta$ and $\lambda$ in the 2D solution and $\vartheta$, $\phi$ and $\tau$ in the 3D solution are called the Bäcklund transformation parameters. They control such things as the orientation and steepness of the kink. For the purposes of testing the code against the exact solution, one should choose the parameters so that the kink is aligned with the grid.

        The solutions that we implement in the ExactSolution class are these:

        • In 1D:

          @@ -261,7 +261,7 @@ u(x,y,t) = 4 \arctan \left[a_0 e^{s\xi}\right], \]" src="form_3534.png"/>

          -

          where $\xi$ is defined as

          +

          where $\xi$ is defined as

          \[
     \xi = x \cos\vartheta + \sin(\vartheta) (y\cosh\lambda + t\sinh \lambda),
   \] @@ -275,7 +275,7 @@ u(x,y,z,t) = 4 \arctan \left[c_0 e^{s\xi}\right], \]" src="form_3537.png"/>

          - where $\xi$ is defined as

          + where $\xi$ is defined as

          \[
     \xi = x \cos\vartheta + y \sin \vartheta \cos\phi +
           \sin \vartheta \sin\phi (z\cosh\tau + t\sinh \tau),
@@ -327,7 +327,7 @@
 <p>The entire algorithm for solving the problem is encapsulated in this class. As in previous example programs, the class is declared with a template parameter, which is the spatial dimension, so that we can solve the sine-Gordon equation in one, two or three spatial dimensions. For more on the dimension-independent class-encapsulation of the problem, the reader should consult <a class=step-3 and step-4.

          Compared to step-23 and step-24, there isn't anything newsworthy in the general structure of the program (though there is of course in the inner workings of the various functions!). The most notable difference is the presence of the two new functions compute_nl_term and compute_nl_matrix that compute the nonlinear contributions to the system matrix and right-hand side of the first equation, as discussed in the Introduction. In addition, we have to have a vector solution_update that contains the nonlinear update to the solution vector in each Newton step.

          As also mentioned in the introduction, we do not store the velocity variable in this program, but the mass matrix times the velocity. This is done in the M_x_velocity variable (the "x" is intended to stand for "times").

          -

          Finally, the output_timestep_skip variable stores the number of time steps to be taken each time before graphical output is to be generated. This is of importance when using fine meshes (and consequently small time steps) where we would run lots of time steps and create lots of output files of solutions that look almost the same in subsequent files. This only clogs up our visualization procedures and we should avoid creating more output than we are really interested in. Therefore, if this variable is set to a value $n$ bigger than one, output is generated only every $n$th time step.

          +

          Finally, the output_timestep_skip variable stores the number of time steps to be taken each time before graphical output is to be generated. This is of importance when using fine meshes (and consequently small time steps) where we would run lots of time steps and create lots of output files of solutions that look almost the same in subsequent files. This only clogs up our visualization procedures and we should avoid creating more output than we are really interested in. Therefore, if this variable is set to a value $n$ bigger than one, output is generated only every $n$th time step.

            template <int dim>
            class SineGordonProblem
            {
          @@ -470,8 +470,8 @@

          Implementation of the SineGordonProblem class

          Let's move on to the implementation of the main class, as it implements the algorithm outlined in the introduction.

          SineGordonProblem::SineGordonProblem

          -

          This is the constructor of the SineGordonProblem class. It specifies the desired polynomial degree of the finite elements, associates a DoFHandler to the triangulation object (just as in the example programs step-3 and step-4), initializes the current or initial time, the final time, the time step size, and the value of $\theta$ for the time stepping scheme. Since the solutions we compute here are time-periodic, the actual value of the start-time doesn't matter, and we choose it so that we start at an interesting time.

          -

          Note that if we were to chose the explicit Euler time stepping scheme ( $\theta = 0$), then we must pick a time step $k \le h$, otherwise the scheme is not stable and oscillations might arise in the solution. The Crank-Nicolson scheme ( $\theta = \frac{1}{2}$) and the implicit Euler scheme ( $\theta=1$) do not suffer from this deficiency, since they are unconditionally stable. However, even then the time step should be chosen to be on the order of $h$ in order to obtain a good solution. Since we know that our mesh results from the uniform subdivision of a rectangle, we can compute that time step easily; if we had a different domain, the technique in step-24 using GridTools::minimal_cell_diameter would work as well.

          +

          This is the constructor of the SineGordonProblem class. It specifies the desired polynomial degree of the finite elements, associates a DoFHandler to the triangulation object (just as in the example programs step-3 and step-4), initializes the current or initial time, the final time, the time step size, and the value of $\theta$ for the time stepping scheme. Since the solutions we compute here are time-periodic, the actual value of the start-time doesn't matter, and we choose it so that we start at an interesting time.

          +

          Note that if we were to chose the explicit Euler time stepping scheme ( $\theta = 0$), then we must pick a time step $k \le h$, otherwise the scheme is not stable and oscillations might arise in the solution. The Crank-Nicolson scheme ( $\theta = \frac{1}{2}$) and the implicit Euler scheme ( $\theta=1$) do not suffer from this deficiency, since they are unconditionally stable. However, even then the time step should be chosen to be on the order of $h$ in order to obtain a good solution. Since we know that our mesh results from the uniform subdivision of a rectangle, we can compute that time step easily; if we had a different domain, the technique in step-24 using GridTools::minimal_cell_diameter would work as well.

            template <int dim>
            SineGordonProblem<dim>::SineGordonProblem()
            : fe(1)
          @@ -486,7 +486,7 @@
           
          STL namespace.

          SineGordonProblem::make_grid_and_dofs

          -

          This function creates a rectangular grid in dim dimensions and refines it several times. Also, all matrix and vector members of the SineGordonProblem class are initialized to their appropriate sizes once the degrees of freedom have been assembled. Like step-24, we use MatrixCreator functions to generate a mass matrix $M$ and a Laplace matrix $A$ and store them in the appropriate variables for the remainder of the program's life.

          +

          This function creates a rectangular grid in dim dimensions and refines it several times. Also, all matrix and vector members of the SineGordonProblem class are initialized to their appropriate sizes once the degrees of freedom have been assembled. Like step-24, we use MatrixCreator functions to generate a mass matrix $M$ and a Laplace matrix $A$ and store them in the appropriate variables for the remainder of the program's life.

            template <int dim>
            void SineGordonProblem<dim>::make_grid_and_dofs()
            {
          @@ -762,7 +762,7 @@
            << "advancing to t = " << time << '.' << std::endl;
           

          At the beginning of each time step we must solve the nonlinear equation in the split formulation via Newton's method — i.e. solve for $\delta U^{n,l}$ then compute $U^{n,l+1}$ and so on. The stopping criterion for this nonlinear iteration is that $\|F_h(U^{n,l})\|_2 \le 10^{-6} \|F_h(U^{n,0})\|_2$. Consequently, we need to record the norm of the residual in the first iteration.

          -

          At the end of each iteration, we output to the console how many linear solver iterations it took us. When the loop below is done, we have (an approximation of) $U^n$.

          +

          At the end of each iteration, we output to the console how many linear solver iterations it took us. When the loop below is done, we have (an approximation of) $U^n$.

            double initial_rhs_norm = 0.;
            bool first_iteration = true;
            do
          @@ -786,7 +786,7 @@
           
            std::cout << " CG iterations per nonlinear step." << std::endl;
           
          -

          Upon obtaining the solution to the first equation of the problem at $t=t_n$, we must update the auxiliary velocity variable $V^n$. However, we do not compute and store $V^n$ since it is not a quantity we use directly in the problem. Hence, for simplicity, we update $MV^n$ directly:

          +

    Upon obtaining the solution to the first equation of the problem at $t=t_n$, we must update the auxiliary velocity variable $V^n$. However, we do not compute and store $V^n$ since it is not a quantity we use directly in the problem. Hence, for simplicity, we update $MV^n$ directly:

      Vector<double> tmp_vector(solution.size());
      laplace_matrix.vmult(tmp_vector, solution);
      M_x_velocity.add(-time_step * theta, tmp_vector);
    @@ -845,7 +845,7 @@
      return 0;
      }

    Results

    -

    The explicit Euler time stepping scheme ( $\theta=0$) performs adequately for the problems we wish to solve. Unfortunately, a rather small time step has to be chosen due to stability issues — $k\sim h/10$ appears to work for most the simulations we performed. On the other hand, the Crank-Nicolson scheme ( $\theta=\frac{1}{2}$) is unconditionally stable, and (at least for the case of the 1D breather) we can pick the time step to be as large as $25h$ without any ill effects on the solution. The implicit Euler scheme ( $\theta=1$) is "exponentially damped," so it is not a good choice for solving the sine-Gordon equation, which is conservative. However, some of the damped schemes in the continuum that is offered by the $\theta$-method were useful for eliminating spurious oscillations due to boundary effects.

    +

    The explicit Euler time stepping scheme ( $\theta=0$) performs adequately for the problems we wish to solve. Unfortunately, a rather small time step has to be chosen due to stability issues — $k\sim h/10$ appears to work for most the simulations we performed. On the other hand, the Crank-Nicolson scheme ( $\theta=\frac{1}{2}$) is unconditionally stable, and (at least for the case of the 1D breather) we can pick the time step to be as large as $25h$ without any ill effects on the solution. The implicit Euler scheme ( $\theta=1$) is "exponentially damped," so it is not a good choice for solving the sine-Gordon equation, which is conservative. However, some of the damped schemes in the continuum that is offered by the $\theta$-method were useful for eliminating spurious oscillations due to boundary effects.

    In the simulations below, we solve the sine-Gordon equation on the interval $\Omega =
 [-10,10]$ in 1D and on the square $\Omega = [-10,10]\times [-10,10]$ in 2D. In each case, the respective grid is refined uniformly 6 times, i.e. $h\sim
 2^{-6}$.

    @@ -855,7 +855,7 @@ u_{\mathrm{breather}}(x,t) = -4\arctan \left(\frac{m}{\sqrt{1-m^2}} \frac{\sin\left(\sqrt{1-m^2}t +c_2\right)}{\cosh(mx+c_1)} \right), \]" src="form_3569.png"/>

    -

    where $c_1$, $c_2$ and $m<1$ are constants. In the simulation below, we have chosen $c_1=0$, $c_2=0$, $m=0.5$. Moreover, it is know that the period of oscillation of the breather is $2\pi\sqrt{1-m^2}$, hence we have chosen $t_0=-5.4414$ and $t_f=2.7207$ so that we can observe three oscillations of the solution. Then, taking $u_0(x) = u_{\mathrm{breather}}(x,t_0)$, $\theta=0$ and $k=h/10$, the program computed the following solution.

    +

    where $c_1$, $c_2$ and $m<1$ are constants. In the simulation below, we have chosen $c_1=0$, $c_2=0$, $m=0.5$. Moreover, it is know that the period of oscillation of the breather is $2\pi\sqrt{1-m^2}$, hence we have chosen $t_0=-5.4414$ and $t_f=2.7207$ so that we can observe three oscillations of the solution. Then, taking $u_0(x) = u_{\mathrm{breather}}(x,t_0)$, $\theta=0$ and $k=h/10$, the program computed the following solution.

    Animation of the 1D stationary breather.

    Though not shown how to do this in the program, another way to visualize the (1+1)-d solution is to use output generated by the DataOutStack class; it allows to "stack" the solutions of individual time steps, so that we get 2D space-time graphs from 1D time-dependent solutions. This produces the space-time plot below instead of the animation above.

    A space-time plot of the 1D stationary breather.

    @@ -875,7 +875,7 @@

    The simulation shown below was performed with $u_0(x) = u_{\mathrm{kink}}(x,t_0)$, $\theta=\frac{1}{2}$, $k=20h$, $t_0=1$ and $t_f=500$. The $L^2$ norm of the error of the finite element solution at each time step remained on the order of $10^{-2}$, showing that the program is working correctly in 2D, as well as 1D. Unfortunately, the solution is not very interesting, nonetheless we have included a snapshot of it below for completeness.

    Stationary 2D kink.

    Now that we have validated the code in 1D and 2D, we move to a problem where the analytical solution is unknown.

    -

    To this end, we rotate the kink solution discussed above about the $z$ axis: we let $\vartheta=\frac{\pi}{4}$. The latter results in a solitary wave that is not aligned with the grid, so reflections occur at the boundaries of the domain immediately. For the simulation shown below, we have taken $u_0(x)=u_{\mathrm{kink}}(x,t_0)$, $\theta=\frac{2}{3}$, $k=20h$, $t_0=0$ and $t_f=20$. Moreover, we had to pick $\theta=\frac{2}{3}$ because for any $\theta\le\frac{1}{2}$ oscillations arose at the boundary, which are likely due to the scheme and not the equation, thus picking a value of $\theta$ a good bit into the "exponentially damped" spectrum of the time stepping schemes assures these oscillations are not created.

    +

    To this end, we rotate the kink solution discussed above about the $z$ axis: we let $\vartheta=\frac{\pi}{4}$. The latter results in a solitary wave that is not aligned with the grid, so reflections occur at the boundaries of the domain immediately. For the simulation shown below, we have taken $u_0(x)=u_{\mathrm{kink}}(x,t_0)$, $\theta=\frac{2}{3}$, $k=20h$, $t_0=0$ and $t_f=20$. Moreover, we had to pick $\theta=\frac{2}{3}$ because for any $\theta\le\frac{1}{2}$ oscillations arose at the boundary, which are likely due to the scheme and not the equation, thus picking a value of $\theta$ a good bit into the "exponentially damped" spectrum of the time stepping schemes assures these oscillations are not created.

    Animation of a moving 2D kink, at 45 degrees to the axes of the grid, showing boundary effects.

    Another interesting solution to the sine-Gordon equation (which cannot be obtained analytically) can be produced by using two 1D breathers to construct the following separable 2D initial condition:

    \[
/usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_26.html differs (HTML document, UTF-8 Unicode text, with very long lines)
--- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_26.html	2023-08-09 23:38:59.318633213 +0000
+++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_26.html	2023-08-09 23:38:59.318633213 +0000
@@ -164,8 +164,8 @@
   \right].
 \end{align*}

    -

    Here, $k_n=t_n-t_{n-1}$ is the time step size. The theta-scheme generalizes the explicit Euler ( $\theta=0$), implicit Euler ( $\theta=1$) and Crank-Nicolson ( $\theta=\frac 12$) time discretizations. Since the latter has the highest convergence order, we will choose $\theta=\frac 12$ in the program below, but make it so that playing with this parameter remains simple. (If you are interested in playing with higher order methods, take a look at step-52.)

    -

    Given this time discretization, space discretization happens as it always does, by multiplying with test functions, integrating by parts, and then restricting everything to a finite dimensional subspace. This yields the following set of fully discrete equations after multiplying through with $k_n$:

    +

    Here, $k_n=t_n-t_{n-1}$ is the time step size. The theta-scheme generalizes the explicit Euler ( $\theta=0$), implicit Euler ( $\theta=1$) and Crank-Nicolson ( $\theta=\frac 12$) time discretizations. Since the latter has the highest convergence order, we will choose $\theta=\frac 12$ in the program below, but make it so that playing with this parameter remains simple. (If you are interested in playing with higher order methods, take a look at step-52.)

    +

    Given this time discretization, space discretization happens as it always does, by multiplying with test functions, integrating by parts, and then restricting everything to a finite dimensional subspace. This yields the following set of fully discrete equations after multiplying through with $k_n$:

    \begin{align*}
   M U^n-MU^{n-1}
   +
@@ -183,7 +183,7 @@
   \right],
 \end{align*}

    -

    where $M$ is the mass matrix and $A$ is the stiffness matrix that results from discretizing the Laplacian. Bringing all known quantities to the right hand side yields the linear system we have to solve in every step:

    +

    where $M$ is the mass matrix and $A$ is the stiffness matrix that results from discretizing the Laplacian. Bringing all known quantities to the right hand side yields the linear system we have to solve in every step:

    \begin{align*}
   (M
   +
@@ -209,7 +209,7 @@
 <ul>
 <li>
 <p class=Time step size and minimal mesh size: For stationary problems, the general approach is "make the mesh as fine as it is necessary". For problems with singularities, this often leads to situations where we get many levels of refinement into corners or along interfaces. The very first tutorial to use adaptive meshes, step-6, is a point in case already.

    -

    However, for time dependent problems, we typically need to choose the time step related to the mesh size. For explicit time discretizations, this is obvious, since we need to respect a CFL condition that ties the time step size to the smallest mesh size. For implicit time discretizations, no such hard restriction exists, but in practice we still want to make the time step smaller if we make the mesh size smaller since we typically have error estimates of the form $\|e\| \le {\cal O}(k^p + h^q)$ where $p,q$ are the convergence orders of the time and space discretization, respectively. We can only make the error small if we decrease both terms. Ideally, an estimate like this would suggest to choose $k \propto h^{q/p}$. Because, at least for problems with non-smooth solutions, the error is typically localized in the cells with the smallest mesh size, we have to indeed choose $k \propto h_{\text{min}}^{q/p}$, using the smallest mesh size.

    +

    However, for time dependent problems, we typically need to choose the time step related to the mesh size. For explicit time discretizations, this is obvious, since we need to respect a CFL condition that ties the time step size to the smallest mesh size. For implicit time discretizations, no such hard restriction exists, but in practice we still want to make the time step smaller if we make the mesh size smaller since we typically have error estimates of the form $\|e\| \le {\cal O}(k^p + h^q)$ where $p,q$ are the convergence orders of the time and space discretization, respectively. We can only make the error small if we decrease both terms. Ideally, an estimate like this would suggest to choose $k \propto h^{q/p}$. Because, at least for problems with non-smooth solutions, the error is typically localized in the cells with the smallest mesh size, we have to indeed choose $k \propto h_{\text{min}}^{q/p}$, using the smallest mesh size.

    The consequence is that refining the mesh further in one place implies not only the moderate additional effort of increasing the number of degrees of freedom slightly, but also the much larger effort of having the solve the global linear system more often because of the smaller time step.

    In practice, one typically deals with this by acknowledging that we can not make the time step arbitrarily small, and consequently can not make the local mesh size arbitrarily small. Rather, we set a maximal level of refinement and when we flag cells for refinement, we simply do not refine those cells whose children would exceed this maximal level of refinement.

    There is a similar problem in that we will choose a right hand side that will switch on in different parts of the domain at different times. To avoid being caught flat footed with too coarse a mesh in areas where we suddenly need a finer mesh, we will also enforce in our program a minimal mesh refinement level.

    @@ -240,7 +240,7 @@ \sum_j U^n \varphi_j(\mathbf x), \end{align*}" src="form_3618.png"/>

    -

    multiply with test functions $\varphi_i(\mathbf x)$ and integrate by parts where necessary. In a process as outlined above, this would yield

    +

    multiply with test functions $\varphi_i(\mathbf x)$ and integrate by parts where necessary. In a process as outlined above, this would yield

    \begin{align*}
     \sum_j
     (M
@@ -260,7 +260,7 @@
     \right].
   \end{align*}

    -

    Now imagine that we have changed the mesh between time steps $n-1$ and $n$. Then the problem is that the basis functions we use for $u_h^n$ and $u^{n-1}$ are different! This pertains to the terms on the right hand side, the first of which we could more clearly write as (the second follows the same pattern)

    +

    Now imagine that we have changed the mesh between time steps $n-1$ and $n$. Then the problem is that the basis functions we use for $u_h^n$ and $u^{n-1}$ are different! This pertains to the terms on the right hand side, the first of which we could more clearly write as (the second follows the same pattern)

    \begin{align*}
     (\varphi_i, u_h^{n-1})
     =
@@ -272,7 +272,7 @@
     i=1\ldots N_n.
   \end{align*}

    -

    If the meshes used in these two time steps are the same, then $(\varphi_i^n, \varphi_j^{n-1})$ forms a square mass matrix $M_{ij}$. However, if the meshes are not the same, then in general the matrix is rectangular. Worse, it is difficult to even compute these integrals because if we loop over the cells of the mesh at time step $n$, then we need to evaluate $\varphi_j^{n-1}$ at the quadrature points of these cells, but they do not necessarily correspond to the cells of the mesh at time step $n-1$ and $\varphi_j^{n-1}$ is not defined via these cells; the same of course applies if we wanted to compute the integrals via integration on the cells of mesh $n-1$.

    +

    If the meshes used in these two time steps are the same, then $(\varphi_i^n, \varphi_j^{n-1})$ forms a square mass matrix $M_{ij}$. However, if the meshes are not the same, then in general the matrix is rectangular. Worse, it is difficult to even compute these integrals because if we loop over the cells of the mesh at time step $n$, then we need to evaluate $\varphi_j^{n-1}$ at the quadrature points of these cells, but they do not necessarily correspond to the cells of the mesh at time step $n-1$ and $\varphi_j^{n-1}$ is not defined via these cells; the same of course applies if we wanted to compute the integrals via integration on the cells of mesh $n-1$.

    In any case, what we have to face is a situation where we need to integrate shape functions defined on two different meshes. This can be done, and is in fact demonstrated in step-28, but the process is at best described by the word "awkward".

    In practice, one does not typically want to do this. Rather, we avoid the whole situation by interpolating the solution from the old to the new mesh every time we adapt the mesh. In other words, rather than solving the equations above, we instead solve the problem

    \begin{align*}
@@ -294,14 +294,14 @@
     \right],
   \end{align*}

    -

    where $I_h^n$ is the interpolation operator onto the finite element space used in time step $n$. This is not the optimal approach since it introduces an additional error besides time and space discretization, but it is a pragmatic one that makes it feasible to do time adapting meshes.

    +

    where $I_h^n$ is the interpolation operator onto the finite element space used in time step $n$. This is not the optimal approach since it introduces an additional error besides time and space discretization, but it is a pragmatic one that makes it feasible to do time adapting meshes.

    What could possibly go wrong? Verifying whether the code is correct

    There are a number of things one can typically get wrong when implementing a finite element code. In particular, for time dependent problems, the following are common sources of bugs:

    A less common problem is getting the initial conditions wrong because one can typically see that it is wrong by just outputting the first time step. In any case, in order to verify the correctness of the code, it is helpful to have a testing protocol that allows us to verify each of these components separately. This means:

    However, fortunately, CellAccessor::neighbor_child_on_subface() takes care of these situations by itself, if you loop over the correct number of subfaces, in the above example this is two. The FESubfaceValues<dim>::reinit function takes care of this too, so that the resulting state is always correct. There is one little caveat, however: For reiniting the neighbors FEFaceValues object you need to know the index of the face that points toward the current cell. Usually you assume that the neighbor you get directly is as coarse or as fine as you, if it has children, thus this information can be obtained with CellAccessor::neighbor_of_neighbor(). If the neighbor is coarser, however, you would have to use the first value in CellAccessor::neighbor_of_coarser_neighbor() instead. In order to make this easy for you, there is CellAccessor::neighbor_face_no() which does the correct thing for you and returns the desired result.

    @@ -292,12 +292,12 @@

    This approach is similar to the one we have used in step-27 for hp-refinement and has the great advantage of flexibility: Any error indicator can be used in the anisotropic process, i.e. if you have quite involved a posteriori goal-oriented error indicators available you can use them as easily as a simple Kelly error estimator. The anisotropic part of the refinement process is not influenced by this choice. Furthermore, simply leaving out the third and forth steps leads to the same isotropic refinement you used to get before any anisotropic changes in deal.II or your application program. As a last advantage, working only on cells flagged for refinement results in a faster evaluation of the anisotropic indicator, which can become noticeable on finer meshes with a lot of cells if the indicator is quite involved.

    Here, we use a very simple approach which is only applicable to DG methods. The general idea is quite simple: DG methods allow the discrete solution to jump over the faces of a cell, whereas it is smooth within each cell. Of course, in the limit we expect that the jumps tend to zero as we refine the mesh and approximate the true solution better and better. Thus, a large jump across a given face indicates that the cell should be refined (at least) orthogonally to that face, whereas a small jump does not lead to this conclusion. It is possible, of course, that the exact solution is not smooth and that it also features a jump. In that case, however, a large jump over one face indicates, that this face is more or less parallel to the jump and in the vicinity of it, thus again we would expect a refinement orthogonal to the face under consideration to be effective.

    -

    The proposed indicator calculates the average jump $K_j$, i.e. the mean value of the absolute jump $|[u]|$ of the discrete solution $u$ over the two faces $f_i^j$, $i=1,2$, $j=1..d$ orthogonal to coordinate direction $j$ on the unit cell.

    +

    The proposed indicator calculates the average jump $K_j$, i.e. the mean value of the absolute jump $|[u]|$ of the discrete solution $u$ over the two faces $f_i^j$, $i=1,2$, $j=1..d$ orthogonal to coordinate direction $j$ on the unit cell.

    \[
 K_j = \frac{\sum_{i=1}^2 \int_{f_i^j}|[u]| dx}{\sum_{i=1}^2 |f_i^j|} .
 \]

    -

    If the average jump in one direction is larger than the average of the jumps in the other directions by a certain factor $\kappa$, i.e. if $K_i > \kappa \frac 1{d-1} \sum_{j=1, j\neq i}^d K_j$, the cell is refined only along that particular direction $i$, otherwise the cell is refined isotropically.

    +

    If the average jump in one direction is larger than the average of the jumps in the other directions by a certain factor $\kappa$, i.e. if $K_i > \kappa \frac 1{d-1} \sum_{j=1, j\neq i}^d K_j$, the cell is refined only along that particular direction $i$, otherwise the cell is refined isotropically.

    Such a criterion is easily generalized to systems of equations: the absolute value of the jump would be replaced by an appropriate norm of the vector-valued jump.

    The problem

    We solve the linear transport equation presented in step-12. The domain is extended to cover $[-1,1]\times[0,1]$ in 2D, where the flow field $\beta$ describes a counterclockwise quarter circle around the origin in the right half of the domain and is parallel to the x-axis in the left part of the domain. The inflow boundary is again located at $x=1$ and along the positive part of the x-axis, and the boundary conditions are chosen as in step-12.

    @@ -381,7 +381,7 @@
    Definition: point.h:112
    #define AssertDimension(dim1, dim2)
    Definition: exceptions.h:1787
    -

    The flow field is chosen to be a quarter circle with counterclockwise flow direction and with the origin as midpoint for the right half of the domain with positive $x$ values, whereas the flow simply goes to the left in the left part of the domain at a velocity that matches the one coming in from the right. In the circular part the magnitude of the flow velocity is proportional to the distance from the origin. This is a difference to step-12, where the magnitude was 1 everywhere. the new definition leads to a linear variation of $\beta$ along each given face of a cell. On the other hand, the solution $u(x,y)$ is exactly the same as before.

    +

    The flow field is chosen to be a quarter circle with counterclockwise flow direction and with the origin as midpoint for the right half of the domain with positive $x$ values, whereas the flow simply goes to the left in the left part of the domain at a velocity that matches the one coming in from the right. In the circular part the magnitude of the flow velocity is proportional to the distance from the origin. This is a difference to step-12, where the magnitude was 1 everywhere. the new definition leads to a linear variation of $\beta$ along each given face of a cell. On the other hand, the solution $u(x,y)$ is exactly the same as before.

      void value_list(const std::vector<Point<dim>> &points,
      std::vector<Point<dim>> & values) const
      {
    @@ -1335,7 +1335,7 @@

    We see, that the solution on the anisotropically refined mesh is very similar to the solution obtained on the isotropically refined mesh. Thus the anisotropic indicator seems to effectively select the appropriate cells for anisotropic refinement.

    -

    The pictures also explain why the mesh is refined as it is. In the whole left part of the domain refinement is only performed along the $y$-axis of cells. In the right part of the domain the refinement is dominated by isotropic refinement, as the anisotropic feature of the solution - the jump from one to zero - is not well aligned with the mesh where the advection direction takes a turn. However, at the bottom and closest (to the observer) parts of the quarter circle this jumps again becomes more and more aligned with the mesh and the refinement algorithm reacts by creating anisotropic cells of increasing aspect ratio.

    +

    The pictures also explain why the mesh is refined as it is. In the whole left part of the domain refinement is only performed along the $y$-axis of cells. In the right part of the domain the refinement is dominated by isotropic refinement, as the anisotropic feature of the solution - the jump from one to zero - is not well aligned with the mesh where the advection direction takes a turn. However, at the bottom and closest (to the observer) parts of the quarter circle this jumps again becomes more and more aligned with the mesh and the refinement algorithm reacts by creating anisotropic cells of increasing aspect ratio.

    It might seem that the necessary alignment of anisotropic features and the coarse mesh can decrease performance significantly for real world problems. That is not wrong in general: If one were, for example, to apply anisotropic refinement to problems in which shocks appear (e.g., the equations solved in step-69), then it many cases the shock is not aligned with the mesh and anisotropic refinement will help little unless one also introduces techniques to move the mesh in alignment with the shocks. On the other hand, many steep features of solutions are due to boundary layers. In those cases, the mesh is already aligned with the anisotropic features because it is of course aligned with the boundary itself, and anisotropic refinement will almost always increase the efficiency of computations on adapted grids for these cases.

    The plain program

    /* ---------------------------------------------------------------------
    /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_31.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_31.html 2023-08-09 23:38:59.734636319 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_31.html 2023-08-09 23:38:59.734636319 +0000 @@ -172,7 +172,7 @@

    The Boussinesq equations

    This program deals with an interesting physical problem: how does a fluid (i.e., a liquid or gas) behave if it experiences differences in buoyancy caused by temperature differences? It is clear that those parts of the fluid that are hotter (and therefore lighter) are going to rise up and those that are cooler (and denser) are going to sink down with gravity.

    In cases where the fluid moves slowly enough such that inertial effects can be neglected, the equations that describe such behavior are the Boussinesq equations that read as follows:

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   -\nabla \cdot (2 \eta \varepsilon ({\mathbf u})) + \nabla p &=&
   -\rho\; \beta \; T\; \mathbf{g},
   \\
@@ -183,49 +183,49 @@
   {\mathbf u} \cdot \nabla T
   -
   \nabla \cdot \kappa \nabla T &=& \gamma.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3945.png"/>

    -

    These equations fall into the class of vector-valued problems (a toplevel overview of this topic can be found in the Handling vector valued problems module). Here, $\mathbf u$ is the velocity field, $p$ the pressure, and $T$ the temperature of the fluid. $\varepsilon ({\mathbf u}) = \frac 12
-[(\nabla{\mathbf u}) + (\nabla {\mathbf u})^T]$ is the symmetric gradient of the velocity. As can be seen, velocity and pressure solve a Stokes equation describing the motion of an incompressible fluid, an equation we have previously considered in step-22; we will draw extensively on the experience we have gained in that program, in particular with regard to efficient linear Stokes solvers.

    -

    The forcing term of the fluid motion is the buoyancy of the fluid, expressed as the product of the density $\rho$, the thermal expansion coefficient $\beta$, the temperature $T$ and the gravity vector $\mathbf{g}$ pointing downward. (A derivation of why the right hand side looks like it looks is given in the introduction of step-32.) While the first two equations describe how the fluid reacts to temperature differences by moving around, the third equation states how the fluid motion affects the temperature field: it is an advection diffusion equation, i.e., the temperature is attached to the fluid particles and advected along in the flow field, with an additional diffusion (heat conduction) term. In many applications, the diffusion coefficient is fairly small, and the temperature equation is in fact transport, not diffusion dominated and therefore in character more hyperbolic than elliptic; we will have to take this into account when developing a stable discretization.

    -

    In the equations above, the term $\gamma$ on the right hand side denotes the heat sources and may be a spatially and temporally varying function. $\eta$ and $\kappa$ denote the viscosity and diffusivity coefficients, which we assume constant for this tutorial program. The more general case when $\eta$ depends on the temperature is an important factor in physical applications: Most materials become more fluid as they get hotter (i.e., $\eta$ decreases with $T$); sometimes, as in the case of rock minerals at temperatures close to their melting point, $\eta$ may change by orders of magnitude over the typical range of temperatures.

    -

    We note that the Stokes equation above could be nondimensionalized by introducing the Rayleigh number $\mathrm{Ra}=\frac{\|\mathbf{g}\| \beta \rho}{\eta \kappa} \delta T L^3$ using a typical length scale $L$, typical temperature difference $\delta T$, density $\rho$, thermal diffusivity $\eta$, and thermal conductivity $\kappa$. $\mathrm{Ra}$ is a dimensionless number that describes the ratio of heat transport due to convection induced by buoyancy changes from temperature differences, and of heat transport due to thermal diffusion. A small Rayleigh number implies that buoyancy is not strong relative to viscosity and fluid motion $\mathbf{u}$ is slow enough so that heat diffusion $\kappa\nabla T$ is the dominant heat transport term. On the other hand, a fluid with a high Rayleigh number will show vigorous convection that dominates heat conduction.

    -

    For most fluids for which we are interested in computing thermal convection, the Rayleigh number is very large, often $10^6$ or larger. From the structure of the equations, we see that this will lead to large pressure differences and large velocities. Consequently, the convection term in the convection-diffusion equation for $T$ will also be very large and an accurate solution of this equation will require us to choose small time steps. Problems with large Rayleigh numbers are therefore hard to solve numerically for similar reasons that make solving the Navier-Stokes equations hard to solve when the Reynolds number $\mathrm{Re}$ is large.

    -

    Note that a large Rayleigh number does not necessarily involve large velocities in absolute terms. For example, the Rayleigh number in the earth mantle is larger than $10^6$. Yet the velocities are small: the material is in fact solid rock but it is so hot and under pressure that it can flow very slowly, on the order of at most a few centimeters per year. Nevertheless, this can lead to mixing over time scales of many million years, a time scale much shorter than for the same amount of heat to be distributed by thermal conductivity and a time scale of relevance to affect the evolution of the earth's interior and surface structure.

    +

    These equations fall into the class of vector-valued problems (a toplevel overview of this topic can be found in the Handling vector valued problems module). Here, $\mathbf u$ is the velocity field, $p$ the pressure, and $T$ the temperature of the fluid. $\varepsilon ({\mathbf u}) = \frac 12
+[(\nabla{\mathbf u}) + (\nabla {\mathbf u})^T]$ is the symmetric gradient of the velocity. As can be seen, velocity and pressure solve a Stokes equation describing the motion of an incompressible fluid, an equation we have previously considered in step-22; we will draw extensively on the experience we have gained in that program, in particular with regard to efficient linear Stokes solvers.

    +

    The forcing term of the fluid motion is the buoyancy of the fluid, expressed as the product of the density $\rho$, the thermal expansion coefficient $\beta$, the temperature $T$ and the gravity vector $\mathbf{g}$ pointing downward. (A derivation of why the right hand side looks like it looks is given in the introduction of step-32.) While the first two equations describe how the fluid reacts to temperature differences by moving around, the third equation states how the fluid motion affects the temperature field: it is an advection diffusion equation, i.e., the temperature is attached to the fluid particles and advected along in the flow field, with an additional diffusion (heat conduction) term. In many applications, the diffusion coefficient is fairly small, and the temperature equation is in fact transport, not diffusion dominated and therefore in character more hyperbolic than elliptic; we will have to take this into account when developing a stable discretization.

    +

    In the equations above, the term $\gamma$ on the right hand side denotes the heat sources and may be a spatially and temporally varying function. $\eta$ and $\kappa$ denote the viscosity and diffusivity coefficients, which we assume constant for this tutorial program. The more general case when $\eta$ depends on the temperature is an important factor in physical applications: Most materials become more fluid as they get hotter (i.e., $\eta$ decreases with $T$); sometimes, as in the case of rock minerals at temperatures close to their melting point, $\eta$ may change by orders of magnitude over the typical range of temperatures.

    +

    We note that the Stokes equation above could be nondimensionalized by introducing the Rayleigh number $\mathrm{Ra}=\frac{\|\mathbf{g}\| \beta \rho}{\eta \kappa} \delta T L^3$ using a typical length scale $L$, typical temperature difference $\delta T$, density $\rho$, thermal diffusivity $\eta$, and thermal conductivity $\kappa$. $\mathrm{Ra}$ is a dimensionless number that describes the ratio of heat transport due to convection induced by buoyancy changes from temperature differences, and of heat transport due to thermal diffusion. A small Rayleigh number implies that buoyancy is not strong relative to viscosity and fluid motion $\mathbf{u}$ is slow enough so that heat diffusion $\kappa\nabla T$ is the dominant heat transport term. On the other hand, a fluid with a high Rayleigh number will show vigorous convection that dominates heat conduction.

    +

    For most fluids for which we are interested in computing thermal convection, the Rayleigh number is very large, often $10^6$ or larger. From the structure of the equations, we see that this will lead to large pressure differences and large velocities. Consequently, the convection term in the convection-diffusion equation for $T$ will also be very large and an accurate solution of this equation will require us to choose small time steps. Problems with large Rayleigh numbers are therefore hard to solve numerically for similar reasons that make solving the Navier-Stokes equations hard to solve when the Reynolds number $\mathrm{Re}$ is large.

    +

    Note that a large Rayleigh number does not necessarily involve large velocities in absolute terms. For example, the Rayleigh number in the earth mantle is larger than $10^6$. Yet the velocities are small: the material is in fact solid rock but it is so hot and under pressure that it can flow very slowly, on the order of at most a few centimeters per year. Nevertheless, this can lead to mixing over time scales of many million years, a time scale much shorter than for the same amount of heat to be distributed by thermal conductivity and a time scale of relevance to affect the evolution of the earth's interior and surface structure.

    Note
    If you are interested in using the program as the basis for your own experiments, you will also want to take a look at its continuation in step-32. Furthermore, step-32 later was developed into the much larger open source code ASPECT (see https://aspect.geodynamics.org/ ) that can solve realistic problems and that you may want to investigate before trying to morph step-31 into something that can solve whatever you want to solve.

    Boundary and initial conditions

    -

    Since the Boussinesq equations are derived under the assumption that inertia of the fluid's motion does not play a role, the flow field is at each time entirely determined by buoyancy difference at that time, not by the flow field at previous times. This is reflected by the fact that the first two equations above are the steady state Stokes equation that do not contain a time derivative. Consequently, we do not need initial conditions for either velocities or pressure. On the other hand, the temperature field does satisfy an equation with a time derivative, so we need initial conditions for $T$.

    -

    As for boundary conditions: if $\kappa>0$ then the temperature satisfies a second order differential equation that requires boundary data all around the boundary for all times. These can either be a prescribed boundary temperature $T|_{\partial\Omega}=T_b$ (Dirichlet boundary conditions), or a prescribed thermal flux $\mathbf{n}\cdot\kappa\nabla
-T|_{\partial\Omega}=\phi$; in this program, we will use an insulated boundary condition, i.e., prescribe no thermal flux: $\phi=0$.

    -

    Similarly, the velocity field requires us to pose boundary conditions. These may be no-slip no-flux conditions $\mathbf{u}=0$ on $\partial\Omega$ if the fluid sticks to the boundary, or no normal flux conditions $\mathbf n \cdot \mathbf
-u = 0$ if the fluid can flow along but not across the boundary, or any number of other conditions that are physically reasonable. In this program, we will use no normal flux conditions.

    +

    Since the Boussinesq equations are derived under the assumption that inertia of the fluid's motion does not play a role, the flow field is at each time entirely determined by buoyancy difference at that time, not by the flow field at previous times. This is reflected by the fact that the first two equations above are the steady state Stokes equation that do not contain a time derivative. Consequently, we do not need initial conditions for either velocities or pressure. On the other hand, the temperature field does satisfy an equation with a time derivative, so we need initial conditions for $T$.

    +

    As for boundary conditions: if $\kappa>0$ then the temperature satisfies a second order differential equation that requires boundary data all around the boundary for all times. These can either be a prescribed boundary temperature $T|_{\partial\Omega}=T_b$ (Dirichlet boundary conditions), or a prescribed thermal flux $\mathbf{n}\cdot\kappa\nabla
+T|_{\partial\Omega}=\phi$; in this program, we will use an insulated boundary condition, i.e., prescribe no thermal flux: $\phi=0$.

    +

    Similarly, the velocity field requires us to pose boundary conditions. These may be no-slip no-flux conditions $\mathbf{u}=0$ on $\partial\Omega$ if the fluid sticks to the boundary, or no normal flux conditions $\mathbf n \cdot \mathbf
+u = 0$ if the fluid can flow along but not across the boundary, or any number of other conditions that are physically reasonable. In this program, we will use no normal flux conditions.

    Solution approach

    -

    Like the equations solved in step-21, we here have a system of differential-algebraic equations (DAE): with respect to the time variable, only the temperature equation is a differential equation whereas the Stokes system for $\mathbf{u}$ and $p$ has no time-derivatives and is therefore of the sort of an algebraic constraint that has to hold at each time instant. The main difference to step-21 is that the algebraic constraint there was a mixed Laplace system of the form

    -\begin{eqnarray*}
+<p>Like the equations solved in <a class=step-21, we here have a system of differential-algebraic equations (DAE): with respect to the time variable, only the temperature equation is a differential equation whereas the Stokes system for $\mathbf{u}$ and $p$ has no time-derivatives and is therefore of the sort of an algebraic constraint that has to hold at each time instant. The main difference to step-21 is that the algebraic constraint there was a mixed Laplace system of the form

    +\begin{eqnarray*}
   \mathbf u + {\mathbf K}\lambda \nabla p &=& 0, \\
   \nabla\cdot \mathbf u &=& f,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3960.png"/>

    where now we have a Stokes system

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   -\nabla \cdot (2 \eta \varepsilon ({\mathbf u})) + \nabla p &=& f, \\
   \nabla\cdot \mathbf u &=& 0,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3961.png"/>

    -

    where $\nabla \cdot \eta \varepsilon (\cdot)$ is an operator similar to the Laplacian $\Delta$ applied to a vector field.

    +

    where $\nabla \cdot \eta \varepsilon (\cdot)$ is an operator similar to the Laplacian $\Delta$ applied to a vector field.

    Given the similarity to what we have done in step-21, it may not come as a surprise that we choose a similar approach, although we will have to make adjustments for the change in operator in the top-left corner of the differential operator.

    Time stepping

    -

    The structure of the problem as a DAE allows us to use the same strategy as we have already used in step-21, i.e., we use a time lag scheme: we first solve the temperature equation (using an extrapolated velocity field), and then insert the new temperature solution into the right hand side of the velocity equation. The way we implement this in our code looks at things from a slightly different perspective, though. We first solve the Stokes equations for velocity and pressure using the temperature field from the previous time step, which means that we get the velocity for the previous time step. In other words, we first solve the Stokes system for time step $n - 1$ as

    -\begin{eqnarray*}
+<p>The structure of the problem as a DAE allows us to use the same strategy as we have already used in <a class=step-21, i.e., we use a time lag scheme: we first solve the temperature equation (using an extrapolated velocity field), and then insert the new temperature solution into the right hand side of the velocity equation. The way we implement this in our code looks at things from a slightly different perspective, though. We first solve the Stokes equations for velocity and pressure using the temperature field from the previous time step, which means that we get the velocity for the previous time step. In other words, we first solve the Stokes system for time step $n - 1$ as

    +\begin{eqnarray*}
   -\nabla \cdot (2\eta \varepsilon ({\mathbf u}^{n-1})) + \nabla p^{n-1} &=&
   -\rho\; \beta \; T^{n-1} \mathbf{g},
   \\
   \nabla \cdot {\mathbf u}^{n-1} &=& 0,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3965.png"/>

    -

    and then the temperature equation with an extrapolated velocity field to time $n$.

    -

    In contrast to step-21, we'll use a higher order time stepping scheme here, namely the Backward Differentiation Formula scheme of order 2 (BDF-2 in short) that replaces the time derivative $\frac{\partial T}{\partial t}$ by the (one-sided) difference quotient $\frac{\frac 32 T^{n}-2T^{n-1}+\frac 12 T^{n-2}}{k}$ with $k$ the time step size. This gives the discretized-in-time temperature equation

    -\begin{eqnarray*}
+<p> and then the temperature equation with an extrapolated velocity field to time <picture><source srcset=$n$.

    +

    In contrast to step-21, we'll use a higher order time stepping scheme here, namely the Backward Differentiation Formula scheme of order 2 (BDF-2 in short) that replaces the time derivative $\frac{\partial T}{\partial t}$ by the (one-sided) difference quotient $\frac{\frac 32 T^{n}-2T^{n-1}+\frac 12 T^{n-2}}{k}$ with $k$ the time step size. This gives the discretized-in-time temperature equation

    +\begin{eqnarray*}
   \frac 32 T^n
   -
   k\nabla \cdot \kappa \nabla T^n
@@ -237,13 +237,13 @@
   k(2{\mathbf u}^{n-1} - {\mathbf u}^{n-2} ) \cdot \nabla (2T^{n-1}-T^{n-2})
   +
   k\gamma.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3968.png"/>

    -

    Note how the temperature equation is solved semi-explicitly: diffusion is treated implicitly whereas advection is treated explicitly using an extrapolation (or forward-projection) of temperature and velocity, including the just-computed velocity ${\mathbf u}^{n-1}$. The forward-projection to the current time level $n$ is derived from a Taylor expansion, $T^n
+<p> Note how the temperature equation is solved semi-explicitly: diffusion is treated implicitly whereas advection is treated explicitly using an extrapolation (or forward-projection) of temperature and velocity, including the just-computed velocity <picture><source srcset=${\mathbf u}^{n-1}$. The forward-projection to the current time level $n$ is derived from a Taylor expansion, $T^n
 \approx T^{n-1} + k_n \frac{\partial T}{\partial t} \approx T^{n-1} + k_n
-\frac{T^{n-1}-T^{n-2}}{k_n} = 2T^{n-1}-T^{n-2}$. We need this projection for maintaining the order of accuracy of the BDF-2 scheme. In other words, the temperature fields we use in the explicit right hand side are second order approximations of the current temperature field — not quite an explicit time stepping scheme, but by character not too far away either.

    -

    The introduction of the temperature extrapolation limits the time step by a Courant-Friedrichs-Lewy (CFL) condition just like it was in step-21. (We wouldn't have had that stability condition if we treated the advection term implicitly since the BDF-2 scheme is A-stable, at the price that we needed to build a new temperature matrix at each time step.) We will discuss the exact choice of time step in the results section, but for the moment of importance is that this CFL condition means that the time step size $k$ may change from time step to time step, and that we have to modify the above formula slightly. If $k_n,k_{n-1}$ are the time steps sizes of the current and previous time step, then we use the approximations

    -\begin{align*}
+\frac{T^{n-1}-T^{n-2}}{k_n} = 2T^{n-1}-T^{n-2}$. We need this projection for maintaining the order of accuracy of the BDF-2 scheme. In other words, the temperature fields we use in the explicit right hand side are second order approximations of the current temperature field — not quite an explicit time stepping scheme, but by character not too far away either.

    +

    The introduction of the temperature extrapolation limits the time step by a Courant-Friedrichs-Lewy (CFL) condition just like it was in step-21. (We wouldn't have had that stability condition if we treated the advection term implicitly since the BDF-2 scheme is A-stable, at the price that we needed to build a new temperature matrix at each time step.) We will discuss the exact choice of time step in the results section, but for the moment of importance is that this CFL condition means that the time step size $k$ may change from time step to time step, and that we have to modify the above formula slightly. If $k_n,k_{n-1}$ are the time steps sizes of the current and previous time step, then we use the approximations

    +\begin{align*}
 \frac{\partial T}{\partial t} \approx
  \frac 1{k_n}
  \left(
@@ -253,10 +253,10 @@
        +
        \frac{k_n^2}{k_{n-1}(k_n+k_{n-1})} T^{n-2}
  \right)
- \end{align*} + \end{align*}" src="form_3972.png"/>

    and

    -\begin{align*}
+<picture><source srcset=\begin{align*}
 T^n \approx
    T^{n-1} + k_n \frac{\partial T}{\partial t}
    \approx
@@ -264,10 +264,10 @@
    \frac{T^{n-1}-T^{n-2}}{k_{n-1}}
    =
    \left(1+\frac{k_n}{k_{n-1}}\right)T^{n-1}-\frac{k_n}{k_{n-1}}T^{n-2},
-\end{align*} +\end{align*}" src="form_3973.png"/>

    and above equation is generalized as follows:

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   \frac{2k_n+k_{n-1}}{k_n+k_{n-1}} T^n
   -
   k_n\nabla \cdot \kappa \nabla T^n
@@ -279,14 +279,14 @@
   k_n{\mathbf u}^{*,n} \cdot \nabla T^{*,n}
   +
   k_n\gamma,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3974.png"/>

    -

    where ${(\cdot)}^{*,n} = \left(1+\frac{k_n}{k_{n-1}}\right)(\cdot)^{n-1} -
-\frac{k_n}{k_{n-1}}(\cdot)^{n-2}$ denotes the extrapolation of velocity $\mathbf u$ and temperature $T$ to time level $n$, using the values at the two previous time steps. That's not an easy to read equation, but will provide us with the desired higher order accuracy. As a consistency check, it is easy to verify that it reduces to the same equation as above if $k_n=k_{n-1}$.

    -

    As a final remark we note that the choice of a higher order time stepping scheme of course forces us to keep more time steps in memory; in particular, we here will need to have $T^{n-2}$ around, a vector that we could previously discard. This seems like a nuisance that we were able to avoid previously by using only a first order time stepping scheme, but as we will see below when discussing the topic of stabilization, we will need this vector anyway and so keeping it around for time discretization is essentially for free and gives us the opportunity to use a higher order scheme.

    +

    where ${(\cdot)}^{*,n} = \left(1+\frac{k_n}{k_{n-1}}\right)(\cdot)^{n-1} -
+\frac{k_n}{k_{n-1}}(\cdot)^{n-2}$ denotes the extrapolation of velocity $\mathbf u$ and temperature $T$ to time level $n$, using the values at the two previous time steps. That's not an easy to read equation, but will provide us with the desired higher order accuracy. As a consistency check, it is easy to verify that it reduces to the same equation as above if $k_n=k_{n-1}$.

    +

    As a final remark we note that the choice of a higher order time stepping scheme of course forces us to keep more time steps in memory; in particular, we here will need to have $T^{n-2}$ around, a vector that we could previously discard. This seems like a nuisance that we were able to avoid previously by using only a first order time stepping scheme, but as we will see below when discussing the topic of stabilization, we will need this vector anyway and so keeping it around for time discretization is essentially for free and gives us the opportunity to use a higher order scheme.

    Weak form and space discretization for the Stokes part

    -

    Like solving the mixed Laplace equations, solving the Stokes equations requires us to choose particular pairs of finite elements for velocities and pressure variables. Because this has already been discussed in step-22, we only cover this topic briefly: Here, we use the stable pair $Q_{p+1}^d \times Q_p, p\ge 1$. These are continuous elements, so we can form the weak form of the Stokes equation without problem by integrating by parts and substituting continuous functions by their discrete counterparts:

    -\begin{eqnarray*}
+<p>Like solving the mixed Laplace equations, solving the Stokes equations requires us to choose particular pairs of finite elements for velocities and pressure variables. Because this has already been discussed in <a class=step-22, we only cover this topic briefly: Here, we use the stable pair $Q_{p+1}^d \times Q_p, p\ge 1$. These are continuous elements, so we can form the weak form of the Stokes equation without problem by integrating by parts and substituting continuous functions by their discrete counterparts:

    +\begin{eqnarray*}
   (\nabla {\mathbf v}_h, 2\eta \varepsilon ({\mathbf u}^{n-1}_h))
   -
   (\nabla \cdot {\mathbf v}_h, p^{n-1}_h)
@@ -294,12 +294,12 @@
   -({\mathbf v}_h, \rho\; \beta \; T^{n-1}_h \mathbf{g}),
   \\
   (q_h, \nabla \cdot {\mathbf u}^{n-1}_h) &=& 0,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3979.png"/>

    -

    for all test functions $\mathbf v_h, q_h$. The first term of the first equation is considered as the inner product between tensors, i.e. $(\nabla {\mathbf v}_h, \eta \varepsilon ({\mathbf u}^{n-1}_h))_\Omega
+<p> for all test functions <picture><source srcset=$\mathbf v_h, q_h$. The first term of the first equation is considered as the inner product between tensors, i.e. $(\nabla {\mathbf v}_h, \eta \varepsilon ({\mathbf u}^{n-1}_h))_\Omega
  = \int_\Omega \sum_{i,j=1}^d [\nabla {\mathbf v}_h]_{ij}
-           \eta [\varepsilon ({\mathbf u}^{n-1}_h)]_{ij}\, dx$. Because the second tensor in this product is symmetric, the anti-symmetric component of $\nabla {\mathbf v}_h$ plays no role and it leads to the entirely same form if we use the symmetric gradient of $\mathbf v_h$ instead. Consequently, the formulation we consider and that we implement is

    -\begin{eqnarray*}
+           \eta [\varepsilon ({\mathbf u}^{n-1}_h)]_{ij}\, dx$. Because the second tensor in this product is symmetric, the anti-symmetric component of $\nabla {\mathbf v}_h$ plays no role and it leads to the entirely same form if we use the symmetric gradient of $\mathbf v_h$ instead. Consequently, the formulation we consider and that we implement is

    +\begin{eqnarray*}
   (\varepsilon({\mathbf v}_h), 2\eta \varepsilon ({\mathbf u}^{n-1}_h))
   -
   (\nabla \cdot {\mathbf v}_h, p^{n-1}_h)
@@ -307,32 +307,32 @@
   -({\mathbf v}_h, \rho\; \beta \; T^{n-1}_h \mathbf{g}),
   \\
   (q_h, \nabla \cdot {\mathbf u}^{n-1}_h) &=& 0.
-\end{eqnarray*} +\end{eqnarray*}" src="form_3984.png"/>

    This is exactly the same as what we already discussed in step-22 and there is not much more to say about this here.

    Stabilization, weak form and space discretization for the temperature equation

    The more interesting question is what to do with the temperature advection-diffusion equation. By default, not all discretizations of this equation are equally stable unless we either do something like upwinding, stabilization, or all of this. One way to achieve this is to use discontinuous elements (i.e., the FE_DGQ class that we used, for example, in the discretization of the transport equation in step-12, or in discretizing the pressure in step-20 and step-21) and to define a flux at the interface between cells that takes into account upwinding. If we had a pure advection problem this would probably be the simplest way to go. However, here we have some diffusion as well, and the discretization of the Laplace operator with discontinuous elements is cumbersome because of the significant number of additional terms that need to be integrated on each face between cells. Discontinuous elements also have the drawback that the use of numerical fluxes introduces an additional numerical diffusion that acts everywhere, whereas we would really like to minimize the effect of numerical diffusion to a minimum and only apply it where it is necessary to stabilize the scheme.

    A better alternative is therefore to add some nonlinear viscosity to the model. Essentially, what this does is to transform the temperature equation from the form

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   \frac{\partial T}{\partial t}
   +
   {\mathbf u} \cdot \nabla T
   -
   \nabla \cdot \kappa \nabla T &=& \gamma
-\end{eqnarray*} +\end{eqnarray*}" src="form_3985.png"/>

    to something like

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   \frac{\partial T}{\partial t}
   +
   {\mathbf u} \cdot \nabla T
   -
   \nabla \cdot (\kappa+\nu(T)) \nabla T &=& \gamma,
-\end{eqnarray*} +\end{eqnarray*}" src="form_3986.png"/> /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_32.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_32.html 2023-08-09 23:38:59.902637574 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_32.html 2023-08-09 23:38:59.906637604 +0000 @@ -164,58 +164,58 @@

    In addition to these changes, we also use a slightly different preconditioner, and we will have to make a number of changes that have to do with the fact that we want to solve a realistic problem here, not a model problem. The latter, in particular, will require that we think about scaling issues as well as what all those parameters and coefficients in the equations under consideration actually mean. We will discuss first the issues that affect changes in the mathematical formulation and solver structure, then how to parallelize things, and finally the actual testcase we will consider.

    Using the "right" pressure

    In step-31, we used the following Stokes model for the velocity and pressure field:

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   -\nabla \cdot (2 \eta \varepsilon ({\mathbf u})) + \nabla p &=&
   -\rho \; \beta \; T \mathbf{g},
   \\
   \nabla \cdot {\mathbf u} &=& 0.
-\end{eqnarray*} +\end{eqnarray*}" src="form_4126.png"/>

    -

    The right hand side of the first equation appears a wee bit unmotivated. Here's how things should really be. We need the external forces that act on the fluid, which we assume are given by gravity only. In the current case, we assume that the fluid does expand slightly for the purposes of this gravity force, but not enough that we need to modify the incompressibility condition (the second equation). What this means is that for the purpose of the right hand side, we can assume that $\rho=\rho(T)$. An assumption that may not be entirely justified is that we can assume that the changes of density as a function of temperature are small, leading to an expression of the form $\rho(T) = \rho_{\text{ref}}
-[1-\beta(T-T_{\text{ref}})]$, i.e., the density equals $\rho_{\text{ref}}$ at reference temperature and decreases linearly as the temperature increases (as the material expands). The force balance equation then looks properly written like this:

    -\begin{eqnarray*}
+<p> The right hand side of the first equation appears a wee bit unmotivated. Here's how things should really be. We need the external forces that act on the fluid, which we assume are given by gravity only. In the current case, we assume that the fluid does expand slightly for the purposes of this gravity force, but not enough that we need to modify the incompressibility condition (the second equation). What this means is that for the purpose of the right hand side, we can assume that <picture><source srcset=$\rho=\rho(T)$. An assumption that may not be entirely justified is that we can assume that the changes of density as a function of temperature are small, leading to an expression of the form $\rho(T) = \rho_{\text{ref}}
+[1-\beta(T-T_{\text{ref}})]$, i.e., the density equals $\rho_{\text{ref}}$ at reference temperature and decreases linearly as the temperature increases (as the material expands). The force balance equation then looks properly written like this:

    +\begin{eqnarray*}
   -\nabla \cdot (2 \eta \varepsilon ({\mathbf u})) + \nabla p &=&
   \rho_{\text{ref}} [1-\beta(T-T_{\text{ref}})] \mathbf{g}.
-\end{eqnarray*} +\end{eqnarray*}" src="form_4130.png"/>

    -

    Now note that the gravity force results from a gravity potential as $\mathbf g=-\nabla \varphi$, so that we can re-write this as follows:

    -\begin{eqnarray*}
+<p> Now note that the gravity force results from a gravity potential as <picture><source srcset=$\mathbf g=-\nabla \varphi$, so that we can re-write this as follows:

    +\begin{eqnarray*}
   -\nabla \cdot (2 \eta \varepsilon ({\mathbf u})) + \nabla p &=&
   -\rho_{\text{ref}} \; \beta\; T\; \mathbf{g}
   -\rho_{\text{ref}} [1+\beta T_{\text{ref}}] \nabla\varphi.
-\end{eqnarray*} +\end{eqnarray*}" src="form_4132.png"/>

    -

    The second term on the right is time independent, and so we could introduce a new "dynamic" pressure $p_{\text{dyn}}=p+\rho_{\text{ref}}
-[1+\beta T_{\text{ref}}] \varphi=p_{\text{total}}-p_{\text{static}}$ with which the Stokes equations would read:

    -\begin{eqnarray*}
+<p> The second term on the right is time independent, and so we could introduce a new $p_{\text{dyn}}=p+\rho_{\text{ref}}
+[1+\beta T_{\text{ref}}] \varphi=p_{\text{total}}-p_{\text{static}}$ with which the Stokes equations would read:

    +\begin{eqnarray*}
   -\nabla \cdot (2 \eta \varepsilon ({\mathbf u})) + \nabla p_{\text{dyn}} &=&
   -\rho_{\text{ref}} \; \beta \; T \; \mathbf{g},
   \\
   \nabla \cdot {\mathbf u} &=& 0.
-\end{eqnarray*} +\end{eqnarray*}" src="form_4134.png"/>

    This is exactly the form we used in step-31, and it was appropriate to do so because all changes in the fluid flow are only driven by the dynamic pressure that results from temperature differences. (In other words: Any contribution to the right hand side that results from taking the gradient of a scalar field have no effect on the velocity field.)

    On the other hand, we will here use the form of the Stokes equations that considers the total pressure instead:

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   -\nabla \cdot (2 \eta \varepsilon ({\mathbf u})) + \nabla p &=&
   \rho(T)\; \mathbf{g},
   \\
   \nabla \cdot {\mathbf u} &=& 0.
-\end{eqnarray*} +\end{eqnarray*}" src="form_4135.png"/>

    There are several advantages to this:

    • This way we can plot the pressure in our program in such a way that it actually shows the total pressure that includes the effects of temperature differences as well as the static pressure of the overlying rocks. Since the pressure does not appear any further in any of the other equations, whether to use one or the other is more a matter of taste than of correctness. The flow field is exactly the same, but we get a pressure that we can now compare with values that are given in geophysical books as those that hold at the bottom of the earth mantle, for example.
    • If we wanted to make the model even more realistic, we would have to take into account that many of the material parameters (e.g. the viscosity, the density, etc) not only depend on the temperature but also the total pressure.
    • -
    • The model above assumed a linear dependence $\rho(T) = \rho_{\text{ref}}
-  [1-\beta(T-T_{\text{ref}})]$ and assumed that $\beta$ is small. In practice, this may not be so. In fact, realistic models are certainly not linear, and $\beta$ may also not be small for at least part of the temperature range because the density's behavior is substantially dependent not only on thermal expansion but by phase changes.
    • +
    • The model above assumed a linear dependence $\rho(T) = \rho_{\text{ref}}
+  [1-\beta(T-T_{\text{ref}})]$ and assumed that $\beta$ is small. In practice, this may not be so. In fact, realistic models are certainly not linear, and $\beta$ may also not be small for at least part of the temperature range because the density's behavior is substantially dependent not only on thermal expansion but by phase changes.
    • A final reason to do this is discussed in the results section and concerns possible extensions to the model we use here. It has to do with the fact that the temperature equation (see below) we use here does not include a term that contains the pressure. It should, however: rock, like gas, heats up as you compress it. Consequently, material that rises up cools adiabatically, and cold material that sinks down heats adiabatically. We discuss this further below.
    -
    Note
    There is, however, a downside to this procedure. In the earth, the dynamic pressure is several orders of magnitude smaller than the total pressure. If we use the equations above and solve all variables to, say, 4 digits of accuracy, then we may be able to get the velocity and the total pressure right, but we will have no accuracy at all if we compute the dynamic pressure by subtracting from the total pressure the static part $p_\text{static}=\rho_{\text{ref}}
-[1+\beta T_{\text{ref}}] \varphi$. If, for example, the dynamic pressure is six orders of magnitude smaller than the static pressure, then we need to solve the overall pressure to at least seven digits of accuracy to get anything remotely accurate. That said, in practice this turns out not to be a limiting factor.
    +
    Note
    There is, however, a downside to this procedure. In the earth, the dynamic pressure is several orders of magnitude smaller than the total pressure. If we use the equations above and solve all variables to, say, 4 digits of accuracy, then we may be able to get the velocity and the total pressure right, but we will have no accuracy at all if we compute the dynamic pressure by subtracting from the total pressure the static part $p_\text{static}=\rho_{\text{ref}}
+[1+\beta T_{\text{ref}}] \varphi$. If, for example, the dynamic pressure is six orders of magnitude smaller than the static pressure, then we need to solve the overall pressure to at least seven digits of accuracy to get anything remotely accurate. That said, in practice this turns out not to be a limiting factor.

    The scaling of discretized equations

    Remember that we want to solve the following set of equations:

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   -\nabla \cdot (2 \eta \varepsilon ({\mathbf u})) + \nabla p &=&
   \rho(T) \mathbf{g},
   \\
@@ -226,11 +226,11 @@
   {\mathbf u} \cdot \nabla T
   -
   \nabla \cdot \kappa \nabla T &=& \gamma,
-\end{eqnarray*} +\end{eqnarray*}" src="form_4138.png"/>

    augmented by appropriate boundary and initial conditions. As discussed in step-31, we will solve this set of equations by solving for a Stokes problem first in each time step, and then moving the temperature equation forward by one time interval.

    The problem under consideration in this current section is with the Stokes problem: if we discretize it as usual, we get a linear system

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   M \; X
   =
   \left(\begin{array}{cc}
@@ -245,10 +245,10 @@
   \end{array}\right)
   =
   F
-\end{eqnarray*} +\end{eqnarray*}" src="form_4139.png"/>

    which in this program we will solve with a FGMRES solver. This solver iterates until the residual of these linear equations is below a certain tolerance, i.e., until

    -\[
+<picture><source srcset=\[
   \left\|
   \left(\begin{array}{c}
     F_U - A U^{(k)} - B P^{(k)}
@@ -257,35 +257,35 @@
   \end{array}\right)
   \right\|
   < \text{Tol}.
-\] +\]" src="form_4140.png"/>

    -

    This does not make any sense from the viewpoint of physical units: the quantities involved here have physical units so that the first part of the residual has units $\frac{\text{Pa}}{\text{m}}
-\text{m}^{\text{dim}}$ (most easily established by considering the term $(\nabla \cdot \mathbf v, p)_{\Omega}$ and considering that the pressure has units $\text{Pa}=\frac{\text{kg}}{\text{m}\;\text{s}^2}$ and the integration yields a factor of $\text{m}^{\text{dim}}$), whereas the second part of the residual has units $\frac{\text{m}^{\text{dim}}}{\text{s}}$. Taking the norm of this residual vector would yield a quantity with units $\text{m}^{\text{dim}-1} \sqrt{\left(\text{Pa}\right)^2 +
-       \left(\frac{\text{m}}{\text{s}}\right)^2}$. This, quite obviously, does not make sense, and we should not be surprised that doing so is eventually going to come back hurting us.

    -

    So why is this an issue here, but not in step-31? The reason back there is that everything was nicely balanced: velocities were on the order of one, the pressure likewise, the viscosity was one, and the domain had a diameter of $\sqrt{2}$. As a result, while nonsensical, nothing bad happened. On the other hand, as we will explain below, things here will not be that simply scaled: $\eta$ will be around $10^{21}$, velocities on the order of $10^{-8}$, pressure around $10^8$, and the diameter of the domain is $10^7$. In other words, the order of magnitude for the first equation is going to be $\eta\text{div}\varepsilon(\mathbf u) \approx 10^{21} \frac{10^{-8}}{(10^7)^2}
-\approx 10^{-1}$, whereas the second equation will be around $\text{div}{\mathbf u}\approx \frac{10^{-8}}{10^7} \approx 10^{-15}$. Well, so what this will lead to is this: if the solver wants to make the residual small, it will almost entirely focus on the first set of equations because they are so much bigger, and ignore the divergence equation that describes mass conservation. That's exactly what happens: unless we set the tolerance to extremely small values, the resulting flow field is definitely not divergence free. As an auxiliary problem, it turns out that it is difficult to find a tolerance that always works; in practice, one often ends up with a tolerance that requires 30 or 40 iterations for most time steps, and 10,000 for some others.

    -

    So what's a numerical analyst to do in a case like this? The answer is to start at the root and first make sure that everything is mathematically consistent first. In our case, this means that if we want to solve the system of Stokes equations jointly, we have to scale them so that they all have the same physical dimensions. In our case, this means multiplying the second equation by something that has units $\frac{\text{Pa}\;\text{s}}{\text{m}}$; one choice is to multiply with $\frac{\eta}{L}$ where $L$ is a typical lengthscale in our domain (which experiments show is best chosen to be the diameter of plumes — around 10 km — rather than the diameter of the domain). Using these numbers for $\eta$ and $L$, this factor is around $10^{17}$. So, we now get this for the Stokes system:

    -\begin{eqnarray*}
+<p> This does not make any sense from the viewpoint of physical units: the quantities involved here have physical units so that the first part of the residual has units <picture><source srcset=$\frac{\text{Pa}}{\text{m}}
+\text{m}^{\text{dim}}$ (most easily established by considering the term $(\nabla \cdot \mathbf v, p)_{\Omega}$ and considering that the pressure has units $\text{Pa}=\frac{\text{kg}}{\text{m}\;\text{s}^2}$ and the integration yields a factor of $\text{m}^{\text{dim}}$), whereas the second part of the residual has units $\frac{\text{m}^{\text{dim}}}{\text{s}}$. Taking the norm of this residual vector would yield a quantity with units $\text{m}^{\text{dim}-1} \sqrt{\left(\text{Pa}\right)^2 +
+       \left(\frac{\text{m}}{\text{s}}\right)^2}$. This, quite obviously, does not make sense, and we should not be surprised that doing so is eventually going to come back hurting us.

    +

    So why is this an issue here, but not in step-31? The reason back there is that everything was nicely balanced: velocities were on the order of one, the pressure likewise, the viscosity was one, and the domain had a diameter of $\sqrt{2}$. As a result, while nonsensical, nothing bad happened. On the other hand, as we will explain below, things here will not be that simply scaled: $\eta$ will be around $10^{21}$, velocities on the order of $10^{-8}$, pressure around $10^8$, and the diameter of the domain is $10^7$. In other words, the order of magnitude for the first equation is going to be $\eta\text{div}\varepsilon(\mathbf u) \approx 10^{21} \frac{10^{-8}}{(10^7)^2}
+\approx 10^{-1}$, whereas the second equation will be around $\text{div}{\mathbf u}\approx \frac{10^{-8}}{10^7} \approx 10^{-15}$. Well, so what this will lead to is this: if the solver wants to make the residual small, it will almost entirely focus on the first set of equations because they are so much bigger, and ignore the divergence equation that describes mass conservation. That's exactly what happens: unless we set the tolerance to extremely small values, the resulting flow field is definitely not divergence free. As an auxiliary problem, it turns out that it is difficult to find a tolerance that always works; in practice, one often ends up with a tolerance that requires 30 or 40 iterations for most time steps, and 10,000 for some others.

    +

    So what's a numerical analyst to do in a case like this? The answer is to start at the root and first make sure that everything is mathematically consistent first. In our case, this means that if we want to solve the system of Stokes equations jointly, we have to scale them so that they all have the same physical dimensions. In our case, this means multiplying the second equation by something that has units $\frac{\text{Pa}\;\text{s}}{\text{m}}$; one choice is to multiply with $\frac{\eta}{L}$ where $L$ is a typical lengthscale in our domain (which experiments show is best chosen to be the diameter of plumes — around 10 km — rather than the diameter of the domain). Using these numbers for $\eta$ and $L$, this factor is around $10^{17}$. So, we now get this for the Stokes system:

    +\begin{eqnarray*}
   -\nabla \cdot (2 \eta \varepsilon ({\mathbf u})) + \nabla p &=&
   \rho(T) \; \mathbf{g},
   \\
   \frac{\eta}{L} \nabla \cdot {\mathbf u} &=& 0.
-\end{eqnarray*} +\end{eqnarray*}" src="form_4156.png"/>

    -

    The trouble with this is that the result is not symmetric any more (we have $\frac{\eta}{L} \nabla \cdot$ at the bottom left, but not its transpose operator at the top right). This, however, can be cured by introducing a scaled pressure $\hat p = \frac{L}{\eta}p$, and we get the scaled equations

    -\begin{eqnarray*}
+<p> The trouble with this is that the result is not symmetric any more (we have <picture><source srcset=$\frac{\eta}{L} \nabla \cdot$ at the bottom left, but not its transpose operator at the top right). This, however, can be cured by introducing a scaled pressure $\hat p = \frac{L}{\eta}p$, and we get the scaled equations

    +\begin{eqnarray*}
   -\nabla \cdot (2 \eta \varepsilon ({\mathbf u})) +
   \nabla \left(\frac{\eta}{L} \hat p\right) &=&
   \rho(T) \; \mathbf{g},
   \\
   \frac{\eta}{L} \nabla \cdot {\mathbf u} &=& 0.
-\end{eqnarray*} +\end{eqnarray*}" src="form_4159.png"/>

    -

    This is now symmetric. Obviously, we can easily recover the original pressure $p$ from the scaled pressure $\hat p$ that we compute as a result of this procedure.

    -

    In the program below, we will introduce a factor EquationData::pressure_scaling that corresponds to $\frac{\eta}{L}$, and we will use this factor in the assembly of the system matrix and preconditioner. Because it is annoying and error prone, we will recover the unscaled pressure immediately following the solution of the linear system, i.e., the solution vector's pressure component will immediately be unscaled to retrieve the physical pressure. Since the solver uses the fact that we can use a good initial guess by extrapolating the previous solutions, we also have to scale the pressure immediately before solving.

    +

    This is now symmetric. Obviously, we can easily recover the original pressure $p$ from the scaled pressure $\hat p$ that we compute as a result of this procedure.

    +

    In the program below, we will introduce a factor EquationData::pressure_scaling that corresponds to $\frac{\eta}{L}$, and we will use this factor in the assembly of the system matrix and preconditioner. Because it is annoying and error prone, we will recover the unscaled pressure immediately following the solution of the linear system, i.e., the solution vector's pressure component will immediately be unscaled to retrieve the physical pressure. Since the solver uses the fact that we can use a good initial guess by extrapolating the previous solutions, we also have to scale the pressure immediately before solving.

    Changes to the Stokes preconditioner and solver

    -

    In this tutorial program, we apply a variant of the preconditioner used in step-31. That preconditioner was built to operate on the system matrix $M$ in block form such that the product matrix

    -\begin{eqnarray*}
+<p>In this tutorial program, we apply a variant of the preconditioner used in <a class=step-31. That preconditioner was built to operate on the system matrix $M$ in block form such that the product matrix

    +\begin{eqnarray*}
   P^{-1} M
   =
   \left(\begin{array}{cc}
@@ -294,24 +294,24 @@
   \left(\begin{array}{cc}
     A & B^T \\ B & 0
   \end{array}\right)
-\end{eqnarray*} +\end{eqnarray*}" src="form_4161.png"/>

    -

    is of a form that Krylov-based iterative solvers like GMRES can solve in a few iterations. We then replaced the exact inverse of $A$ by the action of an AMG preconditioner $\tilde{A}$ based on a vector Laplace matrix, approximated the Schur complement $S = B A^{-1} B^T$ by a mass matrix $M_p$ on the pressure space and wrote an InverseMatrix class for implementing the action of $M_p^{-1}\approx S^{-1}$ on vectors. In the InverseMatrix class, we used a CG solve with an incomplete Cholesky (IC) preconditioner for performing the inner solves.

    -

    An observation one can make is that we use just the action of a preconditioner for approximating the velocity inverse $A^{-1}$ (and the outer GMRES iteration takes care of the approximate character of the inverse), whereas we use a more or less exact inverse for $M_p^{-1}$, realized by a fully converged CG solve. This appears unbalanced, but there's system to this madness: almost all the effort goes into the upper left block to which we apply the AMG preconditioner, whereas even an exact inversion of the pressure mass matrix costs basically nothing. Consequently, if it helps us reduce the overall number of iterations somewhat, then this effort is well spent.

    +

    is of a form that Krylov-based iterative solvers like GMRES can solve in a few iterations. We then replaced the exact inverse of $A$ by the action of an AMG preconditioner $\tilde{A}$ based on a vector Laplace matrix, approximated the Schur complement $S = B A^{-1} B^T$ by a mass matrix $M_p$ on the pressure space and wrote an InverseMatrix class for implementing the action of $M_p^{-1}\approx S^{-1}$ on vectors. In the InverseMatrix class, we used a CG solve with an incomplete Cholesky (IC) preconditioner for performing the inner solves.

    +

    An observation one can make is that we use just the action of a preconditioner for approximating the velocity inverse $A^{-1}$ (and the outer GMRES iteration takes care of the approximate character of the inverse), whereas we use a more or less exact inverse for $M_p^{-1}$, realized by a fully converged CG solve. This appears unbalanced, but there's system to this madness: almost all the effort goes into the upper left block to which we apply the AMG preconditioner, whereas even an exact inversion of the pressure mass matrix costs basically nothing. Consequently, if it helps us reduce the overall number of iterations somewhat, then this effort is well spent.

    That said, even though the solver worked well for step-31, we have a problem here that is a bit more complicated (cells are deformed, the pressure varies by orders of magnitude, and we want to plan ahead for more complicated physics), and so we'll change a few things slightly:

    • For more complex problems, it turns out that using just a single AMG V-cycle as preconditioner is not always sufficient. The outer solver converges just fine most of the time in a reasonable number of iterations (say, less than 50) but there are the occasional time step where it suddenly takes 700 or so. What exactly is going on there is hard to determine, but the problem can be avoided by using a more accurate solver for the top left block. Consequently, we'll want to use a CG iteration to invert the top left block of the preconditioner matrix, and use the AMG as a preconditioner for the CG solver.
    • The downside of this is that, of course, the Stokes preconditioner becomes much more expensive (approximately 10 times more expensive than when we just use a single V-cycle). Our strategy then is this: let's do up to 30 GMRES iterations with just the V-cycle as a preconditioner and if that doesn't yield convergence, then take the best approximation of the Stokes solution obtained after this first round of iterations and use that as the starting guess for iterations where we use the full inner solver with a rather lenient tolerance as preconditioner. In all our experiments this leads to convergence in only a few additional iterations.
    • -
    • One thing we need to pay attention to is that when using a CG with a lenient tolerance in the preconditioner, then $y = \tilde A^{-1} r$ is no longer a linear function of $r$ (it is, of course, if we have a very stringent tolerance in our solver, or if we only apply a single V-cycle). This is a problem since now our preconditioner is no longer a linear operator; in other words, every time GMRES uses it the preconditioner looks different. The standard GMRES solver can't deal with this, leading to slow convergence or even breakdown, but the F-GMRES variant is designed to deal with exactly this kind of situation and we consequently use it.
    • -
    • On the other hand, once we have settled on using F-GMRES we can relax the tolerance used in inverting the preconditioner for $S$. In step-31, we ran a preconditioned CG method on $\tilde S$ until the residual had been reduced by 7 orders of magnitude. Here, we can again be more lenient because we know that the outer preconditioner doesn't suffer.
    • +
    • One thing we need to pay attention to is that when using a CG with a lenient tolerance in the preconditioner, then $y = \tilde A^{-1} r$ is no longer a linear function of $r$ (it is, of course, if we have a very stringent tolerance in our solver, or if we only apply a single V-cycle). This is a problem since now our preconditioner is no longer a linear operator; in other words, every time GMRES uses it the preconditioner looks different. The standard GMRES solver can't deal with this, leading to slow convergence or even breakdown, but the F-GMRES variant is designed to deal with exactly this kind of situation and we consequently use it.
    • +
    • On the other hand, once we have settled on using F-GMRES we can relax the tolerance used in inverting the preconditioner for $S$. In step-31, we ran a preconditioned CG method on $\tilde S$ until the residual had been reduced by 7 orders of magnitude. Here, we can again be more lenient because we know that the outer preconditioner doesn't suffer.
    • In step-31, we used a left preconditioner in which we first invert the top left block of the preconditioner matrix, then apply the bottom left (divergence) one, and then invert the bottom right. In other words, the application of the preconditioner acts as a lower left block triangular matrix. Another option is to use a right preconditioner that here would be upper right block triangulation, i.e., we first invert the bottom right Schur complement, apply the top right (gradient) operator and then invert the elliptic top left block. To a degree, which one to choose is a matter of taste. That said, there is one significant advantage to a right preconditioner in GMRES-type solvers: the residual with which we determine whether we should stop the iteration is the true residual, not the norm of the preconditioned equations. Consequently, it is much simpler to compare it to the stopping criterion we typically use, namely the norm of the right hand side vector. In writing this code we found that the scaling issues we discussed above also made it difficult to determine suitable stopping criteria for left-preconditioned linear systems, and consequently this program uses a right preconditioner.
    • In step-31, we used an IC (incomplete Cholesky) preconditioner for the pressure mass matrix in the Schur complement preconditioner and for the solution of the temperature system. Here, we could in principle do the same, but we do choose an even simpler preconditioner, namely a Jacobi preconditioner for both systems. This is because here we target at massively parallel computations, where the decompositions for IC/ILU would have to be performed block-wise for the locally owned degrees of freedom on each processor. This means, that the preconditioner gets more like a Jacobi preconditioner anyway, so we rather start from that variant straight away. Note that we only use the Jacobi preconditioners for CG solvers with mass matrices, where they give optimal (h-independent) convergence anyway, even though they usually require about twice as many iterations as an IC preconditioner.
    -

    As a final note, let us remark that in step-31 we computed the Schur complement $S=B A^{-1} B^T$ by approximating $-\text{div}(-\eta\Delta)^{-1}\nabla \approx \frac 1{\eta} \mathbf{1}$. Now, however, we have re-scaled the $B$ and $B^T$ operators. So $S$ should now approximate $-\frac{\eta}{L}\text{div}(-\eta\Delta)^{-1}\nabla \frac{\eta}{L} \approx
-\left(\frac{\eta}{L}\right)^2 \frac 1{\eta} \mathbf{1}$. We use the discrete form of the right hand side of this as our approximation $\tilde S$ to $S$.

    +

    As a final note, let us remark that in step-31 we computed the Schur complement $S=B A^{-1} B^T$ by approximating $-\text{div}(-\eta\Delta)^{-1}\nabla \approx \frac 1{\eta} \mathbf{1}$. Now, however, we have re-scaled the $B$ and $B^T$ operators. So $S$ should now approximate $-\frac{\eta}{L}\text{div}(-\eta\Delta)^{-1}\nabla \frac{\eta}{L} \approx
+\left(\frac{\eta}{L}\right)^2 \frac 1{\eta} \mathbf{1}$. We use the discrete form of the right hand side of this as our approximation $\tilde S$ to $S$.

    Changes to the artificial viscosity stabilization

    -

    Similarly to step-31, we will use an artificial viscosity for stabilization based on a residual of the equation. As a difference to step-31, we will provide two slightly different definitions of the stabilization parameter. For $\alpha=1$, we use the same definition as in step-31:

    -\begin{eqnarray*}
+<p>Similarly to <a class=step-31, we will use an artificial viscosity for stabilization based on a residual of the equation. As a difference to step-31, we will provide two slightly different definitions of the stabilization parameter. For $\alpha=1$, we use the same definition as in step-31:

    +\begin{eqnarray*}
   \nu_\alpha(T)|_K
   =
   \nu_1(T)|_K
@@ -323,76 +323,76 @@
     1,
     \frac{\|R_1(T)\|_{L^\infty(K)}}{c(\mathbf{u},T)}
   \right\}
-\end{eqnarray*} +\end{eqnarray*}" src="form_4168.png"/> /usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_33.html differs (HTML document, UTF-8 Unicode text, with very long lines) --- old//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_33.html 2023-08-09 23:39:00.018638440 +0000 +++ new//usr/share/doc/packages/dealii-openmpi2/doxygen/deal.II/step_33.html 2023-08-09 23:39:00.022638469 +0000 @@ -163,17 +163,17 @@ While this program demonstrates the use of automatic differentiation well, it does not express the state of the art in Euler equation solvers. There are much faster and more accurate method for this equation, and you should take a look at step-67 and step-69 to see how this equation can be solved more efficiently.

    Introduction

    Euler flow

    -

    The equations that describe the movement of a compressible, inviscid gas (the so-called Euler equations of gas dynamics) are a basic system of conservation laws. In spatial dimension $d$ they read

    -\[
+<p>The equations that describe the movement of a compressible, inviscid gas (the so-called Euler equations of gas dynamics) are a basic system of conservation laws. In spatial dimension <picture><source srcset=$d$ they read

    +\[
 \partial_t \mathbf{w} + \nabla \cdot \mathbf{F}(\mathbf{w}) =
 \mathbf{G}(\mathbf w),
-\] +\]" src="form_4265.png"/>

    -

    with the solution $\mathbf{w}=(\rho v_1,\ldots,\rho v_d,\rho,
-E)^{\top}$ consisting of $\rho$ the fluid density, ${\mathbf v}=(v_1,\ldots v_d)^T$ the flow velocity (and thus $\rho\mathbf v$ being the linear momentum density), and $E$ the energy density of the gas. We interpret the equations above as $\partial_t \mathbf{w}_i + \nabla \cdot \mathbf{F}_i(\mathbf{w}) = \mathbf
-G_i(\mathbf w)$, $i=1,\ldots,dim+2$.

    -

    For the Euler equations, the flux matrix $\mathbf F$ (or system of flux functions) is defined as (shown here for the case $d=3$)

    -\begin{eqnarray*}
+<p> with the solution <picture><source srcset=$\mathbf{w}=(\rho v_1,\ldots,\rho v_d,\rho,
+E)^{\top}$ consisting of $\rho$ the fluid density, ${\mathbf v}=(v_1,\ldots v_d)^T$ the flow velocity (and thus $\rho\mathbf v$ being the linear momentum density), and $E$ the energy density of the gas. We interpret the equations above as $\partial_t \mathbf{w}_i + \nabla \cdot \mathbf{F}_i(\mathbf{w}) = \mathbf
+G_i(\mathbf w)$, $i=1,\ldots,dim+2$.

    +

    For the Euler equations, the flux matrix $\mathbf F$ (or system of flux functions) is defined as (shown here for the case $d=3$)

    +\begin{eqnarray*}
   \mathbf F(\mathbf w)
   =
   \left(
@@ -185,10 +185,10 @@
     (E+p) v_1 & (E+p) v_2 & (E+p) v_3
   \end{array}
   \right),
-\end{eqnarray*} +\end{eqnarray*}" src="form_4272.png"/>

    and we will choose as particular right hand side forcing only the effects of gravity, described by

    -\begin{eqnarray*}
+<picture><source srcset=\begin{eqnarray*}
   \mathbf G(\mathbf w)
   =
   \left(
@@ -200,43 +200,43 @@
     \rho \mathbf g \cdot \mathbf v
   \end{array}
   \right),
-\end{eqnarray*} +\end{eqnarray*}" src="form_4273.png"/>

    -

    where $\mathbf g=(g_1,g_2,g_3)^T$ denotes the gravity vector. With this, the entire system of equations reads:

    -\begin{eqnarray*}
+<p> where <picture><source srcset=$\mathbf g=(g_1,g_2,g_3)^T$ denotes the gravity vector. With this, the entire system of equations reads:

    +\begin{eqnarray*}
   \partial_t (\rho v_i) + \sum_{s=1}^d \frac{\partial(\rho v_i v_s +
   \delta_{is} p)}{\partial x_s} &=& g_i \rho, \qquad i=1,\dots,d, \\
   \partial_t \rho + \sum_{s=1}^d \frac{\partial(\rho v_s)}{\partial x_s} &=& 0,  \\
   \partial_t E + \sum_{s=1}^d \frac{\partial((E+p)v_s)}{\partial x_s} &=&
   \rho \mathbf g \cdot \mathbf v.
-\end{eqnarray*} +\end{eqnarray*}" src="form_4275.png"/>

    -

    These equations describe, respectively, the conservation of momentum, mass, and energy. The system is closed by a relation that defines the pressure: $p =
-(\gamma -1)(E-\frac{1}{2} \rho |\mathbf v|^2)$. For the constituents of air (mainly nitrogen and oxygen) and other diatomic gases, the ratio of specific heats is $\gamma=1.4$.

    +

    These equations describe, respectively, the conservation of momentum, mass, and energy. The system is closed by a relation that defines the pressure: $p =
+(\gamma -1)(E-\frac{1}{2} \rho |\mathbf v|^2)$. For the constituents of air (mainly nitrogen and oxygen) and other diatomic gases, the ratio of specific heats is $\gamma=1.4$.

    This problem obviously falls into the class of vector-valued problems. A general overview of how to deal with these problems in deal.II can be found in the Handling vector valued problems module.

    Discretization

    -

    Discretization happens in the usual way, taking into account that this is a hyperbolic problem in the same style as the simple one discussed in step-12: We choose a finite element space $V_h$, and integrate our conservation law against our (vector-valued) test function $\mathbf{z} \in V_h$. We then integrate by parts and approximate the boundary flux with a numerical flux $\mathbf{H}$,

    -\begin{eqnarray*}
+<p>Discretization happens in the usual way, taking into account that this is a hyperbolic problem in the same style as the simple one discussed in <a class=step-12: We choose a finite element space $V_h$, and integrate our conservation law against our (vector-valued) test function $\mathbf{z} \in V_h$. We then integrate by parts and approximate the boundary flux with a numerical flux $\mathbf{H}$,

    +\begin{eqnarray*}
 &&\int_{\Omega} (\partial_t \mathbf{w}, \mathbf{z}) + (\nabla \cdot \mathbf{F}(\mathbf{w}), \mathbf{z}) \\
 &\approx &\int_{\Omega} (\partial_t \mathbf{w}, \mathbf{z}) - (\mathbf{F}(\mathbf{w}), \nabla \mathbf{z}) + h^{\eta}(\nabla \mathbf{w} , \nabla \mathbf{z}) + \int_{\partial \Omega} (\mathbf{H}(\mathbf{w}^+, \mathbf{w}^-, \mathbf{n}), \mathbf{z}^+),
-\end{eqnarray*} +\end{eqnarray*}" src="form_4280.png"/>

    -

    where a superscript $+$ denotes the interior trace of a function, and $-$ represents the outer trace. The diffusion term $h^{\eta}(\nabla \mathbf{w} , \nabla \mathbf{z})$ is introduced strictly for stability, where $h$ is the mesh size and $\eta$ is a parameter prescribing how much diffusion to add.

    -

    On the boundary, we have to say what the outer trace $\mathbf{w}^-$ is. Depending on the boundary condition, we prescribe either of the following: