From: wolf Date: Fri, 14 Jun 2002 10:11:23 +0000 (+0000) Subject: Commit report on assembling matrices. X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f56c2ead8ec34b2d61ddddb07a60a8c144d8b702;p=dealii-svn.git Commit report on assembling matrices. git-svn-id: https://svn.dealii.org/trunk@6114 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/reports/assemble/assemble.css b/deal.II/doc/reports/assemble/assemble.css new file mode 100644 index 0000000000..d1824aff42 --- /dev/null +++ b/deal.II/doc/reports/assemble/assemble.css @@ -0,0 +1,30 @@ +/* Century Schoolbook font is very similar to Computer Modern Math: cmmi */ +.MATH { font-family: "Century Schoolbook", serif; } +.MATH I { font-family: "Century Schoolbook", serif; font-style: italic } +.BOLDMATH { font-family: "Century Schoolbook", serif; font-weight: bold } + +/* implement both fixed-size and relative sizes */ +SMALL.XTINY { font-size : xx-small } +SMALL.TINY { font-size : x-small } +SMALL.SCRIPTSIZE { font-size : smaller } +SMALL.FOOTNOTESIZE { font-size : small } +SMALL.SMALL { } +BIG.LARGE { } +BIG.XLARGE { font-size : large } +BIG.XXLARGE { font-size : x-large } +BIG.HUGE { font-size : larger } +BIG.XHUGE { font-size : xx-large } + +/* heading styles */ +H1 { } +H2 { } +H3 { } +H4 { } +H5 { } + +/* mathematics styles */ +DIV.displaymath { } /* math displays */ +TD.eqno { } /* equation-number cells */ + + +/* document-specific styles come next */ diff --git a/deal.II/doc/reports/assemble/img1.gif b/deal.II/doc/reports/assemble/img1.gif new file mode 100644 index 0000000000..d6b9f87468 Binary files /dev/null and b/deal.II/doc/reports/assemble/img1.gif differ diff --git a/deal.II/doc/reports/assemble/img10.gif b/deal.II/doc/reports/assemble/img10.gif new file mode 100644 index 0000000000..aaaa4feb77 Binary files /dev/null and b/deal.II/doc/reports/assemble/img10.gif differ diff --git a/deal.II/doc/reports/assemble/img11.gif b/deal.II/doc/reports/assemble/img11.gif new file mode 100644 index 0000000000..e73eb272d6 Binary files /dev/null and b/deal.II/doc/reports/assemble/img11.gif differ diff --git a/deal.II/doc/reports/assemble/img12.gif b/deal.II/doc/reports/assemble/img12.gif new file mode 100644 index 0000000000..48ac2d85d7 Binary files /dev/null and b/deal.II/doc/reports/assemble/img12.gif differ diff --git a/deal.II/doc/reports/assemble/img13.gif b/deal.II/doc/reports/assemble/img13.gif new file mode 100644 index 0000000000..c89091bd46 Binary files /dev/null and b/deal.II/doc/reports/assemble/img13.gif differ diff --git a/deal.II/doc/reports/assemble/img14.gif b/deal.II/doc/reports/assemble/img14.gif new file mode 100644 index 0000000000..918bd25602 Binary files /dev/null and b/deal.II/doc/reports/assemble/img14.gif differ diff --git a/deal.II/doc/reports/assemble/img15.gif b/deal.II/doc/reports/assemble/img15.gif new file mode 100644 index 0000000000..f3eacb2aa5 Binary files /dev/null and b/deal.II/doc/reports/assemble/img15.gif differ diff --git a/deal.II/doc/reports/assemble/img16.gif b/deal.II/doc/reports/assemble/img16.gif new file mode 100644 index 0000000000..abca97a9ba Binary files /dev/null and b/deal.II/doc/reports/assemble/img16.gif differ diff --git a/deal.II/doc/reports/assemble/img17.gif b/deal.II/doc/reports/assemble/img17.gif new file mode 100644 index 0000000000..742ed0363e Binary files /dev/null and b/deal.II/doc/reports/assemble/img17.gif differ diff --git a/deal.II/doc/reports/assemble/img18.gif b/deal.II/doc/reports/assemble/img18.gif new file mode 100644 index 0000000000..d28fe1b8f1 Binary files /dev/null and b/deal.II/doc/reports/assemble/img18.gif differ diff --git a/deal.II/doc/reports/assemble/img19.gif b/deal.II/doc/reports/assemble/img19.gif new file mode 100644 index 0000000000..78d68bbb4d Binary files /dev/null and b/deal.II/doc/reports/assemble/img19.gif differ diff --git a/deal.II/doc/reports/assemble/img2.gif b/deal.II/doc/reports/assemble/img2.gif new file mode 100644 index 0000000000..7c2f274b89 Binary files /dev/null and b/deal.II/doc/reports/assemble/img2.gif differ diff --git a/deal.II/doc/reports/assemble/img20.gif b/deal.II/doc/reports/assemble/img20.gif new file mode 100644 index 0000000000..2c840cb524 Binary files /dev/null and b/deal.II/doc/reports/assemble/img20.gif differ diff --git a/deal.II/doc/reports/assemble/img21.gif b/deal.II/doc/reports/assemble/img21.gif new file mode 100644 index 0000000000..4ee5086e35 Binary files /dev/null and b/deal.II/doc/reports/assemble/img21.gif differ diff --git a/deal.II/doc/reports/assemble/img22.gif b/deal.II/doc/reports/assemble/img22.gif new file mode 100644 index 0000000000..47342d25ea Binary files /dev/null and b/deal.II/doc/reports/assemble/img22.gif differ diff --git a/deal.II/doc/reports/assemble/img23.gif b/deal.II/doc/reports/assemble/img23.gif new file mode 100644 index 0000000000..a7cd819a92 Binary files /dev/null and b/deal.II/doc/reports/assemble/img23.gif differ diff --git a/deal.II/doc/reports/assemble/img24.gif b/deal.II/doc/reports/assemble/img24.gif new file mode 100644 index 0000000000..b44ef076b6 Binary files /dev/null and b/deal.II/doc/reports/assemble/img24.gif differ diff --git a/deal.II/doc/reports/assemble/img25.gif b/deal.II/doc/reports/assemble/img25.gif new file mode 100644 index 0000000000..eb8edea871 Binary files /dev/null and b/deal.II/doc/reports/assemble/img25.gif differ diff --git a/deal.II/doc/reports/assemble/img26.gif b/deal.II/doc/reports/assemble/img26.gif new file mode 100644 index 0000000000..2ef4c1d073 Binary files /dev/null and b/deal.II/doc/reports/assemble/img26.gif differ diff --git a/deal.II/doc/reports/assemble/img27.gif b/deal.II/doc/reports/assemble/img27.gif new file mode 100644 index 0000000000..a9c26a33cb Binary files /dev/null and b/deal.II/doc/reports/assemble/img27.gif differ diff --git a/deal.II/doc/reports/assemble/img28.gif b/deal.II/doc/reports/assemble/img28.gif new file mode 100644 index 0000000000..002b77a932 Binary files /dev/null and b/deal.II/doc/reports/assemble/img28.gif differ diff --git a/deal.II/doc/reports/assemble/img29.gif b/deal.II/doc/reports/assemble/img29.gif new file mode 100644 index 0000000000..7793704481 Binary files /dev/null and b/deal.II/doc/reports/assemble/img29.gif differ diff --git a/deal.II/doc/reports/assemble/img3.gif b/deal.II/doc/reports/assemble/img3.gif new file mode 100644 index 0000000000..8a05126914 Binary files /dev/null and b/deal.II/doc/reports/assemble/img3.gif differ diff --git a/deal.II/doc/reports/assemble/img30.gif b/deal.II/doc/reports/assemble/img30.gif new file mode 100644 index 0000000000..d8e107d117 Binary files /dev/null and b/deal.II/doc/reports/assemble/img30.gif differ diff --git a/deal.II/doc/reports/assemble/img31.gif b/deal.II/doc/reports/assemble/img31.gif new file mode 100644 index 0000000000..c19ad2ace2 Binary files /dev/null and b/deal.II/doc/reports/assemble/img31.gif differ diff --git a/deal.II/doc/reports/assemble/img32.gif b/deal.II/doc/reports/assemble/img32.gif new file mode 100644 index 0000000000..e17f19d9e0 Binary files /dev/null and b/deal.II/doc/reports/assemble/img32.gif differ diff --git a/deal.II/doc/reports/assemble/img33.gif b/deal.II/doc/reports/assemble/img33.gif new file mode 100644 index 0000000000..8ebedd0720 Binary files /dev/null and b/deal.II/doc/reports/assemble/img33.gif differ diff --git a/deal.II/doc/reports/assemble/img34.gif b/deal.II/doc/reports/assemble/img34.gif new file mode 100644 index 0000000000..d6de723df3 Binary files /dev/null and b/deal.II/doc/reports/assemble/img34.gif differ diff --git a/deal.II/doc/reports/assemble/img35.gif b/deal.II/doc/reports/assemble/img35.gif new file mode 100644 index 0000000000..bbc5bc6912 Binary files /dev/null and b/deal.II/doc/reports/assemble/img35.gif differ diff --git a/deal.II/doc/reports/assemble/img36.gif b/deal.II/doc/reports/assemble/img36.gif new file mode 100644 index 0000000000..1214cb8369 Binary files /dev/null and b/deal.II/doc/reports/assemble/img36.gif differ diff --git a/deal.II/doc/reports/assemble/img37.gif b/deal.II/doc/reports/assemble/img37.gif new file mode 100644 index 0000000000..9aa700db13 Binary files /dev/null and b/deal.II/doc/reports/assemble/img37.gif differ diff --git a/deal.II/doc/reports/assemble/img38.gif b/deal.II/doc/reports/assemble/img38.gif new file mode 100644 index 0000000000..5e639468da Binary files /dev/null and b/deal.II/doc/reports/assemble/img38.gif differ diff --git a/deal.II/doc/reports/assemble/img39.gif b/deal.II/doc/reports/assemble/img39.gif new file mode 100644 index 0000000000..255d05e0de Binary files /dev/null and b/deal.II/doc/reports/assemble/img39.gif differ diff --git a/deal.II/doc/reports/assemble/img4.gif b/deal.II/doc/reports/assemble/img4.gif new file mode 100644 index 0000000000..e2aff43f8a Binary files /dev/null and b/deal.II/doc/reports/assemble/img4.gif differ diff --git a/deal.II/doc/reports/assemble/img40.gif b/deal.II/doc/reports/assemble/img40.gif new file mode 100644 index 0000000000..aac5a4b07b Binary files /dev/null and b/deal.II/doc/reports/assemble/img40.gif differ diff --git a/deal.II/doc/reports/assemble/img41.gif b/deal.II/doc/reports/assemble/img41.gif new file mode 100644 index 0000000000..6930a1e5eb Binary files /dev/null and b/deal.II/doc/reports/assemble/img41.gif differ diff --git a/deal.II/doc/reports/assemble/img42.gif b/deal.II/doc/reports/assemble/img42.gif new file mode 100644 index 0000000000..36e9d63c91 Binary files /dev/null and b/deal.II/doc/reports/assemble/img42.gif differ diff --git a/deal.II/doc/reports/assemble/img43.gif b/deal.II/doc/reports/assemble/img43.gif new file mode 100644 index 0000000000..efde6fcc0b Binary files /dev/null and b/deal.II/doc/reports/assemble/img43.gif differ diff --git a/deal.II/doc/reports/assemble/img44.gif b/deal.II/doc/reports/assemble/img44.gif new file mode 100644 index 0000000000..afe88c6b60 Binary files /dev/null and b/deal.II/doc/reports/assemble/img44.gif differ diff --git a/deal.II/doc/reports/assemble/img45.gif b/deal.II/doc/reports/assemble/img45.gif new file mode 100644 index 0000000000..d64b0e259e Binary files /dev/null and b/deal.II/doc/reports/assemble/img45.gif differ diff --git a/deal.II/doc/reports/assemble/img46.gif b/deal.II/doc/reports/assemble/img46.gif new file mode 100644 index 0000000000..6034c45bbe Binary files /dev/null and b/deal.II/doc/reports/assemble/img46.gif differ diff --git a/deal.II/doc/reports/assemble/img47.gif b/deal.II/doc/reports/assemble/img47.gif new file mode 100644 index 0000000000..159a7faf07 Binary files /dev/null and b/deal.II/doc/reports/assemble/img47.gif differ diff --git a/deal.II/doc/reports/assemble/img48.gif b/deal.II/doc/reports/assemble/img48.gif new file mode 100644 index 0000000000..6c8fa26024 Binary files /dev/null and b/deal.II/doc/reports/assemble/img48.gif differ diff --git a/deal.II/doc/reports/assemble/img49.gif b/deal.II/doc/reports/assemble/img49.gif new file mode 100644 index 0000000000..d52efb8cd2 Binary files /dev/null and b/deal.II/doc/reports/assemble/img49.gif differ diff --git a/deal.II/doc/reports/assemble/img5.gif b/deal.II/doc/reports/assemble/img5.gif new file mode 100644 index 0000000000..c9e8e7497b Binary files /dev/null and b/deal.II/doc/reports/assemble/img5.gif differ diff --git a/deal.II/doc/reports/assemble/img50.gif b/deal.II/doc/reports/assemble/img50.gif new file mode 100644 index 0000000000..0053aa24e8 Binary files /dev/null and b/deal.II/doc/reports/assemble/img50.gif differ diff --git a/deal.II/doc/reports/assemble/img51.gif b/deal.II/doc/reports/assemble/img51.gif new file mode 100644 index 0000000000..93bd487395 Binary files /dev/null and b/deal.II/doc/reports/assemble/img51.gif differ diff --git a/deal.II/doc/reports/assemble/img52.gif b/deal.II/doc/reports/assemble/img52.gif new file mode 100644 index 0000000000..96e89ccc0d Binary files /dev/null and b/deal.II/doc/reports/assemble/img52.gif differ diff --git a/deal.II/doc/reports/assemble/img53.gif b/deal.II/doc/reports/assemble/img53.gif new file mode 100644 index 0000000000..98014b04df Binary files /dev/null and b/deal.II/doc/reports/assemble/img53.gif differ diff --git a/deal.II/doc/reports/assemble/img54.gif b/deal.II/doc/reports/assemble/img54.gif new file mode 100644 index 0000000000..72f9c4a4ea Binary files /dev/null and b/deal.II/doc/reports/assemble/img54.gif differ diff --git a/deal.II/doc/reports/assemble/img55.gif b/deal.II/doc/reports/assemble/img55.gif new file mode 100644 index 0000000000..0536f80f7f Binary files /dev/null and b/deal.II/doc/reports/assemble/img55.gif differ diff --git a/deal.II/doc/reports/assemble/img56.gif b/deal.II/doc/reports/assemble/img56.gif new file mode 100644 index 0000000000..6e37c133b6 Binary files /dev/null and b/deal.II/doc/reports/assemble/img56.gif differ diff --git a/deal.II/doc/reports/assemble/img57.gif b/deal.II/doc/reports/assemble/img57.gif new file mode 100644 index 0000000000..e75a97361e Binary files /dev/null and b/deal.II/doc/reports/assemble/img57.gif differ diff --git a/deal.II/doc/reports/assemble/img58.gif b/deal.II/doc/reports/assemble/img58.gif new file mode 100644 index 0000000000..8ad71c8dcc Binary files /dev/null and b/deal.II/doc/reports/assemble/img58.gif differ diff --git a/deal.II/doc/reports/assemble/img59.gif b/deal.II/doc/reports/assemble/img59.gif new file mode 100644 index 0000000000..f898b00d9a Binary files /dev/null and b/deal.II/doc/reports/assemble/img59.gif differ diff --git a/deal.II/doc/reports/assemble/img6.gif b/deal.II/doc/reports/assemble/img6.gif new file mode 100644 index 0000000000..596606c14d Binary files /dev/null and b/deal.II/doc/reports/assemble/img6.gif differ diff --git a/deal.II/doc/reports/assemble/img60.gif b/deal.II/doc/reports/assemble/img60.gif new file mode 100644 index 0000000000..4d219c6ac6 Binary files /dev/null and b/deal.II/doc/reports/assemble/img60.gif differ diff --git a/deal.II/doc/reports/assemble/img61.gif b/deal.II/doc/reports/assemble/img61.gif new file mode 100644 index 0000000000..c812f39445 Binary files /dev/null and b/deal.II/doc/reports/assemble/img61.gif differ diff --git a/deal.II/doc/reports/assemble/img62.gif b/deal.II/doc/reports/assemble/img62.gif new file mode 100644 index 0000000000..1771abb767 Binary files /dev/null and b/deal.II/doc/reports/assemble/img62.gif differ diff --git a/deal.II/doc/reports/assemble/img63.gif b/deal.II/doc/reports/assemble/img63.gif new file mode 100644 index 0000000000..f19edb894e Binary files /dev/null and b/deal.II/doc/reports/assemble/img63.gif differ diff --git a/deal.II/doc/reports/assemble/img64.gif b/deal.II/doc/reports/assemble/img64.gif new file mode 100644 index 0000000000..781dbf8c24 Binary files /dev/null and b/deal.II/doc/reports/assemble/img64.gif differ diff --git a/deal.II/doc/reports/assemble/img65.gif b/deal.II/doc/reports/assemble/img65.gif new file mode 100644 index 0000000000..ef1f07b8b0 Binary files /dev/null and b/deal.II/doc/reports/assemble/img65.gif differ diff --git a/deal.II/doc/reports/assemble/img66.gif b/deal.II/doc/reports/assemble/img66.gif new file mode 100644 index 0000000000..89a9c89147 Binary files /dev/null and b/deal.II/doc/reports/assemble/img66.gif differ diff --git a/deal.II/doc/reports/assemble/img67.gif b/deal.II/doc/reports/assemble/img67.gif new file mode 100644 index 0000000000..74852b156f Binary files /dev/null and b/deal.II/doc/reports/assemble/img67.gif differ diff --git a/deal.II/doc/reports/assemble/img68.gif b/deal.II/doc/reports/assemble/img68.gif new file mode 100644 index 0000000000..32d7aa9d6b Binary files /dev/null and b/deal.II/doc/reports/assemble/img68.gif differ diff --git a/deal.II/doc/reports/assemble/img69.gif b/deal.II/doc/reports/assemble/img69.gif new file mode 100644 index 0000000000..852f7187a0 Binary files /dev/null and b/deal.II/doc/reports/assemble/img69.gif differ diff --git a/deal.II/doc/reports/assemble/img7.gif b/deal.II/doc/reports/assemble/img7.gif new file mode 100644 index 0000000000..4ea752380f Binary files /dev/null and b/deal.II/doc/reports/assemble/img7.gif differ diff --git a/deal.II/doc/reports/assemble/img70.gif b/deal.II/doc/reports/assemble/img70.gif new file mode 100644 index 0000000000..4db374d678 Binary files /dev/null and b/deal.II/doc/reports/assemble/img70.gif differ diff --git a/deal.II/doc/reports/assemble/img71.gif b/deal.II/doc/reports/assemble/img71.gif new file mode 100644 index 0000000000..233c0f45a8 Binary files /dev/null and b/deal.II/doc/reports/assemble/img71.gif differ diff --git a/deal.II/doc/reports/assemble/img72.gif b/deal.II/doc/reports/assemble/img72.gif new file mode 100644 index 0000000000..3b49c00e3f Binary files /dev/null and b/deal.II/doc/reports/assemble/img72.gif differ diff --git a/deal.II/doc/reports/assemble/img73.gif b/deal.II/doc/reports/assemble/img73.gif new file mode 100644 index 0000000000..936e029c88 Binary files /dev/null and b/deal.II/doc/reports/assemble/img73.gif differ diff --git a/deal.II/doc/reports/assemble/img74.gif b/deal.II/doc/reports/assemble/img74.gif new file mode 100644 index 0000000000..a5539ec3ef Binary files /dev/null and b/deal.II/doc/reports/assemble/img74.gif differ diff --git a/deal.II/doc/reports/assemble/img75.gif b/deal.II/doc/reports/assemble/img75.gif new file mode 100644 index 0000000000..9bf6432d29 Binary files /dev/null and b/deal.II/doc/reports/assemble/img75.gif differ diff --git a/deal.II/doc/reports/assemble/img76.gif b/deal.II/doc/reports/assemble/img76.gif new file mode 100644 index 0000000000..dc0048143d Binary files /dev/null and b/deal.II/doc/reports/assemble/img76.gif differ diff --git a/deal.II/doc/reports/assemble/img77.gif b/deal.II/doc/reports/assemble/img77.gif new file mode 100644 index 0000000000..3e08c35e42 Binary files /dev/null and b/deal.II/doc/reports/assemble/img77.gif differ diff --git a/deal.II/doc/reports/assemble/img78.gif b/deal.II/doc/reports/assemble/img78.gif new file mode 100644 index 0000000000..a915a75bfd Binary files /dev/null and b/deal.II/doc/reports/assemble/img78.gif differ diff --git a/deal.II/doc/reports/assemble/img79.gif b/deal.II/doc/reports/assemble/img79.gif new file mode 100644 index 0000000000..9ae0de6db3 Binary files /dev/null and b/deal.II/doc/reports/assemble/img79.gif differ diff --git a/deal.II/doc/reports/assemble/img8.gif b/deal.II/doc/reports/assemble/img8.gif new file mode 100644 index 0000000000..43fe3e7f2b Binary files /dev/null and b/deal.II/doc/reports/assemble/img8.gif differ diff --git a/deal.II/doc/reports/assemble/img80.gif b/deal.II/doc/reports/assemble/img80.gif new file mode 100644 index 0000000000..affbada694 Binary files /dev/null and b/deal.II/doc/reports/assemble/img80.gif differ diff --git a/deal.II/doc/reports/assemble/img81.gif b/deal.II/doc/reports/assemble/img81.gif new file mode 100644 index 0000000000..f2bc847f57 Binary files /dev/null and b/deal.II/doc/reports/assemble/img81.gif differ diff --git a/deal.II/doc/reports/assemble/img82.gif b/deal.II/doc/reports/assemble/img82.gif new file mode 100644 index 0000000000..3999439939 Binary files /dev/null and b/deal.II/doc/reports/assemble/img82.gif differ diff --git a/deal.II/doc/reports/assemble/img83.gif b/deal.II/doc/reports/assemble/img83.gif new file mode 100644 index 0000000000..b45068e0b5 Binary files /dev/null and b/deal.II/doc/reports/assemble/img83.gif differ diff --git a/deal.II/doc/reports/assemble/img84.gif b/deal.II/doc/reports/assemble/img84.gif new file mode 100644 index 0000000000..9207600c6e Binary files /dev/null and b/deal.II/doc/reports/assemble/img84.gif differ diff --git a/deal.II/doc/reports/assemble/img85.gif b/deal.II/doc/reports/assemble/img85.gif new file mode 100644 index 0000000000..a6bbaa36e1 Binary files /dev/null and b/deal.II/doc/reports/assemble/img85.gif differ diff --git a/deal.II/doc/reports/assemble/img86.gif b/deal.II/doc/reports/assemble/img86.gif new file mode 100644 index 0000000000..e9bdeb31c8 Binary files /dev/null and b/deal.II/doc/reports/assemble/img86.gif differ diff --git a/deal.II/doc/reports/assemble/img87.gif b/deal.II/doc/reports/assemble/img87.gif new file mode 100644 index 0000000000..0e4d10b3a5 Binary files /dev/null and b/deal.II/doc/reports/assemble/img87.gif differ diff --git a/deal.II/doc/reports/assemble/img88.gif b/deal.II/doc/reports/assemble/img88.gif new file mode 100644 index 0000000000..5bd558f521 Binary files /dev/null and b/deal.II/doc/reports/assemble/img88.gif differ diff --git a/deal.II/doc/reports/assemble/img89.gif b/deal.II/doc/reports/assemble/img89.gif new file mode 100644 index 0000000000..5f489d9b68 Binary files /dev/null and b/deal.II/doc/reports/assemble/img89.gif differ diff --git a/deal.II/doc/reports/assemble/img9.gif b/deal.II/doc/reports/assemble/img9.gif new file mode 100644 index 0000000000..6b8151632b Binary files /dev/null and b/deal.II/doc/reports/assemble/img9.gif differ diff --git a/deal.II/doc/reports/assemble/img90.gif b/deal.II/doc/reports/assemble/img90.gif new file mode 100644 index 0000000000..9cfeed2fb6 Binary files /dev/null and b/deal.II/doc/reports/assemble/img90.gif differ diff --git a/deal.II/doc/reports/assemble/img91.gif b/deal.II/doc/reports/assemble/img91.gif new file mode 100644 index 0000000000..5c92644af9 Binary files /dev/null and b/deal.II/doc/reports/assemble/img91.gif differ diff --git a/deal.II/doc/reports/assemble/img92.gif b/deal.II/doc/reports/assemble/img92.gif new file mode 100644 index 0000000000..26d549bd88 Binary files /dev/null and b/deal.II/doc/reports/assemble/img92.gif differ diff --git a/deal.II/doc/reports/assemble/img93.gif b/deal.II/doc/reports/assemble/img93.gif new file mode 100644 index 0000000000..784eba0d76 Binary files /dev/null and b/deal.II/doc/reports/assemble/img93.gif differ diff --git a/deal.II/doc/reports/assemble/img94.gif b/deal.II/doc/reports/assemble/img94.gif new file mode 100644 index 0000000000..7097f9c50c Binary files /dev/null and b/deal.II/doc/reports/assemble/img94.gif differ diff --git a/deal.II/doc/reports/assemble/img95.gif b/deal.II/doc/reports/assemble/img95.gif new file mode 100644 index 0000000000..bf8a8497c3 Binary files /dev/null and b/deal.II/doc/reports/assemble/img95.gif differ diff --git a/deal.II/doc/reports/assemble/img96.gif b/deal.II/doc/reports/assemble/img96.gif new file mode 100644 index 0000000000..8134a66931 Binary files /dev/null and b/deal.II/doc/reports/assemble/img96.gif differ diff --git a/deal.II/doc/reports/assemble/index.html b/deal.II/doc/reports/assemble/index.html new file mode 100644 index 0000000000..25f5eb648e --- /dev/null +++ b/deal.II/doc/reports/assemble/index.html @@ -0,0 +1,151 @@ + + + + + +assemble + + + + + + + + + + + + + + + + + +next +up +previous +
+ Next: Introduction +
+
+ + +

+

+
+
Assembling matrices in deal.II + +
+

+

+
+
+
+

+

+
Wolfgang Bangerth +
+ETH Zürich, Switzerland +
+
+May 2002 +
+
+ +

+


+ + + +

Overview

+ +

+Assembling the system matrix for finite element discretizations is standard, +at least as far as scalar problems are concerned. However, things become a +little more complicated in implementations once problems are vector-valued, +and in particular if finite elements are used in which different components of +vector-valued shape functions are coupled, such as for example for +divergence-free elements. + +

+It is this case that we are interested in in this report, and we will discuss +the implementational details user programs must follow if they want to use +such elements with deal.II. In order to explain the problem in a +simple way, we start by reviewing the algorithms that are used, first for the +scalar case, then for the case of ``simple'' vector-valued finite elements, +and finally for the most general case. However, we do not intend to give an +introduction into the derivation of finite element methods, or of posing a +partial differential equation in weak form. + +

+The interface for vector-valued finite element shape functions with more than +one non-zero component that is described in this report is presently being +implemented, and will be merged with the library after version 3.4 is +released. Thus, it will be part of version 3.5 or 4.0 of the library, +depending on which version number we will assign to the successor of 3.4. By +then, the library will also contain an implementation of Nedelec elements, for +which these techniques are necessary. The interface for primitive +vector-valued shape functions, for which only one vector component is +non-zero, has been part of the library since its publication with version 3.0. + + +

Table of contents

+ + + + + +

+
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node10.html b/deal.II/doc/reports/assemble/node10.html new file mode 100644 index 0000000000..f5d49fc212 --- /dev/null +++ b/deal.II/doc/reports/assemble/node10.html @@ -0,0 +1,156 @@ + + + + + +Assembling vector-valued problems: The complicated case + + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: Getting information about shape + Up: assemble + Previous: The Stokes equations +
+
+ + +

+Assembling vector-valued problems: The complicated case +

+ +

+The more complicated case is when more than one component of a vector-valued +shape function is non-zero, i.e. the representation +

+
+ + + +
$\displaystyle \Phi_i(\vec x) = \left( 0, \dots, 0, \varphi_i(\vec x), 0, \ldots, 0\right)^T,$ +   
+

+does not hold any more. The usual case where this happens is when shape +functions have to satisfy certain constraints, such as that they should have +zero divergence or curl, or when the normal fluxes at some points, e.g. the +face centers, are the degrees of freedom: + +$ \vec n\cdot \Phi_i(x_a) = \delta_{ia}$. In this case, the individual +components of a shape function are no more independent, and thus cannot be +chosen such that only one component is non-zero. + +

+What happens in this case? First, the function +FiniteElement::system_to_component_index does not make much sense +any more, since a shape function $ \Phi_i$ cannot be associated with only one +vector component any more. Calling this function for basis functions $ \Phi_i$ +that are not restricted to only one non-zero component will thus yield an +exception being thrown. + +

+Second, the functions FEValues::shape_value and +FEValues::shape_grad returning the values and gradients of the only +non-zero component of a shape function at a quadrature point cannot work any +more, since there are now more than only one non-zero components for some or +all values of $ i$. For those shape function for which this holds, you will +again get an exception upon calling these functions. + +

+


+ +Subsections + + + +
+ + +next + +up + +previous +
+ Next: Getting information about shape + Up: assemble + Previous: The Stokes equations + +
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node11.html b/deal.II/doc/reports/assemble/node11.html new file mode 100644 index 0000000000..b537efd228 --- /dev/null +++ b/deal.II/doc/reports/assemble/node11.html @@ -0,0 +1,153 @@ + + + + + +Getting information about shape functions + + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: Evaluating shape functions + Up: Assembling vector-valued problems: The + Previous: Assembling vector-valued problems: The +
+
+ + +

+Getting information about shape functions +

+ +

+So how do you find out whether calling these functions is ok or not? In other +words, how do you know whether shape function $ \Phi_i$ has only one non-zero +component, or more? For this, there are two functions: +FiniteElement::is_primitive(i) returns as a bool whether +the shape function has only one non-zero component. For example, for a + +$ Q^2/Q^2/Q^1$ element, this would be true for all 22 shape functions. +For a finite element for which every shape function is non-zero in more than +one component, it would be false for all indices $ i$. It might also +be true for only some shape functions, for example if the velocity +components of the Stokes discretization are done using some more complicated +element, but the pressure component with a $ Q^1$, then it would be +true for the pressure shape functions, but false otherwise. + +

+Second, the FiniteElement::n_nonzero_components(i) function returns +in how many components the $ i$th shape function is non-zero. Again, for the + +$ Q^2/Q^2/Q^1$ combination, this would yield the value 1 for all allowed +indices $ i$. For coupled elements, it would be greater than 1. + +

+Third, you may sometimes want to know in which components a certain shape +function is non-zero. For this, the +FiniteElement::get_nonzero_components(i) function is the right thing: it +returns a reference to a vector of boolean values, one for each component of +the vector-valued finite element, and the values indicate whether the shape +function is non-zero for each of them. + +

+Note that if you have the result of +FiniteElement::get_nonzero_components(i), then the result of +FiniteElement::n_nonzero_components(i) is simply the number of +true values in the array returned by the first function. Likewise, +FiniteElement::is_primitive(i) is simply whether +FiniteElement::n_nonzero_components(i) returned a value other than +1. The functions are thus redundant in some way, but useful nevertheless. Of +course, the values of the FiniteElement::is_primitive(i) +and FiniteElement::n_nonzero_components(i) functions are not +recomputed every time based on the result of some other function, but are +cached once at the time of construction of a finite element object. + +

+


+ + +next + +up + +previous +
+ Next: Evaluating shape functions + Up: Assembling vector-valued problems: The + Previous: Assembling vector-valued problems: The + +
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node12.html b/deal.II/doc/reports/assemble/node12.html new file mode 100644 index 0000000000..879e388d9f --- /dev/null +++ b/deal.II/doc/reports/assemble/node12.html @@ -0,0 +1,94 @@ + + + + + +Evaluating shape functions + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: The elastic equations + Up: Assembling vector-valued problems: The + Previous: Getting information about shape +
+
+ + +

+Evaluating shape functions +

+ +

+Now, we have seen which functions cannot be called for non-primitive shape +functions, and also how to find out about shape functions and whether they are +primitive and the like. Yet, we don't have replacements for the functions that +cannot be called, so here they are: instead of FEValues::shape_value +and FEValues::shape_grad, call +FEValues::shape_value_component and +FEValues::shape_grad_component. These functions take as arguments +first the number of the shape function, and second the number of the +quadrature point (these are also the arguments of the original functions), but +now as additional third argument the vector component. + +

+Of course, these functions can be called on primitive shape functions as +well. In that case, the following holds: + +

+The same of course also holds for +FEValues::shape_grad_component(i,q,c) and +FEValues::shape_2nd_derivative_component(i,q,c). + +

+


+
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node13.html b/deal.II/doc/reports/assemble/node13.html new file mode 100644 index 0000000000..a547f6ff95 --- /dev/null +++ b/deal.II/doc/reports/assemble/node13.html @@ -0,0 +1,149 @@ + + + + + +The elastic equations + + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: The Stokes equations + Up: Assembling vector-valued problems: The + Previous: Evaluating shape functions +
+
+ + +

+The elastic equations +

+ +

+With the above, we can now assemble the matrix for the elastic equation in +mostly the same way as before. The difference is that for each shape function, +we have to loop over all components. The code then looks like this (compare +this with the one in Section 5.1): +

+  for (unsigned int i=0; i<fe.dofs_per_cell; ++i)
+    for (unsigned int comp_i=0; comp_i<fe.n_components(); ++comp_i)
+      for (unsigned int j=0; j<fe.dofs_per_cell; ++j)
+        for (unsigned int comp_j=0; comp_j<fe.n_components(); ++comp_j)
+          for (unsigned int q=0; q<n_q_points; ++q) 
+            {
+                           // first assemble part with lambda+mu
+              cell_matrix(i,j)
+                 += ((lambda+mu)                       *
+                     fe_values.shape_grad_component(i,q,comp_i)[comp_i] * 
+                     fe_values.shape_grad_component(j,q,comp_j)[comp_j] *
+                     fe_values.JxW(q)); 
+
+                           // then part with mu only
+              if (comp_i == comp_j)
+                cell_matrix(i,j)
+                  += (mu                           *
+                      (fe_values.shape_grad_component(i,q,comp_i) * 
+                       fe_values.shape_grad_component(j,q,comp_j)  )*
+                       fe_values.JxW(q)); 
+            };
+
+If you dislike this particular order of the loops, you can reorder them as you +like, as they are independent. + +

+The code as shown above can be optimized. For example, instead of +unconditionally performing the loop over all components of shape functions $ i$ +of $ j$, we might first ask whether these shape functions are primitive, using +fe.is_primitive(i), and use the loop only if the result is false; +if, on the other hand, the result is true, we only need to set +comp_i to the fixed value +fe.system_to_component_index(i).first, and likewise for shape +function $ j$. + +

+Another possibility for optimization would be to ask whether a certain +component over which we loop is actually non-zero, or if the shape function is +a non-primitive one but happens to be zero in the present component +nevertheless. For this, we could replace the loop over comp_i by +this: +

+    for (unsigned int comp_i=0; comp_i<fe.n_components(); ++comp_i)
+      if (fe.get_nonzero_components(i)[comp_i] == true)
+
+If the if-clause does not succeed then this component of the shape function is +definitely zero, and there will not be a contribution to the matrix anyway, so +we can also skip the computations. + +

+


+ + +next + +up + +previous +
+ Next: The Stokes equations + Up: Assembling vector-valued problems: The + Previous: Evaluating shape functions + +
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node14.html b/deal.II/doc/reports/assemble/node14.html new file mode 100644 index 0000000000..ad5eeaf519 --- /dev/null +++ b/deal.II/doc/reports/assemble/node14.html @@ -0,0 +1,105 @@ + + + + + +The Stokes equations + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: Conclusions + Up: Assembling vector-valued problems: The + Previous: The elastic equations +
+
+ + +

+The Stokes equations +

+ +

+Likewise, this is now the code for the Stokes equations: +

+  for (unsigned int i=0; i<fe.dofs_per_cell; ++i)
+    for (unsigned int comp_i=0; comp_i<fe.n_components(); ++comp_i)
+      for (unsigned int j=0; j<fe.dofs_per_cell; ++j)
+        for (unsigned int comp_j=0; comp_j<fe.n_components(); ++comp_j)
+          for (unsigned int q=0; q<n_q_points; ++q) 
+            {
+                           // velocity-velocity coupling?
+              if ((comp_i<dim) && (comp_j<dim))
+                if (comp_i == comp_j)
+                  cell_matrix(i,j)
+                      += (nu *
+                          (fe_values.shape_grad_component(i,q,comp_i) * 
+                           fe_values.shape_grad_component(j,q,comp_j)  ) *
+                          fe_values.JxW(q)); 
+
+                           // velocity-pressure coupling
+              if ((comp_i<dim) && (comp_j==dim))
+                cell_matrix(i,j)
+                    += (-fe_values.shape_grad_component(i,q,comp_i)[comp_i] * 
+                        fe_values.shape_value_component(j,q,comp_j)        *
+                        fe_values.JxW(q)); 
+
+                           // pressure-velocity coupling
+              if ((comp_i==dim) && (comp_j<dim))
+                cell_matrix(i,j)
+                    += (fe_values.shape_value_component(i,q,comp_i) * 
+                        fe_values.shape_grad_component(j,q,comp_j)[comp_j] *
+                        fe_values.JxW(q)); 
+            };
+
+Again, the same optimizations as above are possible. Here, they even seem +worthwhile, since it is often the case that the velocity variables are +discretized using a non-primitive finite element, while the pressure uses a +primitive element. In that case, some shape functions are primitive (namely +those discretizing the pressure), and of the non-primitive shape functions +(those for the velocity variables) some vector components (the pressure +components) are always zero. Thus, both optimizations described above would be +useful. We leave the implementation of this to the reader. + +

+


+
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node15.html b/deal.II/doc/reports/assemble/node15.html new file mode 100644 index 0000000000..546d82241a --- /dev/null +++ b/deal.II/doc/reports/assemble/node15.html @@ -0,0 +1,74 @@ + + + + + +Conclusions + + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: About this document ... + Up: assemble + Previous: The Stokes equations +
+
+ + +

+Conclusions +

+ +

+We have shown how finite element matrices are assembled using the +functionality of the deal.II library. For the scalar case, and, in +the vector-valued case, if the +finite element shape functions are such that only one vector component of each +shape function is non-zero, assembling is relatively simple. In the other +case, when there are shape functions with more than one non-zero component, +some more care is necessary, but assembling is still straightforward and +follows the same pattern as before. + +

+


+
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node16.html b/deal.II/doc/reports/assemble/node16.html new file mode 100644 index 0000000000..84bf42eacc --- /dev/null +++ b/deal.II/doc/reports/assemble/node16.html @@ -0,0 +1,73 @@ + + + + + +About this document ... + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Up: assemble + Previous: Conclusions +
+
+ + +

+About this document ... +

+

+This document was generated using the +LaTeX2HTML translator Version 2002-1 (1.68) +

+Copyright © 1993, 1994, 1995, 1996, +Nikos Drakos, +Computer Based Learning Unit, University of Leeds. +
+Copyright © 1997, 1998, 1999, +Ross Moore, +Mathematics Department, Macquarie University, Sydney. +

+The command line arguments were:
+ latex2html assemble.tex +

+The translation was initiated by Wolfgang Bangerth on 2002-06-14 +


+
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node2.html b/deal.II/doc/reports/assemble/node2.html new file mode 100644 index 0000000000..f393f7447c --- /dev/null +++ b/deal.II/doc/reports/assemble/node2.html @@ -0,0 +1,775 @@ + + + + + +Linear systems for finite element methods + + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: Assembling scalar problems + Up: assemble + Previous: Introduction +
+
+ + +

+Linear systems for finite element methods +

+ +

+We start by briefly introducing the way finite element matrices are assembled +``on paper''. As usual in finite elements, we take the weak form of the partial +differential equation. In the most general case, it reads: find $ u\in
+V$ such that +

+
+ + + +
$\displaystyle a(u, v) = (f,v)_\Omega \qquad \forall v\in V,$ +   
+

+where +$ a(\cdot,\cdot)$ is the bilinear form associated with the partial +differential equations, and $ V$ is the space of test functions. For +simplicity, we have here assumed that the problem is linear and that then + +$ a(\cdot,\cdot)$ is a bilinear form; if the problem is nonlinear, it is +usually solved using a sequence of linear problems, so this is no restriction. + +

+In finite elements, we define an approximation of the solution $ u$ by choosing +a finite dimensional subspace $ V_h$ spanned by the basis functions + +$ \{\varphi_i\}$, and searching +$ u_h\in V_h$ by testing the weak form by the +test functions from $ V_h$. The problem then reads: find +$ u_h\in V_h$ +such that +

+
+ + + +
$\displaystyle a(u_h, v_h) = (f,v_h)_\Omega \qquad \forall v_h\in V_h.$ +   
+

+ +

+Now, +$ \{\varphi_i\}$ is a basis of $ V_h$. We denote the dimension of $ V_h$ by +$ N$, and will henceforth let all sums be over the range +$ 0\ldots N-1$, to keep +with the standard notation of the C/C++ programming languages. With this, we +can expand the solution +$ u_h=\sum_{j=0}^{N-1} U_j \varphi_j$, and by +bilinearity of the form +$ a(\cdot,\cdot)$, the problem above is equivalent to +

+
+ + + +
$\displaystyle \sum_{j=0}^{N-1} U_j a(\varphi_j,\varphi_i) = (f, \varphi_i) \qquad \forall i=0\ldots N-1.$ +(1)
+

+Denoting +

+
+ + + +
$\displaystyle A_{ij} = a(\varphi_j,\varphi_i), \qquad \qquad F_j = (f, \varphi_j),$ +   
+

+the equations determining the expansion coefficients $ U_i$ are therefore: +

+
+ + + +
$\displaystyle A U = F.$ +(2)
+

+ +

+Note that we have taken a reverted order of indices in the definition of $ A$, +since we want the linear system (2) with the solution to the +right of the matrix, to keep with standard notation, instead of to the left as +in (1). For symmetric problems, there is no difference, but for +non-symmetric ones this is a common source for problems and a rather common +trap. + +

+For partial differential equations, the bilinear form used in (1) +involves an integral over the domain $ \Omega$ on which the problem is +posed. For example, for the Laplace equation we have +

+
+ + + +
$\displaystyle A_{ij} = a(\varphi_j, \varphi_i) = (\nabla \varphi_j, \nabla \varphi_i)_\Omega = \int_\Omega \nabla \varphi_j \cdot \nabla \varphi_i \; dx.$ +   
+

+For practical purposes, we split this equation into integrals over the +individual cells $ K$ of the triangulation +$ \mathbb{T}$ we use for the +discretization. In deal.II, these cells are always lines, +quadrilaterals, or hexahedra. With this, we have that +

+
+ + + +
$\displaystyle A = \sum_{K \in {\mathbb{T}}} A^K, \qquad\qquad A^K_{ij} = a_K(\varphi_j, \varphi_i) \qquad 0\le i,j\le N-1,$ +   
+

+where the bilinear form +$ a_K(\cdot,\cdot)$ only involves an integral over the +cell $ K$. The important point is that we do so since for the localized basis +functions used in finite elements, $ A^K$ is a matrix with almost only zeros. +The only elements which are not zero are those corresponding to indices $ i,j$ +indicating those shape functions that have support also on the element $ K$. +For example, in 2d and using the usual bilinear shape functions for a scalar +problem, only the four shape functions associated with the vertices of the +cell $ K$ are nonzero on $ K$, and thus only the entries in $ A^K$ are nonzero +where the four rows corresponding to these indices and the respective four +columns intersect. + +

+In general, assume that there are $ N_K$ shape functions with support on cell +$ K$, and let the set of their indices be denoted by $ I_K$. Then we can define +a matrix $ \hat A^K$ of (small dimension) +$ N_K\times N_K$ holding these nonzero +entries, and we can obtain back the original contribution $ A_K$ to $ A$ by the +transformation +

+
+ + + +
$\displaystyle A^K_{ij} = \left\{ \begin{array}{ll} 0 & \text{if $i\not\in I_K$\...
+...al(i),local(j)} & \text{otherwise}, \end{array} \right. \qquad 0\le i,j\le N-1.$ +   
+

+Here, $ local(i)$ gives the number of the global degree of freedom $ i$ on the +cell $ K$, i.e. the position of $ i$ in the index set $ I_K$. One could call +$ \hat A^K$ the reduced form of $ A^K$, since the many zero rows and +column have been stripped. + +

+In general, when assembling the global matrix, the reverse way is used: when +adding up $ A^K$ to $ A$, we do so only with $ \hat A^K$ by +

+
+ + + +
$\displaystyle A_{global(i),global(j)} +\!\!= \hat A^K_{ij} \qquad \qquad 0\le i,j\le N_K-1.$ +   
+

+Thus, indices only run over the (small) range +$ 0\ldots N_K-1$ instead of + +$ 0\ldots N-1$. Here, $ global(i)$ denotes the global number of the degree of +freedom with number $ i$ on this cell $ K$, i.e. +$ global(i)=I_K[i]$, where the +bracket operator returns the $ i$th element of the set $ I_K$. + +

+The main part of assembling finite element matrices is therefore to assemble +the local matrix $ \hat A^K$. Before we go on with discussing how this is done +in deal.II, we would like to comment on the evaluation of the +integrals involved. Since the integrals are usually too complex to be +evaluated exactly (they may depend on coefficients appearing in the equation, +or the solution of previous steps in nonlinear or time-dependent problems), +they are approximated by quadrature. Assume we have a quadrature formula with +$ N_q$ points $ x_q$ defined on cell in real space (as opposed to the unit cell) +and weights $ w_q$. Then, for example for the Laplace equation, we approximate +

+
+ + + +
$\displaystyle \hat A^K_{ij} \equiv \int_K \nabla\varphi_i \cdot \nabla \varphi_...
+...\sum_{q=0}^{N_q-1} \nabla\varphi_i(x_q) \cdot \nabla \varphi_j(x_q) \ w_q \vert$det$\displaystyle \ J(\hat x_q)\vert.$ +(3)
+

+For other problems, the integrand is different, but the principle remains the +same. +det$ \ J(\hat x_q)$ denotes the determinant of the Jacobian of the +transformation between the unit cell on which the quadrature weights are +defined, and the real cell, and $ \hat x_q$ is the point on the unit cell +corresponding to the quadrature point $ x_q$ in real space. + +

+Since all matrices and right hand side vectors only require knowledge of the +values and gradients of shape functions at quadrature points, this is all that +deal.II usually provides. One can see this as a kind of view +on a finite element, as it only provides a certain perspective on the actual +definition of a shape function. Nevertheless, this is entirely sufficient for +all purposes of programming finite element programs. + +

+In deal.II the FEValues class does this: you give it a +finite element definition, a quadrature formula object, and an object defining +the transformation between unit and real cell, and it provides you with the +values, gradient, and second derivatives of shape functions at the quadrature +points. It also gives access to the determinant of the Jacobian, although only +multiplied with $ w_q$ as these two are always used in conjunction. It also +provides you with many other fields, such as normal vectors to the outer +boundary. In practice you do not need them all computed on each cell; thus, +you have to specify explicitly in which data you are interested when +constructing FEValues objects. + +

+In the following, we provide a list of connections between the symbols introduced +above, and the respective functions and variable names used in typical +deal.II programs. With this, we will subsequently show the basic +structure of an assembly routine. If you have already taken a look at the +example programs provided with deal.II, you will recognize all these +names. If you haven't, this would be a good time to look at the first +three of them. + +

+

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
$ A$system_matrix
$ \hat A^K$cell_matrix
$ K$cell
$ N$dof_handler.n_dofs()
$ N_K$fe.dofs_per_cell
$ I_K$local_dof_indices
$ N_q$quadrature_formula.n_quadrature_points
+$ \varphi_i(x_q)$fe_values.shape_value(i,q)
+$ \nabla\varphi_i(x_q)$fe_values.shape_grad(i,q)
$ x_q$fe_values.quadrature_point(q)
+$ \vert$det$ J(\hat x_q)\vert w_q$fe_values.JxW(q)
+
+ +

+With this vocabulary, the typical matrix assembly loop in deal.II has +the following form: first declare a quadrature object and use it for the +initialization of a FEValues object as discussed above: +

+  QGauss2<2>  quadrature_formula;
+  FEValues<2> fe_values (fe, quadrature_formula, 
+                         UpdateFlags(update_values    |
+                                     update_gradients |
+                                     update_JxW_values));
+
+In practice, you may want to use a different set of fields to be updated on +each cell. For example if you do not need the values of shape functions on a +cell, you may omit update_values from the list. Also note that by +default a bi- or tri-linear (depending on space dimension) mapping between +unit and real cell is used. Other mappings are possible, for example quadratic +ones, or a mapping that makes use of the fact that in many cases cells are +actually rectangular, rather than arbitrary quadrilaterals; in order to use +them, another constructor of the FEValues class can be used, which +takes a mapping object as first argument, before the other arguments listed +above. + +

+Next we define abbreviations for the values of $ N_K$ and $ N_q$: +

+  const unsigned int 
+      dofs_per_cell = fe.dofs_per_cell,
+      n_q_points    = quadrature_formula.n_quadrature_points;
+
+Then have an object to store the matrix $ \hat A^K$, which is of size + +$ N_K\times N_K$: +
+  FullMatrix<double>   cell_matrix (dofs_per_cell, dofs_per_cell);
+
+And an object representing the set of global indices of degrees of freedom, +previously denoted by $ I_K$, that have support on the present cell, i.e. those +degrees of freedom local to the present cell: +
+  std::vector<unsigned int> local_dof_indices (dofs_per_cell);
+
+The next step is then to loop over all cells: +
+  typename DoFHandler<dim>::active_cell_iterator
+       cell = dof_handler.begin_active(),
+       endc = dof_handler.end();
+  for (; cell!=endc; ++cell)
+    {
+
+On each cell, first tell the FEValues object to compute the values of +the various fields for this particular cell, and do not forget to reset the +local matrix $ \hat A^K$ to zero before adding it up: +
+      fe_values.reinit (cell);
+      cell_matrix.clear ();
+
+Now comes the main part, assembling the local matrix $ \hat A^K$. It consists +of a loop over all indices +$ 0\le i,j \le N_K$ and all quadrature points +$ 0\le
+q\le N_q$, and summing up the contributions. As this is what we will discuss +in detail later on, we only denote it here by an ellipse: +
+      for (unsigned int i=0; i<dofs_per_cell; ++i)
+        for (unsigned int j=0; j<dofs_per_cell; ++j)
+          for (unsigned int q=0; q<n_q_points; ++q)
+            cell_matrix(i,j) += ...;
+
+After we have $ \hat A^K$, we still have to sum it into the global matrix +$ A$. This is done by first getting the set $ I_K$ of the global indices of the +shape functions that were active on this cell, and then distributing $ \hat A^K$: +
+      cell->get_dof_indices (local_dof_indices);
+
+      for (unsigned int i=0; i<dofs_per_cell; ++i)
+        for (unsigned int j=0; j<dofs_per_cell; ++j)
+          system_matrix.add (local_dof_indices[i],
+                             local_dof_indices[j],
+                             cell_matrix(i,j));
+    };
+
+When this is done, we go on to the next cell. + +

+Within this framework, the only open point is assembling $ \hat A^K$ on one +quadrature point. This will be subject of the rest of this report. + +

+


+ + +next + +up + +previous +
+ Next: Assembling scalar problems + Up: assemble + Previous: Introduction + +
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node3.html b/deal.II/doc/reports/assemble/node3.html new file mode 100644 index 0000000000..9d1ecb7eaf --- /dev/null +++ b/deal.II/doc/reports/assemble/node3.html @@ -0,0 +1,143 @@ + + + + + +Assembling scalar problems + + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: Vector-valued problems + Up: assemble + Previous: Linear systems for finite +
+
+ + +

+Assembling scalar problems +

+ +

+For scalar problems, assembling $ \hat A^K$ is relatively simple. With the +terms introduced above, and for the Laplace equation, this looks as follows: +

+    local_matrix(i,j) += (fe_values.shape_grad(i,q_point) *
+                          fe_values.shape_grad(j,q_point) *
+                          fe_values.JxW (q_point));
+
+This term is placed in the innermost loop, i.e. is performed for all indices +$ i,j$, and all quadrature points q_point. + +

+For nonsymmetric problems, the order of terms has to be considered, as +mentioned above. For example, for the advection equation +

+
+ + + +
$\displaystyle \beta \cdot \nabla u = f,$ +   
+

+with which the bilinear form +

+
+ + + +
$\displaystyle a(u,v) = (\beta \cdot \nabla u, v)_\Omega$ +   
+

+is associated, the local matrix is assembled as +
+    local_matrix(i,j) += (fe_values.shape_values(i,q_point) *
+                          ( beta * fe_values.shape_grad(j,q_point) ) *
+                          fe_values.JxW (q_point));
+
+Here, beta is an object of type Tensor<1,dim>, which +represents a tensor of rank 1 in dim space dimensions. + +

+Assembling matrices for scalar problems is also shown from a practical +perspective in many of the example programs of deal.II, where it is +also demonstrated how to do this for the right hand side vectors. Thus, scalar +problems are not too interesting, and we now turn to vector-valued problems. + +

+


+ + +next + +up + +previous +
+ Next: Vector-valued problems + Up: assemble + Previous: Linear systems for finite + +
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node4.html b/deal.II/doc/reports/assemble/node4.html new file mode 100644 index 0000000000..f8e652c3b8 --- /dev/null +++ b/deal.II/doc/reports/assemble/node4.html @@ -0,0 +1,81 @@ + + + + + +Vector-valued problems + + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: The elastic equations + Up: assemble + Previous: Assembling scalar problems +
+
+ + +

+Vector-valued problems +

+ +

+Since we need some problems at which we will explain assembling the matrix for +the vector-valued case, we now briefly introduce two simple equations. The +first are the Lamé equations of elasticity, which are taken for the symmetric +case, then we briefly introduce the Stokes equations as a nonsymmetric problem. + +

+


+ +Subsections + + + +

+
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node5.html b/deal.II/doc/reports/assemble/node5.html new file mode 100644 index 0000000000..67e3e8e61b --- /dev/null +++ b/deal.II/doc/reports/assemble/node5.html @@ -0,0 +1,355 @@ + + + + + +The elastic equations + + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: The Stokes equations + Up: Vector-valued problems + Previous: Vector-valued problems +
+
+ + +

+ +
+The elastic equations +

+ +

+As first example for the methods we are going to discuss for vector-valued +problems, we consider the elastic Lamé equations for isotropic materials, +which read in strong form: + +

+
+$\displaystyle -
+\nabla (\lambda+\mu) (\div\vec u)
+-
+(\nabla \cdot \mu \nabla) \vec u
+=
+\vec f.
+$ +

+These equations describe the three-dimensional deformation $ \vec u$ of an +elastic body under a body force $ \vec f$. The respective bilinear form +associated with this operator is then + +

+
+$\displaystyle a(\vec u, \vec v) =
+\left(
+(\lambda+\mu) \div\vec u, \div\vec v
+\right)_\Omega
++
+\sum_k
+\left(
+\mu \nabla u_k, \nabla v_k
+\right)_\Omega,
+$ +

+or as a sum over components: + +

+
+$\displaystyle a(\vec u, \vec v) =
+\sum_{k,l}
+\left(
+(\lambda+\mu) \partial_l u_...
+..._\Omega
++
+\sum_{k,l}
+\left(
+\mu \partial_l u_k, \partial_l v_k
+\right)_\Omega.
+$ +

+ +

+When assembling matrices, it is advantageous to write the weak form +(i.e. after integration by parts) as a kind of operator. This is since matrix +elements after discretization are defined as +

+
+ + + +
$\displaystyle A_{ij} = a(\varphi_j,\varphi_i)_\Omega,$ +   
+

+where +$ \varphi_i,\varphi_j$ are two vector-valued trial functions, and it +would be nice if we could write the bilinear form +$ a(\cdot,\cdot)$ as a kind +of scalar product +$ (\varphi_i, Q \varphi_j)$, where $ Q$ is a differential +operator. This is trivial if we take $ Q$ as the operator of the strong form, + +$ Q=-\nabla (\lambda+\mu) \div - (\nabla \cdot \mu \nabla)$, but we wanted to +do this for the weak form. For this, we introduce some notation that is used +in quantum field theory: for differential operators, we indicate by an arrow +placed atop of it whether it shall act on the object to the left or to the +right of it. Thus, + +$ \varphi \overleftarrow\nabla \cdot \overrightarrow\nabla \psi
+=(\nabla\varphi)\cdot(\nabla\psi)$. With this, a simple computation shows +that +

+
+\begin{multline*}
+a(\vec u,\vec v)
+=
+(\lambda+\mu)
+\left(
+\begin{pmatrix}
+...
+...\mid
+\begin{pmatrix}
+v_1 \\ v_2
+\end{pmatrix} \right)_\Omega.
+\end{multline*}
+
+

+The sought operator $ Q$ is then +

+
+ + + +
$\displaystyle Q = (\lambda+\mu) \begin{pmatrix}\overleftarrow \partial _1 \over...
+...tial _1 + \overleftarrow \partial _2 \overrightarrow \partial _2 \end{pmatrix},$ +   
+

+and +$ a(\vec u,\vec v)=(\vec u \vert Q \vert \vec v)$. We demonstrate the fact that $ Q$ +acts to both sides by placing it in the middle of the scalar product, just as +in the bra-ket notation of quantum physics. + +

+The advantages of this formulation will become clear when discussing +assembling matrices below. For now, we remark that the symmetry of the weak +form is equally apparent from the form of $ Q$ as well as from the initial +definition of +$ a(\cdot,\cdot)$. + +

+


+ + +next + +up + +previous +
+ Next: The Stokes equations + Up: Vector-valued problems + Previous: Vector-valued problems + +
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node6.html b/deal.II/doc/reports/assemble/node6.html new file mode 100644 index 0000000000..287b5f6327 --- /dev/null +++ b/deal.II/doc/reports/assemble/node6.html @@ -0,0 +1,183 @@ + + + + + +The Stokes equations + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: Assembling vector-valued problems: The + Up: Vector-valued problems + Previous: The elastic equations +
+
+ + +

+ +
+The Stokes equations +

+ +

+For a nonsymmetric problem, we take the Stokes equations: +

+
+ + + + + + + + +
$\displaystyle -\Delta \vec u + \nabla p$$\displaystyle = 0,$ +   
div $\displaystyle \vec u$$\displaystyle = 0.$ +   
+

+We denote by +$ \vec w=\{\vec u,p\}$ the entire solution vector. In the weak +form, the above equations read +

+
+ + + +
$\displaystyle a(\vec u,p; \vec v, q) = \nu(\nabla \vec u_1, \nabla \vec v_1) +\...
+... \vec u_2, \nabla \vec v_2) - (p, \nabla\cdot \vec v) + (\nabla\cdot\vec u, q).$ +   
+

+Since we integrated the gradient term in the first equation by parts, but not +the divergence term in the second equation, the problem is now +nonsymmetric. If we would have liked, we could have made the problem symmetric +again by multiplying the entire second equation by $ -1$, but we don't want to +do that for now for illustrational purposes. + +

+Again, we introduce the operator $ Q$ for this problem, which after some +computations turns out to be +

+
+ + + +
$\displaystyle Q = \begin{pmatrix}\nu(\overleftarrow \partial _1 \overrightarrow...
+...\\ \overrightarrow \partial _1 & \overrightarrow \partial _2 & 0 \end{pmatrix}.$ +   
+

+Again, it is clear from this form that we could have made the operator +symmetric by multiplying the last row by $ -1$. Note when checking the symmetry +of $ Q$ that taking the transpose of such an operator means reverting the +directions of the arrows over the operators, and exchanging their order. +For example, using the first term, these two steps are + +$ \overleftarrow \partial _1 \overrightarrow \partial _1 \rightarrow \overrighta...
+... \partial _1
+\rightarrow \overleftarrow \partial _1 \overrightarrow \partial _1$. + +

+


+ + +next + +up + +previous +
+ Next: Assembling vector-valued problems: The + Up: Vector-valued problems + Previous: The elastic equations + +
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node7.html b/deal.II/doc/reports/assemble/node7.html new file mode 100644 index 0000000000..a05621fe17 --- /dev/null +++ b/deal.II/doc/reports/assemble/node7.html @@ -0,0 +1,321 @@ + + + + + +Assembling vector-valued problems: The simple case + + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: The elastic equations + Up: assemble + Previous: The Stokes equations +
+
+ + +

+Assembling vector-valued problems: The simple case +

+ +

+The simple case in assembling vector-valued problems is when the (also +vector-valued) shape functions are chosen such that only one component in the +vector is nonzero. This is usually the case, if we choose the shape functions +to be the outer product of scalar shape functions, such as independent +bilinear ansatz spaces for each component of a finite element space. + +

+In this case, each shape function $ \Phi_i$ has the representation +

+
+ + + +
$\displaystyle \Phi_i(\vec x) = \left( 0, \dots, 0, \varphi_i(\vec x), 0, \ldots, 0\right)^T,$ +   
+

+where $ \Phi_i$ is the vector-valued shape function, and $ \varphi_i$ its +only non-zero component. Let us denote by $ c(i)$ the index of this non-zero +component, then $ \Phi_i$ can also be written as +

+
+ + + +
$\displaystyle \left(\Phi_i(\vec x)\right)_l = \varphi_i(\vec x) \delta_{c(i),l},$ +   
+

+with the Kronecker delta function +$ \delta_{jk}$. + +

+With this simple form, the cell matrix on cell $ K$ has a simple form: +

+
+ + + +
$\displaystyle A^K_{ij} = a_K(\Phi_i,\Phi_j) = \left(\Phi_i \mid Q \mid \Phi_j \right)_K = \left(\varphi_i \mid Q_{c(i),c(j)} \mid \varphi_j \right)_K.$ +   
+

+Thus, in assembling the local cell matrices, we only have to determine the +single components in which the two shape functions are non-zero, and +pick one element from the matrix $ Q$ to assemble each entry of the cell +matrix with the help of the values of the functions $ \varphi_i$ at the +quadrature points. Here, it comes handy that we have written the operator as a +matrix operator $ Q$, since this makes it very clear how shape functions $ i$ +and $ j$ couple: if +$ Q_{c(i),c(j)}$ is zero, then they do not couple at all for +this operator. Otherwise, it is easily visible which derivative acts on which +shape function for this combination of shape functions. + +

+In deal.II, these two actions mentioned above (getting the non-zero +component of a shape function, and the value of this component at a given +quadrature point) are done as follows: + +

+ +

+


+ +Subsections + + + +
+ + +next + +up + +previous +
+ Next: The elastic equations + Up: assemble + Previous: The Stokes equations + +
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node8.html b/deal.II/doc/reports/assemble/node8.html new file mode 100644 index 0000000000..0d730b7e9f --- /dev/null +++ b/deal.II/doc/reports/assemble/node8.html @@ -0,0 +1,116 @@ + + + + + +The elastic equations + + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: The Stokes equations + Up: Assembling vector-valued problems: The + Previous: Assembling vector-valued problems: The +
+
+ + +

+ +
+The elastic equations +

+ +

+With this, and the definition of the ``bi-directional'' operator $ Q$ in +Section 4.1, the local matrix assembly function for the elastic +equations would then read as follows: +

+  for (unsigned int i=0; i<fe.dofs_per_cell; ++i)
+    for (unsigned int j=0; j<fe.dofs_per_cell; ++j)
+      for (unsigned int q=0; q<n_q_points; ++q) 
+        {
+          const unsigned int
+            comp_i = fe.system_to_component_index(i).first,
+            comp_j = fe.system_to_component_index(j).first;
+
+                           // first assemble part with lambda+mu
+          cell_matrix(i,j) += ((lambda+mu)                       *
+                               fe_values.shape_grad(i,q)[comp_i] * 
+                               fe_values.shape_grad(j,q)[comp_j] *
+                               fe_values.JxW(q)); 
+
+                           // then part with mu only
+          if (comp_i == comp_j)
+            cell_matrix(i,j) += (mu                           *
+                                 (fe_values.shape_grad(i,q) * 
+                                  fe_values.shape_grad(j,q)  )*
+                                 fe_values.JxW(q)); 
+        };
+
+Note that this code works in any space dimension, not only for +dim==2. Optimization of this is possible by hoisting the computation +of comp_i and comp_j, denoting $ c(i)$ and $ c(j)$, +respectively, out of the inner loops. Also, if the coefficients are +non-constant, they need to be computed at each quadrature point; this may be +done using this fragment in the innermost loop: +
+  const double
+    lambda_value = lambda.value(fe_values.quadrature_point(q)),
+    mu_value     = mu.value(fe_values.quadrature_point(q));
+
+assuming that lambda,mu are variables of classes that are derived +from the Function<dim> class. + +

+


+
+Wolfgang Bangerth +2002-06-14 +
+ + diff --git a/deal.II/doc/reports/assemble/node9.html b/deal.II/doc/reports/assemble/node9.html new file mode 100644 index 0000000000..b08791e1ec --- /dev/null +++ b/deal.II/doc/reports/assemble/node9.html @@ -0,0 +1,108 @@ + + + + + +The Stokes equations + + + + + + + + + + + + + + + + + + + +next + +up + +previous +
+ Next: Assembling vector-valued problems: The + Up: Assembling vector-valued problems: The + Previous: The elastic equations +
+
+ + +

+ +
+The Stokes equations +

+ +

+For the Stokes equation, things are slightly more complicated since the three +components denote different quantities, and the operator $ Q$ does not have +such a simple form, but the case is still simple enough. We present its +generalization to an arbitrary number of space dimensions, i.e. assume that +there are dim velocity variables and one scalar pressure: +

+  for (unsigned int i=0; i<fe.dofs_per_cell; ++i)
+    for (unsigned int j=0; j<fe.dofs_per_cell; ++j)
+      for (unsigned int q=0; q<n_q_points; ++q) 
+        {
+          const unsigned int
+            comp_i = fe.system_to_component_index(i).first,
+            comp_j = fe.system_to_component_index(j).first;
+
+                           // velocity-velocity coupling?
+          if ((comp_i<dim) && (comp_j<dim))
+            if (comp_i == comp_j)
+              cell_matrix(i,j) += (nu *
+                                   (fe_values.shape_grad(i,q) * 
+                                    fe_values.shape_grad(j,q)  ) *
+                                   fe_values.JxW(q)); 
+
+                           // velocity-pressure coupling
+          if ((comp_i<dim) && (comp_j==dim))
+            cell_matrix(i,j) += (-fe_values.shape_grad(i,q)[comp_i] * 
+                                  fe_values.shape_value(j,q)        *
+                                 fe_values.JxW(q)); 
+
+                           // pressure-velocity coupling
+          if ((comp_i==dim) && (comp_j<dim))
+            cell_matrix(i,j) += (fe_values.shape_value(i,q) * 
+                                 fe_values.shape_grad(j,q)[comp_j] *
+                                 fe_values.JxW(q)); 
+        };
+
+Again, optimization is possible by observing that only one of the outer +ifs in the body can be true, for example using else clauses, +or break statements. + +

+


+
+Wolfgang Bangerth +2002-06-14 +
+ +