From: guido Date: Mon, 15 Nov 2004 14:04:35 +0000 (+0000) Subject: remove html formatted article assemble X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=59b1c555cf73cca74e468fd79d04a867184bcbce;p=dealii-svn.git remove html formatted article assemble git-svn-id: https://svn.dealii.org/trunk@9758 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/Makefile.in b/deal.II/doc/Makefile.in index fafc8a5806..1b77c24f36 100644 --- a/deal.II/doc/Makefile.in +++ b/deal.II/doc/Makefile.in @@ -31,7 +31,10 @@ glossary: 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 diff --git a/deal.II/doc/news/2002/c-3-4.html b/deal.II/doc/news/2002/c-3-4.html deleted file mode 100644 index e57bbdd244..0000000000 --- a/deal.II/doc/news/2002/c-3-4.html +++ /dev/null @@ -1,1392 +0,0 @@ - - - - - - The deal.II news page - - - - - - -

Changes after Version 3.4

- -

-This is the list of changes made after the release of -deal.II version 3.4. It is subdivided into changes -made to the three sub-libraries base, -lac, and deal.II, as well as -changes to the general infrastructure, -documentation, etc. -

- -

-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). -

- - - -

General

- -
    -

  1. - New: deal.II 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 ThreadManager class and now only store handles - to individual threads (which can be discarded, or added to a - ThreadGroup variable that is able to wait for a - whole set of threads at once. -
    - 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. -
    - Some documentation for the new scheme can be found - on this - page. -
    - (WB 2003/02/06) -

    - -

  2. - New: deal.II now makes use of some parts of - the boost library, which is - supposed to be a testground for the next generation C++ standard - library. The parts which we use are now in - contrib/boost/include/boost_local/ and can be - referenced from within your programs. The directory contains - the string _local since you may still want to use - another version or installation of boost in your own programs. -

    - -

    - Also note that boost is large -- much larger than the subset we - have imported --, so we only took what we needed. -
    - (WB 2003/02/06) -

    - -

  3. - Fixed: A longstanding bug in the documentation system has been fixed: if - a namespace was ended with } instead of }; - (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. -
    - (WB 2003/02/02) -

    - -

  4. - Changed: Classes and structures that are declared inside namespaces named - internal 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. -
    - (WB 2003/02/02) -

    - -

  5. - Fixed: Some of the formulas in the step-14 tutorial were obviously - scrambled a little. This is now fixed. -
    - (Roy Stogner, WB 2003/01/30) -

    - -

  6. - 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. -
    - (WB 2003/01/24) -

    - -

  7. - New: Changes have been made to support compiling and using - deal.II on AIX 5 systems. -
    - (WB 2003/01/24) -

    - -

  8. - Removed: Thread support now relies solely on the use of POSIX - functions. The use of the - ACE - (Adaptive Communications Environment) 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. -
    - (WB 2003/01/11) -

    - -

  9. - 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. -
    - (WB 2002/12/18) -

    - -

  10. - New: deal.II 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 -Xc -ansi 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 GXX-VERSION now no longer - holds the non-versioned string intel_icc when icc is - detected, but rather either intel_icc5, - intel_icc6, or intel_icc7, depending on what - version of the compiler was detected. -
    - (WB 2002/12/05) -

    - -

  11. - Changed: Previously, we just set the preprocessor variable - DEAL_II_USE_MT, when --with-multithreading was - given as argument to ./configure. Tests in the code - therefore looked like #ifdef DEAL_II_USE_MT. This has been - changed so that the variable is always defined, but its value is now - equal to 1 - when multithreading was requested, and zero otherwise. The reason for - this is that you can now write if (DEAL_II_USE_MT && ...) - 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 #ifdef - DEAL_II_USE_MT be changed to #if DEAL_II_USE_MT == - 1, since the variable is now defined unconditionally. -
    - (WB 2002/11/14) -

    - -

  12. - 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 .o suffix, while on Windows it is - .obj. Likewise for executables, which have no - suffix on Unix, but .exe on Windows. -
    - (WB 2002/11/11) -

    - -

  13. - New: deal.II 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 Frequently Asked - Questions section. -
    - (WB 2002/10/14) -

    - -

  14. - Fixed: On CygWin, one header files has a #define quad - quad_t. This is annoying, since we have local variables and - member functions with the name quad, and in fact it breaks - compilation on those versions of CygWin that has this. Fortunately, the - define is only active if a preprocessor variable - _POSIX_SOURCE 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. -
    - (Stephen Kolaroff, WB - 2002/09/28) -

    - -

  15. - New: Since math.h only defines the values of PI or E (as - M_PI and M_E) when certain defines are set (on - Linux, these are __USE_BSD or __USE_XOPEN), - portable programs usually defined these constants themselves. In - deal.II, this happened at 6 different places. To - avoid this in the future, base/config.h now exports a - namespace deal_II_numbers that defines these two, and a - number of other numerical constants. -
    - (WB 2002/09/12) -

    - -

  16. - New: base/config.h now exports the - deal.II base directory through the - DEAL_II_PATH preprocessor variable. -
    - (WB 2002/09/09) -

    - -

  17. - 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. -
    - 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. -
    - (WB 2002/09/05) -

    - -

  18. - New: There is now - a new report - on assembling matrices available from the - documentation - page. 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. -
    - (WB 2002/06/17) -

    - -

  19. - Removed: The functions FEValuesBase::get_shape_values, FEValuesBase::get_shape_grads, and FEValuesBase::get_shape_2nd_derivatives 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 FEValuesBase::shape_value and alike - functions as a replacement. -
    - For more information, read - this mail. -
    - (WB 2002/06/10) -

    - -

  20. - New: deal.II 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. -
    - (WB 2002/06/10) -

    - -

  21. - New: The top-level makefile now how a target distclean. - clean leaves the libraries now, removing - everything that is not needed to use - deal.II. distclean removes even the - libraries, leaving the directory more or less in the state like - after configure. -
    - (GK 2002/06/07) -

- - - - -

base

- -
    -

  1. - Fixed: A bug in the Patterns::MultipleSelection class if more - than two elements in a comma-separated list were given. -
    - (Brian Carnes 2003/05/14) -

    - -

  2. - Changed: The Polynomials::Legendre - 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. -
    - (WB 2003/05/12) -

    - -

  3. - New: There is now a class AnisotropicPolynomials that constructs a higher - dimensional polynomial space from a set of 1-d polynomials in each of - the coordinate directions. -
    - (WB 2003/04/20) -

    - -

  4. - Changed: The Table accessor classes - have been moved to a namespace internal. 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. -
    - (WB 2003/02/13) -

    - -

  5. - New: The Function 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. -
    - (WB 2003/02/06) -

    - -

  6. - New: The ThreadMutex classes now have a - member class ScopedLock that implements the - scoped thread-safe locking pattern of Doug Schmidt. It is also used in - various places of the code now. -
    - (WB 2003/01/28) -

    - -

  7. - Fixed: The PosixThreadManager called - its wait 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 wait 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. -
    - (Michael Anderson, WB 2003/01/16) -

    - -

  8. - Fixed: The Subscriptor uses a counter to - count how many SmartPointer 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. -
    - (WB 2003/01/11) -

    - -

  9. - 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. -
    - (Michael Anderson, WB 2003/01/11) -

    - -

  10. - New: There are now classes ThreadCondition - that implement thread condition variable operations through POSIX - functions (in multithreaded mode) or doing nothing (in singlethreaded - mode). -
    - (WB 2003/01/11) -

    - -

  11. - 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. -
    - (WB 2002/12/19) -

    - -

  12. - New: There is now a Patterns::List pattern - that matches a list of elements each of which has to satisfy a pattern - that was given to the constructor. -
    - (WB 2002/11/29) -

    - -

  13. - Changed: In POSIX mode, when the ThreadManager class created a new thread through - pthread_create, it only checked for the - error code and aborted if it was non-zero. Now, it checks whether the - error code is EAGAIN 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. -
    - (WB 2002/11/13) -

    - -

  14. - Fixed: The write_text and write_tex functions of the TableHandler class now check whether their - ofstream arguments are in a proper state before - using them for output. -
    - (RH 2002/11/11) -

    - -

  15. - 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. -
    - (Brian Carnes 2002/10/15) -

    - -

  16. Changed: Because they became too many, the classes describing 1d - polynomials are now in a namespace - Polynomials. -
    - (WB 2002/10/14) -

    - -

  17. 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 Threads - 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. -
    - (WB 2002/10/13) -

    - -

  18. Changed: The class Table<2>::fill function, which is also - inherited from the FullMatrix 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. -
    - (WB 2002/09/28) -

    - -

  19. New: The classes TableIndices<N> and Table<N,T> are now implemented also - for N=4,5 and 6. The Table<N,T> class represents an - N-dimensional array and might replace the - N-times-nested-use of the std::vector class. -
    - (RH 2002/09/24) -

    - -

  20. - New: The Threads::n_existing_threads - 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. -
    - (WB 2002/09/08) -

    - -

  21. New: Global exception class ExcIteratorPastEnd, which should be used if an - iterator is incremented or decremented beyond its end value. -
    - (GK 2002/09/08) -

    - -

  22. - Extended: Previously, the Threads::PosixThreadBarrier - 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. -
    - (WB 2002/09/05) -

    - -

  23. - New: The old class vector2d, implementing a - two-dimensional array of objects is now gone. Instead, there is the new - Table class that implements tables of - arbitrary dimension. Transition is painless: where there was - vector2d<type> before, use - Table<2,type> 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 Table<3,type> now. -
    - (WB 2002/09/03) -

    - -

  24. - New: There are now functions returning the transpose of Tensor objects of rank 2. -
    - (WB 2002/08/31) -

    - -

  25. - New: Row accessors for the vector2d - class now have a member function size that returns the size of the row, - i.e. the number of columns of the table. -
    - (WB 2002/07/24) -

    - -

  26. - 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. -
    - (WB 2002/07/24) -

    - -

  27. - 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. -
    - (WB 2002/07/24) -

    - -

  28. - New: There are now operators to allow multiplication and - division of Tensor objects by scalar - factors. -
    - (WB 2002/06/07) -

    -
- - - - -

lac

- -
    -

  1. New: Function - BlockSparseMatrix::print_formatted - added, similar to the - BlockVector::print_formatted function. -
    - (Brian Carnes 2003/06/02) -

    - -

  2. New: Functions SparseMatrix::operator *= - and SparseMatrix::operator /= as well as - BlockSparseMatrix::operator *= - and BlockSparseMatrix::operator /= - are added. -
    - (Brian Carnes 2003/06/02) -

    - -

  3. Deprecated: The functions Vector::scale - and BlockVector::scale are now deprecated - and will be removed in a future version. Use operator*= and - operator/= instead. -
    - (WB 2003/05/31) -

    - -

  4. New: Vector, BlockVector and - FullMatrix now have operator/= - for scaling by a scalar. -
    - (WB 2003/05/31) -

    - -

  5. New: PointerMatrix now - has empty() function, which returns true if the pointer is - null; otherwise we call the pointer's empty() function. - This requires the class MATRIX to have an empty() - function. -
    - (Brian Carnes 2003/05/22) -

    - -

  6. New: SparseLUDecomposition now - has empty() function, which calls the inherited SparseMatrix empty() function. -
    - (Brian Carnes 2003/05/22) -

    - -

  7. New: PreconditionPSOR implements - interface to permuted SOR preconditioner function in SparseMatrix. -
    - (GK 2003/05/12) -

    - -

  8. Improved: FullMatrix::fill now copies the largest possible block, - whether the destination or source matrix is bigger. Additionally, an - offset inside the source matrix may be specified. -
    - (GK 2003/03/31) -

    - -

  9. - New/Changed: The SparseILU, SparseMIC and SparseLUDecomposition now use the same - interface (initialize, vmult, clear) - as all PreconditionBlock classes. In - virtue of an unified preconditioner interface it is now - recommended to use the new methods. The old methods (reinit, decompose, apply_decomposition) are now deprecated, - and will be removed in a later version. -
    - (RH 2003/02/19) -

    - -

  10. - Changed: The BlockVector accessor classes - have been moved to a namespace internal. 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. -
    - (WB 2003/02/13) -

    - -

  11. - New: The SolverGMRES now accepts an - AdditionalData parameter - use_default_residual whose default is - true. By setting this flag to false, - 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 false only - for debugging/testing purposes. -
    - (RH 2003/01/31) -

    - -

  12. - New: FullMatrix has a function copy_from, copying from sparse matrices. - It uses iterators of the sparse matrix classes. -
    - (GK 2003/01/08) -

    - - -

  13. - Changed: In an attempt to unify the use of preconditioners a - little, the function initialize of - classes PreconditionRelaxation and - PreconditionBlock take an argument - of type AdditionalData, defined in - the same class. Standard behavior of PreconditionBlock has been changed on this - occasion to invert diagonal blocks during initialization. -
    - (GK 2003/01/06) -

    - -

  14. - 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. -
    - (Stephen Kolaroff 2002/11/27) -

    - -

  15. - Changed: In multithread mode, the SparseMatrix would spawn - multithread_info.n_default_threads threads to - perform matrix-vector multiplications and similar - operations. It would even do so if - multithread_info.n_default_threads 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. -
    - (WB 2002/11/13) -

    - -

  16. - Fixed: In the SparseDirectMA27 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. -
    - (WB 2002/09/30) -

    - -

  17. - 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 - SparseDirectMA27 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 - SparseDirectMA27 class. -
    - (WB 2002/09/25) -

    - -

  18. Changed: The classes PreconditionBlock, PreconditionBlockJacobi, PreconditionBlockSOR, and PreconditionBlockSSOR have changed their - template signature. The first template argument is now the matrix - type, not just a number type. -
    - (GK 2002/09/18) -

    - -

  19. New: Class BlockVector has a - function collect_sizes(), very much as - BlockSparsityPattern. This allows - updating internal structures after blocks have been resized. -
    - (GK 2002/09/17) -

    - -

  20. New: Class SparseMatrix has an - STL-conforming const_iterator and - functions begin() and end() for looping through all existing - entries. Furthermore, begin(row) and - end(row) allow looping through all - entries of a single line. -
    - (GK 2002/09/11) -

    - -

  21. - New: Classes SparsityPattern and SparseMatrix now have functions block_write/block_read, 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. -
    - (WB 2002/09/09) -

    - -

  22. - New: Vector has a function lp_norm, computing the lp-norm - of a vector for arbitrary p. -
    - (GK 2002/08/13) -

    - -

  23. - New: a way of using abstract base classes for matrices has - been implemented with PointerMatrixBase - and PointerMatrix. Storing a matrix in - PointerMatrix allows to use the base - class in functions only templated for the vector class. -
    - (GK 2002/07/18) -

    -
- - - - -

deal.II

- -
    -

  1. - 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. -
    - (WB 2003/05/06) -

    - -

  2. - New: The GeometryInfo classes now - have new static member functions child_cell_from_point that, given a point - in the unit cell, returns which child cell it is on; cell_to_child_coordinates that transforms - coordinates between the unit coordinate systems from the mother - to the child cell; child_to_cell_coordinates that does - exactly the opposite; and is_inside_unit_cell that tells whether a - given point is inside the unit cell. -
    - (WB 2003/05/01) -

    - -

  3. - New: There are now functions recursively_set/clear_user_pointer that - do much the same as recursively_set/clear_user_flag on a - line/quad/hex and all of its descendants, but on user pointers - rather than flags. -
    - (WB 2003/04/11) -

    - -

  4. - New: The functions in the DerivativeApproximation class can now also - work on BlockVector. -
    - (WB 2003/04/11) -

    - -

  5. - Changed: The cell argument to Mapping::transform_unit_to_real_cell (and its - reverse function) is now passed by reference, rather than by value, for - efficiency reasons. -
    - (WB 2003/04/06) -

    - -

  6. - New: The GridGenerator::subdivided_hyper_cube generated a - hypercube as coarse grid that is subdivided a given number of times. -
    - (WB 2003/04/05) -

    - -

  7. - New: The DataOut_DoFData::merge_patches - 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. -
    - (WB 2003/04/05) -

    - -

  8. - Fixed: The DataOutStack 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. -
    - (WB 2003/03/02) -

    - -

  9. - Fixed: The DataOutFaces class was - broken for cell data. It should now be correct, although the - algorithm used is not optimal, being approximately quadratic in - runtime. -
    - (WB 2003/02/25) -

    - -

  10. - New: The ConstraintMatrix::shift - function shifts and translates the elements of the constraint - matrix by a certain number of indices. -
    - (Roy Stogner 2003/02/24) -

    - -

  11. - New: The GridReordering class now uses a - vastly better algorithm in 2d than previously. The new algorithm is - linear in time, where it could be exponential before. -
    - (Michael Anderson 2003/02/21) -

    - -

  12. - New: There is now a function GridIn::read_xda that allows reading - grids from a file in XDA format. -
    - (WB 2003/02/21) -

    - -

  13. - Changed: Some implementation details of the GridReordering class have been moved to a - namespace internal. -
    - (WB 2003/02/19) -

    - -

  14. - New: There are now functions FiniteElement::prolongation_is_implemented and - FiniteElement::constraints_are_implemented - that inform the caller about whether the finite element in question in - fact implements its prolongation matrices and hanging node constraints. -
    - (WB 2003/02/15) -

    - -

  15. - Fixed: The ConstraintMatrix::is_identity_constrained 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. -
    - (WB 2003/02/15) -

    - -

  16. - Fixed: Objects of type FESystem - 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. -
    - (WB 2003/02/15) -

    - -

  17. - New: For each of the renumbering functions in the DoFRenumbering class there is now an - additional compute_* - function. These new functions compute and return the - corresponding renumbering vectors but do not perform the actual - renumbering on the DoFHandler - object. The behaviour of the old functions is not changed. -
    - (RH 2003/02/03) -

    - -

  18. - Fixed: The GridReordering tried to be - thread-safe in the initialization of some data, but was not due to a - typo. This is now fixed. -
    - (WB 2003/01/28) -

    - -

  19. - Changed: The FEValues::get_cell and - FEValues::get_face 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. -
    - (WB 2003/01/17) -

    - -

  20. - New: The DoF accessor classes now have a function get_fe() that returns a reference to the finite - element being used on this cell. The result is of course identical to - what a call to iterator->get_dof_handler().get_fe() would have - yielded. -
    - (WB 2003/01/10) -

    - -

  21. - New: Checked in new GridGenerator - member function half_hyper_ball, - derived from member hyper_ball. - The intial mesh contains four elements. This mesh will work with - the boundary class HalfHyperBallBoundary. -
    - (Brian Carnes 2002/12/16) -

    - -

  22. - New: Checked in new class FE_Q_Hierarchical - derived from class FiniteElement. - This element is analogous to FE_Q, but - makes use of hierachical shape functions, based on the - Polynomials::Hierarchical class. - For degree>1, 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 - degree>1. It is planned to implement a different - interpolation-projection operator, based on an hp-type interpolant. -
    - The files for this element are - deal.II/include/fe/fe_q_hierarchical.h and - deal.II/source/fe/fe_q_hierarchical.cc. -
    - (Brian Carnes 2002/12/13) -

    - -

  23. - New: For finite element classes, the functions - unit_support_point and - unit_face_support_point 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 - get_unit_support_points function returns. -
    - (WB 2002/11/23) -

    - -

  24. - Fixed: Vectors could not be given as input and output vectors to the - SolutionTransfer class at the same time, but - this was not checked. An assertion has now been added to ensure this - requirement. -
    - (WB 2002/10/28) -

    - -

  25. - Fixed: The DoFRenumbering::component_wise 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. -
    - (WB 2002/10/17) -

    - -

  26. - New: The FiniteElement::system_to_base_index function now - exports the values of the FiniteElement::system_to_base_table member - variable. Likewise for the indices on faces. -
    - (WB 2002/10/17) -

    - -

  27. - New: The FiniteElement::element_multiplicity function was - previously only available in the FESystem - 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. -
    - (WB 2002/10/17) -

    - -

  28. - Fixed: The algorithm to generate neighbor information for patches from - cells in DataOut::build_patches 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. -
    - (WB 2002/10/10) -

    - -

  29. - 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.) -
    - (WB 2002/09/28) -

    - -

  30. Improved: The different transfer functions in FETools operate on template vector arguments. -
    - (GK 2002/09/24) -

    - -

  31. New: the class FE_DGPNonparametric implements finite elements - where shape functions are polynomials of order k 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. -
    - (GK 2002/09/19) -

    - -

  32. - Fixed: Some of the various instances of the VectorTools::interpolate_boundary_values functions - were not explicitly instantiated, leading to linker errors. This is now - fixed. -
    - (WB 2002/09/19) -

    - -

  33. - Removed: The FiniteElement::component_to_system_index 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. -
    - (WB 2002/09/16) -

    - -

  34. - Changed: The FiniteElement::restriction_is_additive 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. -
    - (WB 2002/09/16) -

    - -

  35. - 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. -
    - (WB 2002/09/03) -

    - -

  36. - Fixed: the GridIn class had problems - when reading in UCD grids with comment lines that contained - only the comment sign, but nothing else. This is now fixed. -
    - (WB 2002/08/30) -

    - -

  37. - Improved: VectorTools::integrate_difference can compute Lp - and W1,p norms for arbitrary p. The function - receives an additional optional argument p for this. All previous - fuctionality remains unchanged, although the code has been cleaned up a bit. -
    - (GK 2002/08/01) -

    - -

  38. New: The GridTools 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. -
    - (RH 2002/07/25) -

    - -

  39. New: The existing FETools::extrapolate 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 FETools::extrapolate function with an - additional ConstraintMatrix 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. -
    - (RH 2002/06/17) -

    - -

  40. New: There are now Triangulation::save/load_user_pointers(vector<void - *> &) functions similar to the respective Triangulation::save/load_user_flags(vector<bool> - &) functions. -
    - (RH 2002/06/14) -

    - -

  41. Fixed: Bug in Triangulation<3>::load_user_flags(vector<bool> - &) is now fixed. -
    - (RH 2002/06/14) -

    - -

  42. Fixed: Triangulation::load_user_flags(vector<bool> - &) erroneously threw an assertion for - dim==1. This is now fixed. -
    - (RH 2002/06/14) -

    - -

  43. Changed: Triangulation<1>::n_quads now returns 0, - instead of throwing an assertion, as before. The same holds for - similar functions like Triangulation<dim>::n_hexs that now - returns 0 for dim<3. -
    - (RH 2002/06/14) -

    - -

  44. Improved: Several functions like the DoFHandler::distribute_dofs and DoFTools::make_flux_sparsity_pattern - functions altered the user_flags. This was stated in the - documentation of these functions. Nevertheless, it might have - led to unexpected behaviour of the user_flags for users who weren't aware of - this side-effect. Now, these functions do not alter - the user_flags, any - more. Consequently, the users do not need to worry any more - about the reliability of the user_flags when calling any function of - the library. -
    - (RH 2002/06/14) -

    - -

  45. Fixed: FE_Q::has_support_on_face 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 FE_DGQ::has_support_on_face -
    - (WB 2002/06/13) -

    - -

  46. New: The existing FETools::interpolate, FETools::back_interpolate and FETools::interpolate_difference 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 ConstraintMatrix 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. -
    - (RH 2002/06/13) -

    - -

  47. Changed: The constructor of DoFHandler now takes a reference to a - const Triangulation. -
    - (RH 2002/06/12) -

    - -

  48. Changed: The constructors of all DoFAccessor, TriaAccessor and TriaIterator classes now take pointers to - const Triangulations. -
    - (RH 2002/06/12) -

    - -

  49. Fixed: In debug mode the MappingQ1::transform_real_to_unit_cell - function erroneously threw an assertion when used in 1 or 3 - dimensions. This is now fixed. -
    - (RH 2002/06/10) -

    - -

  50. - Fixed: The get_dof_indices - 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. -
    - (WB 2002/06/08) -

    - -

  51. - New: For encapsulated postscript output of 2d grids, it is now - possible to tell the GridOut class to - write the cell numbers into each cell, as well as the numbers - of the vertices. -
    - (WB 2002/06/04) -

    -
- -
-Last update $Date$ - - - diff --git a/deal.II/doc/news/3.4.0-vs-4.0.0.html b/deal.II/doc/news/3.4.0-vs-4.0.0.html index 3f0e0ecc9b..b303664c54 100644 --- a/deal.II/doc/news/3.4.0-vs-4.0.0.html +++ b/deal.II/doc/news/3.4.0-vs-4.0.0.html @@ -267,7 +267,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK

  • New: There is now - a new report + a new report on assembling matrices available from the documentation page. The main focus is assembling of matrices for diff --git a/deal.II/doc/reports/assemble/img1.gif b/deal.II/doc/reports/assemble/img1.gif deleted file mode 100644 index d6b9f87468..0000000000 Binary files a/deal.II/doc/reports/assemble/img1.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img10.gif b/deal.II/doc/reports/assemble/img10.gif deleted file mode 100644 index aaaa4feb77..0000000000 Binary files a/deal.II/doc/reports/assemble/img10.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img11.gif b/deal.II/doc/reports/assemble/img11.gif deleted file mode 100644 index e73eb272d6..0000000000 Binary files a/deal.II/doc/reports/assemble/img11.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img12.gif b/deal.II/doc/reports/assemble/img12.gif deleted file mode 100644 index 48ac2d85d7..0000000000 Binary files a/deal.II/doc/reports/assemble/img12.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img13.gif b/deal.II/doc/reports/assemble/img13.gif deleted file mode 100644 index c89091bd46..0000000000 Binary files a/deal.II/doc/reports/assemble/img13.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img14.gif b/deal.II/doc/reports/assemble/img14.gif deleted file mode 100644 index 918bd25602..0000000000 Binary files a/deal.II/doc/reports/assemble/img14.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img15.gif b/deal.II/doc/reports/assemble/img15.gif deleted file mode 100644 index f3eacb2aa5..0000000000 Binary files a/deal.II/doc/reports/assemble/img15.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img16.gif b/deal.II/doc/reports/assemble/img16.gif deleted file mode 100644 index abca97a9ba..0000000000 Binary files a/deal.II/doc/reports/assemble/img16.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img17.gif b/deal.II/doc/reports/assemble/img17.gif deleted file mode 100644 index 742ed0363e..0000000000 Binary files a/deal.II/doc/reports/assemble/img17.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img18.gif b/deal.II/doc/reports/assemble/img18.gif deleted file mode 100644 index d28fe1b8f1..0000000000 Binary files a/deal.II/doc/reports/assemble/img18.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img19.gif b/deal.II/doc/reports/assemble/img19.gif deleted file mode 100644 index 78d68bbb4d..0000000000 Binary files a/deal.II/doc/reports/assemble/img19.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img2.gif b/deal.II/doc/reports/assemble/img2.gif deleted file mode 100644 index 7c2f274b89..0000000000 Binary files a/deal.II/doc/reports/assemble/img2.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img20.gif b/deal.II/doc/reports/assemble/img20.gif deleted file mode 100644 index 2c840cb524..0000000000 Binary files a/deal.II/doc/reports/assemble/img20.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img21.gif b/deal.II/doc/reports/assemble/img21.gif deleted file mode 100644 index 4ee5086e35..0000000000 Binary files a/deal.II/doc/reports/assemble/img21.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img22.gif b/deal.II/doc/reports/assemble/img22.gif deleted file mode 100644 index 47342d25ea..0000000000 Binary files a/deal.II/doc/reports/assemble/img22.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img23.gif b/deal.II/doc/reports/assemble/img23.gif deleted file mode 100644 index a7cd819a92..0000000000 Binary files a/deal.II/doc/reports/assemble/img23.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img24.gif b/deal.II/doc/reports/assemble/img24.gif deleted file mode 100644 index b44ef076b6..0000000000 Binary files a/deal.II/doc/reports/assemble/img24.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img25.gif b/deal.II/doc/reports/assemble/img25.gif deleted file mode 100644 index eb8edea871..0000000000 Binary files a/deal.II/doc/reports/assemble/img25.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img26.gif b/deal.II/doc/reports/assemble/img26.gif deleted file mode 100644 index 2ef4c1d073..0000000000 Binary files a/deal.II/doc/reports/assemble/img26.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img27.gif b/deal.II/doc/reports/assemble/img27.gif deleted file mode 100644 index a9c26a33cb..0000000000 Binary files a/deal.II/doc/reports/assemble/img27.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img28.gif b/deal.II/doc/reports/assemble/img28.gif deleted file mode 100644 index 002b77a932..0000000000 Binary files a/deal.II/doc/reports/assemble/img28.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img29.gif b/deal.II/doc/reports/assemble/img29.gif deleted file mode 100644 index 7793704481..0000000000 Binary files a/deal.II/doc/reports/assemble/img29.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img3.gif b/deal.II/doc/reports/assemble/img3.gif deleted file mode 100644 index 8a05126914..0000000000 Binary files a/deal.II/doc/reports/assemble/img3.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img30.gif b/deal.II/doc/reports/assemble/img30.gif deleted file mode 100644 index d8e107d117..0000000000 Binary files a/deal.II/doc/reports/assemble/img30.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img31.gif b/deal.II/doc/reports/assemble/img31.gif deleted file mode 100644 index c19ad2ace2..0000000000 Binary files a/deal.II/doc/reports/assemble/img31.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img32.gif b/deal.II/doc/reports/assemble/img32.gif deleted file mode 100644 index e17f19d9e0..0000000000 Binary files a/deal.II/doc/reports/assemble/img32.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img33.gif b/deal.II/doc/reports/assemble/img33.gif deleted file mode 100644 index 8ebedd0720..0000000000 Binary files a/deal.II/doc/reports/assemble/img33.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img34.gif b/deal.II/doc/reports/assemble/img34.gif deleted file mode 100644 index d6de723df3..0000000000 Binary files a/deal.II/doc/reports/assemble/img34.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img35.gif b/deal.II/doc/reports/assemble/img35.gif deleted file mode 100644 index bbc5bc6912..0000000000 Binary files a/deal.II/doc/reports/assemble/img35.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img36.gif b/deal.II/doc/reports/assemble/img36.gif deleted file mode 100644 index 1214cb8369..0000000000 Binary files a/deal.II/doc/reports/assemble/img36.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img37.gif b/deal.II/doc/reports/assemble/img37.gif deleted file mode 100644 index 9aa700db13..0000000000 Binary files a/deal.II/doc/reports/assemble/img37.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img38.gif b/deal.II/doc/reports/assemble/img38.gif deleted file mode 100644 index 5e639468da..0000000000 Binary files a/deal.II/doc/reports/assemble/img38.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img39.gif b/deal.II/doc/reports/assemble/img39.gif deleted file mode 100644 index 255d05e0de..0000000000 Binary files a/deal.II/doc/reports/assemble/img39.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img4.gif b/deal.II/doc/reports/assemble/img4.gif deleted file mode 100644 index e2aff43f8a..0000000000 Binary files a/deal.II/doc/reports/assemble/img4.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img40.gif b/deal.II/doc/reports/assemble/img40.gif deleted file mode 100644 index aac5a4b07b..0000000000 Binary files a/deal.II/doc/reports/assemble/img40.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img41.gif b/deal.II/doc/reports/assemble/img41.gif deleted file mode 100644 index 6930a1e5eb..0000000000 Binary files a/deal.II/doc/reports/assemble/img41.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img42.gif b/deal.II/doc/reports/assemble/img42.gif deleted file mode 100644 index 36e9d63c91..0000000000 Binary files a/deal.II/doc/reports/assemble/img42.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img43.gif b/deal.II/doc/reports/assemble/img43.gif deleted file mode 100644 index efde6fcc0b..0000000000 Binary files a/deal.II/doc/reports/assemble/img43.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img44.gif b/deal.II/doc/reports/assemble/img44.gif deleted file mode 100644 index afe88c6b60..0000000000 Binary files a/deal.II/doc/reports/assemble/img44.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img45.gif b/deal.II/doc/reports/assemble/img45.gif deleted file mode 100644 index d64b0e259e..0000000000 Binary files a/deal.II/doc/reports/assemble/img45.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img46.gif b/deal.II/doc/reports/assemble/img46.gif deleted file mode 100644 index 6034c45bbe..0000000000 Binary files a/deal.II/doc/reports/assemble/img46.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img47.gif b/deal.II/doc/reports/assemble/img47.gif deleted file mode 100644 index 159a7faf07..0000000000 Binary files a/deal.II/doc/reports/assemble/img47.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img48.gif b/deal.II/doc/reports/assemble/img48.gif deleted file mode 100644 index 6c8fa26024..0000000000 Binary files a/deal.II/doc/reports/assemble/img48.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img49.gif b/deal.II/doc/reports/assemble/img49.gif deleted file mode 100644 index d52efb8cd2..0000000000 Binary files a/deal.II/doc/reports/assemble/img49.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img5.gif b/deal.II/doc/reports/assemble/img5.gif deleted file mode 100644 index c9e8e7497b..0000000000 Binary files a/deal.II/doc/reports/assemble/img5.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img50.gif b/deal.II/doc/reports/assemble/img50.gif deleted file mode 100644 index 0053aa24e8..0000000000 Binary files a/deal.II/doc/reports/assemble/img50.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img51.gif b/deal.II/doc/reports/assemble/img51.gif deleted file mode 100644 index 93bd487395..0000000000 Binary files a/deal.II/doc/reports/assemble/img51.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img52.gif b/deal.II/doc/reports/assemble/img52.gif deleted file mode 100644 index 96e89ccc0d..0000000000 Binary files a/deal.II/doc/reports/assemble/img52.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img53.gif b/deal.II/doc/reports/assemble/img53.gif deleted file mode 100644 index 98014b04df..0000000000 Binary files a/deal.II/doc/reports/assemble/img53.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img54.gif b/deal.II/doc/reports/assemble/img54.gif deleted file mode 100644 index 72f9c4a4ea..0000000000 Binary files a/deal.II/doc/reports/assemble/img54.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img55.gif b/deal.II/doc/reports/assemble/img55.gif deleted file mode 100644 index 0536f80f7f..0000000000 Binary files a/deal.II/doc/reports/assemble/img55.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img56.gif b/deal.II/doc/reports/assemble/img56.gif deleted file mode 100644 index 6e37c133b6..0000000000 Binary files a/deal.II/doc/reports/assemble/img56.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img57.gif b/deal.II/doc/reports/assemble/img57.gif deleted file mode 100644 index e75a97361e..0000000000 Binary files a/deal.II/doc/reports/assemble/img57.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img58.gif b/deal.II/doc/reports/assemble/img58.gif deleted file mode 100644 index 8ad71c8dcc..0000000000 Binary files a/deal.II/doc/reports/assemble/img58.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img59.gif b/deal.II/doc/reports/assemble/img59.gif deleted file mode 100644 index f898b00d9a..0000000000 Binary files a/deal.II/doc/reports/assemble/img59.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img6.gif b/deal.II/doc/reports/assemble/img6.gif deleted file mode 100644 index 596606c14d..0000000000 Binary files a/deal.II/doc/reports/assemble/img6.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img60.gif b/deal.II/doc/reports/assemble/img60.gif deleted file mode 100644 index 4d219c6ac6..0000000000 Binary files a/deal.II/doc/reports/assemble/img60.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img61.gif b/deal.II/doc/reports/assemble/img61.gif deleted file mode 100644 index c812f39445..0000000000 Binary files a/deal.II/doc/reports/assemble/img61.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img62.gif b/deal.II/doc/reports/assemble/img62.gif deleted file mode 100644 index 1771abb767..0000000000 Binary files a/deal.II/doc/reports/assemble/img62.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img63.gif b/deal.II/doc/reports/assemble/img63.gif deleted file mode 100644 index f19edb894e..0000000000 Binary files a/deal.II/doc/reports/assemble/img63.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img64.gif b/deal.II/doc/reports/assemble/img64.gif deleted file mode 100644 index 781dbf8c24..0000000000 Binary files a/deal.II/doc/reports/assemble/img64.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img65.gif b/deal.II/doc/reports/assemble/img65.gif deleted file mode 100644 index ef1f07b8b0..0000000000 Binary files a/deal.II/doc/reports/assemble/img65.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img66.gif b/deal.II/doc/reports/assemble/img66.gif deleted file mode 100644 index 89a9c89147..0000000000 Binary files a/deal.II/doc/reports/assemble/img66.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img67.gif b/deal.II/doc/reports/assemble/img67.gif deleted file mode 100644 index 74852b156f..0000000000 Binary files a/deal.II/doc/reports/assemble/img67.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img68.gif b/deal.II/doc/reports/assemble/img68.gif deleted file mode 100644 index 32d7aa9d6b..0000000000 Binary files a/deal.II/doc/reports/assemble/img68.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img69.gif b/deal.II/doc/reports/assemble/img69.gif deleted file mode 100644 index 852f7187a0..0000000000 Binary files a/deal.II/doc/reports/assemble/img69.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img7.gif b/deal.II/doc/reports/assemble/img7.gif deleted file mode 100644 index 4ea752380f..0000000000 Binary files a/deal.II/doc/reports/assemble/img7.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img70.gif b/deal.II/doc/reports/assemble/img70.gif deleted file mode 100644 index 4db374d678..0000000000 Binary files a/deal.II/doc/reports/assemble/img70.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img71.gif b/deal.II/doc/reports/assemble/img71.gif deleted file mode 100644 index 233c0f45a8..0000000000 Binary files a/deal.II/doc/reports/assemble/img71.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img72.gif b/deal.II/doc/reports/assemble/img72.gif deleted file mode 100644 index 3b49c00e3f..0000000000 Binary files a/deal.II/doc/reports/assemble/img72.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img73.gif b/deal.II/doc/reports/assemble/img73.gif deleted file mode 100644 index 936e029c88..0000000000 Binary files a/deal.II/doc/reports/assemble/img73.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img74.gif b/deal.II/doc/reports/assemble/img74.gif deleted file mode 100644 index a5539ec3ef..0000000000 Binary files a/deal.II/doc/reports/assemble/img74.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img75.gif b/deal.II/doc/reports/assemble/img75.gif deleted file mode 100644 index 9bf6432d29..0000000000 Binary files a/deal.II/doc/reports/assemble/img75.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img76.gif b/deal.II/doc/reports/assemble/img76.gif deleted file mode 100644 index dc0048143d..0000000000 Binary files a/deal.II/doc/reports/assemble/img76.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img77.gif b/deal.II/doc/reports/assemble/img77.gif deleted file mode 100644 index 3e08c35e42..0000000000 Binary files a/deal.II/doc/reports/assemble/img77.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img78.gif b/deal.II/doc/reports/assemble/img78.gif deleted file mode 100644 index a915a75bfd..0000000000 Binary files a/deal.II/doc/reports/assemble/img78.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img79.gif b/deal.II/doc/reports/assemble/img79.gif deleted file mode 100644 index 9ae0de6db3..0000000000 Binary files a/deal.II/doc/reports/assemble/img79.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img8.gif b/deal.II/doc/reports/assemble/img8.gif deleted file mode 100644 index 43fe3e7f2b..0000000000 Binary files a/deal.II/doc/reports/assemble/img8.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img80.gif b/deal.II/doc/reports/assemble/img80.gif deleted file mode 100644 index affbada694..0000000000 Binary files a/deal.II/doc/reports/assemble/img80.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img81.gif b/deal.II/doc/reports/assemble/img81.gif deleted file mode 100644 index f2bc847f57..0000000000 Binary files a/deal.II/doc/reports/assemble/img81.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img82.gif b/deal.II/doc/reports/assemble/img82.gif deleted file mode 100644 index 3999439939..0000000000 Binary files a/deal.II/doc/reports/assemble/img82.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img83.gif b/deal.II/doc/reports/assemble/img83.gif deleted file mode 100644 index b45068e0b5..0000000000 Binary files a/deal.II/doc/reports/assemble/img83.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img84.gif b/deal.II/doc/reports/assemble/img84.gif deleted file mode 100644 index 9207600c6e..0000000000 Binary files a/deal.II/doc/reports/assemble/img84.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img85.gif b/deal.II/doc/reports/assemble/img85.gif deleted file mode 100644 index a6bbaa36e1..0000000000 Binary files a/deal.II/doc/reports/assemble/img85.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img86.gif b/deal.II/doc/reports/assemble/img86.gif deleted file mode 100644 index e9bdeb31c8..0000000000 Binary files a/deal.II/doc/reports/assemble/img86.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img87.gif b/deal.II/doc/reports/assemble/img87.gif deleted file mode 100644 index 0e4d10b3a5..0000000000 Binary files a/deal.II/doc/reports/assemble/img87.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img88.gif b/deal.II/doc/reports/assemble/img88.gif deleted file mode 100644 index 5bd558f521..0000000000 Binary files a/deal.II/doc/reports/assemble/img88.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img89.gif b/deal.II/doc/reports/assemble/img89.gif deleted file mode 100644 index 5f489d9b68..0000000000 Binary files a/deal.II/doc/reports/assemble/img89.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img9.gif b/deal.II/doc/reports/assemble/img9.gif deleted file mode 100644 index 6b8151632b..0000000000 Binary files a/deal.II/doc/reports/assemble/img9.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img90.gif b/deal.II/doc/reports/assemble/img90.gif deleted file mode 100644 index 9cfeed2fb6..0000000000 Binary files a/deal.II/doc/reports/assemble/img90.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img91.gif b/deal.II/doc/reports/assemble/img91.gif deleted file mode 100644 index 5c92644af9..0000000000 Binary files a/deal.II/doc/reports/assemble/img91.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img92.gif b/deal.II/doc/reports/assemble/img92.gif deleted file mode 100644 index 26d549bd88..0000000000 Binary files a/deal.II/doc/reports/assemble/img92.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img93.gif b/deal.II/doc/reports/assemble/img93.gif deleted file mode 100644 index 784eba0d76..0000000000 Binary files a/deal.II/doc/reports/assemble/img93.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img94.gif b/deal.II/doc/reports/assemble/img94.gif deleted file mode 100644 index 7097f9c50c..0000000000 Binary files a/deal.II/doc/reports/assemble/img94.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img95.gif b/deal.II/doc/reports/assemble/img95.gif deleted file mode 100644 index bf8a8497c3..0000000000 Binary files a/deal.II/doc/reports/assemble/img95.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/img96.gif b/deal.II/doc/reports/assemble/img96.gif deleted file mode 100644 index 8134a66931..0000000000 Binary files a/deal.II/doc/reports/assemble/img96.gif and /dev/null differ diff --git a/deal.II/doc/reports/assemble/index.html b/deal.II/doc/reports/assemble/index.html deleted file mode 100644 index 25f5eb648e..0000000000 --- a/deal.II/doc/reports/assemble/index.html +++ /dev/null @@ -1,151 +0,0 @@ - - - - - -assemble - - - - - - - - - - - - - - - - - -next -up -previous -
    - Next: Introduction -
    -
    - - -

    -

    -
    -
    Assembling matrices in deal.II - -
    -

    -

    -
    -
    -
    -

    -

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

    -

    - - - -

    Overview

    - -

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

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

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

    Table of contents

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

    -Assembling vector-valued problems: The complicated case -

    - -

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

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

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

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

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

    -

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

    -Getting information about shape functions -

    - -

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

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

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

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

    -

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

    -Evaluating shape functions -

    - -

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

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

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

    -

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

    -The elastic equations -

    - -

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

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

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

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

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

    -

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

    -The Stokes equations -

    - -

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

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

    -

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

    -Conclusions -

    - -

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

    -

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

    -About this document ... -

    -

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

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

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

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

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

    -Linear systems for finite element methods -

    - -

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

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

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

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

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

    - -

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

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

    -Denoting -

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

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

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

    - -

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    -

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

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

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

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

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

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

    -

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

    -Assembling scalar problems -

    - -

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

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

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

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

    -with which the bilinear form -

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

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

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

    -

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

    -Vector-valued problems -

    - -

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

    -

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

    - -
    -The elastic equations -

    - -

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

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

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

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

    -or as a sum over components: - -

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

    - -

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

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

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

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

    -The sought operator $ Q$ is then -

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

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

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

    -

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

    - -
    -The Stokes equations -

    - -

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

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

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

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

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

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

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

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

    -

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

    -Assembling vector-valued problems: The simple case -

    - -

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

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

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

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

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

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

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

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

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

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

    - -

    -

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

    - -
    -The elastic equations -

    - -

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

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

    -

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

    - -
    -The Stokes equations -

    - -

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

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

    -

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