validate-xrefs:
@echo "Validating cross-references in HTML files."
- $(PERL) $D/common/scripts/validate-xrefs.pl *html doxygen/*/*.html
+ $(PERL) $D/common/scripts/validate-xrefs.pl *html
+ $(PERL) $D/common/scripts/validate-xrefs.pl doxygen/base/*.html
+ $(PERL) $D/common/scripts/validate-xrefs.pl doxygen/lac/*.html
+ $(PERL) $D/common/scripts/validate-xrefs.pl doxygen/deal.II/*.html
cd tutorial ; $(MAKE) validate-xrefs
cd development ; $(MAKE) validate-xrefs
cd publications ; $(MAKE) validate-xrefs
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
- "http://www.w3.org/TR/REC-html40/frameset.dtd">
-<html>
- <head>
- <link href="../../screen.css" rel="StyleSheet" media="screen">
- <link href="../../print.css" rel="StyleSheet" media="print">
- <title>The deal.II news page</title>
- <meta name="author" content="the deal.II authors <authors@dealii.org>">
- <meta name="keywords" content="deal.II"></head>
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-<body>
-
-
-<h2>Changes after Version 3.4</h2>
-
-<p>
-This is the list of changes made after the release of
-<acronym>deal.II</acronym> version 3.4. It is subdivided into changes
-made to the three sub-libraries <a href="#base">base</a>,
-<a href="#lac">lac</a>, and <a href="#deal.II">deal.II</a>, as well as
-changes to the <a href="#general">general infrastructure,
-documentation, etc</a>.
-</p>
-
-<p>
-All entries are signed with the names of the author. Regular
-contributor's names are abbreviated by WB (Wolfgang Bangerth), GK
-(Guido Kanschat), RH (Ralf Hartmann).
-</p>
-
-
-<a name="general"></a>
-<h3>General</h3>
-
-<ol>
- <li> <p>
- New: <acronym>deal.II</acronym> now uses a new threading
- scheme. The new scheme is simpler to use, and in particular
- more flexible in some cases where only one thread is started,
- or where a thread is completely detached, since we got rid of
- the <code>ThreadManager</code> class and now only store handles
- to individual threads (which can be discarded, or added to a
- <code>ThreadGroup</code> variable that is able to wait for a
- whole set of threads at once.
- <br>
- The new scheme also implements a much needed feature: calling
- functions on a new thread that return values. Previously, such
- functions needed to be written in a way that they return their
- return value through an additional reference parameter. This
- was inflexible if one wanted to call functions that already
- exist. This restriction is now lifted: such functions can be
- called, and the return value can be accessed once the thread
- has finished.
- <br>
- Some documentation for the new scheme can be found
- <a href="../../reports/new-threads/index.html" target="body">on this
- page</a>.
- <br>
- (WB 2003/02/06)
- </p>
-
- <li> <p>
- New: <acronym>deal.II</acronym> now makes use of some parts of
- the <a href="http://www.boost.org/">boost</a> library, which is
- supposed to be a testground for the next generation C++ standard
- library. The parts which we use are now in
- <code>contrib/boost/include/boost_local/</code> and can be
- referenced from within your programs. The directory contains
- the string <code>_local</code> since you may still want to use
- another version or installation of boost in your own programs.
- </p>
-
- <p>
- Also note that boost is large -- much larger than the subset we
- have imported --, so we only took what we needed.
- <br>
- (WB 2003/02/06)
- </p>
-
- <li> <p>
- Fixed: A longstanding bug in the documentation system has been fixed: if
- a namespace was ended with <code>}</code> instead of <code>};</code>
- (note the semicolon), then the documentation tool assumed that the
- following entities were still part of the namespace just left. This was
- since the closing brace alone was not accepted as ending a namespace
- (after all, structures, classes, and enums -- the other entities that
- can enclose other declarations -- need the semicolon). This led to some
- classes not showing up in the class index of the sublibraries. This is
- now fixed.
- <br>
- (WB 2003/02/02)
- </p>
-
- <li> <p>
- Changed: Classes and structures that are declared inside namespaces named
- <code class="class">internal</code> are now no longer shown in the class
- index view of the documentation of each of the sublibraries. Since they
- are supposed to be used internally only, this is no drawback for the
- general public. However, they are documented as members of these
- namespaces.
- <br>
- (WB 2003/02/02)
- </p>
-
- <li> <p>
- Fixed: Some of the formulas in the step-14 tutorial were obviously
- scrambled a little. This is now fixed.
- <br>
- (Roy Stogner, WB 2003/01/30)
- </p>
-
- <li> <p>
- Changed: The main Makefile has been changed to sequentialize building
- the base, lac, and deal.II sublibraries. We changed this, since on some
- systems (notably AIX), the latter libraries need to be linked against
- the former ones, when creating shared libraries.
- <br>
- (WB 2003/01/24)
- </p>
-
- <li> <p>
- New: Changes have been made to support compiling and using
- <acronym>deal.II</acronym> on AIX 5 systems.
- <br>
- (WB 2003/01/24)
- </p>
-
- <li> <p>
- Removed: Thread support now relies solely on the use of POSIX
- functions. The use of the
- <a href="http://www.cs.wustl.edu/~schmidt/ACE.html" target="_top">ACE
- (Adaptive Communications Environment)</a> library for this is now no
- longer supported. However, application programs can of course still use
- ACE, but they will need to generate paths to this library in their
- makefiles themselves.
- <br>
- (WB 2003/01/11)
- </p>
-
- <li> <p>
- New: Some changes have been made to support Mac OS X 10.2. Shared
- libraries are not supported on this architecture, but everything else
- should work.
- <br>
- (WB 2002/12/18)
- </p>
-
- <li> <p>
- New: <acronym>deal.II</acronym> can be compiled with version 7.0 of
- Intel's icc compiler, which was recently released. Since this compiler
- finally supports the very restrictive flags <code>-Xc -ansi</code> that
- check for close conformance with the C++ standard, we use them (previous
- versions of icc would crash when these two flags are given). This
- requires that we distinguish between these compiler versions, and the
- corresponding Makefile variable <code>GXX-VERSION</code> now no longer
- holds the non-versioned string <code>intel_icc</code> when icc is
- detected, but rather either <code>intel_icc5</code>,
- <code>intel_icc6</code>, or <code>intel_icc7</code>, depending on what
- version of the compiler was detected.
- <br>
- (WB 2002/12/05)
- </p>
-
- <li> <p>
- Changed: Previously, we just set the preprocessor variable
- <code>DEAL_II_USE_MT</code>, when <code>--with-multithreading</code> was
- given as argument to <code>./configure</code>. Tests in the code
- therefore looked like <code>#ifdef DEAL_II_USE_MT</code>. This has been
- changed so that the variable is always defined, but its value is now
- equal to <code>1</code>
- when multithreading was requested, and zero otherwise. The reason for
- this is that you can now write <code>if (DEAL_II_USE_MT && ...)</code>
- conditions, and need not interleave if-else clauses from regular code
- and the preprocessor, if conditions involve both the state of this
- preprocessor variable and the run-time state of your program. However,
- this change requires that all appearances of <code>#ifdef
- DEAL_II_USE_MT</code> be changed to <code>#if DEAL_II_USE_MT ==
- 1</code>, since the variable is now defined unconditionally.
- <br>
- (WB 2002/11/14)
- </p>
-
- <li> <p>
- New: Object files are now named according to the local defaults
- on the system we are running on. On Unix systems, this is
- usually a <code>.o</code> suffix, while on Windows it is
- <code>.obj</code>. Likewise for executables, which have no
- suffix on Unix, but <code>.exe</code> on Windows.
- <br>
- (WB 2002/11/11)
- </p>
-
- <li> <p>
- New: <acronym>deal.II</acronym> can now also be compiled with Red Hat's
- version of the gcc compiler, gcc 2.96. However, some problems remain;
- for more information, refer
- to the <a href="../../faq.html" target="body">Frequently Asked
- Questions</a> section.
- <br>
- (WB 2002/10/14)
- </p>
-
- <li> <p>
- Fixed: On CygWin, one header files has a <code>#define quad
- quad_t</code>. This is annoying, since we have local variables and
- member functions with the name <code>quad</code>, and in fact it breaks
- compilation on those versions of CygWin that has this. Fortunately, the
- define is only active if a preprocessor variable
- <code>_POSIX_SOURCE</code> is not set. Thus, we now check for the define
- when configuring the library, and if necessary set the preprocessor
- variable. However, while this allows to compile the library on these
- systems, it may otherwise affect your code, if you use functions or
- other features of the system that are not available when the flag is
- set.
- <br>
- (Stephen Kolaroff, WB
- 2002/09/28)
- </p>
-
- <li> <p>
- New: Since <code>math.h</code> only defines the values of PI or E (as
- <code>M_PI</code> and <code>M_E</code>) when certain defines are set (on
- Linux, these are <code>__USE_BSD</code> or <code>__USE_XOPEN</code>),
- portable programs usually defined these constants themselves. In
- <acronym>deal.II</acronym>, this happened at 6 different places. To
- avoid this in the future, <code>base/config.h</code> now exports a
- namespace <code>deal_II_numbers</code> that defines these two, and a
- number of other numerical constants.
- <br>
- (WB 2002/09/12)
- </p>
-
- <li> <p>
- New: <code>base/config.h</code> now exports the
- <acronym>deal.II</acronym> base directory through the
- <code>DEAL_II_PATH</code> preprocessor variable.
- <br>
- (WB 2002/09/09)
- </p>
-
- <li> <p>
- Removed: The forward declarations files have gone. We have never
- propagated their use in the example programs, but these files have been
- there in the base, lac, and grid include directories, and forward
- declared all classes that were present in the respective parts of the
- library. This, the idea was, enables you to use just this include file
- in your own header files, rather than including the full declarations of
- these classes. However, maintaining these forward declaration files has
- been a constant thorn in our side, be it that the timing of their
- generation was difficult when using parallel builds, or that they were
- difficult to generate at first. The latter is now the reason for their
- abolition: we had a script for their generation, but it did not take
- into account namespaces, so we got clashes when we found that we had
- used the same class name in two different namespaces, since the script
- put the forward declaration incorrectly into the global namespace where
- they conflicted. Since we do not plan to extend the script by a
- parser that can properly handle opening and closing braces of
- namespaces, we simply drop these files.
- <br>
- What you should do if you have used these forward declaration files: you
- have two possibilities - either include the respective header file in
- which the class is fully declared, or write the forward declaration into
- your headers yourself.
- <br>
- (WB 2002/09/05)
- </p>
-
- <li> <p>
- New: There is now
- <a href="../../reports/assemble/index.html" target="body">a new report
- on assembling matrices</a> available from the
- <a href="../../documentation.html" target="body">documentation
- page</a>. The main focus is assembling of matrices for
- vector-valued problems, where shape functions are
- vector-valued, and may have only one or more non-zero vector
- components.
- <br>
- (WB 2002/06/17)
- </p>
-
- <li> <p>
- Removed: The functions <code
- class="member">FEValuesBase::get_shape_values</code>, <code
- class="member">FEValuesBase::get_shape_grads</code>, and <code
- class="member">FEValuesBase::get_shape_2nd_derivatives</code> are
- now removed as they expose too much of the internal data
- structure of their class, and interfere with plans for the
- extension of this and related classes. These functions, which
- had been deprecated in the previous version, are thus not
- part of the release after version 3.4 any more. Use the <code
- class="member">FEValuesBase::shape_value</code> and alike
- functions as a replacement.
- <br>
- For more information, read
- <a href="http://www.dealii.org/mail/msg00638.html" target="body">this mail</a>.
- <br>
- (WB 2002/06/10)
- </p>
-
- <li> <p>
- New: <acronym>deal.II</acronym> now also supports vector-valued
- finite elements with shape functions for which more than just
- one vector component is non-zero. Such elements are, for
- example, the Nedelec and Raviart-Thomas families. Previously,
- vector-valued elements were only supported insofar as they
- could be composed of scalar ones; in that case, each
- (vector-valued) shape function had only one non-zero vector
- component.
- <br>
- (WB 2002/06/10)
- </p>
-
- <li> <p>
- New: The top-level makefile now how a target <tt>distclean</tt>.
- <tt>clean</tt> leaves the libraries now, removing
- everything that is not needed to use
- <acronym>deal.II</acronym>. <tt>distclean</tt> removes even the
- libraries, leaving the directory more or less in the state like
- after <tt>configure</tt>.
- <br>
- (GK 2002/06/07)
-</ol>
-
-
-
-<a name="base"></a>
-<h3>base</h3>
-
-<ol>
- <li> <p>
- Fixed: A bug in the <code
- class="class">Patterns::MultipleSelection</code> class if more
- than two elements in a comma-separated list were given.
- <br>
- (Brian Carnes 2003/05/14)
- </p>
-
- <li> <p>
- Changed: The <code class="class">Polynomials::Legendre</code>
- class lost its template argument and is now just a regular
- class. There was no real good reason for the template argument,
- it had just crept in.
- <br>
- (WB 2003/05/12)
- </p>
-
- <li> <p>
- New: There is now a class <code
- class="class">AnisotropicPolynomials</code> that constructs a higher
- dimensional polynomial space from a set of 1-d polynomials in each of
- the coordinate directions.
- <br>
- (WB 2003/04/20)
- </p>
-
- <li> <p>
- Changed: The <code class="class">Table</code> accessor classes
- have been moved to a namespace <code
- class="class">internal</code>. Since these classes are not (or should
- not be) used directly in applications, this should not change
- compatibility. However, they will now no longer show up in the class
- overview of the documentation, which they were cluttering up.
- <br>
- (WB 2003/02/13)
- </p>
-
- <li> <p>
- New: The <code class="class">Function</code> class now has an assignment
- operator. This way, you can put function objects into
- containers. However, the assignment operator makes sure that only
- objects can be assigned that have the same number of vector components.
- <br>
- (WB 2003/02/06)
- </p>
-
- <li> <p>
- New: The <code class="class">ThreadMutex</code> classes now have a
- member class <code class="class">ScopedLock</code> that implements the
- scoped thread-safe locking pattern of Doug Schmidt. It is also used in
- various places of the code now.
- <br>
- (WB 2003/01/28)
- </p>
-
- <li> <p>
- Fixed: The <code class="class">PosixThreadManager</code> called
- its <code class="member">wait</code> function in the
- destructor. If this had been called before already, then the
- same threads would have been waited for twice, which invokes
- undefined behavior. This is fixed by making sure that <code
- class="member">wait</code> removes the id's of the threads it
- has already waited for, and so calling it more than once will
- not wait for threads which have already been waited for.
- <br>
- (Michael Anderson, WB 2003/01/16)
- </p>
-
- <li> <p>
- Fixed: The <code class="class">Subscriptor</code> uses a counter to
- count how many <code class="class">SmartPointer</code> objects subscribe
- to the pointed-to object. This counter needs to be a volatile variable
- in multithreaded mode, to avoid false compiler optimizations based on
- the assumption that the variable cannot change between two subsequent
- reads.
- <br>
- (WB 2003/01/11)
- </p>
-
- <li> <p>
- Fixed: In multithreaded mode, when a new thread is started, the
- arguments to the function being called need to be copied from the stack
- of the starting thread to that of the new thread. In order to
- synchronise this, mutexes were used that were acquired from one thread
- and released from another thread. On Linux this does not lead to
- problems, but POSIX functions do not guarantee that this actually works,
- and it also leads to problems when running programs under valgrind. This
- is now fixed with the help of condition variables.
- <br>
- (Michael Anderson, WB 2003/01/11)
- </p>
-
- <li> <p>
- New: There are now classes <code class="class">ThreadCondition</code>
- that implement thread condition variable operations through POSIX
- functions (in multithreaded mode) or doing nothing (in singlethreaded
- mode).
- <br>
- (WB 2003/01/11)
- </p>
-
- <li> <p>
- New: Newer versions of gcc have a very nice feature: you can set
- a verbose terminate handler, that not only aborts a program
- when an exception is thrown and not caught somewhere, but
- before aborting it prints that an exception has been thrown,
- and possibly what the std::exception::what() function has to
- say. Since many people run into the trap of not having a
- catch clause in main(), they wonder where that abort may be
- coming from. The terminate handler then at least says what is
- missing in their program.
- <br>
- (WB 2002/12/19)
- </p>
-
- <li> <p>
- New: There is now a <code class="class">Patterns::List</code> pattern
- that matches a list of elements each of which has to satisfy a pattern
- that was given to the constructor.
- <br>
- (WB 2002/11/29)
- </p>
-
- <li> <p>
- Changed: In POSIX mode, when the <code
- class="member">ThreadManager</code> class created a new thread through
- <code class="member">pthread_create</code>, it only checked for the
- error code and aborted if it was non-zero. Now, it checks whether the
- error code is <code class="member">EAGAIN</code> and simply retries the
- call if this is the case. This may, in rare cases, lead to a deadlock or
- an infinite loop, but will usually just wait until the respective
- resources for thread creation are available from the operating system
- and will then succeed.
- <br>
- (WB 2002/11/13)
- </p>
-
- <li> <p>
- Fixed: The <code class="member">write_text</code> and <code
- class="member">write_tex</code> functions of the <code
- class="class">TableHandler</code> class now check whether their
- <code>ofstream</code> arguments are in a proper state before
- using them for output.
- <br>
- (RH 2002/11/11)
- </p>
-
- <li> <p>
- New: Added Hierarchical Polynomial (similar to Legendre class). Will
- eventually be used in a hierarchical FiniteElement class similar to
- FE_Q class. Included in Polynomials namespace.
- <br>
- (Brian Carnes 2002/10/15)
- </p>
-
- <li> <p> Changed: Because they became too many, the classes describing 1d
- polynomials are now in a <code class="class">namespace
- Polynomials</code>.
- <br>
- (WB 2002/10/14)
- </p>
-
- <li> <p> Changed: When an exception is thrown but not caught in a sub-thread,
- this exception is not passed to the main thread by the operating
- system. Rather, if the exception is not caught from the function that
- was invoked by the spawning system function, the entire program is
- terminated without an additional message. The wrapper functions which
- are used to spawn new threads in the <code class="class">Threads</code>
- namespace therefore now catch these exceptions and at least print the
- message they carry, before aborting the program. This way, at least the
- message gets displayed.
- <br>
- (WB 2002/10/13)
- </p>
-
- <li> <p> Changed: The class <code
- class="member">Table<2>::fill</code> function, which is also
- inherited from the <code class="class">FullMatrix</code> class, used to
- work also when the size of the matrix was zero, by simply not copying
- something. This led to difficult to detect errors. It is therefore no
- more allowed to call this function when the matrix is empty. For all
- other cases, the status of copying without checking the size of the
- array copied from remains unchanged.
- <br>
- (WB 2002/09/28)
- </p>
-
- <li> <p> New: The classes <code
- class="class">TableIndices<N></code> and <code
- class="class">Table<N,T></code> are now implemented also
- for <code>N=4,5</code> and <code>6</code>. The <code
- class="class">Table<N,T></code> class represents an
- <code>N</code>-dimensional array and might replace the
- N-times-nested-use of the <code
- class="class">std::vector</code> class.
- <br>
- (RH 2002/09/24)
- </p>
-
- <li> <p>
- New: The <code class="member">Threads::n_existing_threads</code>
- function returns the present number of existing threads, allowing an
- assessment whether it is useful to spawn new threads or rather perform
- the operation in question sequentially.
- <br>
- (WB 2002/09/08)
- </p>
-
- <li> <p> New: Global exception class <code
- class="class">ExcIteratorPastEnd</code>, which should be used if an
- iterator is incremented or decremented beyond its end value.
- <br>
- (GK 2002/09/08)
- </p>
-
- <li> <p>
- Extended: Previously, the <code
- class="class">Threads::PosixThreadBarrier</code>
- class could not be used at all (they threw exceptions), if your system
- did not have the respective POSIX functions. This restriction is lifted
- for the special case that you give one as the number of parties that
- will be waiting for the barrier: in this case, a barrier is a
- no-operation, so we do not need assistence from the operating
- system. This change makes it slightly simpler to write programs in a way
- such that they run in both single- and multithreaded environments.
- <br>
- (WB 2002/09/05)
- </p>
-
- <li> <p>
- New: The old class <code class="class">vector2d</code>, implementing a
- two-dimensional array of objects is now gone. Instead, there is the new
- <code class="class">Table</code> class that implements tables of
- arbitrary dimension. Transition is painless: where there was
- <code>vector2d<type></code> before, use
- <code>Table<2,type></code> now (and don't forget to update the
- name of the header file, of course). If you have a three-dimensional
- array, you can use <code class="class">Table<3,type></code> now.
- <br>
- (WB 2002/09/03)
- </p>
-
- <li> <p>
- New: There are now functions returning the transpose of <code
- class="class">Tensor</code> objects of rank 2.
- <br>
- (WB 2002/08/31)
- </p>
-
- <li> <p>
- New: Row accessors for the <code class="class">vector2d</code>
- class now have a member function <code
- class="member">size</code> that returns the size of the row,
- i.e. the number of columns of the table.
- <br>
- (WB 2002/07/24)
- </p>
-
- <li> <p>
- Fixed: In EPS output, colors were set to invalid values if the
- values of the field that is used for coloring are all
- equal. This happens, for example, in the very first time step
- of time dependent problems, if initial values are zero. The
- color value now used is arbitrary, but valid.
- <br>
- (WB 2002/07/24)
- </p>
-
- <li> <p>
- Changed: To save disk space, color values in EPS output are
- written as grey scale with only one value instead of three RGB
- values if the color so represented is actually a grey scale.
- <br>
- (WB 2002/07/24)
- </p>
-
- <li> <p>
- New: There are now operators to allow multiplication and
- division of <code class="class">Tensor</code> objects by scalar
- factors.
- <br>
- (WB 2002/06/07)
- </p>
-</ol>
-
-
-
-<a name="lac"></a>
-<h3>lac</h3>
-
-<ol>
- <li> <p> New: Function
- <code class="member">BlockSparseMatrix::print_formatted</code>
- added, similar to the
- <code class="member">BlockVector::print_formatted</code> function.
- <br>
- (Brian Carnes 2003/06/02)
- </p>
-
- <li> <p> New: Functions <code class="member">SparseMatrix::operator *=</code>
- and <code class="member">SparseMatrix::operator /=</code> as well as
- <code class="member">BlockSparseMatrix::operator *=</code>
- and <code class="member">BlockSparseMatrix::operator /=</code>
- are added.
- <br>
- (Brian Carnes 2003/06/02)
- </p>
-
- <li> <p> Deprecated: The functions <code class="member">Vector::scale</code>
- and <code class="member">BlockVector::scale</code> are now deprecated
- and will be removed in a future version. Use <code>operator*=</code> and
- <code>operator/=</code> instead.
- <br>
- (WB 2003/05/31)
- </p>
-
- <li> <p> New: <code class="class">Vector</code>, <code
- class="class">BlockVector</code> and
- <code class="class">FullMatrix</code> now have <code>operator/=</code>
- for scaling by a scalar.
- <br>
- (WB 2003/05/31)
- </p>
-
- <li> <p> New: <code class="class">PointerMatrix</code> now
- has <code>empty()</code> function, which returns true if the pointer is
- null; otherwise we call the pointer's <code>empty()</code> function.
- This requires the class MATRIX to have an <code>empty()</code>
- function.
- <br>
- (Brian Carnes 2003/05/22)
- </p>
-
- <li> <p> New: <code class="class">SparseLUDecomposition</code> now
- has <code>empty()</code> function, which calls the inherited <code
- class="class">SparseMatrix</code> <code>empty()</code> function.
- <br>
- (Brian Carnes 2003/05/22)
- </p>
-
- <li> <p> New: <code class="class">PreconditionPSOR</code> implements
- interface to permuted SOR preconditioner function in <code
- class="class">SparseMatrix</code>.
- <br>
- (GK 2003/05/12)
- </p>
-
- <li> <p> Improved: <code class="class">FullMatrix</code>::<code
- class="member">fill</code> now copies the largest possible block,
- whether the destination or source matrix is bigger. Additionally, an
- offset inside the source matrix may be specified.
- <br>
- (GK 2003/03/31)
- </p>
-
- <li> <p>
- New/Changed: The <code class="class">SparseILU</code>, <code
- class="class">SparseMIC</code> and <code
- class="class">SparseLUDecomposition</code> now use the same
- interface (<code class="class">initialize</code>, <code
- class="class">vmult</code>, <code class="class">clear</code>)
- as all <code class="class">PreconditionBlock</code> classes. In
- virtue of an unified preconditioner interface it is now
- recommended to use the new methods. The old methods (<code
- class="class">reinit</code>, <code
- class="class">decompose</code>, <code
- class="class">apply_decomposition</code>) are now deprecated,
- and will be removed in a later version.
- <br>
- (RH 2003/02/19)
- </p>
-
- <li> <p>
- Changed: The <code class="class">BlockVector</code> accessor classes
- have been moved to a namespace <code
- class="class">internal</code>. Since these classes are not (or should
- not be) used directly in applications, this should not change
- compatibility. However, they will now no longer show up in the class
- overview of the documentation, which they were cluttering up.
- <br>
- (WB 2003/02/13)
- </p>
-
- <li> <p>
- New: The <code class="class">SolverGMRES</code> now accepts an
- <code class="class">AdditionalData</code> parameter
- <code>use_default_residual</code> whose default is
- <code>true</code>. By setting this flag to <code>false</code>,
- the stopping criterion of the left-preconditioned GMRes solver
- is not the default preconditioned residual but the normal
- (unpreconditioned) residual and visa versa for the
- right-preconditioned GMRes solver. Due to a performance loss of
- the solver this flag should be set to <code>false</code> only
- for debugging/testing purposes.
- <br>
- (RH 2003/01/31)
- </p>
-
- <li> <p>
- New: <code class="class">FullMatrix</code> has a function <code
- class="member">copy_from</code>, copying from sparse matrices.
- It uses iterators of the sparse matrix classes.
- <br>
- (GK 2003/01/08)
- </p>
-
-
- <li><p>
- Changed: In an attempt to unify the use of preconditioners a
- little, the function <code class="member">initialize</code> of
- classes <code class="class">PreconditionRelaxation</code> and
- <code class="class">PreconditionBlock</code> take an argument
- of type <code class="class">AdditionalData</code>, defined in
- the same class. Standard behavior of <code
- class="class">PreconditionBlock</code> has been changed on this
- occasion to invert diagonal blocks during initialization.
- <br>
- (GK 2003/01/06)
- </p>
-
- <li> <p>
- New: The interface for sparse decompositions has been abstracted, and
- there is now an Modified Incomplete Cholesky (MIC) decomposition in
- addition to the Imcomplete LU (ILU) decomposition.
- <br>
- (Stephen Kolaroff 2002/11/27)
- </p>
-
- <li> <p>
- Changed: In multithread mode, the <code
- class="class">SparseMatrix</code> would spawn
- <code>multithread_info.n_default_threads</code> threads to
- perform matrix-vector multiplications and similar
- operations. It would even do so if
- <code>multithread_info.n_default_threads</code> was equal to
- one. In that case, we now do the operation on the thread we are
- presently on, eliminating the overhead of spawning a single
- thread, and later waiting and terminating it.
- <br>
- (WB 2002/11/13)
- </p>
-
- <li> <p>
- Fixed: In the <code class="class">SparseDirectMA27</code> class, wrapping
- the MA27 solver written in Fortran77 into some structure amenable to C++,
- we wrote beyond the end of an array on rare inputs. This is now fixed. The
- same probably holds for the respective code for MA47.
- <br>
- (WB 2002/09/30)
- </p>
-
- <li> <p>
- New: Since the MA27 sparse direct solver uses Fortran common blocks, it
- was previously impossible to run several instances of this solver in
- parallel, in a multihreaded environment. To solve this problem, the
- <code class="class">SparseDirectMA27</code> class now has a detached
- mode, in which it forks off a separate program that will do the
- computations using this solver. The actual operations are therefore
- distributed to distint programs that have separate address spaces. This
- allows to have as many concurrent instances of this solver in parallel
- as you want. For more information, read the documentation of the
- <code class="class">SparseDirectMA27</code> class.
- <br>
- (WB 2002/09/25)
- </p>
-
- <li> <p> Changed: The classes <code
- class="class">PreconditionBlock</code>, <code
- class="class">PreconditionBlockJacobi</code>, <code
- class="class">PreconditionBlockSOR</code>, and <code
- class="class">PreconditionBlockSSOR</code> have changed their
- template signature. The first template argument is now the matrix
- type, not just a number type.
- <br>
- (GK 2002/09/18)
- </p>
-
- <li> <p> New: Class <code class="class">BlockVector</code> has a
- function <code class="member">collect_sizes()</code>, very much as
- <code class="class">BlockSparsityPattern</code>. This allows
- updating internal structures after blocks have been resized.
- <br>
- (GK 2002/09/17)
- </p>
-
- <li> <p> New: Class <code class="class">SparseMatrix</code> has an
- STL-conforming <code class="class">const_iterator</code> and
- functions <code class="member">begin()</code> and <code
- class="member">end()</code> for looping through all existing
- entries. Furthermore, <code class="member">begin(row)</code> and
- <code class="member">end(row)</code> allow looping through all
- entries of a single line.
- <br>
- (GK 2002/09/11)
- </p>
-
- <li> <p>
- New: Classes <code class="class">SparsityPattern</code> and <code
- class="class">SparseMatrix</code> now have functions <code
- class="member">block_write/block_read</code>, allowing to dump the data
- of these objects into a file in binary format, and later to re-read it
- without much need for parsing.
- <br>
- (WB 2002/09/09)
- </p>
-
- <li> <p>
- New: <code class="class">Vector</code> has a function <code
- class="member">lp_norm</code>, computing the <i>l<sub>p</sub></i>-norm
- of a vector for arbitrary <i>p</i>.
- <br>
- (GK 2002/08/13)
- </p>
-
- <li> <p>
- New: a way of using abstract base classes for matrices has
- been implemented with <code class="class">PointerMatrixBase</code>
- and <code class="class">PointerMatrix</code>. Storing a matrix in
- <code class="class">PointerMatrix</code> allows to use the base
- class in functions only templated for the vector class.
- <br>
- (GK 2002/07/18)
- </p>
-</ol>
-
-
-
-<a name="deal.II"></a>
-<h3>deal.II</h3>
-
-<ol>
- <li> <p>
- Fixed: The restriction matrices for the Q1 element in 1d had a
- trivial bug in that one element was not set. Due to the fact
- that contributions from all child cells are taken into account,
- this did no harm, though, since all computations were done
- correctly anyway.
- <br>
- (WB 2003/05/06)
- </p>
-
- <li> <p>
- New: The <code class="class">GeometryInfo</code> classes now
- have new static member functions <code
- class="member">child_cell_from_point</code> that, given a point
- in the unit cell, returns which child cell it is on; <code
- class="member">cell_to_child_coordinates</code> that transforms
- coordinates between the unit coordinate systems from the mother
- to the child cell; <code
- class="member">child_to_cell_coordinates</code> that does
- exactly the opposite; and <code
- class="member">is_inside_unit_cell</code> that tells whether a
- given point is inside the unit cell.
- <br>
- (WB 2003/05/01)
- </p>
-
- <li> <p>
- New: There are now functions <code
- class="member">recursively_set/clear_user_pointer</code> that
- do much the same as <code
- class="member">recursively_set/clear_user_flag</code> on a
- line/quad/hex and all of its descendants, but on user pointers
- rather than flags.
- <br>
- (WB 2003/04/11)
- </p>
-
- <li> <p>
- New: The functions in the <code
- class="class">DerivativeApproximation</code> class can now also
- work on <code class="class">BlockVector</code>.
- <br>
- (WB 2003/04/11)
- </p>
-
- <li> <p>
- Changed: The cell argument to <code
- class="member">Mapping::transform_unit_to_real_cell</code> (and its
- reverse function) is now passed by reference, rather than by value, for
- efficiency reasons.
- <br>
- (WB 2003/04/06)
- </p>
-
- <li> <p>
- New: The <code
- class="member">GridGenerator::subdivided_hyper_cube</code> generated a
- hypercube as coarse grid that is subdivided a given number of times.
- <br>
- (WB 2003/04/05)
- </p>
-
- <li> <p>
- New: The <code class="member">DataOut_DoFData::merge_patches</code>
- function allows to merge the patches of two objects, so as to create one
- output file from several DoF handlers. This is useful if one uses a
- domain decomposition algorithm where each block of the domain is
- represented by one DoF handler.
- <br>
- (WB 2003/04/05)
- </p>
-
- <li> <p>
- Fixed: The <code class="class">DataOutStack</code> class had a problem
- when there were as many degrees of freedom as there were cells (i.e. if
- we were using DG0 elements). This should now be fixed.
- <br>
- (WB 2003/03/02)
- </p>
-
- <li> <p>
- Fixed: The <code class="class">DataOutFaces</code> class was
- broken for cell data. It should now be correct, although the
- algorithm used is not optimal, being approximately quadratic in
- runtime.
- <br>
- (WB 2003/02/25)
- </p>
-
- <li> <p>
- New: The <code class="member">ConstraintMatrix::shift</code>
- function shifts and translates the elements of the constraint
- matrix by a certain number of indices.
- <br>
- (Roy Stogner 2003/02/24)
- </p>
-
- <li> <p>
- New: The <code class="class">GridReordering</code> class now uses a
- vastly better algorithm in 2d than previously. The new algorithm is
- linear in time, where it could be exponential before.
- <br>
- (Michael Anderson 2003/02/21)
- </p>
-
- <li> <p>
- New: There is now a function <code
- class="member">GridIn::read_xda</code> that allows reading
- grids from a file in XDA format.
- <br>
- (WB 2003/02/21)
- </p>
-
- <li> <p>
- Changed: Some implementation details of the <code
- class="class">GridReordering</code> class have been moved to a
- namespace <code class="class">internal</code>.
- <br>
- (WB 2003/02/19)
- </p>
-
- <li> <p>
- New: There are now functions <code
- class="member">FiniteElement::prolongation_is_implemented</code> and
- <code class="member">FiniteElement::constraints_are_implemented</code>
- that inform the caller about whether the finite element in question in
- fact implements its prolongation matrices and hanging node constraints.
- <br>
- (WB 2003/02/15)
- </p>
-
- <li> <p>
- Fixed: The <code
- class="member">ConstraintMatrix::is_identity_constrained</code> function
- would previously generate a segmentation fault if called on a constraint
- matrix object that did not contain any constraints at all. This is now
- fixed.
- <br>
- (WB 2003/02/15)
- </p>
-
- <li> <p>
- Fixed: Objects of type <code class="class">FESystem</code>
- could not be constructed if one of the elements it is to be composed of
- did not implement interface constraints for hanging nodes. This is now
- fixed: you can construct such a composed element, but it does not
- implement hanging node constraints either.
- <br>
- (WB 2003/02/15)
- </p>
-
- <li> <p>
- New: For each of the renumbering functions in the <code
- class="class">DoFRenumbering</code> class there is now an
- additional <code class="member">compute_*</code>
- function. These new functions compute and return the
- corresponding renumbering vectors but do not perform the actual
- renumbering on the <code class="class">DoFHandler</code>
- object. The behaviour of the old functions is not changed.
- <br>
- (RH 2003/02/03)
- </p>
-
- <li> <p>
- Fixed: The <code class="class">GridReordering</code> tried to be
- thread-safe in the initialization of some data, but was not due to a
- typo. This is now fixed.
- <br>
- (WB 2003/01/28)
- </p>
-
- <li> <p>
- Changed: The <code class="member">FEValues::get_cell</code> and
- <code class="member">FEValues::get_face</code> functions have
- been removed, since they limited our ability to use this
- class for other types of DoFHandlers, for example future
- extensions for hp elements.
- <br>
- (WB 2003/01/17)
- </p>
-
- <li> <p>
- New: The DoF accessor classes now have a function <code
- class="member">get_fe()</code> that returns a reference to the finite
- element being used on this cell. The result is of course identical to
- what a call to <code
- class="member">iterator->get_dof_handler().get_fe()</code> would have
- yielded.
- <br>
- (WB 2003/01/10)
- </p>
-
- <li> <p>
- New: Checked in new <code class="class">GridGenerator</code>
- member function <code class="member">half_hyper_ball</code>,
- derived from member <code class="member">hyper_ball</code>.
- The intial mesh contains four elements. This mesh will work with
- the boundary class <code class="class">HalfHyperBallBoundary</code>.
- <br>
- (Brian Carnes 2002/12/16)
- </p>
-
- <li> <p>
- New: Checked in new class <code class="class">FE_Q_Hierarchical</code>
- derived from class <code class="class">FiniteElement</code>.
- This element is analogous to <code class="class">FE_Q</code>, but
- makes use of hierachical shape functions, based on the
- <code class="class">Polynomials::Hierarchical</code> class.
- For <code>degree>1</code>, the non-nodal basis functions are "bubble"
- functions, which are not Lagrange polynomials. Therefore, the usual
- interpolation based on using unit support points will not work for
- <code>degree>1</code>. It is planned to implement a different
- interpolation-projection operator, based on an hp-type interpolant.
- <br>
- The files for this element are
- <code>deal.II/include/fe/fe_q_hierarchical.h</code> and
- <code>deal.II/source/fe/fe_q_hierarchical.cc</code>.
- <br>
- (Brian Carnes 2002/12/13)
- </p>
-
- <li> <p>
- New: For finite element classes, the functions
- <code class="member">unit_support_point</code> and
- <code class="member">unit_face_support_point</code> return the position
- of an individual support point. This is necessary when you want to get
- information about the support points of certain components in a composed
- finite element, where not all components provide support points, and the
- composed element thus does not fill the array the
- <code class="member">get_unit_support_points</code> function returns.
- <br>
- (WB 2002/11/23)
- </p>
-
- <li> <p>
- Fixed: Vectors could not be given as input and output vectors to the
- <code class="class">SolutionTransfer</code> class at the same time, but
- this was not checked. An assertion has now been added to ensure this
- requirement.
- <br>
- (WB 2002/10/28)
- </p>
-
- <li> <p>
- Fixed: The <code
- class="member">DoFRenumbering::component_wise</code> function accepts a
- parameter indicating the order in which the degrees of freedom
- corresponding to one vector component are to be sorted. However, it did
- not honor this order, but always sorted them in the order in which the
- components appear. This is now fixed.
- <br>
- (WB 2002/10/17)
- </p>
-
- <li> <p>
- New: The <code
- class="member">FiniteElement::system_to_base_index</code> function now
- exports the values of the <code
- class="member">FiniteElement::system_to_base_table</code> member
- variable. Likewise for the indices on faces.
- <br>
- (WB 2002/10/17)
- </p>
-
- <li> <p>
- New: The <code
- class="member">FiniteElement::element_multiplicity</code> function was
- previously only available in the <code class="class">FESystem</code>
- class, where it actually returned a non-trivial value. However, in some
- cases one would need to access this field also for general finite
- elements, even if the returned value will be equal to one in all cases
- other than a composed element.
- <br>
- (WB 2002/10/17)
- </p>
-
- <li> <p>
- Fixed: The algorithm to generate neighbor information for patches from
- cells in <code class="member">DataOut::build_patches</code> was rather
- inefficient, tripling the time for patch generation when support for
- neighbor information was added. Furthermore, the algorithm was at least
- O(N log N), where the rest was all O(N), making this particularly
- problematic when the data set was already large. This should now be back
- to the previous level, by using a more efficient algorithm.
- <br>
- (WB 2002/10/10)
- </p>
-
- <li> <p>
- Changed (internals): Previously, the finite element base class
- initialized the restriction, prolongation, and face constraints matrices
- to their correct size. Derived classes had to fill these classes, and
- should have set their size back to zero in case they chose not to
- implement them. However, we found a class that forgot to resize it to
- zero, so it is now the other way round: they remain at size zero, and a
- class that chooses to implement these matrices has to set them to the
- correct size, to avoid programs that run on data that as just been
- forgotten to add. (This information only concerns programs that
- implement some finite element class on their own.)
- <br>
- (WB 2002/09/28)
- </p>
-
- <li> <p>Improved: The different transfer functions in <code
- class="class">FETools</code> operate on template vector arguments.
- <br>
- (GK 2002/09/24)
- </p>
-
- <li> <p> New: the class <code
- class="class">FE_DGPNonparametric</code> implements finite elements
- where shape functions are polynomials of order <i>k</i> on the
- actual grid cell. This is achieved by evaluating the polynomials at
- the mapped quadrature points. No grid transfer matrices are
- available for this class.
- <br>
- (GK 2002/09/19)
- </p>
-
- <li> <p>
- Fixed: Some of the various instances of the <code
- class="member">VectorTools::interpolate_boundary_values</code> functions
- were not explicitly instantiated, leading to linker errors. This is now
- fixed.
- <br>
- (WB 2002/09/19)
- </p>
-
- <li> <p>
- Removed: The <code
- class="member">FiniteElement::component_to_system_index</code> function
- and its counterpart for faces is gone. This data did not make much sense
- in the case of elements that are non-zero in more than one vector
- component, such as the Nedelec element. The respective information can
- also be obtained from other sources provided by the finite element
- classes, if so necessary.
- <br>
- (WB 2002/09/16)
- </p>
-
- <li> <p>
- Changed: The <code
- class="member">FiniteElement::restriction_is_additive</code> function
- used to take an argument that denoted the vector component of a finite
- element. This has become difficult with elements that are non-zero in
- more than one vector component, such as the Nedelec element. Thus, the
- semantics of the function have been changed so that the argument now
- denotes the index of a shape function, rather than a vector
- component. Since the function is probably not used in application code,
- this will most probably not lead to more serious problems.
- <br>
- (WB 2002/09/16)
- </p>
-
- <li> <p>
- New: The mapping classes now also know how to transform tensors of rank
- 2, not only vectors (tensors of rank 1) in a co- and contravariant way.
- <br>
- (WB 2002/09/03)
- </p>
-
- <li> <p>
- Fixed: the <code class="class">GridIn</code> class had problems
- when reading in UCD grids with comment lines that contained
- only the comment sign, but nothing else. This is now fixed.
- <br>
- (WB 2002/08/30)
- </p>
-
- <li> <p>
- Improved: <code class="class">VectorTools</code>::<code
- class="member">integrate_difference</code> can compute <i>L<sup>p</sup></i>
- and <i>W<sup>1,p</sup></i> norms for arbitrary <i>p</i>. The function
- receives an additional optional argument <i>p</i> for this. All previous
- fuctionality remains unchanged, although the code has been cleaned up a bit.
- <br>
- (GK 2002/08/01)
- </p>
-
- <li> <p> New: The <code class="class">GridTools</code> class now
- offers functions to apply general transformations to all
- vertices of a triangulation, and also more specialized
- functions that shift, scale, and rotate triangulations.
- <br>
- (RH 2002/07/25)
- </p>
-
- <li> <p> New: The existing <code
- class="member">FETools::extrapolate</code> functions does not
- take into account hanging node constraints. Therefore, it works
- for continuous elements on globally refined grids and on
- discontinuous elements, only. Now, there is a new <code
- class="member">FETools::extrapolate</code> function with an
- additional <code class="class">ConstraintMatrix</code> argument
- for the hanging node constraints. This new function works for
- continuous as well as for discontinuous elements. But, the old
- function is still supported.
- <br>
- (RH 2002/06/17)
- </p>
-
- <li> <p> New: There are now <code
- class="member">Triangulation::save/load_user_pointers(vector<void
- *> &)</code> functions similar to the respective <code
- class="member">Triangulation::save/load_user_flags(vector<bool>
- &)</code> functions.
- <br>
- (RH 2002/06/14)
- </p>
-
- <li> <p> Fixed: Bug in <code
- class="member">Triangulation<3>::load_user_flags(vector<bool>
- &)</code> is now fixed.
- <br>
- (RH 2002/06/14)
- </p>
-
- <li> <p> Fixed: <code
- class="member">Triangulation::load_user_flags(vector<bool>
- &)</code> erroneously threw an assertion for
- <code>dim==1</code>. This is now fixed.
- <br>
- (RH 2002/06/14)
- </p>
-
- <li> <p> Changed: <code
- class="member">Triangulation<1>::n_quads</code> now returns 0,
- instead of throwing an assertion, as before. The same holds for
- similar functions like <code
- class="member">Triangulation<dim>::n_hexs</code> that now
- returns 0 for <code>dim<3</code>.
- <br>
- (RH 2002/06/14)
- </p>
-
- <li> <p> Improved: Several functions like the <code
- class="member">DoFHandler::distribute_dofs</code> and <code
- class="member">DoFTools::make_flux_sparsity_pattern</code>
- functions altered the <code
- class="member">user_flags</code>. This was stated in the
- documentation of these functions. Nevertheless, it might have
- led to unexpected behaviour of the <code
- class="member">user_flags</code> for users who weren't aware of
- this <em>side-effect</em>. Now, these functions do not alter
- the <code class="member">user_flags</code>, any
- more. Consequently, the users do not need to worry any more
- about the reliability of the <code
- class="member">user_flags</code> when calling any function of
- the library.
- <br>
- (RH 2002/06/14)
- </p>
-
- <li> <p> Fixed: <code
- class="member">FE_Q::has_support_on_face</code> always returned
- true in 1d, partly because faces are not really an issue in
- 1d. It now does so only when the support point of the
- respective shape function is actually the requested vertex. The
- same applied to <code
- class="member">FE_DGQ::has_support_on_face</code>
- <br>
- (WB 2002/06/13)
- </p>
-
- <li> <p> New: The existing <code
- class="member">FETools::interpolate</code>, <code
- class="member">FETools::back_interpolate</code> and <code
- class="member">FETools::interpolate_difference</code> functions
- do not take into account hanging node constraints. Therefore,
- they work for continuous elements on globally refined grids and
- on discontinuous elements, only. Now, there are new functions
- with the same names but additional <code
- class="class">ConstraintMatrix</code> arguments for the hanging
- node constraints. These new functions work for continuous as
- well as for discontinuous elements. But, the old functions are
- still supported.
- <br>
- (RH 2002/06/13)
- </p>
-
- <li> <p> Changed: The constructor of <code
- class="class">DoFHandler</code> now takes a reference to a
- <code>const</code> <code class="class">Triangulation</code>.
- <br>
- (RH 2002/06/12)
- </p>
-
- <li> <p> Changed: The constructors of all <code
- class="class">DoFAccessor</code>, <code
- class="class">TriaAccessor</code> and <code
- class="class">TriaIterator</code> classes now take pointers to
- <tt>const</tt> <code class="class">Triangulation</code>s.
- <br>
- (RH 2002/06/12)
- </p>
-
- <li> <p> Fixed: In debug mode the <code
- class="member">MappingQ1::transform_real_to_unit_cell</code>
- function erroneously threw an assertion when used in 1 or 3
- dimensions. This is now fixed.
- <br>
- (RH 2002/06/10)
- </p>
-
- <li> <p>
- Fixed: The <code class="member">get_dof_indices</code>
- functions of DoF accessor classes used to work also for
- non-active cells. However, the results were bogus except for
- the special case that we had a finite element that has all its
- degrees of freedom located in vertices. This is now fixed: the
- function throws an exception in all other cases, since there is
- no useful meaning for it then. It continues to work in the
- special case.
- <br>
- (WB 2002/06/08)
- </p>
-
- <li> <p>
- New: For encapsulated postscript output of 2d grids, it is now
- possible to tell the <code class="class">GridOut</code> class to
- write the cell numbers into each cell, as well as the numbers
- of the vertices.
- <br>
- (WB 2002/06/04)
- </p>
-</ol>
-
-<hr>
-Last update $Date$
-
-</body>
-</html>
<li> <p>
New: There is now
- <a href="../reports/assemble/index.html" target="body">a new report
+ <a href="../reports/assemble/assemble.pdf" target="body">a new report
on assembling matrices</a> available from the
<a href="../documentation.html" target="body">documentation
page</a>. The main focus is assembling of matrices for
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>assemble</TITLE>
-<META NAME="description" CONTENT="assemble">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="next" HREF="node1.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html2"
- HREF="node1.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif_gr.gif">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif_gr.gif">
-<BR>
-<B> Next:</B> <A NAME="tex2html3"
- HREF="node1.html">Introduction</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<P>
-<DIV ALIGN="CENTER">
-</DIV>
-<DIV ALIGN="CENTER"><FONT SIZE="+3">Assembling matrices in <TT>deal.II</TT>
- </FONT>
-</DIV>
-<P>
-<DIV ALIGN="CENTER">
-<BR>
-<BR>
-</DIV>
-<P>
-<DIV ALIGN="CENTER"></DIV>
-<DIV ALIGN="CENTER"><FONT SIZE="+1">Wolfgang Bangerth
-<BR>
-ETH Zürich, Switzerland
-<BR>
-<BR>
-May 2002
- </FONT>
-</DIV>
-
-<P>
-<BR><HR>
-<!--Table of Child-Links-->
-<A NAME="CHILD_LINKS"></A>
-
-<H2>Overview</H2>
-
-<P>
-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.
-
-<P>
-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 <TT>deal.II</TT>. 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.
-
-<P>
-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.
-
-
-<H2>Table of contents</h2>
-
-
-
-<UL>
-<LI><A NAME="tex2html5"
- HREF="node2.html">Linear systems for finite element methods</A>
-<LI><A NAME="tex2html6"
- HREF="node3.html">Assembling scalar problems</A>
-<LI><A NAME="tex2html7"
- HREF="node4.html">Vector-valued problems</A>
-<UL>
-<LI><A NAME="tex2html8"
- HREF="node5.html">The elastic equations</A>
-<LI><A NAME="tex2html9"
- HREF="node6.html">The Stokes equations</A>
-</UL>
-<BR>
-<LI><A NAME="tex2html10"
- HREF="node7.html">Assembling vector-valued problems: The simple case</A>
-<UL>
-<LI><A NAME="tex2html11"
- HREF="node8.html">The elastic equations</A>
-<LI><A NAME="tex2html12"
- HREF="node9.html">The Stokes equations</A>
-</UL>
-<BR>
-<LI><A NAME="tex2html13"
- HREF="node10.html">Assembling vector-valued problems: The complicated case</A>
-<UL>
-<LI><A NAME="tex2html14"
- HREF="node11.html">Getting information about shape functions</A>
-<LI><A NAME="tex2html15"
- HREF="node12.html">Evaluating shape functions</A>
-<LI><A NAME="tex2html16"
- HREF="node13.html">The elastic equations</A>
-<LI><A NAME="tex2html17"
- HREF="node14.html">The Stokes equations</A>
-</UL>
-<BR>
-<LI><A NAME="tex2html18"
- HREF="node15.html">Conclusions</A>
-</UL>
-<!--End of Table of Child-Links-->
-<BR><HR>
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>Assembling vector-valued problems: The complicated case</TITLE>
-<META NAME="description" CONTENT="Assembling vector-valued problems: The complicated case">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="next" HREF="node15.html">
-<LINK REL="previous" HREF="node7.html">
-<LINK REL="up" HREF="assemble.html">
-<LINK REL="next" HREF="node11.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html118"
- HREF="node11.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html116"
- HREF="assemble.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html110"
- HREF="node9.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html119"
- HREF="node11.html">Getting information about shape</A>
-<B> Up:</B> <A NAME="tex2html117"
- HREF="assemble.html">assemble</A>
-<B> Previous:</B> <A NAME="tex2html111"
- HREF="node9.html">The Stokes equations</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H1><A NAME="SECTION00060000000000000000">
-Assembling vector-valued problems: The complicated case</A>
-</H1>
-
-<P>
-The more complicated case is when more than one component of a vector-valued
-shape function is non-zero, i.e. the representation
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="248" HEIGHT="39" ALIGN="MIDDLE" BORDER="0"
- SRC="img77.gif"
- ALT="$\displaystyle \Phi_i(\vec x) = \left( 0, \dots, 0, \varphi_i(\vec x), 0, \ldots, 0\right)^T,$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-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:
-<!-- MATH
- $\vec n\cdot \Phi_i(x_a) = \delta_{ia}$
- -->
-<IMG
- WIDTH="112" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img95.gif"
- ALT="$ \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.
-
-<P>
-What happens in this case? First, the function
-<TT>FiniteElement::system_to_component_index</TT> does not make much sense
-any more, since a shape function <IMG
- WIDTH="21" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img76.gif"
- ALT="$ \Phi_i$"> cannot be associated with only one
-vector component any more. Calling this function for basis functions <IMG
- WIDTH="21" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img76.gif"
- ALT="$ \Phi_i$">
-that are not restricted to only one non-zero component will thus yield an
-exception being thrown.
-
-<P>
-Second, the functions <TT>FEValues::shape_value</TT> and
-<TT>FEValues::shape_grad</TT> 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 <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$">. For those shape function for which this holds, you will
-again get an exception upon calling these functions.
-
-<P>
-<BR><HR>
-<!--Table of Child-Links-->
-<A NAME="CHILD_LINKS"><STRONG>Subsections</STRONG></A>
-
-<UL>
-<LI><UL>
-<LI><A NAME="tex2html120"
- HREF="node11.html">Getting information about shape functions</A>
-<LI><A NAME="tex2html121"
- HREF="node12.html">Evaluating shape functions</A>
-</UL>
-<BR>
-<LI><A NAME="tex2html122"
- HREF="node13.html">The elastic equations</A>
-<LI><A NAME="tex2html123"
- HREF="node14.html">The Stokes equations</A>
-</UL>
-<!--End of Table of Child-Links-->
-<HR>
-<!--Navigation Panel-->
-<A NAME="tex2html118"
- HREF="node11.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html116"
- HREF="assemble.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html110"
- HREF="node9.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html119"
- HREF="node11.html">Getting information about shape</A>
-<B> Up:</B> <A NAME="tex2html117"
- HREF="assemble.html">assemble</A>
-<B> Previous:</B> <A NAME="tex2html111"
- HREF="node9.html">The Stokes equations</A>
-<!--End of Navigation Panel-->
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>Getting information about shape functions</TITLE>
-<META NAME="description" CONTENT="Getting information about shape functions">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="next" HREF="node12.html">
-<LINK REL="previous" HREF="node10.html">
-<LINK REL="up" HREF="node10.html">
-<LINK REL="next" HREF="node12.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html132"
- HREF="node12.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html130"
- HREF="node10.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html124"
- HREF="node10.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html133"
- HREF="node12.html">Evaluating shape functions</A>
-<B> Up:</B> <A NAME="tex2html131"
- HREF="node10.html">Assembling vector-valued problems: The</A>
-<B> Previous:</B> <A NAME="tex2html125"
- HREF="node10.html">Assembling vector-valued problems: The</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H3><A NAME="SECTION00060100000000000000">
-Getting information about shape functions</A>
-</H3>
-
-<P>
-So how do you find out whether calling these functions is ok or not? In other
-words, how do you know whether shape function <IMG
- WIDTH="21" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img76.gif"
- ALT="$ \Phi_i$"> has only one non-zero
-component, or more? For this, there are two functions:
-<TT>FiniteElement::is_primitive(i)</TT> returns as a <TT>bool</TT> whether
-the shape function has only one non-zero component. For example, for a
-<!-- MATH
- $Q^2/Q^2/Q^1$
- -->
-<IMG
- WIDTH="79" HEIGHT="33" ALIGN="MIDDLE" BORDER="0"
- SRC="img86.gif"
- ALT="$ Q^2/Q^2/Q^1$"> element, this would be <TT>true</TT> 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 <TT>false</TT> for all indices <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$">. It might also
-be <TT>true</TT> 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 <IMG
- WIDTH="24" HEIGHT="33" ALIGN="MIDDLE" BORDER="0"
- SRC="img96.gif"
- ALT="$ Q^1$">, then it would be
-<TT>true</TT> for the pressure shape functions, but <TT>false</TT> otherwise.
-
-<P>
-Second, the <TT>FiniteElement::n_nonzero_components(i)</TT> function returns
-in how many components the <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$">th shape function is non-zero. Again, for the
-<!-- MATH
- $Q^2/Q^2/Q^1$
- -->
-<IMG
- WIDTH="79" HEIGHT="33" ALIGN="MIDDLE" BORDER="0"
- SRC="img86.gif"
- ALT="$ Q^2/Q^2/Q^1$"> combination, this would yield the value 1 for all allowed
-indices <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$">. For coupled elements, it would be greater than 1.
-
-<P>
-Third, you may sometimes want to know in which components a certain shape
-function is non-zero. For this, the
-<TT>FiniteElement::get_nonzero_components(i)</TT> 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.
-
-<P>
-Note that if you have the result of
-<TT>FiniteElement::get_nonzero_components(i)</TT>, then the result of
-<TT>FiniteElement::n_nonzero_components(i)</TT> is simply the number of
-<TT>true</TT> values in the array returned by the first function. Likewise,
-<TT>FiniteElement::is_primitive(i)</TT> is simply whether
-<TT>FiniteElement::n_nonzero_components(i)</TT> returned a value other than
-1. The functions are thus redundant in some way, but useful nevertheless. Of
-course, the values of the <TT>FiniteElement::is_primitive(i)</TT>
-and <TT>FiniteElement::n_nonzero_components(i)</TT> 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.
-
-<P>
-<HR>
-<!--Navigation Panel-->
-<A NAME="tex2html132"
- HREF="node12.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html130"
- HREF="node10.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html124"
- HREF="node10.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html133"
- HREF="node12.html">Evaluating shape functions</A>
-<B> Up:</B> <A NAME="tex2html131"
- HREF="node10.html">Assembling vector-valued problems: The</A>
-<B> Previous:</B> <A NAME="tex2html125"
- HREF="node10.html">Assembling vector-valued problems: The</A>
-<!--End of Navigation Panel-->
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>Evaluating shape functions</TITLE>
-<META NAME="description" CONTENT="Evaluating shape functions">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="previous" HREF="node11.html">
-<LINK REL="up" HREF="node10.html">
-<LINK REL="next" HREF="node13.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html140"
- HREF="node13.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html138"
- HREF="node10.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html134"
- HREF="node11.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html141"
- HREF="node13.html">The elastic equations</A>
-<B> Up:</B> <A NAME="tex2html139"
- HREF="node10.html">Assembling vector-valued problems: The</A>
-<B> Previous:</B> <A NAME="tex2html135"
- HREF="node11.html">Getting information about shape</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H3><A NAME="SECTION00060200000000000000">
-Evaluating shape functions</A>
-</H3>
-
-<P>
-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 <TT>FEValues::shape_value</TT>
-and <TT>FEValues::shape_grad</TT>, call
-<TT>FEValues::shape_value_component</TT> and
-<TT>FEValues::shape_grad_component</TT>. 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.
-
-<P>
-Of course, these functions can be called on primitive shape functions as
-well. In that case, the following holds:
-
-<UL>
-<LI>The value of <TT>FEValues::shape_value_component(i,q,c)</TT> is equal
- to <TT>FEValues::shape_value(i,q)</TT> if and only if the component
- <TT>c</TT> is equal to <TT>fe.system_to_component_index(i).first</TT>,
- i.e. if <TT>c</TT> is the only non-zero component of the shape function
- <TT>i</TT>.
-</LI>
-<LI>For all other components <TT>c</TT>, the returned value of
- <TT>FEValues::shape_value_component(i,q,c)</TT> is zero.
-</LI>
-</UL>
-The same of course also holds for
-<TT>FEValues::shape_grad_component(i,q,c)</TT> and
-<TT>FEValues::shape_2nd_derivative_component(i,q,c)</TT>.
-
-<P>
-<BR><HR>
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>The elastic equations</TITLE>
-<META NAME="description" CONTENT="The elastic equations">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="next" HREF="node14.html">
-<LINK REL="previous" HREF="node10.html">
-<LINK REL="up" HREF="node10.html">
-<LINK REL="next" HREF="node14.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html150"
- HREF="node14.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html148"
- HREF="node10.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html142"
- HREF="node12.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html151"
- HREF="node14.html">The Stokes equations</A>
-<B> Up:</B> <A NAME="tex2html149"
- HREF="node10.html">Assembling vector-valued problems: The</A>
-<B> Previous:</B> <A NAME="tex2html143"
- HREF="node12.html">Evaluating shape functions</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H2><A NAME="SECTION00061000000000000000">
-The elastic equations</A>
-</H2>
-
-<P>
-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 <A HREF="node8.html#sec:elastic-simple">5.1</A>):
-<PRE>
- 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));
- };
-</PRE>
-If you dislike this particular order of the loops, you can reorder them as you
-like, as they are independent.
-
-<P>
-The code as shown above can be optimized. For example, instead of
-unconditionally performing the loop over all components of shape functions <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$">
-of <IMG
- WIDTH="12" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img83.gif"
- ALT="$ j$">, we might first ask whether these shape functions are primitive, using
-<TT>fe.is_primitive(i)</TT>, and use the loop only if the result is false;
-if, on the other hand, the result is true, we only need to set
-<TT>comp_i</TT> to the fixed value
-<TT>fe.system_to_component_index(i).first</TT>, and likewise for shape
-function <IMG
- WIDTH="12" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img83.gif"
- ALT="$ j$">.
-
-<P>
-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 <TT>comp_i</TT> by
-this:
-<PRE>
- for (unsigned int comp_i=0; comp_i<fe.n_components(); ++comp_i)
- if (fe.get_nonzero_components(i)[comp_i] == true)
-</PRE>
-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.
-
-<P>
-<HR>
-<!--Navigation Panel-->
-<A NAME="tex2html150"
- HREF="node14.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html148"
- HREF="node10.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html142"
- HREF="node12.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html151"
- HREF="node14.html">The Stokes equations</A>
-<B> Up:</B> <A NAME="tex2html149"
- HREF="node10.html">Assembling vector-valued problems: The</A>
-<B> Previous:</B> <A NAME="tex2html143"
- HREF="node12.html">Evaluating shape functions</A>
-<!--End of Navigation Panel-->
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>The Stokes equations</TITLE>
-<META NAME="description" CONTENT="The Stokes equations">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="previous" HREF="node13.html">
-<LINK REL="up" HREF="node10.html">
-<LINK REL="next" HREF="node15.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html158"
- HREF="node15.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html156"
- HREF="node10.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html152"
- HREF="node13.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html159"
- HREF="node15.html">Conclusions</A>
-<B> Up:</B> <A NAME="tex2html157"
- HREF="node10.html">Assembling vector-valued problems: The</A>
-<B> Previous:</B> <A NAME="tex2html153"
- HREF="node13.html">The elastic equations</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H2><A NAME="SECTION00062000000000000000">
-The Stokes equations</A>
-</H2>
-
-<P>
-Likewise, this is now the code for the Stokes equations:
-<PRE>
- 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));
- };
-</PRE>
-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.
-
-<P>
-<BR><HR>
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>Conclusions</TITLE>
-<META NAME="description" CONTENT="Conclusions">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="next" HREF="node16.html">
-<LINK REL="previous" HREF="node10.html">
-<LINK REL="up" HREF="assemble.html">
-<LINK REL="next" HREF="node16.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html168"
- HREF="node16.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html166"
- HREF="assemble.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html160"
- HREF="node14.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html169"
- HREF="node16.html">About this document ...</A>
-<B> Up:</B> <A NAME="tex2html167"
- HREF="assemble.html">assemble</A>
-<B> Previous:</B> <A NAME="tex2html161"
- HREF="node14.html">The Stokes equations</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H1><A NAME="SECTION00070000000000000000">
-Conclusions</A>
-</H1>
-
-<P>
-We have shown how finite element matrices are assembled using the
-functionality of the <TT>deal.II</TT> 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.
-
-<P>
-<BR><HR>
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>About this document ...</TITLE>
-<META NAME="description" CONTENT="About this document ...">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="previous" HREF="node15.html">
-<LINK REL="up" HREF="assemble.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif_gr.gif">
-<A NAME="tex2html174"
- HREF="assemble.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html170"
- HREF="node15.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Up:</B> <A NAME="tex2html175"
- HREF="assemble.html">assemble</A>
-<B> Previous:</B> <A NAME="tex2html171"
- HREF="node15.html">Conclusions</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H1><A NAME="SECTION00080000000000000000">
-About this document ...</A>
-</H1>
- <P>
-This document was generated using the
-<A HREF="http://www.latex2html.org/"><STRONG>LaTeX</STRONG>2<tt>HTML</tt></A> translator Version 2002-1 (1.68)
-<P>
-Copyright © 1993, 1994, 1995, 1996,
-<A HREF="http://cbl.leeds.ac.uk/nikos/personal.html">Nikos Drakos</A>,
-Computer Based Learning Unit, University of Leeds.
-<BR>
-Copyright © 1997, 1998, 1999,
-<A HREF="http://www.maths.mq.edu.au/~ross/">Ross Moore</A>,
-Mathematics Department, Macquarie University, Sydney.
-<P>
-The command line arguments were: <BR>
- <STRONG>latex2html</STRONG> <TT><A NAME="tex2html1"
- HREF="../assemble.tex">assemble.tex</A></TT>
-<P>
-The translation was initiated by Wolfgang Bangerth on 2002-06-14
-<BR><HR>
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>Linear systems for finite element methods</TITLE>
-<META NAME="description" CONTENT="Linear systems for finite element methods">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="next" HREF="node3.html">
-<LINK REL="previous" HREF="node1.html">
-<LINK REL="up" HREF="assemble.html">
-<LINK REL="next" HREF="node3.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html38"
- HREF="node3.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html36"
- HREF="assemble.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html30"
- HREF="node1.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html39"
- HREF="node3.html">Assembling scalar problems</A>
-<B> Up:</B> <A NAME="tex2html37"
- HREF="assemble.html">assemble</A>
-<B> Previous:</B> <A NAME="tex2html31"
- HREF="node1.html">Introduction</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H1><A NAME="SECTION00020000000000000000">
-Linear systems for finite element methods</A>
-</H1>
-
-<P>
-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: <I>find <IMG
- WIDTH="45" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img1.gif"
- ALT="$ u\in
-V$"> such that</I>
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="200" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img2.gif"
- ALT="$\displaystyle a(u, v) = (f,v)_\Omega \qquad \forall v\in V,$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-where <!-- MATH
- $a(\cdot,\cdot)$
- -->
-<IMG
- WIDTH="41" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img3.gif"
- ALT="$ a(\cdot,\cdot)$"> is the bilinear form associated with the partial
-differential equations, and <IMG
- WIDTH="17" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img4.gif"
- ALT="$ V$"> is the space of test functions. For
-simplicity, we have here assumed that the problem is linear and that then
-<!-- MATH
- $a(\cdot,\cdot)$
- -->
-<IMG
- WIDTH="41" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img3.gif"
- ALT="$ 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.
-
-<P>
-In finite elements, we define an approximation of the solution <IMG
- WIDTH="13" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
- SRC="img5.gif"
- ALT="$ u$"> by choosing
-a finite dimensional subspace <IMG
- WIDTH="22" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img6.gif"
- ALT="$ V_h$"> spanned by the basis functions
-<!-- MATH
- $\{\varphi_i\}$
- -->
-<IMG
- WIDTH="36" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img7.gif"
- ALT="$ \{\varphi_i\}$">, and searching <!-- MATH
- $u_h\in V_h$
- -->
-<IMG
- WIDTH="58" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img8.gif"
- ALT="$ u_h\in V_h$"> by testing the weak form by the
-test functions from <IMG
- WIDTH="22" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img6.gif"
- ALT="$ V_h$">. The problem then reads: <I>find <!-- MATH
- $u_h\in V_h$
- -->
-<IMG
- WIDTH="58" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img8.gif"
- ALT="$ u_h\in V_h$">
-such that</I>
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="238" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img9.gif"
- ALT="$\displaystyle a(u_h, v_h) = (f,v_h)_\Omega \qquad \forall v_h\in V_h.$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-
-<P>
-Now, <!-- MATH
- $\{\varphi_i\}$
- -->
-<IMG
- WIDTH="36" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img7.gif"
- ALT="$ \{\varphi_i\}$"> is a basis of <IMG
- WIDTH="22" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img6.gif"
- ALT="$ V_h$">. We denote the dimension of <IMG
- WIDTH="22" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img6.gif"
- ALT="$ V_h$"> by
-<IMG
- WIDTH="19" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img10.gif"
- ALT="$ N$">, and will henceforth let all sums be over the range <!-- MATH
- $0\ldots N-1$
- -->
-<IMG
- WIDTH="78" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img11.gif"
- ALT="$ 0\ldots N-1$">, to keep
-with the standard notation of the C/C++ programming languages. With this, we
-can expand the solution <!-- MATH
- $u_h=\sum_{j=0}^{N-1} U_j \varphi_j$
- -->
-<IMG
- WIDTH="125" HEIGHT="39" ALIGN="MIDDLE" BORDER="0"
- SRC="img12.gif"
- ALT="$ u_h=\sum_{j=0}^{N-1} U_j \varphi_j$">, and by
-bilinearity of the form <!-- MATH
- $a(\cdot,\cdot)$
- -->
-<IMG
- WIDTH="41" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img3.gif"
- ALT="$ a(\cdot,\cdot)$">, the problem above is equivalent to
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="323" HEIGHT="65" ALIGN="MIDDLE" BORDER="0"
- SRC="img13.gif"
- ALT="$\displaystyle \sum_{j=0}^{N-1} U_j a(\varphi_j,\varphi_i) = (f, \varphi_i) \qquad \forall i=0\ldots N-1.$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
-<A NAME="eq:lin-1">(1)</A></TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-Denoting
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="268" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img14.gif"
- ALT="$\displaystyle A_{ij} = a(\varphi_j,\varphi_i), \qquad \qquad F_j = (f, \varphi_j),$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-the equations determining the expansion coefficients <IMG
- WIDTH="20" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img15.gif"
- ALT="$ U_i$"> are therefore:
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="65" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img16.gif"
- ALT="$\displaystyle A U = F.$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
-<A NAME="eq:lin-2">(2)</A></TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-
-<P>
-Note that we have taken a reverted order of indices in the definition of <IMG
- WIDTH="16" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img17.gif"
- ALT="$ A$">,
-since we want the linear system (<A HREF="node2.html#eq:lin-2">2</A>) with the solution to the
-right of the matrix, to keep with standard notation, instead of to the left as
-in (<A HREF="node2.html#eq:lin-1">1</A>). For symmetric problems, there is no difference, but for
-non-symmetric ones this is a common source for problems and a rather common
-trap.
-
-<P>
-For partial differential equations, the bilinear form used in (<A HREF="node2.html#eq:lin-1">1</A>)
-involves an integral over the domain <IMG
- WIDTH="16" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img18.gif"
- ALT="$ \Omega$"> on which the problem is
-posed. For example, for the Laplace equation we have
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="359" HEIGHT="51" ALIGN="MIDDLE" BORDER="0"
- SRC="img19.gif"
- ALT="$\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.$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-For practical purposes, we split this equation into integrals over the
-individual cells <IMG
- WIDTH="19" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img20.gif"
- ALT="$ K$"> of the triangulation <!-- MATH
- $\mathbb{T}$
- -->
-<IMG
- WIDTH="15" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img21.gif"
- ALT="$ \mathbb{T}$"> we use for the
-discretization. In <TT>deal.II</TT>, these cells are always lines,
-quadrilaterals, or hexahedra. With this, we have that
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="429" HEIGHT="50" ALIGN="MIDDLE" BORDER="0"
- SRC="img22.gif"
- ALT="$\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,$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-where the bilinear form <!-- MATH
- $a_K(\cdot,\cdot)$
- -->
-<IMG
- WIDTH="53" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img23.gif"
- ALT="$ a_K(\cdot,\cdot)$"> only involves an integral over the
-cell <IMG
- WIDTH="19" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img20.gif"
- ALT="$ K$">. The important point is that we do so since for the localized basis
-functions used in finite elements, <IMG
- WIDTH="28" HEIGHT="18" ALIGN="BOTTOM" BORDER="0"
- SRC="img24.gif"
- ALT="$ A^K$"> is a matrix with almost only zeros.
-The only elements which are not zero are those corresponding to indices <IMG
- WIDTH="24" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img25.gif"
- ALT="$ i,j$">
-indicating those shape functions that have support also on the element <IMG
- WIDTH="19" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img20.gif"
- ALT="$ 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 <IMG
- WIDTH="19" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img20.gif"
- ALT="$ K$"> are nonzero on <IMG
- WIDTH="19" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img20.gif"
- ALT="$ K$">, and thus only the entries in <IMG
- WIDTH="28" HEIGHT="18" ALIGN="BOTTOM" BORDER="0"
- SRC="img24.gif"
- ALT="$ A^K$"> are nonzero
-where the four rows corresponding to these indices and the respective four
-columns intersect.
-
-<P>
-In general, assume that there are <IMG
- WIDTH="29" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img26.gif"
- ALT="$ N_K$"> shape functions with support on cell
-<IMG
- WIDTH="19" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img20.gif"
- ALT="$ K$">, and let the set of their indices be denoted by <IMG
- WIDTH="23" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img27.gif"
- ALT="$ I_K$">. Then we can define
-a matrix <IMG
- WIDTH="28" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
- SRC="img28.gif"
- ALT="$ \hat A^K$"> of (small dimension) <!-- MATH
- $N_K\times N_K$
- -->
-<IMG
- WIDTH="74" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img29.gif"
- ALT="$ N_K\times N_K$"> holding these nonzero
-entries, and we can obtain back the original contribution <IMG
- WIDTH="28" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img30.gif"
- ALT="$ A_K$"> to <IMG
- WIDTH="16" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img17.gif"
- ALT="$ A$"> by the
-transformation
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="481" HEIGHT="57" ALIGN="MIDDLE" BORDER="0"
- SRC="img31.gif"
- ALT="$\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.$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-Here, <IMG
- WIDTH="55" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img32.gif"
- ALT="$ local(i)$"> gives the number of the global degree of freedom <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$"> on the
-cell <IMG
- WIDTH="19" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img20.gif"
- ALT="$ K$">, i.e. the position of <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$"> in the index set <IMG
- WIDTH="23" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img27.gif"
- ALT="$ I_K$">. One could call
-<IMG
- WIDTH="28" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
- SRC="img28.gif"
- ALT="$ \hat A^K$"> the <TT>reduced</TT> form of <IMG
- WIDTH="28" HEIGHT="18" ALIGN="BOTTOM" BORDER="0"
- SRC="img24.gif"
- ALT="$ A^K$">, since the many zero rows and
-column have been stripped.
-
-<P>
-In general, when assembling the global matrix, the reverse way is used: when
-adding up <IMG
- WIDTH="28" HEIGHT="18" ALIGN="BOTTOM" BORDER="0"
- SRC="img24.gif"
- ALT="$ A^K$"> to <IMG
- WIDTH="16" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img17.gif"
- ALT="$ A$">, we do so only with <IMG
- WIDTH="28" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
- SRC="img28.gif"
- ALT="$ \hat A^K$"> by
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="361" HEIGHT="37" ALIGN="MIDDLE" BORDER="0"
- SRC="img34.gif"
- ALT="$\displaystyle A_{global(i),global(j)} +\!\!= \hat A^K_{ij} \qquad \qquad 0\le i,j\le N_K-1.$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-Thus, indices only run over the (small) range <!-- MATH
- $0\ldots N_K-1$
- -->
-<IMG
- WIDTH="88" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img35.gif"
- ALT="$ 0\ldots N_K-1$"> instead of
-<!-- MATH
- $0\ldots N-1$
- -->
-<IMG
- WIDTH="78" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img11.gif"
- ALT="$ 0\ldots N-1$">. Here, <IMG
- WIDTH="63" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img36.gif"
- ALT="$ global(i)$"> denotes the global number of the degree of
-freedom with number <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$"> on this cell <IMG
- WIDTH="19" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img20.gif"
- ALT="$ K$">, i.e. <!-- MATH
- $global(i)=I_K[i]$
- -->
-<IMG
- WIDTH="118" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img37.gif"
- ALT="$ global(i)=I_K[i]$">, where the
-bracket operator returns the <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$">th element of the set <IMG
- WIDTH="23" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img27.gif"
- ALT="$ I_K$">.
-
-<P>
-The main part of assembling finite element matrices is therefore to assemble
-the local matrix <IMG
- WIDTH="28" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
- SRC="img28.gif"
- ALT="$ \hat A^K$">. Before we go on with discussing how this is done
-in <TT>deal.II</TT>, 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
-<IMG
- WIDTH="24" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img38.gif"
- ALT="$ N_q$"> points <IMG
- WIDTH="20" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img39.gif"
- ALT="$ x_q$"> defined on cell in real space (as opposed to the unit cell)
-and weights <IMG
- WIDTH="23" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img40.gif"
- ALT="$ w_q$">. Then, for example for the Laplace equation, we approximate
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="379" HEIGHT="69" ALIGN="MIDDLE" BORDER="0"
- SRC="img41.gif"
- ALT="$\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<IMG
- WIDTH="57" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img42.gif"
- ALT="$\displaystyle \ J(\hat x_q)\vert.$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
-(3)</TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-For other problems, the integrand is different, but the principle remains the
-same. <!-- MATH
- $\text{det}\ J(\hat x_q)$
- -->
-det<IMG
- WIDTH="48" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img43.gif"
- ALT="$ \ 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 <IMG
- WIDTH="20" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img44.gif"
- ALT="$ \hat x_q$"> is the point on the unit cell
-corresponding to the quadrature point <IMG
- WIDTH="20" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img39.gif"
- ALT="$ x_q$"> in real space.
-
-<P>
-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
-<TT>deal.II</TT> usually provides. One can see this as a kind of <I>view</I>
-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.
-
-<P>
-In <TT>deal.II</TT> the <TT>FEValues</TT> 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 <IMG
- WIDTH="23" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img40.gif"
- ALT="$ 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 <TT>FEValues</TT> objects.
-
-<P>
-In the following, we provide a list of connections between the symbols introduced
-above, and the respective functions and variable names used in typical
-<TT>deal.II</TT> 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 <TT>deal.II</TT>, you will recognize all these
-names. If you haven't, this would be a good time to look at the first
-three of them.
-
-<P>
-<DIV ALIGN="CENTER">
-<TABLE CELLPADDING=3 BORDER="1">
-<TR><TD ALIGN="LEFT"><IMG
- WIDTH="16" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img17.gif"
- ALT="$ A$"></TD>
-<TD ALIGN="LEFT"><TT>system_matrix</TT></TD>
-</TR>
-<TR><TD ALIGN="LEFT"><IMG
- WIDTH="28" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
- SRC="img28.gif"
- ALT="$ \hat A^K$"></TD>
-<TD ALIGN="LEFT"><TT>cell_matrix</TT></TD>
-</TR>
-<TR><TD ALIGN="LEFT"><IMG
- WIDTH="19" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img20.gif"
- ALT="$ K$"></TD>
-<TD ALIGN="LEFT"><TT>cell</TT></TD>
-</TR>
-<TR><TD ALIGN="LEFT"><IMG
- WIDTH="19" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img10.gif"
- ALT="$ N$"></TD>
-<TD ALIGN="LEFT"><TT>dof_handler.n_dofs()</TT></TD>
-</TR>
-<TR><TD ALIGN="LEFT"><IMG
- WIDTH="29" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img26.gif"
- ALT="$ N_K$"></TD>
-<TD ALIGN="LEFT"><TT>fe.dofs_per_cell</TT></TD>
-</TR>
-<TR><TD ALIGN="LEFT"><IMG
- WIDTH="23" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img27.gif"
- ALT="$ I_K$"></TD>
-<TD ALIGN="LEFT"><TT>local_dof_indices</TT></TD>
-</TR>
-<TR><TD ALIGN="LEFT"><IMG
- WIDTH="24" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img38.gif"
- ALT="$ N_q$"></TD>
-<TD ALIGN="LEFT"><TT>quadrature_formula.n_quadrature_points</TT></TD>
-</TR>
-<TR><TD ALIGN="LEFT"><!-- MATH
- $\varphi_i(x_q)$
- -->
-<IMG
- WIDTH="48" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img45.gif"
- ALT="$ \varphi_i(x_q)$"></TD>
-<TD ALIGN="LEFT"><TT>fe_values.shape_value(i,q)</TT></TD>
-</TR>
-<TR><TD ALIGN="LEFT"><!-- MATH
- $\nabla\varphi_i(x_q)$
- -->
-<IMG
- WIDTH="62" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img46.gif"
- ALT="$ \nabla\varphi_i(x_q)$"></TD>
-<TD ALIGN="LEFT"><TT>fe_values.shape_grad(i,q)</TT></TD>
-</TR>
-<TR><TD ALIGN="LEFT"><IMG
- WIDTH="20" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img39.gif"
- ALT="$ x_q$"></TD>
-<TD ALIGN="LEFT"><TT>fe_values.quadrature_point(q)</TT></TD>
-</TR>
-<TR><TD ALIGN="LEFT"><!-- MATH
- $|\text{det} J(\hat x_q)| w_q$
- -->
-<IMG
- WIDTH="8" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img47.gif"
- ALT="$ \vert$">det<IMG
- WIDTH="66" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img48.gif"
- ALT="$ J(\hat x_q)\vert w_q$"></TD>
-<TD ALIGN="LEFT"><TT>fe_values.JxW(q)</TT></TD>
-</TR>
-</TABLE>
-</DIV>
-
-<P>
-With this vocabulary, the typical matrix assembly loop in <TT>deal.II</TT> has
-the following form: first declare a quadrature object and use it for the
-initialization of a <TT>FEValues</TT> object as discussed above:
-<PRE>
- QGauss2<2> quadrature_formula;
- FEValues<2> fe_values (fe, quadrature_formula,
- UpdateFlags(update_values |
- update_gradients |
- update_JxW_values));
-</PRE>
-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 <TT>update_values</TT> 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 <TT>FEValues</TT> class can be used, which
-takes a mapping object as first argument, before the other arguments listed
-above.
-
-<P>
-Next we define abbreviations for the values of <IMG
- WIDTH="29" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img26.gif"
- ALT="$ N_K$"> and <IMG
- WIDTH="24" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img38.gif"
- ALT="$ N_q$">:
-<PRE>
- const unsigned int
- dofs_per_cell = fe.dofs_per_cell,
- n_q_points = quadrature_formula.n_quadrature_points;
-</PRE>
-Then have an object to store the matrix <IMG
- WIDTH="28" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
- SRC="img28.gif"
- ALT="$ \hat A^K$">, which is of size
-<!-- MATH
- $N_K\times N_K$
- -->
-<IMG
- WIDTH="74" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img29.gif"
- ALT="$ N_K\times N_K$">:
-<PRE>
- FullMatrix<double> cell_matrix (dofs_per_cell, dofs_per_cell);
-</PRE>
-And an object representing the set of global indices of degrees of freedom,
-previously denoted by <IMG
- WIDTH="23" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img27.gif"
- ALT="$ I_K$">, that have support on the present cell, i.e. those
-degrees of freedom local to the present cell:
-<PRE>
- std::vector<unsigned int> local_dof_indices (dofs_per_cell);
-</PRE>
-The next step is then to loop over all cells:
-<PRE>
- typename DoFHandler<dim>::active_cell_iterator
- cell = dof_handler.begin_active(),
- endc = dof_handler.end();
- for (; cell!=endc; ++cell)
- {
-</PRE>
-On each cell, first tell the <TT>FEValues</TT> object to compute the values of
-the various fields for this particular cell, and do not forget to reset the
-local matrix <IMG
- WIDTH="28" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
- SRC="img28.gif"
- ALT="$ \hat A^K$"> to zero before adding it up:
-<PRE>
- fe_values.reinit (cell);
- cell_matrix.clear ();
-</PRE>
-Now comes the main part, assembling the local matrix <IMG
- WIDTH="28" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
- SRC="img28.gif"
- ALT="$ \hat A^K$">. It consists
-of a loop over all indices <!-- MATH
- $0\le i,j \le N_K$
- -->
-<IMG
- WIDTH="99" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img49.gif"
- ALT="$ 0\le i,j \le N_K$"> and all quadrature points <!-- MATH
- $0\le
-q\le N_q$
- -->
-<IMG
- WIDTH="82" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img50.gif"
- ALT="$ 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:
-<PRE>
- 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) += ...;
-</PRE>
-After we have <IMG
- WIDTH="28" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
- SRC="img28.gif"
- ALT="$ \hat A^K$">, we still have to sum it into the global matrix
-<IMG
- WIDTH="16" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img17.gif"
- ALT="$ A$">. This is done by first getting the set <IMG
- WIDTH="23" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img27.gif"
- ALT="$ I_K$"> of the global indices of the
-shape functions that were active on this cell, and then distributing <IMG
- WIDTH="28" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
- SRC="img28.gif"
- ALT="$ \hat A^K$">:
-<PRE>
- 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));
- };
-</PRE>
-When this is done, we go on to the next cell.
-
-<P>
-Within this framework, the only open point is assembling <IMG
- WIDTH="28" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
- SRC="img28.gif"
- ALT="$ \hat A^K$"> on one
-quadrature point. This will be subject of the rest of this report.
-
-<P>
-<HR>
-<!--Navigation Panel-->
-<A NAME="tex2html38"
- HREF="node3.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html36"
- HREF="assemble.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html30"
- HREF="node1.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html39"
- HREF="node3.html">Assembling scalar problems</A>
-<B> Up:</B> <A NAME="tex2html37"
- HREF="assemble.html">assemble</A>
-<B> Previous:</B> <A NAME="tex2html31"
- HREF="node1.html">Introduction</A>
-<!--End of Navigation Panel-->
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>Assembling scalar problems</TITLE>
-<META NAME="description" CONTENT="Assembling scalar problems">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="next" HREF="node4.html">
-<LINK REL="previous" HREF="node2.html">
-<LINK REL="up" HREF="assemble.html">
-<LINK REL="next" HREF="node4.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html48"
- HREF="node4.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html46"
- HREF="assemble.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html40"
- HREF="node2.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html49"
- HREF="node4.html">Vector-valued problems</A>
-<B> Up:</B> <A NAME="tex2html47"
- HREF="assemble.html">assemble</A>
-<B> Previous:</B> <A NAME="tex2html41"
- HREF="node2.html">Linear systems for finite</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H1><A NAME="SECTION00030000000000000000">
-Assembling scalar problems</A>
-</H1>
-
-<P>
-For scalar problems, assembling <IMG
- WIDTH="28" HEIGHT="19" ALIGN="BOTTOM" BORDER="0"
- SRC="img28.gif"
- ALT="$ \hat A^K$"> is relatively simple. With the
-terms introduced above, and for the Laplace equation, this looks as follows:
-<PRE>
- local_matrix(i,j) += (fe_values.shape_grad(i,q_point) *
- fe_values.shape_grad(j,q_point) *
- fe_values.JxW (q_point));
-</PRE>
-This term is placed in the innermost loop, i.e. is performed for all indices
-<IMG
- WIDTH="24" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img25.gif"
- ALT="$ i,j$">, and all quadrature points <TT>q_point</TT>.
-
-<P>
-For nonsymmetric problems, the order of terms has to be considered, as
-mentioned above. For example, for the advection equation
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="82" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img51.gif"
- ALT="$\displaystyle \beta \cdot \nabla u = f,$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-with which the bilinear form
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="152" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img52.gif"
- ALT="$\displaystyle a(u,v) = (\beta \cdot \nabla u, v)_\Omega$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-is associated, the local matrix is assembled as
-<PRE>
- local_matrix(i,j) += (fe_values.shape_values(i,q_point) *
- ( beta * fe_values.shape_grad(j,q_point) ) *
- fe_values.JxW (q_point));
-</PRE>
-Here, <TT>beta</TT> is an object of type <TT>Tensor<1,dim></TT>, which
-represents a tensor of rank 1 in <TT>dim</TT> space dimensions.
-
-<P>
-Assembling matrices for scalar problems is also shown from a practical
-perspective in many of the example programs of <TT>deal.II</TT>, 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.
-
-<P>
-<HR>
-<!--Navigation Panel-->
-<A NAME="tex2html48"
- HREF="node4.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html46"
- HREF="assemble.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html40"
- HREF="node2.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html49"
- HREF="node4.html">Vector-valued problems</A>
-<B> Up:</B> <A NAME="tex2html47"
- HREF="assemble.html">assemble</A>
-<B> Previous:</B> <A NAME="tex2html41"
- HREF="node2.html">Linear systems for finite</A>
-<!--End of Navigation Panel-->
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>Vector-valued problems</TITLE>
-<META NAME="description" CONTENT="Vector-valued problems">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="next" HREF="node7.html">
-<LINK REL="previous" HREF="node3.html">
-<LINK REL="up" HREF="assemble.html">
-<LINK REL="next" HREF="node5.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html58"
- HREF="node5.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html56"
- HREF="assemble.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html50"
- HREF="node3.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html59"
- HREF="node5.html">The elastic equations</A>
-<B> Up:</B> <A NAME="tex2html57"
- HREF="assemble.html">assemble</A>
-<B> Previous:</B> <A NAME="tex2html51"
- HREF="node3.html">Assembling scalar problems</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H1><A NAME="SECTION00040000000000000000">
-Vector-valued problems</A>
-</H1>
-
-<P>
-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.
-
-<P>
-<BR><HR>
-<!--Table of Child-Links-->
-<A NAME="CHILD_LINKS"><STRONG>Subsections</STRONG></A>
-
-<UL>
-<LI><A NAME="tex2html60"
- HREF="node5.html">The elastic equations</A>
-<LI><A NAME="tex2html61"
- HREF="node6.html">The Stokes equations</A>
-</UL>
-<!--End of Table of Child-Links-->
-<BR><HR>
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>The elastic equations</TITLE>
-<META NAME="description" CONTENT="The elastic equations">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="next" HREF="node6.html">
-<LINK REL="previous" HREF="node4.html">
-<LINK REL="up" HREF="node4.html">
-<LINK REL="next" HREF="node6.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html70"
- HREF="node6.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html68"
- HREF="node4.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html62"
- HREF="node4.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html71"
- HREF="node6.html">The Stokes equations</A>
-<B> Up:</B> <A NAME="tex2html69"
- HREF="node4.html">Vector-valued problems</A>
-<B> Previous:</B> <A NAME="tex2html63"
- HREF="node4.html">Vector-valued problems</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H2><A NAME="SECTION00041000000000000000"></A>
-<A NAME="sec:elastic"></A>
-<BR>
-The elastic equations
-</H2>
-
-<P>
-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:
-<!-- MATH
- \begin{displaymath}
--
- \nabla (\lambda+\mu) (\div\vec u)
- -
- (\nabla \cdot \mu \nabla) \vec u
- =
- \vec f.
-\end{displaymath}
- -->
-<P></P>
-<DIV ALIGN="CENTER">
-<IMG
- WIDTH="250" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img53.gif"
- ALT="$\displaystyle -
-\nabla (\lambda+\mu) (\div\vec u)
--
-(\nabla \cdot \mu \nabla) \vec u
-=
-\vec f.
-$">
-</DIV><P></P>
-These equations describe the three-dimensional deformation <IMG
- WIDTH="14" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
- SRC="img54.gif"
- ALT="$ \vec u$"> of an
-elastic body under a body force <IMG
- WIDTH="12" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img55.gif"
- ALT="$ \vec f$">. The respective bilinear form
-associated with this operator is then
-<!-- MATH
- \begin{displaymath}
-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,
-\end{displaymath}
- -->
-<P></P>
-<DIV ALIGN="CENTER">
-<IMG
- WIDTH="373" HEIGHT="49" ALIGN="MIDDLE" BORDER="0"
- SRC="img56.gif"
- ALT="$\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,
-$">
-</DIV><P></P>
-or as a sum over components:
-<!-- MATH
- \begin{displaymath}
-a(\vec u, \vec v) =
- \sum_{k,l}
- \left(
- (\lambda+\mu) \partial_l u_l, \partial_k v_k
- \right)_\Omega
- +
- \sum_{k,l}
- \left(
- \mu \partial_l u_k, \partial_l v_k
- \right)_\Omega.
-\end{displaymath}
- -->
-<P></P>
-<DIV ALIGN="CENTER">
-<IMG
- WIDTH="388" HEIGHT="53" ALIGN="MIDDLE" BORDER="0"
- SRC="img57.gif"
- ALT="$\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.
-$">
-</DIV><P></P>
-
-<P>
-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
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="123" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img58.gif"
- ALT="$\displaystyle A_{ij} = a(\varphi_j,\varphi_i)_\Omega,$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-where <!-- MATH
- $\varphi_i,\varphi_j$
- -->
-<IMG
- WIDTH="44" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img59.gif"
- ALT="$ \varphi_i,\varphi_j$"> are two vector-valued trial functions, and it
-would be nice if we could write the bilinear form <!-- MATH
- $a(\cdot,\cdot)$
- -->
-<IMG
- WIDTH="41" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img3.gif"
- ALT="$ a(\cdot,\cdot)$"> as a kind
-of scalar product <!-- MATH
- $(\varphi_i, Q \varphi_j)$
- -->
-<IMG
- WIDTH="69" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img60.gif"
- ALT="$ (\varphi_i, Q \varphi_j)$">, where <IMG
- WIDTH="17" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img61.gif"
- ALT="$ Q$"> is a differential
-operator. This is trivial if we take <IMG
- WIDTH="17" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img61.gif"
- ALT="$ Q$"> as the operator of the strong form,
-<!-- MATH
- $Q=-\nabla (\lambda+\mu) \div - (\nabla \cdot \mu \nabla)$
- -->
-<IMG
- WIDTH="211" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img62.gif"
- ALT="$ 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,
-<!-- MATH
- $\varphi \overleftarrow\nabla \cdot \overrightarrow\nabla \psi
-=(\nabla\varphi)\cdot(\nabla\psi)$
- -->
-<IMG
- WIDTH="174" HEIGHT="41" ALIGN="MIDDLE" BORDER="0"
- SRC="img63.gif"
- ALT="$ \varphi \overleftarrow\nabla \cdot \overrightarrow\nabla \psi
-=(\nabla\varphi)\cdot(\nabla\psi)$">. With this, a simple computation shows
-that
-<P></P>
-<DIV ALIGN="CENTER"><!-- MATH
- \begin{multline*}
-a(\vec u,\vec v)
- =
- (\lambda+\mu)
- \left(
- \begin{pmatrix}
- u_1 \\u_2
- \end{pmatrix}
- \mid
- \begin{pmatrix}
- \overleftarrow \partial _1 \overrightarrow \partial _1 &
- \overleftarrow \partial _1 \overrightarrow \partial _2 \\
- \overleftarrow \partial _2 \overrightarrow \partial _1 &
- \overleftarrow \partial _2 \overrightarrow \partial _2
- \end{pmatrix}
- \mid
- \begin{pmatrix}
- v_1 \\v_2
- \end{pmatrix}
- \right)_\Omega
- \\
- +
- \mu
- \left(
- \begin{pmatrix}
- u_1 \\u_2
- \end{pmatrix}
- \mid
- \left(
- \overleftarrow \partial _1 \overrightarrow \partial _1 +
- \overleftarrow \partial _2 \overrightarrow \partial _2
- \right)
- \begin{pmatrix}
- 1 & 0 \\
- 0 & 1
- \end{pmatrix}
- \mid
- \begin{pmatrix}
- v_1 \\v_2
- \end{pmatrix}
- \right)_\Omega.
-\end{multline*}
- -->
-<IMG
- WIDTH="540" HEIGHT="105" ALIGN="BOTTOM" BORDER="0"
- SRC="img64.gif"
- ALT="\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*}"></DIV>
-<BR CLEAR="ALL">
-<P><P></P>
-The sought operator <IMG
- WIDTH="17" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img61.gif"
- ALT="$ Q$"> is then
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="528" HEIGHT="63" ALIGN="MIDDLE" BORDER="0"
- SRC="img65.gif"
- ALT="$\displaystyle Q = (\lambda+\mu) \begin{pmatrix}\overleftarrow \partial _1 \over...
-...tial _1 + \overleftarrow \partial _2 \overrightarrow \partial _2 \end{pmatrix},$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-and <!-- MATH
- $a(\vec u,\vec v)=(\vec u | Q | \vec v)$
- -->
-<IMG
- WIDTH="127" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img66.gif"
- ALT="$ a(\vec u,\vec v)=(\vec u \vert Q \vert \vec v)$">. We demonstrate the fact that <IMG
- WIDTH="17" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img61.gif"
- ALT="$ 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.
-
-<P>
-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 <IMG
- WIDTH="17" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img61.gif"
- ALT="$ Q$"> as well as from the initial
-definition of <!-- MATH
- $a(\cdot,\cdot)$
- -->
-<IMG
- WIDTH="41" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img3.gif"
- ALT="$ a(\cdot,\cdot)$">.
-
-<P>
-<HR>
-<!--Navigation Panel-->
-<A NAME="tex2html70"
- HREF="node6.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html68"
- HREF="node4.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html62"
- HREF="node4.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html71"
- HREF="node6.html">The Stokes equations</A>
-<B> Up:</B> <A NAME="tex2html69"
- HREF="node4.html">Vector-valued problems</A>
-<B> Previous:</B> <A NAME="tex2html63"
- HREF="node4.html">Vector-valued problems</A>
-<!--End of Navigation Panel-->
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>The Stokes equations</TITLE>
-<META NAME="description" CONTENT="The Stokes equations">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="previous" HREF="node5.html">
-<LINK REL="up" HREF="node4.html">
-<LINK REL="next" HREF="node7.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html78"
- HREF="node7.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html76"
- HREF="node4.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html72"
- HREF="node5.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html79"
- HREF="node7.html">Assembling vector-valued problems: The</A>
-<B> Up:</B> <A NAME="tex2html77"
- HREF="node4.html">Vector-valued problems</A>
-<B> Previous:</B> <A NAME="tex2html73"
- HREF="node5.html">The elastic equations</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H2><A NAME="SECTION00042000000000000000"></A>
-<A NAME="sec:stokes"></A>
-<BR>
-The Stokes equations
-</H2>
-
-<P>
-For a nonsymmetric problem, we take the Stokes equations:
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="RIGHT"><IMG
- WIDTH="81" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img67.gif"
- ALT="$\displaystyle -\Delta \vec u + \nabla p$"></TD>
-<TD NOWRAP ALIGN="LEFT"><IMG
- WIDTH="33" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img68.gif"
- ALT="$\displaystyle = 0,$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="RIGHT">div <IMG
- WIDTH="14" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img69.gif"
- ALT="$\displaystyle \vec u$"></TD>
-<TD NOWRAP ALIGN="LEFT"><IMG
- WIDTH="33" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img70.gif"
- ALT="$\displaystyle = 0.$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-We denote by <!-- MATH
- $\vec w=\{\vec u,p\}$
- -->
-<IMG
- WIDTH="80" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img71.gif"
- ALT="$ \vec w=\{\vec u,p\}$"> the entire solution vector. In the weak
-form, the above equations read
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="468" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img72.gif"
- ALT="$\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).$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-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 <IMG
- WIDTH="24" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img73.gif"
- ALT="$ -1$">, but we don't want to
-do that for now for illustrational purposes.
-
-<P>
-Again, we introduce the operator <IMG
- WIDTH="17" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img61.gif"
- ALT="$ Q$"> for this problem, which after some
-computations turns out to be
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="406" HEIGHT="83" ALIGN="MIDDLE" BORDER="0"
- SRC="img74.gif"
- ALT="$\displaystyle Q = \begin{pmatrix}\nu(\overleftarrow \partial _1 \overrightarrow...
-...\\ \overrightarrow \partial _1 & \overrightarrow \partial _2 & 0 \end{pmatrix}.$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-Again, it is clear from this form that we could have made the operator
-symmetric by multiplying the last row by <IMG
- WIDTH="24" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img73.gif"
- ALT="$ -1$">. Note when checking the symmetry
-of <IMG
- WIDTH="17" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img61.gif"
- ALT="$ 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
-<!-- MATH
- $\overleftarrow \partial _1 \overrightarrow \partial _1 \rightarrow \overrightarrow \partial _1 \overleftarrow \partial _1
-\rightarrow \overleftarrow \partial _1 \overrightarrow \partial _1$
- -->
-<IMG
- WIDTH="192" HEIGHT="41" ALIGN="MIDDLE" BORDER="0"
- SRC="img75.gif"
- ALT="$ \overleftarrow \partial _1 \overrightarrow \partial _1 \rightarrow \overrighta...
-... \partial _1
-\rightarrow \overleftarrow \partial _1 \overrightarrow \partial _1$">.
-
-<P>
-<HR>
-<!--Navigation Panel-->
-<A NAME="tex2html78"
- HREF="node7.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html76"
- HREF="node4.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html72"
- HREF="node5.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html79"
- HREF="node7.html">Assembling vector-valued problems: The</A>
-<B> Up:</B> <A NAME="tex2html77"
- HREF="node4.html">Vector-valued problems</A>
-<B> Previous:</B> <A NAME="tex2html73"
- HREF="node5.html">The elastic equations</A>
-<!--End of Navigation Panel-->
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>Assembling vector-valued problems: The simple case</TITLE>
-<META NAME="description" CONTENT="Assembling vector-valued problems: The simple case">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="next" HREF="node10.html">
-<LINK REL="previous" HREF="node4.html">
-<LINK REL="up" HREF="assemble.html">
-<LINK REL="next" HREF="node8.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html88"
- HREF="node8.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html86"
- HREF="assemble.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html80"
- HREF="node6.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html89"
- HREF="node8.html">The elastic equations</A>
-<B> Up:</B> <A NAME="tex2html87"
- HREF="assemble.html">assemble</A>
-<B> Previous:</B> <A NAME="tex2html81"
- HREF="node6.html">The Stokes equations</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H1><A NAME="SECTION00050000000000000000">
-Assembling vector-valued problems: The simple case</A>
-</H1>
-
-<P>
-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.
-
-<P>
-In this case, each shape function <IMG
- WIDTH="21" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img76.gif"
- ALT="$ \Phi_i$"> has the representation
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="248" HEIGHT="39" ALIGN="MIDDLE" BORDER="0"
- SRC="img77.gif"
- ALT="$\displaystyle \Phi_i(\vec x) = \left( 0, \dots, 0, \varphi_i(\vec x), 0, \ldots, 0\right)^T,$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-where <IMG
- WIDTH="21" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img76.gif"
- ALT="$ \Phi_i$"> is the vector-valued shape function, and <IMG
- WIDTH="20" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img78.gif"
- ALT="$ \varphi_i$"> its
-only non-zero component. Let us denote by <IMG
- WIDTH="29" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img79.gif"
- ALT="$ c(i)$"> the index of this non-zero
-component, then <IMG
- WIDTH="21" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img76.gif"
- ALT="$ \Phi_i$"> can also be written as
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="159" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img80.gif"
- ALT="$\displaystyle \left(\Phi_i(\vec x)\right)_l = \varphi_i(\vec x) \delta_{c(i),l},$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-with the Kronecker delta function <!-- MATH
- $\delta_{jk}$
- -->
-<IMG
- WIDTH="25" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img81.gif"
- ALT="$ \delta_{jk}$">.
-
-<P>
-With this simple form, the cell matrix on cell <IMG
- WIDTH="19" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img20.gif"
- ALT="$ K$"> has a simple form:
-<P></P>
-<DIV ALIGN="CENTER"><TABLE CELLPADDING="0" WIDTH="100%" ALIGN="CENTER">
-<TR VALIGN="MIDDLE">
-<TD NOWRAP ALIGN="CENTER"><IMG
- WIDTH="418" HEIGHT="36" ALIGN="MIDDLE" BORDER="0"
- SRC="img82.gif"
- ALT="$\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.$"></TD>
-<TD NOWRAP WIDTH="10" ALIGN="RIGHT">
- </TD></TR>
-</TABLE></DIV>
-<BR CLEAR="ALL"><P></P>
-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 <IMG
- WIDTH="17" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img61.gif"
- ALT="$ Q$"> to assemble each entry of the cell
-matrix with the help of the values of the functions <IMG
- WIDTH="20" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img78.gif"
- ALT="$ \varphi_i$"> at the
-quadrature points. Here, it comes handy that we have written the operator as a
-matrix operator <IMG
- WIDTH="17" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img61.gif"
- ALT="$ Q$">, since this makes it very clear how shape functions <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$">
-and <IMG
- WIDTH="12" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img83.gif"
- ALT="$ j$"> couple: if <!-- MATH
- $Q_{c(i),c(j)}$
- -->
-<IMG
- WIDTH="63" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img84.gif"
- ALT="$ 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.
-
-<P>
-In <TT>deal.II</TT>, 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:
-
-<UL>
-<LI><I>Determining the non-zero component:</I> Given the shape function
- with number <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$"> (i.e. its index local to the degrees of freedom on the
- present cell), its only non-zero component is obtained by the function call
-<PRE>
- const unsigned int nonzero_component_i
- = fe.system_to_component_index(i).first;
-</PRE>
- The <TT>FiniteElement::system_to_component_index</TT> returns a pair of
- numbers for each index <!-- MATH
- $0\le i < N_K$
- -->
-<IMG
- WIDTH="85" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img85.gif"
- ALT="$ 0\le i < N_K$">, the first of which denotes the only
- non-zero component of the shape function <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$">. Since for the case described
- in this section, the individual components of the vector-valued finite
- element are independent, we consider each component as a set of scalar shape
- functions; the second number of the pair returned by the function then
- denotes the index of the shape function <IMG
- WIDTH="20" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img78.gif"
- ALT="$ \varphi_i$"> within the shape
- functions corresponding to this component.
-
-<P>
-If, for example, our finite element in use is a <!-- MATH
- $Q^2/Q^2/Q^1$
- -->
-<IMG
- WIDTH="79" HEIGHT="33" ALIGN="MIDDLE" BORDER="0"
- SRC="img86.gif"
- ALT="$ Q^2/Q^2/Q^1$"> combination
- (for example for 2d flow computations: bi-quadratic ansatz functions for the
- velocities, bi-linear for the pressure), then we have a total of 22 shape
- functions (9+9+4). For each <!-- MATH
- $0\le i < 22$
- -->
-<IMG
- WIDTH="76" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img87.gif"
- ALT="$ 0\le i < 22$">, the first part of the pair
- returned by the function described above, <IMG
- WIDTH="29" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img79.gif"
- ALT="$ c(i)$">, may then either be 0, 1,
- or 2, denoting the three possible components of the finite element. If
- <IMG
- WIDTH="29" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img79.gif"
- ALT="$ c(i)$"> is either 0 or 1, then the component to which the shape function <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$">
- belongs is a bi-quadratic one, and the second index is between 0 and <IMG
- WIDTH="12" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
- SRC="img88.gif"
- ALT="$ 8$">
- (inclusive) as the <IMG
- WIDTH="24" HEIGHT="33" ALIGN="MIDDLE" BORDER="0"
- SRC="img89.gif"
- ALT="$ Q^2$"> element has 9 shape functions. If <IMG
- WIDTH="70" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img90.gif"
- ALT="$ c(i)==2$">, then
- the second part is between 0 and 3 (inclusive).
-
-<P>
-</LI>
-<LI><I>Getting the value of <!-- MATH
- $\varphi_i(\vec x_q)$
- -->
-<IMG
- WIDTH="49" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img91.gif"
- ALT="$ \varphi_i(\vec x_q)$">:</I> Since only one
- component of <IMG
- WIDTH="21" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img76.gif"
- ALT="$ \Phi_i$"> is non-zero, we can use the same function as before,
- i.e. <TT>FEValues::shape_value(i,q)</TT>, which in the scalar case returned
- the value of shape function <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$"> at quadrature point <IMG
- WIDTH="12" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
- SRC="img92.gif"
- ALT="$ q$">. Likewise, the
- <TT>FEValues::shape_grad(i,q)</TT> function returns the gradient of this
- particular component.
-
-<P>
-In other words, whether the finite element is scalar or not, the two
- indicated functions return value and gradient of the only non-zero component
- of a shape function. If the finite element is scalar, then it is of course
- clear which component this is (since there <IMG
- WIDTH="70" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img93.gif"
- ALT="$ c(i)==0$"> for all valid indices
- <IMG
- WIDTH="10" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
- SRC="img33.gif"
- ALT="$ i$">), in the vector-valued case, it is component <IMG
- WIDTH="29" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img79.gif"
- ALT="$ c(i)$">.
-</LI>
-</UL>
-
-<P>
-<BR><HR>
-<!--Table of Child-Links-->
-<A NAME="CHILD_LINKS"><STRONG>Subsections</STRONG></A>
-
-<UL>
-<LI><A NAME="tex2html90"
- HREF="node8.html">The elastic equations</A>
-<LI><A NAME="tex2html91"
- HREF="node9.html">The Stokes equations</A>
-</UL>
-<!--End of Table of Child-Links-->
-<HR>
-<!--Navigation Panel-->
-<A NAME="tex2html88"
- HREF="node8.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html86"
- HREF="assemble.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html80"
- HREF="node6.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html89"
- HREF="node8.html">The elastic equations</A>
-<B> Up:</B> <A NAME="tex2html87"
- HREF="assemble.html">assemble</A>
-<B> Previous:</B> <A NAME="tex2html81"
- HREF="node6.html">The Stokes equations</A>
-<!--End of Navigation Panel-->
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>The elastic equations</TITLE>
-<META NAME="description" CONTENT="The elastic equations">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="next" HREF="node9.html">
-<LINK REL="previous" HREF="node7.html">
-<LINK REL="up" HREF="node7.html">
-<LINK REL="next" HREF="node9.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html100"
- HREF="node9.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html98"
- HREF="node7.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html92"
- HREF="node7.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html101"
- HREF="node9.html">The Stokes equations</A>
-<B> Up:</B> <A NAME="tex2html99"
- HREF="node7.html">Assembling vector-valued problems: The</A>
-<B> Previous:</B> <A NAME="tex2html93"
- HREF="node7.html">Assembling vector-valued problems: The</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H2><A NAME="SECTION00051000000000000000"></A>
-<A NAME="sec:elastic-simple"></A>
-<BR>
-The elastic equations
-</H2>
-
-<P>
-With this, and the definition of the ``bi-directional'' operator <IMG
- WIDTH="17" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img61.gif"
- ALT="$ Q$"> in
-Section <A HREF="node5.html#sec:elastic">4.1</A>, the local matrix assembly function for the elastic
-equations would then read as follows:
-<PRE>
- 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));
- };
-</PRE>
-Note that this code works in any space dimension, not only for
-<TT>dim==2</TT>. Optimization of this is possible by hoisting the computation
-of <TT>comp_i</TT> and <TT>comp_j</TT>, denoting <IMG
- WIDTH="29" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img79.gif"
- ALT="$ c(i)$"> and <IMG
- WIDTH="31" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
- SRC="img94.gif"
- ALT="$ 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:
-<PRE>
- const double
- lambda_value = lambda.value(fe_values.quadrature_point(q)),
- mu_value = mu.value(fe_values.quadrature_point(q));
-</PRE>
-assuming that <TT>lambda,mu</TT> are variables of classes that are derived
-from the <TT>Function<dim></TT> class.
-
-<P>
-<BR><HR>
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-
-<!--Converted with LaTeX2HTML 2002-1 (1.68)
-original version by: Nikos Drakos, CBLU, University of Leeds
-* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
-* with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
-<HTML>
-<HEAD>
-<TITLE>The Stokes equations</TITLE>
-<META NAME="description" CONTENT="The Stokes equations">
-<META NAME="keywords" CONTENT="assemble">
-<META NAME="resource-type" CONTENT="document">
-<META NAME="distribution" CONTENT="global">
-
-<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
-<META NAME="Generator" CONTENT="LaTeX2HTML v2002-1">
-<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
-
-<LINK REL="STYLESHEET" HREF="assemble.css">
-
-<LINK REL="previous" HREF="node8.html">
-<LINK REL="up" HREF="node7.html">
-<LINK REL="next" HREF="node10.html">
-</HEAD>
-
-<BODY >
-<!--Navigation Panel-->
-<A NAME="tex2html108"
- HREF="node10.html">
-<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next"
- SRC="../deal.II-paper/next_motif.gif"></A>
-<A NAME="tex2html106"
- HREF="node7.html">
-<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
- SRC="../deal.II-paper/up_motif.gif"></A>
-<A NAME="tex2html102"
- HREF="node8.html">
-<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
- SRC="../deal.II-paper/previous_motif.gif"></A>
-<BR>
-<B> Next:</B> <A NAME="tex2html109"
- HREF="node10.html">Assembling vector-valued problems: The</A>
-<B> Up:</B> <A NAME="tex2html107"
- HREF="node7.html">Assembling vector-valued problems: The</A>
-<B> Previous:</B> <A NAME="tex2html103"
- HREF="node8.html">The elastic equations</A>
-<BR>
-<BR>
-<!--End of Navigation Panel-->
-
-<H2><A NAME="SECTION00052000000000000000"></A>
-<A NAME="sec:stokes-simple"></A>
-<BR>
-The Stokes equations
-</H2>
-
-<P>
-For the Stokes equation, things are slightly more complicated since the three
-components denote different quantities, and the operator <IMG
- WIDTH="17" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
- SRC="img61.gif"
- ALT="$ 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 <TT>dim</TT> velocity variables and one scalar pressure:
-<PRE>
- 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));
- };
-</PRE>
-Again, optimization is possible by observing that only one of the outer
-<TT>if</TT>s in the body can be true, for example using <TT>else</TT> clauses,
-or <TT>break</TT> statements.
-
-<P>
-<BR><HR>
-<ADDRESS>
-Wolfgang Bangerth
-2002-06-14
-</ADDRESS>
-</BODY>
-</HTML>
projects / dealii-svn.git / commitdiff
