From: Daniel Arndt Date: Thu, 16 Jan 2020 16:15:44 +0000 (-0700) Subject: Remove trailing whitespace X-Git-Tag: v9.2.0-rc1~656^2~1 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=817379958af6487bcefdd6248dd7fb72bd3825e0;p=dealii.git Remove trailing whitespace --- diff --git a/contrib/python-bindings/source/CMakeLists.txt b/contrib/python-bindings/source/CMakeLists.txt index 775a2d7e52..a76c202ee9 100644 --- a/contrib/python-bindings/source/CMakeLists.txt +++ b/contrib/python-bindings/source/CMakeLists.txt @@ -29,8 +29,8 @@ IF(FEATURE_BOOST_BUNDLED_CONFIGURED) ENDIF() # -# As of 1.67, boost requires specifying the suffix for the python -# component manually. +# As of 1.67, boost requires specifying the suffix for the python +# component manually. # UNSET(Boost_FOUND) IF(${BOOST_VERSION} VERSION_LESS 1.67) diff --git a/doc/developers/testsuite.html b/doc/developers/testsuite.html index 4782ff4c8c..6785714290 100644 --- a/doc/developers/testsuite.html +++ b/doc/developers/testsuite.html @@ -29,8 +29,8 @@ we add at least one new test to the testsuite, and we also do so if we fix a bug, in both cases to make sure that future changes do not break this functionality (again). Machines running the testsuite - submit the results to our cdash - CDash instance, + submit the results to our cdash + CDash instance, a webpage showing the status of our regression tests.

diff --git a/doc/doxygen/CMakeLists.txt b/doc/doxygen/CMakeLists.txt index 96f526349f..8a3bb35008 100644 --- a/doc/doxygen/CMakeLists.txt +++ b/doc/doxygen/CMakeLists.txt @@ -116,8 +116,8 @@ CONFIGURE_FILE( # doxygen-generated HTML files. SET(_last_year "1997") FILE(GLOB _source_files - "${CMAKE_SOURCE_DIR}/source/*/*.cc" - "${CMAKE_SOURCE_DIR}/include/deal.II/*/*.h" + "${CMAKE_SOURCE_DIR}/source/*/*.cc" + "${CMAKE_SOURCE_DIR}/include/deal.II/*/*.h" "${CMAKE_SOURCE_DIR}/examples/*/*.cc") FOREACH (_source ${_source_files}) FILE(READ "${_source}" contents) diff --git a/doc/doxygen/code-gallery/CMakeLists.txt b/doc/doxygen/code-gallery/CMakeLists.txt index c87ce73cf7..751851c733 100644 --- a/doc/doxygen/code-gallery/CMakeLists.txt +++ b/doc/doxygen/code-gallery/CMakeLists.txt @@ -71,7 +71,7 @@ IF (EXISTS ${DEAL_II_CODE_GALLERY_DIRECTORY}/README.md) ${_code_gallery_h_deps} ) ADD_CUSTOM_TARGET(build_code-gallery_h - DEPENDS + DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/code-gallery.h ${_code_gallery_h_deps} COMMENT @@ -120,10 +120,10 @@ IF (EXISTS ${DEAL_II_CODE_GALLERY_DIRECTORY}/README.md) COMMAND ${PERL_EXECUTABLE} ARGS ${CMAKE_SOURCE_DIR}/doc/doxygen/scripts/make_gallery.pl - ${CMAKE_SOURCE_DIR} - ${_step} + ${CMAKE_SOURCE_DIR} + ${_step} ${DEAL_II_CODE_GALLERY_DIRECTORY}/${_step} - ${_relative_src_files} + ${_relative_src_files} > ${CMAKE_CURRENT_BINARY_DIR}/${_step}.h WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} diff --git a/doc/doxygen/headers/automatic_and_symbolic_differentiation.h b/doc/doxygen/headers/automatic_and_symbolic_differentiation.h index 6802c014c5..4969c8e97a 100644 --- a/doc/doxygen/headers/automatic_and_symbolic_differentiation.h +++ b/doc/doxygen/headers/automatic_and_symbolic_differentiation.h @@ -443,7 +443,7 @@ * A summary of the files that implement the interface to the supported auto-differentiable * numbers is as follows: * - * - ad_drivers.h: Provides classes that act as drivers to the interface of internally supported + * - ad_drivers.h: Provides classes that act as drivers to the interface of internally supported * automatic differentiation libraries. These are used internally as an intermediary to the * helper classes that we provide. * - ad_helpers.h: Provides a set of classes to help perform automatic differentiation in a @@ -485,7 +485,7 @@ * * @subsubsection auto_diff_1_3 User interface to the automatic differentiation libraries * - * The deal.II library offers a unified interface to the automatic differentiation libraries that + * The deal.II library offers a unified interface to the automatic differentiation libraries that * we support. To date, the helper classes have been developed for the following contexts: * * - Classes designed to operate at the quadrature point level (or any general continuum point): @@ -500,7 +500,7 @@ * - ResidualLinearization: Differentiation of a vector-valued finite element residual, leading to * its consistent linearization. * - * Naturally, it is also possible for users to manage the initialization and derivative + * Naturally, it is also possible for users to manage the initialization and derivative * computations themselves. * * The most up-to-date examples of how this is done using ADOL-C can be found in diff --git a/doc/doxygen/headers/c++11.h b/doc/doxygen/headers/c++11.h index 075311c7f1..11a5317325 100644 --- a/doc/doxygen/headers/c++11.h +++ b/doc/doxygen/headers/c++11.h @@ -23,7 +23,7 @@ * deal.II are now using features that were only introduced in C++11. * That said, deal.II also has functions and classes that make using * it with C++11 features easier. - * + * * One example is support for C++11 * range-based * for loops. deal.II-based codes often have many loops of the kind diff --git a/doc/doxygen/headers/fe.h b/doc/doxygen/headers/fe.h index 198879a3f3..e6ee9628b6 100644 --- a/doc/doxygen/headers/fe.h +++ b/doc/doxygen/headers/fe.h @@ -61,7 +61,7 @@ * an introduction into the use of this class in the context of the * vector-valued elasticity (Lamé) equations. step-20 discusses a mixed * Laplace discretization that also uses vector-valued elements. - * + * * @ingroup feall */ @@ -96,7 +96,7 @@ * specify up front which information you are actually interested in. The * UpdateFlags enumeration is used to offer symbolic names denoting what you * want the FEValues class to compute. - * + * * All these classes are used in all * @ref Tutorial "tutorial programs" * from step-3 onward, and are described there in significant detail. @@ -171,7 +171,7 @@ *
  • scalar: FE_DGP, FE_DGQ *
  • scalar, different shape functions: FE_DGPMonomial, FE_DGPNonparametric, FE_DGQArbitraryNodes *
  • vector-valued: FE_DGBDM, FE_DGNedelec, FE_DGRaviartThomas - * + * * * @note The implementation of vector valued DG elements is supported * by the class FE_DGVector, in the way, that only the vector @@ -197,13 +197,13 @@ * it accepts a vector that describes a displacement field for each position * of the domain. This is used in Eulerian computations without the need to * actually move vertices after each time step. - * + * * In addition, the MappingC1 class provides for a boundary of the * computational domain that is not only curved, but also has a continuous * derivative at the interface between two cells on the boundary. - * + * * Finally, the MappingCartesian class is an optimization for elements that * are brick-shaped and with edges parallel to the coordinate axes. - * + * * @ingroup feall */ diff --git a/doc/doxygen/headers/fe_vs_mapping_vs_fevalues.h b/doc/doxygen/headers/fe_vs_mapping_vs_fevalues.h index 6b6cf76e8b..70dc7abd90 100644 --- a/doc/doxygen/headers/fe_vs_mapping_vs_fevalues.h +++ b/doc/doxygen/headers/fe_vs_mapping_vs_fevalues.h @@ -16,9 +16,9 @@ /** * @defgroup FE_vs_Mapping_vs_FEValues How Mapping, FiniteElement, and FEValues work together - * + * *

    Introduction

    - * + * * Most people create finite element (and, potentially, mapping) objects once * but then never actually call any member functions on them -- they simply * use them for assembly via the FEValues interface. The only other interaction @@ -134,7 +134,7 @@ * values and derivatives on actual cells (obviously with the help of a * mapping object). For the current discussion, only the latter role is * important. - * + * * As with mappings, all that is important for us here is that the finite * element classes can provide this information at given quadrature points, * and that they can put the computed information into structures provided @@ -182,7 +182,7 @@ * mapping class will indicate by adding update_contravariant_transformation * to the list. * - * + * *

    Pre-computing things

    * * At this point, the FEValues object has found out the complete diff --git a/doc/doxygen/headers/functions.h b/doc/doxygen/headers/functions.h index e3c9b11720..6a5b4a15df 100644 --- a/doc/doxygen/headers/functions.h +++ b/doc/doxygen/headers/functions.h @@ -39,7 +39,7 @@ * * *

    Time dependent functions

    - * + * * For time dependent computations, boundary conditions and/or right * hand side functions may also change with time. Since at a given * time step one is usually only interested in the spatial dependence @@ -61,7 +61,7 @@ * time of the function object to the present time step before handing * it off to the VectorTools::interpolate_boundary_values method. * - * + * *

    Tensor-valued functions

    * * The Function class is the most frequently used, but sometimes one needs a diff --git a/doc/doxygen/headers/geodynamics.h b/doc/doxygen/headers/geodynamics.h index 9439b9898c..223dfaf421 100644 --- a/doc/doxygen/headers/geodynamics.h +++ b/doc/doxygen/headers/geodynamics.h @@ -130,7 +130,7 @@ problems. In particular, they are aimed at the following goals: correctness. Existing tutorial programs typically employ simpler rather than more complicated solver schemes for exposition but frequently suggest more complicated schemes including hints on how they might be implemented in an - appendix. + appendix.
  • Try algorithms: The rapid prototyping abilities of deal.II may also help in determining best algorithms on the scale of programs to which diff --git a/doc/doxygen/headers/grid.h b/doc/doxygen/headers/grid.h index 484f7d92d2..44f139c4db 100644 --- a/doc/doxygen/headers/grid.h +++ b/doc/doxygen/headers/grid.h @@ -45,8 +45,8 @@ * allocates and manages degrees of freedom on vertices, faces, or cells, as * described by the finite element class. This separation makes it possible to * have multiple DoFHandler classes work on the same mesh at the same time. - * - * + * + * *

    Grid generation

    * * There are three ways to create a mesh: @@ -104,7 +104,7 @@ * The GridRefinement class implements a number of mesh refinement algorithms, * based on refinement indicators given to its member functions. * - * + * *

    Internal classes

    * * In addition to the above, there are a significant number of classes in this @@ -112,6 +112,6 @@ * handling. They are generally in the internal namespace, and not meant for * use in application code. * - * + * * @author Wolfgang Bangerth, 1998-2006 */ diff --git a/doc/doxygen/headers/hp.h b/doc/doxygen/headers/hp.h index 357a24f221..fdaf57a7a2 100644 --- a/doc/doxygen/headers/hp.h +++ b/doc/doxygen/headers/hp.h @@ -75,7 +75,7 @@ * for (unsigned int degree=1; degree<5; ++degree) * fe_collection.push_back (FE_Q(degree)); * @endverbatim - * + * * This way, one can add elements of polynomial degree 1 through 4 to the * collection. It is not necessary to retain the added object: the collection * makes a copy of it, it does not only store a pointer to the given finite diff --git a/doc/doxygen/headers/instantiations.h b/doc/doxygen/headers/instantiations.h index 3d61560783..17d558afe0 100644 --- a/doc/doxygen/headers/instantiations.h +++ b/doc/doxygen/headers/instantiations.h @@ -20,13 +20,13 @@ * Instantiation of complex class and function templates is expensive both in * terms of compile time and disk space. Therefore, we try to separate * declaration and implementation of templates as far as possible, and make - * sure that implementations are read by the compiler only when + * sure that implementations are read by the compiler only when * necessary. * * Template classes in deal.II can be grouped into three categories, * depending on the number of probable different instantiations. These three * groups are discussed in the following. - * + * * * @section Inst1 Known and fixed number of instantiations * @@ -50,7 +50,7 @@ * For these classes, adding instantiations for new parameters involves * changing the library. However, this is rarely needed, of course, unless you * are not content with computing only in 1d, 2d, or 3d. - * + * * * @subsection Inst1a Available instances * @@ -65,7 +65,7 @@ * stored values: we only support double, float, * and in some cases std::complex@ and * std::complex@. - * + * * * @section Inst2 A few instantiations, most of which are known * @@ -86,7 +86,7 @@ * interfaces, including vector types that are not part of the library but * possibly defined in an application program. In such a case, applications * can instantiate these templates by hand as described in the next section. - * + * * * @subsection Inst2c Creating new instances * @@ -106,7 +106,7 @@ * template class XXXX; * @endcode * - * + * * @subsection Inst2p Provided instances * * Like with the classes in section @ref Inst1, the instances provided in the diff --git a/doc/doxygen/headers/io.h b/doc/doxygen/headers/io.h index 1f7d712c1f..e93bc9932d 100644 --- a/doc/doxygen/headers/io.h +++ b/doc/doxygen/headers/io.h @@ -60,9 +60,9 @@ * itself), and it can create output used for visualization of data. Finally, * it can output matrices in a graphical format. * - * + * *

    Visualization of data

    - * + * * deal.II supports, through the DataOutBase class, a large number of popular * visualization formats, such as those used by the OpenDX, gmv, or gnuplot * programs. A complete list of supported formats is listed in the @@ -100,8 +100,8 @@ * dependent simulations in the space-time domain: it collects the results * from each time step and at the end outputs all of this information at once * as a space-time file. - * - * + * + * *

    Grid output

    * * Meshes, without any data vectors associated with it, can be written in a diff --git a/doc/doxygen/headers/mg.h b/doc/doxygen/headers/mg.h index 8f51f11c2a..c455f5df04 100644 --- a/doc/doxygen/headers/mg.h +++ b/doc/doxygen/headers/mg.h @@ -41,7 +41,7 @@ * * Finally, we have several auxiliary classes, namely MGLevelObject, * which stores an object on each level* - * + * * See the step-16, step-16b, and step-39 example programs on how to use this * functionality. diff --git a/doc/doxygen/headers/petsc.h b/doc/doxygen/headers/petsc.h index c2e3bdd0ee..89edd1ece0 100644 --- a/doc/doxygen/headers/petsc.h +++ b/doc/doxygen/headers/petsc.h @@ -17,7 +17,7 @@ /** * @defgroup PETScWrappers PETScWrappers - * + * * The classes in this module are * wrappers around functionality provided by the PETSc library. They provide a * modern object-oriented interface that is compatible with the interfaces of diff --git a/doc/doxygen/headers/physics.h b/doc/doxygen/headers/physics.h index 690d56e779..3bcad160e6 100644 --- a/doc/doxygen/headers/physics.h +++ b/doc/doxygen/headers/physics.h @@ -30,23 +30,23 @@ namespace Physics /** * Notations that reduce the order of tensors, effectively storing them in some - * sort of consistent compressed storage pattern. An example is storing the - * 6 independent components of $3\times 3$ symmetric tensors of rank 2 as a - * vector with 6 components, and then representing the 36 independent elements - * of symmetric $3\times 3 \times 3\times 3$ tensors of rank 4 (which when - * applied to a symmetric rank-2 tensor yields another symmetric rank-2 tensor) - * as a $6 \times 6$ matrix. + * sort of consistent compressed storage pattern. An example is storing the + * 6 independent components of $3\times 3$ symmetric tensors of rank 2 as a + * vector with 6 components, and then representing the 36 independent elements + * of symmetric $3\times 3 \times 3\times 3$ tensors of rank 4 (which when + * applied to a symmetric rank-2 tensor yields another symmetric rank-2 tensor) + * as a $6 \times 6$ matrix. * * Although this method of representing tensors is most regularly associated with * the efficient storage of the fourth-order elasticity tensor, with its - * generalization it has wider applicability. This representation is also common + * generalization it has wider applicability. This representation is also common * in the physics, material science and FEM literature. * * There are several variations of tensor notation, each a slightly different * structure. The primary difference between the various forms of tensor notation * is the weighting prescribed to the various elements of the compressed tensors. * This wikipedia article has + * href="https://en.wikipedia.org/wiki/Voigt_notation">wikipedia article has * some further general insights on this topic. * * @ingroup physics diff --git a/doc/doxygen/headers/quadrature.h b/doc/doxygen/headers/quadrature.h index 3bb247ad23..e5dcd2337f 100644 --- a/doc/doxygen/headers/quadrature.h +++ b/doc/doxygen/headers/quadrature.h @@ -30,9 +30,9 @@ * coordinate direction than in another) through the QAnisotropic class, as * well as the definition of quadrature formulas that are not tensor products. * - * + * *

    Use

    - * + * * Quadrature formulas are used, among other uses, when integrating matrix * entries and the components of the right hand side vector. To this end, the * quadrature point defined on the unit cell have to be mapped to the @@ -57,10 +57,10 @@ * quadrature points as mapped to a real cell, for other uses as well. This * can then be used, for example, to evaluate a right hand side function at * these points. - * + * * *

    QIterated

    - * + * * The class QIterated is used to construct an iterated quadrature formula out * of an existing one, thereby increasing the accuracy of the formula without * increasing the order. For example, by iterating the trapezoidal rule with diff --git a/doc/doxygen/headers/slepc.h b/doc/doxygen/headers/slepc.h index 4ec01a3a43..45326a4d68 100644 --- a/doc/doxygen/headers/slepc.h +++ b/doc/doxygen/headers/slepc.h @@ -17,7 +17,7 @@ /** * @defgroup SLEPcWrappers SLEPcWrappers - * + * * The classes in this module are wrappers around functionality * provided by the SLEPc library. All classes and functions in this * group reside in a namespace @p PETScWrappers. diff --git a/doc/doxygen/headers/trilinos.h b/doc/doxygen/headers/trilinos.h index cb4674fd94..61aa2d651f 100644 --- a/doc/doxygen/headers/trilinos.h +++ b/doc/doxygen/headers/trilinos.h @@ -17,7 +17,7 @@ /** * @defgroup TrilinosWrappers TrilinosWrappers - * + * * The classes in this module are wrappers around functionality * provided by the Trilinos library. They provide a modern * object-oriented interface that is compatible with the interfaces of diff --git a/doc/doxygen/headers/update_flags.h b/doc/doxygen/headers/update_flags.h index 08c8e05eff..2c27c9f24c 100644 --- a/doc/doxygen/headers/update_flags.h +++ b/doc/doxygen/headers/update_flags.h @@ -16,9 +16,9 @@ /** * @defgroup UpdateFlags The interplay of UpdateFlags, Mapping, and FiniteElement in FEValues - * + * *

    Introduction

    - * + * * In order to compute local contributions of an individual cell to the global * matrix and right hand side, we usually employ two techniques: * - First, the integral is transformed from the actual cell $K$ to the @@ -52,7 +52,7 @@ * @f] * where $q$ indicates the index of the quadrature point, $\hat{\bf x}_q$ its * location on the reference cell, and $w_q$ its weight. - * + * * In order to evaluate such an expression in an application code, we * have to access three different kinds of objects: a quadrature * object that describes locations $\hat{\bf x}_q$ and weights $w_q$ of @@ -61,7 +61,7 @@ * functions on the unit cell; and a mapping object that provides the * Jacobian as well as its determinant. Dealing with all these * objects would be cumbersome and error prone. - * + * * On the other hand, these three kinds of objects almost always appear together, * and it is in fact very rare for deal.II application codes to do anything with * quadrature, finite element, or mapping objects besides using them together. @@ -73,7 +73,7 @@ * points and weights, mapped shape function values and derivatives as well as * some properties of the transformation from the reference cell to the actual * mesh cell. - * + * * Since computation of any of these values is potentially expensive (for * example when using high order mappings with high order elements), the * FEValues class only computes what it is explicitly asked for. To this @@ -108,10 +108,10 @@ * property does not hold for the shape functions of Raviart-Thomas * elements, however, which must be rotated with the local cell). * This allows further optimization of the computations underlying assembly. - * + * * *

    Tracking dependencies

    - * + * * Let's say you want to compute the Laplace matrix as shown above. In that * case, you need to specify the update_gradients flag * (for $\nabla\varphi_i(\bf x_q)$) and the update_JxW_values @@ -120,7 +120,7 @@ * Jacobian matrix, $J^{-1}(\bf x_q)$ (and not just the determinant of the matrix), * and to compute the inverse of the Jacobian, it is also necessary to compute * the Jacobian matrix first. - * + * * Since these are requirements that are not important to the user, it * is not necessary to specify this in user code. Rather, given a set * of update flags, the FEValues object first asks the finite element @@ -144,15 +144,15 @@ * store some temporary information that can be computed once and for * all, and these flags will be used when re-computing data on each * cell we will visit later on. - * - * + * + * *

    Update once or each

    - * + * * As outlined above, we have now determined the final set of things that are * necessary to satisfy a user's desired pieces of information as conveyed by * the update flags they provided. This information will then typically be queried * on every cell the user code visits in a subsequent integration loop. - * + * * Given that many of the things mappings or finite element classes compute are * potentially expensive, FEValues employs a system whereby mappings and finite * element objects are encouraged to pre-compute information that can be computed @@ -170,7 +170,7 @@ * Jacobian of the mapping which depends on the geometry of the cell we visit; * thus, for this element, simply copying pre-computed information is not * sufficient to evaluate the values of shape functions on a particular cell.) - * + * * To accommodate this structure, both mappings and finite element classes * may internally split the update flags into two sets commonly referenced as * update_once and update_each (though these names @@ -183,23 +183,23 @@ * set update_once=update_values and * update_each=0, whereas the Raviart-Thomas element will * do it the other way around. - * + * * These sets of flags are intended to be mutually exclusive. There is, * on the other hand, nothing that ever provides this decomposition to * anything outside the mapping or finite element classes -- it is a purely * internal decomposition. - * - * + * + * *

    Generation of the actual data

    - * + * * As outlined above, data is computed at two different times: once at * the beginning on the reference cell, and once whenever we move to an * actual cell. The functions involved in each of these steps are * discussed next: - * - * + * + * *

    Initialization

    - * + * * Computing data on the reference cell before we even visit the first * real cell is a two-step process. First, the constructor of FEValues, * FEFaceValues and FESubfaceValues, respectively, need to allow the @@ -219,7 +219,7 @@ *
  • FiniteElement::get_face_data() *
  • FiniteElement::get_subface_data() * - * + * * The FEValues object then takes over ownership of these objects and will * destroy them at the end of the FEValues object's lifetime. After this, * the FEValues object asks the FiniteElement and Mapping objects to fill @@ -231,10 +231,10 @@ *
  • FEFaceValues::initialize() *
  • FESubfaceValues::initialize() * - * - * + * + * *

    Reinitialization for a mesh cell

    - * + * * Once initialization is over and we call FEValues::reinit, FEFaceValues::reinit * or FESubfaceValues::reinit to move to a concrete cell or face, we need * to calculate the "update_each" kinds of data. This is done in the following @@ -245,13 +245,13 @@ *
  • FESubfaceValues::reinit() calls Mapping::fill_fe_subface_values(), * then FiniteElement::fill_fe_subface_values() * - * + * * This is where the actual data fields for FEValues, stored in * internal::FEValues::MappingRelatedData and * internal::FEValues::FiniteElementRelatedData objects, are * computed. These functions call the function in Mapping first, such * that all the mapping data required by the finite element is * available. Then, the FiniteElement function is called. - * + * * @ingroup feall */ diff --git a/doc/doxygen/tutorial/CMakeLists.txt b/doc/doxygen/tutorial/CMakeLists.txt index 7f8264a417..105f027f5e 100644 --- a/doc/doxygen/tutorial/CMakeLists.txt +++ b/doc/doxygen/tutorial/CMakeLists.txt @@ -28,14 +28,14 @@ FILE(GLOB _deal_ii_steps # "/a/b/c/name//doc//author", so make sure we eat the # double slashes in the second step SET_IF_EMPTY(DEAL_II_CODE_GALLERY_DIRECTORY ${CMAKE_SOURCE_DIR}/code-gallery) -FILE(GLOB _code_gallery_names +FILE(GLOB _code_gallery_names "${DEAL_II_CODE_GALLERY_DIRECTORY}/*/doc/author") STRING(REGEX REPLACE "/+doc/+author" "" _code_gallery_names "${_code_gallery_names}") # # Define target for the tutorial. It depends on the # file tutorial.h built via the next target below, as well -# as the various files we create from the tutorial +# as the various files we create from the tutorial # directories below that. These dependencies are added # below the respective targets. # diff --git a/doc/external-libs/opencascade.html b/doc/external-libs/opencascade.html index cda262ac81..05817ef657 100644 --- a/doc/external-libs/opencascade.html +++ b/doc/external-libs/opencascade.html @@ -1,16 +1,16 @@ - + - - + + The deal.II Readme on interfacing to OpenCASCADE - - - + + + + -

    Installation of OpenCASCADE

    OpenCASCADE is a diff --git a/doc/external-libs/trilinos.html b/doc/external-libs/trilinos.html index e5e23743b9..5752cbb275 100644 --- a/doc/external-libs/trilinos.html +++ b/doc/external-libs/trilinos.html @@ -128,28 +128,28 @@

    BLAS and LAPACK

    - Note: At the time of writing (November 2016) Trilinos (at least up to - v12.8.1) cannot link against LAPACK 3.6.0 or later, due to two symbols - that were deprecated (and removed by default) in LAPACK 3.6.0 (see the + Note: At the time of writing (November 2016) Trilinos (at least up to + v12.8.1) cannot link against LAPACK 3.6.0 or later, due to two symbols + that were deprecated (and removed by default) in LAPACK 3.6.0 (see the - release notes). To fix this, edit the Trilinos file - packages/epetra/src/Epetra_LAPACK_wrappers.h and change the + release notes). To fix this, edit the Trilinos file + packages/epetra/src/Epetra_LAPACK_wrappers.h and change the lines 

    -    
+
     #define DGGSVD_F77  F77_BLAS_MANGLE(dggsvd,DGGSVD)
     #define SGGSVD_F77  F77_BLAS_MANGLE(sggsvd,SGGSVD)
    to 
    -    
+
     #define DGGSVD_F77  F77_BLAS_MANGLE(dggsvd3,DGGSVD3)
     #define SGGSVD_F77  F77_BLAS_MANGLE(sggsvd3,SGGSVD3)
    - before installing Trilinos. (Credit for this fix goes to + before installing Trilinos. (Credit for this fix goes to this page.)

    - +

    Trilinos sometimes searches for other libraries but can't find them if they are not in the usual directories or have other @@ -176,7 +176,7 @@ this page for Trilinos 11.8). Most of them are external packages to Trilinos and you will need to tell Trilinos configuration - scripts that you want to use them, for example via the + scripts that you want to use them, for example via the TrilinosWrappers::SolverDirect class. This can be tricky, but adding defines similar to the following to the cmake command line will achieve the goal to enable the UMFPACK and SuperLU/SuperLUDist diff --git a/doc/news/2.0.0-vs-3.0.0.h b/doc/news/2.0.0-vs-3.0.0.h index 75e7e7bcb1..4a260622a0 100644 --- a/doc/news/2.0.0-vs-3.0.0.h +++ b/doc/news/2.0.0-vs-3.0.0.h @@ -45,26 +45,26 @@ The library is written for research purposes and offers many features: refinement strategies based on local error indicators and error estimators.

    -

  • Support for a variety of finite elements, including Lagrange +

  • Support for a variety of finite elements, including Lagrange elements of order one through four, and discontinuous elements.

  • Extensive documentation: all documentation is available online in a - logical tree structure to allow fast access to the information you + logical tree structure to allow fast access to the information you need. If printed it comprises about 200 pages of tutorials, several reports, and far more than 1,000 pages of programming interface - documentation with explanations of all classes, functions, and + documentation with explanations of all classes, functions, and variables.

  • Modern software techniques that make access to the complex data - structures and algorithms as transparent as possible. The use of + structures and algorithms as transparent as possible. The use of object oriented programming allows for program structures similar to the structures in mathematical analysis.

  • Fast algorithms that enable you to solve problems with up to several - millions of degrees of freedom quickly. As opposed to programming + millions of degrees of freedom quickly. As opposed to programming symbolic algebra packages the penalty for readability is low.

    -

  • Support for several output formats, including some common formats +

  • Support for several output formats, including some common formats for visualization of scientific data.

  • Support for a variety of computer platforms, including multi- diff --git a/doc/news/3.0.0-vs-3.0.1.h b/doc/news/3.0.0-vs-3.0.1.h index 640dcf5540..c2e75f695a 100644 --- a/doc/news/3.0.0-vs-3.0.1.h +++ b/doc/news/3.0.0-vs-3.0.1.h @@ -33,7 +33,7 @@ All entries are signed with the names of the author.

  • Fix: getting the support points from system finite elements (class FESystem) resulted in an - exception. + exception.
    (WB 2000/05/10)

    @@ -46,7 +46,7 @@ All entries are signed with the names of the author.

  • - Fix: slight bug in + Fix: slight bug in DataOut::build_patches in multithreaded mode fixed.
    @@ -54,7 +54,7 @@ All entries are signed with the names of the author.

  • - Fix: + Fix: SparsityPattern::print_gnuplot wrote rows and columns exchanged. Since most matrices have symmetric sparsity patterns, this has gone unnoticed by now. @@ -63,8 +63,8 @@ All entries are signed with the names of the author.

  • - Fixed: the - common/scripts/make_dependencies.pl + Fixed: the + common/scripts/make_dependencies.pl script that sets up the dependencies for the make files had a problem when the path to the library included special characters such as `+'. This is now fixed. diff --git a/doc/news/3.0.0-vs-3.1.0.h b/doc/news/3.0.0-vs-3.1.0.h index 6634416153..2f0602b5f2 100644 --- a/doc/news/3.0.0-vs-3.1.0.h +++ b/doc/news/3.0.0-vs-3.1.0.h @@ -41,7 +41,7 @@ All entries are signed with the names of the author.

  • - New: In multithreading mode, the compile flags now also have + New: In multithreading mode, the compile flags now also have _REENTRANT defined. If this flag is defined, then the standard Unix headers also declare reentrant versions (with suffix _r) @@ -65,13 +65,13 @@ All entries are signed with the names of the author.

  • New: the step-9 example program is now ready, showing several advanced programming techniques in - deal.II. + deal.II.
    (WB 2000/07/18)

  • - Changed: deal.II now uses the + Changed: deal.II now uses the kdoc2 program to generate the API documentation. This makes up for much nices documentation and also works better than the previous kdoc1. @@ -92,8 +92,8 @@ All entries are signed with the names of the author.

  • - Fixed: the - common/scripts/make_dependencies.pl + Fixed: the + common/scripts/make_dependencies.pl script that sets up the dependencies for the make files had a problem when the path to the library included special characters such as `+'. This is now fixed. @@ -126,16 +126,16 @@ All entries are signed with the names of the author.

  • Improved: the configure script is now used to select the compiler options. Previously, selection - of compiler options was done both in + of compiler options was done both in configure as well as in the global - options Makefile + options Makefile common/Make.global_options.
    (WB 2000/06/02)

  • - Improved: Dependence on the files + Improved: Dependence on the files forward_declarations.h has been widely removed to improve compilation time
    @@ -144,7 +144,7 @@ All entries are signed with the names of the author.

  • - Fix: configure now uses + Fix: configure now uses config.guess to determine the operating system and hardware platform.
    @@ -186,7 +186,7 @@ All entries are signed with the names of the author. memory_consumption that returns an estimate of the amount of memory (in bytes) used up by this class. Supporting functions to compute the size of STL vectors - and other objects can be found the + and other objects can be found the MemoryConsumption namespace.
    (WB 2000/11/27) @@ -209,7 +209,7 @@ All entries are signed with the names of the author. faces in 3d computations).
    (WB 2000/09/07) -

    +

  • New: There is a new distance function @@ -217,9 +217,9 @@ All entries are signed with the names of the author. distance between two points.
    (Ralf Hartmann 2000/09/06) -

    +

    -

  • +

  • New: Timer now uses the system function getrusage (RUSAGE_CHILDREN, .) that is need in multithreading. But still the (Ralf Hartmann 2000/08/25) -

    +

  • New: There are now a set of functions @@ -236,10 +236,10 @@ All entries are signed with the names of the author. product of tensors.
    (WB 2000/07/23) -

    +

  • - New: The classes + New: The classes Patterns::Integer and Patterns::Double now allow that a range may be specified in which the parameter shall @@ -321,7 +321,7 @@ All entries are signed with the names of the author.

  • - New: There are now functions + New: There are now functions SparsityPattern::symmetrize and SparseMatrix::symmetrize that generate a symmetric matrix from a non-symmetric one. @@ -338,13 +338,13 @@ All entries are signed with the names of the author. (WB 2000/11/27)

    -

  • +

  • New: SparseMatrix::n_actually_nonzero_elements returns the number of entries that are actually nonzero.
    (Ralf Hartmann 2000/11/22) -

    +

  • Fixed: unlike announced in the docs, the @@ -353,7 +353,7 @@ All entries are signed with the names of the author. fixed now.
    (GK 2000/08/28) -

    +

  • Improved: PreconditionBlockSORSolverBicgstab::AdditionalData.
    (GK 2000/07/07) -

    +

  • New: SolverRichardson has a @@ -388,13 +388,13 @@ All entries are signed with the names of the author. (GK 2000/06/30)

    -

  • +

  • New: For recognizing a diverging solver before the maximum - number of steps is reached, - SolverControl returns + number of steps is reached, + SolverControl returns failure also if the residual increases over the start residual by a specific factor. This - factor is given to the SolverControl + factor is given to the SolverControl object by the set_failure_criterion function. After calling the latter function, checking of this additional failure criterion may again be disabled by calling @@ -429,7 +429,7 @@ All entries are signed with the names of the author.

  • - Fix: + Fix: SparsityPattern::print_gnuplot wrote rows and columns exchanged. Since most matrices have symmetric sparsity patterns, this has gone unnoticed by now. @@ -438,7 +438,7 @@ All entries are signed with the names of the author.

  • - Fix: the + Fix: the FullMatrix::Tvmult function suffered from the same problems as the FullMatrix::Tmmult function. This @@ -464,10 +464,10 @@ All entries are signed with the names of the author.

  • New: BlockIndices: Class that manages the conversion of global indices into a block - vector/matrix/... to the indices local to each of the blocks. + vector/matrix/... to the indices local to each of the blocks.
    (WB 2000/05/08) -

    +

  • New: BlockSparsityPattern and @@ -475,23 +475,23 @@ All entries are signed with the names of the author. represent matrices that are composed of sparse matrices.
    (WB 2000/05/08) -

    +

  • - Fix: the + Fix: the FullMatrix::mmult and FullMatrix::Tmmult code don't resize their output argument any more, as this is not common - style in the library. Furthermore, + style in the library. Furthermore, FullMatrix::Tmmult was utterly - broken. + broken.
    (WB 2000/05/08)

  • Change: the matrix_norm functions - of sparse and full matrices are renamed to + of sparse and full matrices are renamed to matrix_norm_square, since they in fact return the square of the norm. This should avoid confusion in some cases. @@ -500,7 +500,7 @@ All entries are signed with the names of the author.

  • - Fix: the ``copy-like'' constructor of + Fix: the ``copy-like'' constructor of SparsityPattern that copies another object and adds some off-diagonals had a bug that caused an exception in some cases. This is now fixed. @@ -519,7 +519,7 @@ All entries are signed with the names of the author.

  • - New: there are now functions Vector::swap + New: there are now functions Vector::swap and BlockVector::swap, as well as global functions swap(u,v) that exchange the data of two vectors without needing a temporary @@ -537,7 +537,7 @@ All entries are signed with the names of the author.

  • Change: the solver classes in LAC lost their first template - argument. Their names are now + argument. Their names are now SolverXX<VECTOR>, where XX denotes the name of the solver (e.g. CG, GMRES, etc). Furthermore, the @@ -587,17 +587,17 @@ All entries are signed with the names of the author.

  • Extend: DoFTools::extract_boundary_dofs now allows to also specify which boundary conditions shall be - considered. + considered.
    (WB 2000/12/04)

  • - New: some arguments of the functions + New: some arguments of the functions DoFHandler::n_boundary_dofs, DoFTools::extract_boundary_dofs, and - DoFTools::map_dof_to_boundary_indices + DoFTools::map_dof_to_boundary_indices are changed from list to set, since that resembles more closely the purpose of the parameter, and makes computations @@ -655,9 +655,9 @@ All entries are signed with the names of the author. class can handle boundary information in 3d as well (i.e. lines and quads in 3d with special material IDs).
    - (Michael + (Michael Stadler 2000/10/11) -

    +

  • Extended: The GridIn @@ -666,7 +666,7 @@ All entries are signed with the names of the author.
    (Michael Stadler 2000/10/11) -

    +

  • New: The GridRefinement::refine_and_coarsen_optimize @@ -674,7 +674,7 @@ All entries are signed with the names of the author. refinement and coarsening.
    (Thomas Richter 2000/10/10) -

    +

  • Extended: The GridIn::delete_unused_vertices @@ -688,14 +688,14 @@ All entries are signed with the names of the author. to the triangulation object.
    (WB 2000/09/26) -

    +

  • New: The GridIn class can now read the basics of grids in DB Mesh format.
    (WB 2000/09/26) -

    +

  • Extended: The KellyErrorEstimator @@ -704,7 +704,7 @@ All entries are signed with the names of the author. DoFHandler object.
    (WB 2000/09/11) -

    +

  • New: The DataOut_Faces class allows to @@ -713,10 +713,10 @@ All entries are signed with the names of the author. cuts through the domain.
    (WB 2000/09/07) -

    +

  • - Removed: The + Removed: The DataOut_Old class has finally gone for good. It was already deprecated in version 3.0, and has been superceded for a long time by the framework of classes around @@ -738,7 +738,7 @@ All entries are signed with the names of the author.

  • - Changed: The + Changed: The map_dof_to_boundary_index functions have been moved from the DoFHandler to the DoFTools class, in order to @@ -817,7 +817,7 @@ All entries are signed with the names of the author. were dormant, since the values of finite elements are always computed for the presently available Lagrange elements, but would have been activated once there are other classes of - elements. + elements.
    (Ralf Hartmann 2000/07/20)

    @@ -840,7 +840,7 @@ All entries are signed with the names of the author.
    (GK 2000/07/12)

    - +

  • New: The new function get_face of FEFaceValues and

  • - Fix: slight bug in + Fix: slight bug in DataOut::build_patches in multithreaded mode fixed.
    @@ -883,7 +883,7 @@ All entries are signed with the names of the author.

    - Removed: The obsolete + Removed: The obsolete MatrixCreator::create_interpolation_matrix function is now removed.

    @@ -916,14 +916,14 @@ All entries are signed with the names of the author.

  • - Changed: enum - MeshSmoothing is moved into the + Changed: enum + MeshSmoothing is moved into the Triangulation class.
    (Ralf Hartmann 2000/05/18)

    -

  • +

  • New: Triangulation::patch_level_1 is a new mesh smoothing. A mesh of patch level 1 consists of patches, i.e. they consists of cells that are all refined at @@ -941,14 +941,14 @@ All entries are signed with the names of the author.

  • - Changed: the + Changed: the MatrixTools::apply_boundary_values now uses a much faster algorithm when working on matrices with symmetric sparsity patterns. On the other hand, it does no more eliminate whole rows when a matrix has a non-symmetric sparsity pattern, or if the user (through a new flag) tells the function that this is not necessary, for example if the matrix itself is - non-symmetric. + non-symmetric.

    @@ -997,40 +997,40 @@ All entries are signed with the names of the author.

  • - Changed: The computation of the Jacobian matrices in the + Changed: The computation of the Jacobian matrices in the FEValues class is now done more efficiently. The speedup is in the range of a factor of 40 for - 3D. + 3D.
    (John Burnell, WB 2000/05/16)

    -

  • +

  • Change: DoFTools::make_hanging_node_constraints () does not use the user flags any more, and can thus run in - parallel more than once. + parallel more than once.
    (WB 2000/05/15)

    -

  • +

  • Extended: DoFTools::make_sparsity_pattern () now accepts a template parameter as sparsity pattern. This - allows to use this function for the usual - SparsityPattern, or for + allows to use this function for the usual + SparsityPattern, or for BlockSparsityPattern arguments.
    (WB 2000/05/15)

    -

  • +

  • New: DoFTools::extract_hanging_node_dofs () identifies nodes that will be constrained by hanging node constraints.
    (WB 2000/05/12)

    -

  • +

  • New: DoFRenumbering::sort_selected_dofs_back () sorts selected degrees of freedom to the end of the index range. @@ -1038,7 +1038,7 @@ All entries are signed with the names of the author. (WB 2000/05/12)

    -

  • +

  • Change: the return value of DoFHandler::max_couplings_between_dofs () is bounded by DoFHandler::n_dofs(). @@ -1046,23 +1046,23 @@ All entries are signed with the names of the author. (Ralf Hartmann 2000/05/11)

    -

  • +

  • New: FEValuesBase::get_cell () returns present cell.
    (Ralf Hartmann 2000/05/11)

    -

  • +

  • Fix: FESystem::reinit() generated - an exception if update_support_points + an exception if update_support_points was set.
    (WB 2000/05/10)

    -

  • - New: IntergridMap::get_{source,destination}_grid +

  • + New: IntergridMap::get_{source,destination}_grid functions return the grids for which the map was created.
    (WB 2000/04/19) @@ -1077,7 +1077,7 @@ All entries are signed with the names of the author.

  • - New: DoFTools::extract_boundary_dofs + New: DoFTools::extract_boundary_dofs finds all degrees of freedom which are at the boundary and belong to specified components.
    @@ -1085,7 +1085,7 @@ All entries are signed with the names of the author.

  • - New: DoFTools::compute_intergrid_constraints + New: DoFTools::compute_intergrid_constraints allows to use different discretization grids for different variables.
    @@ -1095,7 +1095,7 @@ All entries are signed with the names of the author.

  • New: DataOut::clear_data_vectors allows to re-use an object without deleting the DoFHandler. + class="class">DoFHandler.
    (GK 2000/04/05)

    diff --git a/doc/news/3.1.0-vs-3.1.1.h b/doc/news/3.1.0-vs-3.1.1.h index 8b4e81ec2a..8567aa77e0 100644 --- a/doc/news/3.1.0-vs-3.1.1.h +++ b/doc/news/3.1.0-vs-3.1.1.h @@ -51,9 +51,9 @@ All entries are signed with the names of the author.
    (Oliver Rheinbach 2001/04/12)

    - +

  • - Fixed: When using Neuman boundary functions in the + Fixed: When using Neuman boundary functions in the KellyErrorEstimator class, it was assumed that the function object had Function::vector_value overloaded, even @@ -62,7 +62,7 @@ All entries are signed with the names of the author.
    (WB 2001/04/09)

    - +

  • New/Fixed: Now there exists a new Triangulation:: (RH 2001/04/03)

    - +

  • Fixed: Missing ucd is now added to the list of supported output formats returned by -

  • +

  • Removed: The explicit instantiations of SparseMatrix<long double> are removed as a prerelease of gcc3.0 fails to compile it. Now the user of deal.II/include/grid/tria_accessor.templates.h (which contains some inline functions for triangulation - accessor classes) into + accessor classes) into deal.II/include/grid/tria_accessor.h to work around a problem with gcc3.0 which does not place a copy of these functions into the library. Previously we only included diff --git a/doc/news/3.1.0-vs-3.2.0.h b/doc/news/3.1.0-vs-3.2.0.h index 2ab8e870dd..d606024707 100644 --- a/doc/news/3.1.0-vs-3.2.0.h +++ b/doc/news/3.1.0-vs-3.2.0.h @@ -91,7 +91,7 @@ All entries are signed with the names of the author.

  • New Design of FiniteElements and Mappings - +

    New: The finite element classes have been redesigned from scratch to allow also @@ -102,7 +102,7 @@ All entries are signed with the names of the author. to higher degree.

    -

    +

    Furthermore we have totally reimplemented the mapping between unit and real cell. In future we won't be restricted to Q1 mapping any more, but we will have @@ -141,8 +141,8 @@ All entries are signed with the names of the author.

  • - New: There is now some support to include and use routines from the - Harwell Subroutine Library.
    (WB 2001/01/30) @@ -165,14 +165,14 @@ All entries are signed with the names of the author.

    base

      -

    1. +

    2. New: Color function DataOutBase::EpsFlags::reverse_grey_scale_color_function.
      (WB 2001/08/24)

      -

    3. +

    4. New: Function QProjector::project_to_child generates quadrature formulae which act on the area which a child would occupy. @@ -191,7 +191,7 @@ All entries are signed with the names of the author. (WB 2001/07/18)

      -

    5. +

    6. New: classes FourierSineFunction and FourierCosineFunction, resembling one mode of a Fourier decomposition. Classes Vector and BlockVector now have member functions operator*= which scale the vectors - by a constant factor. These functions are aliases for the + by a constant factor. These functions are aliases for the scale member functions except that they return a reference to themselves.
      @@ -423,8 +423,8 @@ All entries are signed with the names of the author.

    7. - New: There is now a function - FullMatrix::precondition_Jacobi. The + New: There is now a function + FullMatrix::precondition_Jacobi. The PreconditionJacobi class is therefore now also applicable with the full matrix class.
      @@ -476,13 +476,13 @@ All entries are signed with the names of the author.

    8. - New: There are now functions + New: There are now functions SparsityPattern::copy_from and SparseMatrix::copy_from that can be used to construct sparsity patterns and matrix at once, i.e. without setting up a sparsity pattern element by element, possibly after using a way too large value for the - maximal row length, then calling + maximal row length, then calling SparsityPattern::compress etc.
      (WB 2001/05/07) @@ -542,7 +542,7 @@ All entries are signed with the names of the author. (GK 2001/03/29)

      -

    9. +

    10. New: The functions FullMatrix::mmult and Tmmult now have an additional @@ -561,7 +561,7 @@ All entries are signed with the names of the author. New: class SchurMatrix implements a Schur complement for block matrices. It provides matrix-vector multiplication suitable for iterative methods as well as pre- and - post-processing of right hand side and slution, respectively. + post-processing of right hand side and slution, respectively.
      (GK 2001/03/22)

      @@ -578,8 +578,8 @@ All entries are signed with the names of the author.
      (RH 2001/03/14)

      - -

    11. + +

    12. New: class BlockMatrixArray<MATRIX> implements a block matrix based on an array of matrix pointers. Since this @@ -590,10 +590,10 @@ All entries are signed with the names of the author.

    13. - New: There is now some support to include and use routines from the - Harwell Subroutine Library, and support - classes + classes SparseDirectMA27 and SparseDirectMA47 for the sparse direct solvers MA27 and MA47. @@ -608,28 +608,28 @@ All entries are signed with the names of the author.

      deal.II

        -

      1. +

      2. New: Class MappingQ1Eulerian implementing an Eulerian mapping.
        (Michael Stadler 2001/09/24)

        -

      3. +

      4. New: VectorTools::create_boundary_right_hand_side integrates boundary forces for inhomogeneous Neumann boundary values.
        (WB 2001/09/13)

        -

      5. +

      6. New: DoFTools::make_flux_sparsity_pattern now exists also for 1d.
        (WB 2001/09/03)

        -

      7. +

      8. New: There are now two functions FETools::hierarchic_to_lexicographic_numbering @@ -641,7 +641,7 @@ All entries are signed with the names of the author. (WB 2001/08/31)

        -

      9. +

      10. New: ConstraintMatrix::close now simply returns instead of throwing an exception, if the matrix was already closed. @@ -694,7 +694,7 @@ All entries are signed with the names of the author. New: Implement DoFTools::make_sparsity_pattern, DoFTools::make_boundary_sparsity_pattern, - and + and ConstraintMatrix::condense to work on the CompressedSparsityPattern and CompressedBlockSparsityPattern and @@ -787,7 +787,7 @@ All entries are signed with the names of the author.

      11. New: There are now functions DoFTools::map_dofs_to_support_points and + class="member">map_dofs_to_support_points and DoFTools::map_support_points_to_dofs that @@ -826,7 +826,7 @@ All entries are signed with the names of the author.
        (Roger Young 2001/04/12)

        - +

      12. Fixed: the DoFRenumbering:: (Oliver Rheinbach 2001/04/12)

        - +

      13. Changed: A typedef FunctionMap was declared in at least four places previously (in classes (WB 2001/04/09)

        - +

      14. - Fixed: When using Neuman boundary functions in the + Fixed: When using Neuman boundary functions in the KellyErrorEstimator class, it was assumed that the function object had Function:: (WB 2001/04/09)

        - +

      15. New: The various MatrixCreator:: (WB 2001/04/08)

        - +

      16. New: The following functions are extended to work on arbitrary mappings: @@ -903,7 +903,7 @@ All entries are signed with the names of the author.

        All these functions now take a Mapping object as additional argument. -
        +
        For backward compatibility there exist second versions of each of these functions that still don't have a Mapping argument. These functions @@ -941,7 +941,7 @@ All entries are signed with the names of the author.
        (RH 2001/04/04)

        - +

      17. New/Fixed: Now there exists a new Triangulation:: (RH 2001/04/03)

        - +

      18. Fixed: Missing ucd is now added to the list of supported output formats returned by

        Removed: the ProblemBase class, - which has been deprecated since before the release of + which has been deprecated since before the release of deal.II 3.0, has finally been removed. The same applies for the classes Assembler, @@ -1011,7 +1011,7 @@ All entries are signed with the names of the author. the class VectorTools are extended to work on arbitrary mappings. All these functions now take a Mapping object as additional - argument. + argument.
        For backward compatibility there exist second versions of each of these functions that still don't have a -

      19. +

      20. Removed: The function FiniteElement<dim>::get_support_points @@ -1096,7 +1096,7 @@ All entries are signed with the names of the author. (RH 2001/03/14)

        -

      21. +

      22. New: The class Boundary has two new functions get_intermediate_points_on_line and (RH 2001/03/14)

        - +

      23. Changed: We now unconditionally include deal.II/include/grid/tria_accessor.templates.h (which contains some inline functions for triangulation - accessor classes) into + accessor classes) into deal.II/include/grid/tria_accessor.h to work around a problem with gcc3.0 which does not place a copy of these functions into the library. Previously we only included @@ -1205,7 +1205,7 @@ All entries are signed with the names of the author. (WB 2001/02/26)

        -

      24. +

      25. New: The DoFTools class now has a function count_dofs_per_component that counts the number of degrees of freedom in each of the diff --git a/doc/news/3.2.0-vs-3.3.0.h b/doc/news/3.2.0-vs-3.3.0.h index b4099005ed..e412f1a6b7 100644 --- a/doc/news/3.2.0-vs-3.3.0.h +++ b/doc/news/3.2.0-vs-3.3.0.h @@ -27,7 +27,7 @@ All entries are signed with the names of the author.

        1. - New: Output for + New: Output for Tecplot has been added. It can be used by choosing output format «tecplot».
          @@ -51,7 +51,7 @@ All entries are signed with the names of the author.

        2. - New: Output for + New: Output for OpenDX has been added. It can be used by choosing output format «dx» (not yet for grid output). The data format is very basic now, but it @@ -280,7 +280,7 @@ All entries are signed with the names of the author.

        3. New: the SparseDirectMA27/47 classes now provide access to Mutex locks for external - synchronisation. + synchronisation.
          (WB 2001/11/14)

          @@ -468,12 +468,12 @@ All entries are signed with the names of the author. class="member">GridRefinement::refine_fixed_fraction           function sometimes had problems when indicators vary over several orders of magnitude, due to roundoff. This is now - fixed. + fixed.
          (WB 2001/11/05)

          -

        4. +

        5. New: DoFTools::extract_subdomain_dofs selects those degrees of freedom which are located on cells with a diff --git a/doc/news/3.3.0-vs-3.3.1.h b/doc/news/3.3.0-vs-3.3.1.h index ab54211aee..0461dd1657 100644 --- a/doc/news/3.3.0-vs-3.3.1.h +++ b/doc/news/3.3.0-vs-3.3.1.h @@ -23,20 +23,20 @@ All entries are signed with the names of the author.

            -

          1. +

          2. Fixed: In 3d, the function DoFTools::make_hanging_node_constraints + class="member">DoFTools::make_hanging_node_constraints contained an assertion that failed erroneously for finite elements that do not have degrees of freedom on vertices. This is now fixed. -
            +
            (WB 2002/02/21)

          3. Fixed: TriaAccessor<3,3>::measure sometimes computed a negative value. This is now fixed. -
            +
            (WB 2002/02/21)

          diff --git a/doc/news/3.3.0-vs-3.4.0.h b/doc/news/3.3.0-vs-3.4.0.h index be61e98123..88752eac12 100644 --- a/doc/news/3.3.0-vs-3.4.0.h +++ b/doc/news/3.3.0-vs-3.4.0.h @@ -55,14 +55,14 @@ All entries are signed with the names of the author. (BK 2002/05/22)

          -

        6. +

        7. New: The step-14 example program demonstrates duality based error estimators and some more software design concepts.
          (WB 2002/05/05)

          -

        8. +

        9. New: In all previous versions, deal.II used the ACE (Adaptive Communications Environment) @@ -72,13 +72,13 @@ All entries are signed with the names of the author. available on many systems. The relieves you from the need of installing a huge library of which the most part is not used anyway. However, if you use ACE for other reasons, then it is - still supported. For installation instructions, see the + still supported. For installation instructions, see the ReadMe file.
          (WB 2002/04/30)

          -

        10. +

        11. Changed: The Makefiles for the library are now truly parallel. To this end, the automatic generation of the files forward_declarations.h in the various directories had @@ -94,14 +94,14 @@ All entries are signed with the names of the author. (GK 2002/04/17)

          -

        12. +

        13. New: The step-13 example program tells you something about software design things for finite element programs.
          (WB 2002/04/16)

          -

        14. +

        15. Changed: Due to problems with undeclared functions and general compatibility concerns, -ansi is now no more part of the compile flags for gcc. @@ -109,7 +109,7 @@ All entries are signed with the names of the author. (WB 2002/04/16)

          -

        16. +

        17. Fixed: Explicit specializations of member templates are now conforming to the C++ standard. While most compilers accepted the previous form, Sun's Forte compiler wants a strictly @@ -118,7 +118,7 @@ All entries are signed with the names of the author. (WB 2002/03/25)

          -

        18. +

        19. Fixed: For gcc versions that used ostrstream instead of ostringstream, it was necessary to append @@ -129,23 +129,23 @@ All entries are signed with the names of the author. (WB 2002/03/13)

          -

        20. +

        21. Changed: The configure machinery has been revamped significantly.
          (WB 2002/03/08)

          -

        22. +

        23. Added: The top-level Makefile now supports "optimized" as a target that builds only optimized versions of the base, lac, 1d, 2d, and 3d - libraries. + libraries.
          (BK 2002/02/19)

          -

        24. +

        25. Changed: The build system was entirely revised. Object files in debug mode now have the suffix .g.o instead of .go. All object files from the @@ -163,17 +163,17 @@ All entries are signed with the names of the author.

          base

            -

          1. +

          2. New: The vector2d row accessor classes now have member functions begin and end which allow iterating over the elements of a row of such an - object. + object.
            (WB 2002/05/30)

            -

          3. +

          4. New: The Legendre and LagrangeEquidistant classes now have static member functions -

          5. +

          6. Changed: The Polynomial and LagrangeEquidistant classes have lost their default constructor, as that did not make much sense @@ -194,7 +194,7 @@ All entries are signed with the names of the author. (WB 2002/05/27)

            -

          7. +

          8. Fixed: When forward declaring the Tensor class, we now also forward declare its partial specialization for a rank one tensor. Not doing so @@ -203,7 +203,7 @@ All entries are signed with the names of the author. (WB 2002/03/22)

            -

          9. +

          10. Fixed: The class TensorFunction now uses local types value_type and gradient_type as return values of @@ -213,7 +213,7 @@ All entries are signed with the names of the author. (WB 2002/03/20)

            -

          11. +

          12. Improved: The AssertThrow macro now uses __builtin_expect if the compiler supports this. This indicates to the compiler that we @@ -234,7 +234,7 @@ All entries are signed with the names of the author. (i.e. like to a two-dimensional C-style array).
            (WB 2002/03/08) -

            +

          13. Changed: The function MultithreadInfo:: @@ -242,9 +242,9 @@ All entries are signed with the names of the author. of CPUs when running on Silicon Graphics.
            (BK 2002/02/19) -

            +

            -

          14. +

          15. Changed: The quite logorrhoeic function name TensorProductPolynomials::n_tensor_product_polynomials was changed to @@ -254,7 +254,7 @@ All entries are signed with the names of the author. (GK 2002/02/11)

            -

          16. +

          17. New: The class PolynomialSpace implements the space of polynomials at most a certain degree in arbitrary space dimensions. @@ -262,7 +262,7 @@ All entries are signed with the names of the author. (GK 2002/02/11)

            -

          18. +

          19. New: The function DataOutBase:: write_tecplot_binary has been added. This function will write Tecplot binary files if the @@ -296,7 +296,7 @@ All entries are signed with the names of the author. (GK 2002/05/24)

            -

          20. +

          21. New: Function SparsityPattern::matrix_position is the inverse function for -

          22. +

          23. New: Functions SparsityPattern::copy_from and SparseMatrix::copy_from allow to copy a full @@ -321,7 +321,7 @@ All entries are signed with the names of the author.

            deal.II

              -

            1. +

            2. New: The GeometryInfo class now provides two methods, unit_cell_vertex and -

            3. +

            4. New: The GridOut:: write_dx function is now implemented. It allows to write the mesh (cells and faces) with some additional @@ -341,7 +341,7 @@ All entries are signed with the names of the author. (GK 2002/05/02)

              -

            5. +

            6. Fixed: The IteratorState::IteratorState enum is now called IteratorState::IteratorStates. This works @@ -352,27 +352,27 @@ All entries are signed with the names of the author. (WB 2002/03/20)

              -

            7. +

            8. Fixed: In 3d, the function DoFTools::make_hanging_node_constraints + class="member">DoFTools::make_hanging_node_constraints contained an assertion that failed erroneously for finite elements that do not have degrees of freedom on vertices. This is now fixed. -
              +
              (WB 2002/02/21)

              -

            9. +

            10. Fixed: TriaAccessor<3,3>::measure sometimes computed a negative value. This is now fixed. -
              +
              (WB 2002/02/21)

              -

            11. +

            12. New: Finite element family with complete polynomial spaces for discontinuous Galerkin: FE_DGP -
              +
              (GK 2002/02/11)

            diff --git a/doc/news/3.4.0-vs-4.0.0.h b/doc/news/3.4.0-vs-4.0.0.h index ce73c93c87..d232304d95 100644 --- a/doc/news/3.4.0-vs-4.0.0.h +++ b/doc/news/3.4.0-vs-4.0.0.h @@ -28,7 +28,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK

            General

              -

            1. +

            2. 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, @@ -50,7 +50,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/02/06)

              -

            3. +

            4. 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 @@ -60,7 +60,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK 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. @@ -68,7 +68,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/02/06)

              -

            5. +

            6. 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 @@ -82,7 +82,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/02/02)

              -

            7. +

            8. 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 @@ -93,15 +93,15 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/02/02)

              -

            9. - Fixed: Some of the formulas in the step-14 tutorial were obviously +

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

              -

            11. - Changed: The main Makefile has been changed to sequentialize building +

            12. + 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. @@ -109,14 +109,14 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/01/24)

              -

            13. - New: Changes have been made to support compiling and using +

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

              -

            15. +

            16. Removed: Thread support now relies solely on the use of POSIX functions. The use of the ACE @@ -128,7 +128,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/01/11)

              -

            17. +

            18. 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. @@ -136,7 +136,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/12/18)

              -

            19. +

            20. 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 @@ -152,13 +152,13 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/12/05)

              -

            21. +

            22. 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 + 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 @@ -171,7 +171,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/11/14)

              -

            23. +

            24. 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 @@ -181,7 +181,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/11/11)

              -

            25. +

            26. 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. @@ -189,7 +189,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/10/14)

              -

            27. +

            28. 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 @@ -203,10 +203,10 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK set.
              (Stephen Kolaroff, WB - 2002/09/28) + 2002/09/28)

              -

            29. +

            30. 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), @@ -219,7 +219,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/09/12)

              -

            31. +

            32. New: base/config.h now exports the deal.II base directory through the DEAL_II_PATH preprocessor variable. @@ -227,7 +227,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/09/09)

              -

            33. +

            34. 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 @@ -254,15 +254,15 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/09/05)

              -

            35. +

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

              @@ -286,7 +286,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/06/10)

              -

            37. +

            38. 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 @@ -299,7 +299,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/06/10)

              -

            39. +

            40. New: The top-level makefile now how a target distclean. clean leaves the libraries now, removing everything that is not needed to use @@ -353,7 +353,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/02/13)

              -

            41. +

            42. 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 @@ -362,7 +362,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/02/06)

              -

            43. +

            44. 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 @@ -371,7 +371,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/01/28)

              -

            45. +

            46. Fixed: The PosixThreadManager called its wait function in the destructor. If this had been called before already, then the @@ -384,7 +384,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (Michael Anderson, WB 2003/01/16)

              -

            47. +

            48. 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 @@ -395,7 +395,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/01/11)

              -

            49. +

            50. 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 @@ -408,7 +408,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (Michael Anderson, WB 2003/01/11)

              -

            51. +

            52. New: There are now classes ThreadCondition that implement thread condition variable operations through POSIX functions (in multithreaded mode) or doing nothing (in singlethreaded @@ -417,7 +417,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/01/11)

              -

            53. +

            54. 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 @@ -431,7 +431,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/12/19)

              -

            55. +

            56. 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. @@ -439,7 +439,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/11/29)

              -

            57. +

            58. Changed: In POSIX mode, when the ThreadManager class created a new thread through pthread_create, it only checked for the @@ -453,7 +453,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/11/13)

              -

            59. +

            60. Fixed: The write_text and write_tex functions of the TableHandler class now check whether their @@ -463,7 +463,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (RH 2002/11/11)

              -

            61. +

            62. 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. @@ -515,7 +515,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (RH 2002/09/24)

              -

            63. +

            64. 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 @@ -531,7 +531,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (GK 2002/09/08)

              -

            65. +

            66. Extended: Previously, the Threads::PosixThreadBarrier class could not be used at all (they threw exceptions), if your system @@ -545,7 +545,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/09/05)

              -

            67. +

            68. 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 @@ -558,14 +558,14 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/09/03)

              -

            69. +

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

              -

            71. +

            72. New: Row accessors for the vector2d class now have a member function size that returns the size of the row, @@ -574,7 +574,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/07/24)

              -

            73. +

            74. 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 @@ -584,7 +584,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/07/24)

              -

            75. +

            76. 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. @@ -592,7 +592,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/07/24)

              -

            77. +

            78. New: There are now operators to allow multiplication and division of Tensor objects by scalar factors. @@ -607,22 +607,22 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK

              lac

                -

              1. New: Function +

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

                +

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

                +

              4. Deprecated: The functions Vector::scale and BlockVector::scale are now deprecated @@ -630,7 +630,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK operator/= instead.
                (WB 2003/05/31) -

                +

              5. New: Vector, BlockVector and @@ -638,7 +638,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK for scaling by a scalar.
                (WB 2003/05/31) -

                +

              6. New: PointerMatrix now has empty() function, which returns true if the pointer is @@ -699,7 +699,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/02/13)

                -

              7. +

              8. New: The SolverGMRES now accepts an AdditionalData parameter use_default_residual whose default is @@ -714,7 +714,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (RH 2003/01/31)

                -

              9. +

              10. New: FullMatrix has a function copy_from, copying from sparse matrices. It uses iterators of the sparse matrix classes. @@ -743,7 +743,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK
                (Stephen Kolaroff 2002/11/27)

                - +

              11. Changed: In multithread mode, the SparseMatrix would spawn @@ -757,9 +757,9 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK
                (WB 2002/11/13)

                - +

              12. - Fixed: In the SparseDirectMA27 class, wrapping + 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. @@ -776,7 +776,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK 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 + as you want. For more information, read the documentation of the SparseDirectMA27 class.
                (WB 2002/09/25) @@ -814,7 +814,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK

              13. New: Classes SparsityPattern and SparseMatrix now have functions 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. @@ -830,7 +830,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (GK 2002/08/13)

                -

              14. +

              15. New: a way of using abstract base classes for matrices has been implemented with PointerMatrixBase and PointerMatrix. Storing a matrix in @@ -867,7 +867,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK to the child cell; child_to_cell_coordinates that does exactly the opposite; and is_inside_unit_cell that tells whether a + class="member">is_inside_unit_cell that tells whether a given point is inside the unit cell.
                (WB 2003/05/01) @@ -960,7 +960,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/02/21)

                -

              16. +

              17. Changed: Some implementation details of the GridReordering class have been moved to a namespace internal. @@ -989,7 +989,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK

              18. - Fixed: Objects of type FESystem + 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 @@ -1010,7 +1010,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (RH 2003/02/03)

                -

              19. +

              20. 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. @@ -1018,7 +1018,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/01/28)

                -

              21. +

              22. Changed: The FEValues::get_cell and FEValues::get_face functions have been removed, since they limited our ability to use this @@ -1028,7 +1028,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/01/17)

                -

              23. +

              24. 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 @@ -1039,22 +1039,22 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2003/01/10)

                -

              25. - New: Checked in new GridGenerator +

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

                -

              27. +

              28. New: Checked in new class FE_Q_Hierarchical - derived from class FiniteElement. - This element is analogous to FE_Q, but - makes use of hierarchical shape functions, based on the - Polynomials::Hierarchical class. + derived from class FiniteElement. + This element is analogous to FE_Q, but + makes use of hierarchical 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 @@ -1062,35 +1062,35 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK 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/include/fe/fe_q_hierarchical.h and deal.II/source/fe/fe_q_hierarchical.cc.
                (Brian Carnes 2002/12/13)

                -

              29. +

              30. 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 + composed element thus does not fill the array the get_unit_support_points function returns.
                (WB 2002/11/23)

                -

              31. +

              32. 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. + requirement.
                (WB 2002/10/28)

                -

              33. +

              34. Fixed: The DoFRenumbering::component_wise function accepts a parameter indicating the order in which the degrees of freedom @@ -1101,7 +1101,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/10/17)

                -

              35. +

              36. New: The FiniteElement::system_to_base_index function now exports the values of the -

              37. +

              38. New: The FiniteElement::element_multiplicity function was previously only available in the FESystem @@ -1123,7 +1123,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/10/17)

                -

              39. +

              40. 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 @@ -1135,7 +1135,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/10/10)

                -

              41. +

              42. 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 @@ -1166,16 +1166,16 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (GK 2002/09/19)

                -

              43. +

              44. 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. + fixed.
                (WB 2002/09/19)

                -

              45. +

              46. Removed: The FiniteElement::component_to_system_index function and its counterpart for faces is gone. This data did not make much sense @@ -1187,7 +1187,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/09/16)

                -

              47. +

              48. Changed: The FiniteElement::restriction_is_additive function used to take an argument that denoted the vector component of a finite @@ -1201,14 +1201,14 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/09/16)

                -

              49. +

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

                -

              51. +

              52. 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. @@ -1216,7 +1216,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/08/30)

                -

              53. +

              54. Improved: VectorTools::integrate_difference can compute Lp and W1,p norms for arbitrary p. The function @@ -1298,7 +1298,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK the library.
                (RH 2002/06/14) -

                +

              55. Fixed: FE_Q::has_support_on_face always returned @@ -1351,7 +1351,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (RH 2002/06/10)

                -

              56. +

              57. 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 @@ -1364,7 +1364,7 @@ contributor's names are abbreviated by WB (Wolfgang Bangerth), GK (WB 2002/06/08)

                -

              58. +

              59. 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 diff --git a/doc/news/4.0.0-vs-5.0.0.h b/doc/news/4.0.0-vs-5.0.0.h index 303c117ae7..337b9ecabf 100644 --- a/doc/news/4.0.0-vs-5.0.0.h +++ b/doc/news/4.0.0-vs-5.0.0.h @@ -15,7 +15,7 @@ /** * @page changes_between_4_0_and_5_0 Changes between Version 4.0 and 5.0 - +

                This is the list of changes made between the deal.II releases listed above. All entries are signed with the names of the author. Regular @@ -49,7 +49,7 @@ inconvenience this causes. that take arguments. Instead, you should now use matrix=0 to simply set all elements of the matrix to zero. If you want to notify a sparse matrix that its sparsity pattern has changed, use the reinit(SparsityPattern) function. -
                +
                (WB 2004/05/10)

                @@ -74,13 +74,13 @@ inconvenience this causes. recommended way is to use the more obvious notation vector=0 and matrix=0. To reset the elements of a table over arbitrary objects, use Table<T>::reset_values(). -
                +
                (WB 2004/05/10)

              60. Removed: The SparseLUDecomposition::reinit and SparseMIC::reinit functions without argument had been deprecated before, and have now been removed. -
                +
                (WB 2004/05/10)

                @@ -103,7 +103,7 @@ inconvenience this causes. therefore been renamed get_restriction_matrix, which also better reflects what it is actually doing. To keep consistent, we have also - rename the corresponding function prolongate to get_prolongation_matrix. + rename the corresponding function prolongate to get_prolongation_matrix.
                (WB 2004/02/29)

                @@ -129,12 +129,12 @@ inconvenience this causes. these quadrature formula onto the faces from the other side. We need this due to the fact that we now support faces in 3d that have a normal vector opposite to the standard direction. -
                +
                (WB 2003/10/17)

              61. Moved and changed: The header file - include/numerics/dof_renumbering.h has been moved to the + include/numerics/dof_renumbering.h has been moved to the directory include/dofs, where it logically belongs. Furthermore, the sorting parameter of the function DoFRenumbering::component_wise has changed its meaning. See the reference documentation for details. @@ -177,14 +177,14 @@ inconvenience this causes. (WB 2004/04/12)

                -

              62. New: deal.II is now able to interface to the +

              63. New: deal.II is now able to interface to the METIS library to generate domain partitionings. This is enabled if a METIS installation is detected, which either happens automatically in ./configure, or by passing a value to the switch --with-metis to configure the path of a METIS installation. For more information see the README - file. + file.
                (WB 2004/03/08)

                @@ -203,7 +203,7 @@ inconvenience this causes.

              64. New: deal.II now comes with a complete set of wrappers classes for PETSc vectors, matrices, linear solvers and + target="_top">PETSc vectors, matrices, linear solvers and preconditioners. Many of the algorithms in deal.II have also been updated to make use of these wrappers. All of this is only enabled if a PETSc installation is detected. This either happens automatically in @@ -225,7 +225,7 @@ inconvenience this causes. some compiler/platforms requires boost files in addition to those included in the contrib directory please report the missing boost files to the deal.II mailing list. -
                +
                (RH 2004/02/16)

                @@ -233,7 +233,7 @@ inconvenience this causes. Changed: We don't support compilation by Intel'c icc compiler version 5 anymore. Since the present version of this compiler is 8, this is probably not a real problem. -
                +
                (WB 2003/12/20)

                @@ -241,8 +241,8 @@ inconvenience this causes. Fixed: step-9 had the computation of the value of the solution in the mid-point of the neighbor cell wrong. This is now fixed. Consequently, the resulting mesh also looks much nicer now (much - smoother). -
                + smoother). +
                (Werner Scholz 2003/12/11)

                @@ -254,17 +254,17 @@ inconvenience this causes. unsigned integer. This value is widely used throughout the library as a marker for an invalid unsigned integer value, such as an invalid array index, an invalid array size, and the like. -
                +
                (WB 2003/10/24)

              65. Augmented: The GeometryInfo::child_cell_on_face + class="member">GeometryInfo::child_cell_on_face results in a result that might not be what you expect in 3d in some cases. A warning has been added to the documentation, as well as a reference to the function to call instead. -
                +
                (WB 2003/10/17)

                @@ -283,7 +283,7 @@ inconvenience this causes. (WB 2003/09/23)

                -

              66. Fixed: On AIX systems, the xlf Fortran77 compiler wasn't recognized +

              67. Fixed: On AIX systems, the xlf Fortran77 compiler wasn't recognized due to the fact that when called with -v it generates many pages of output, later leading to a shell error. This is now fixed.
                @@ -340,7 +340,7 @@ inconvenience this causes.

                base

                  -

                1. +

                2. New: There is now a new PolynomialsP class which is based on Polynomials::Monomial and PolynomialSpace. In contrast to the default ordering of the polynomials in PolynomialSpace, (e.g. for degree=2) 1, @@ -351,7 +351,7 @@ inconvenience this causes. (RH 2004/03/11)

                  -

                3. +

                4. New: The classes PolynomialSpace and TensorProductPolynomials now have new set_numbering functions which @@ -387,7 +387,7 @@ inconvenience this causes.

                5. Fixed: The constructor of the QGauss class computed positions and weights of quadrature points in long double accuracy. - However, on machines where long double is the same as double, it + However, on machines where long double is the same as double, it never reached the requested accuracy, in effect leading to an infinite loop. This is now fixed.
                  @@ -521,14 +521,14 @@ inconvenience this causes.
                  (WB 2004/01/26)

                  - +

                6. Improved: Initialization routines of class SparseMatrix have an additional parameter controlling the storage of diagonal entries.
                  (GK 2003/11/18)

                  -

                7. New: +

                8. New: SolverFGMRES implements the flexible GMRES method with varying preconditioner from the right. It is also accessible in SolverSelector by choosing fgmres. @@ -597,14 +597,14 @@ inconvenience this causes.
                  (Luca Heltai 2004/04/21)

                  - +

                9. New: The function GridGenerator::cylinder_shell generates a domain of the type which the name suggests.
                  (WB 2004/04/19)

                  - +

                10. Changed: The KellyErrorEstimator::estimate function takes an additional parameter that lets it only compute error indicators for a @@ -652,7 +652,7 @@ inconvenience this causes.

                11. New: The new functions SparsityPattern::partition, GridTools::partition_triangulation, DoFTools::get_subdomain_association, DoFTools::count_dofs_with_subdomain_association, - GridTools::get_subdomain_association, GridTools::count_cells_with_subdomain_association, + GridTools::get_subdomain_association, GridTools::count_cells_with_subdomain_association, and DoFRenumbering::subdomain_wise can now be used to generate partitions of a triangulation and its associated degrees of freedom suitable for parallel computations with PETSc. @@ -702,7 +702,7 @@ inconvenience this causes. Improved: FiniteElementData has a function tensor_degree(), returning the degree of the polynomial space suitable for choosing a tensor product quadrature - formula. + formula.
                  (GK 2003/11/28)

                  @@ -751,18 +751,18 @@ inconvenience this causes.

                12. New: There are now functions CellAccessor::neighbor_child_on_subface and DoFCellAccessor::neighbor_child_on_subface that should be called instead of using GeometryInfo::child_cell_on_face in most cases. -
                  +
                  (WB 2003/10/17)

                13. New: GridGenerator has a new - function subdivided_hyper_rectangle - which generates a rectangle with given corner points and possibly + function subdivided_hyper_rectangle + which generates a rectangle with given corner points and possibly different numbers of subdivisions in different directions. Use it, e.g., to generate a domain of 1*4 length units with square cells. -
                  +
                  (Joerg Weimar 2003/09/09)

                  @@ -770,17 +770,17 @@ inconvenience this causes. Improved: The 3d grid reordering code in the GridReordering class now uses an algorithm that is linear in the number of elements. The old code was exponential, so this is a vast improvement. -
                  +
                  (Michael Anderson 2003/09/23)

                14. Improved: GridOut has a an improved - functionality for write_eps + functionality for write_eps to color the grid according to the refinement level. - A corresponding option is included in + A corresponding option is included in GridOutFlags::Eps<2>. -
                  +
                  (Joerg Weimar 2003/09/09)

                  @@ -829,11 +829,11 @@ inconvenience this causes. Improved: FEFaceValuesBase has a new function orientation accessing a unique and consistent orientation for each face. -
                  +
                  (GK 2003/06/23)

                  -

                15. +

                16. Changed: Embedding and restriction matrices for intergrid transfer are now computed in the constructor of most elements, rather than taken from precomputed and tabulated values. This removes restrictions on which @@ -843,7 +843,7 @@ inconvenience this causes. (WB 2003/06/09)

                  -

                17. +

                18. New: Finite elements got a function get_interpolation_matrix, with which they can compute interpolations between different finite elements. Most will use this to compute interpolations between finite elements of the same kind @@ -854,14 +854,14 @@ inconvenience this causes. (WB 2003/06/09)

                  -

                19. +

                20. New: Finite elements got a function get_name, which can be used to identify a finite element by its name.
                  (WB 2003/06/09)

                  -

                21. +

                22. New: Raviart-Thomas elements are now implemented in the FE_RaviartThomas class.
                  (WB 2003/06/09) diff --git a/doc/news/5.0.0-vs-5.1.0.h b/doc/news/5.0.0-vs-5.1.0.h index beeae1cb3a..c84dae49ca 100644 --- a/doc/news/5.0.0-vs-5.1.0.h +++ b/doc/news/5.0.0-vs-5.1.0.h @@ -58,7 +58,7 @@ inconvenience this causes. and leads to very hard to find errors. Therefore, all constructors and reinit functions of the parallel sparse matrix classes now take an additional argument indicating the partitioning of columns of the matrix. -
                  +
                  (WB 2004/06/02)

                @@ -70,7 +70,7 @@ inconvenience this causes.

                1. - New: Support of shared libraries under Cygwin / Windows systems. Shared + New: Support of shared libraries under Cygwin / Windows systems. Shared libraries are used as default. To use, make sure the library path is included in your PATH environment variable.
                  @@ -93,7 +93,7 @@ inconvenience this causes.

                2. - New: Configuration now detects the Intel Fortran compiler and can set + New: Configuration now detects the Intel Fortran compiler and can set compilation flags accordingly.
                  (WB 2004/11/04) @@ -117,7 +117,7 @@ inconvenience this causes.

                3. - New: configuration option --with-umfpack for using the + New: configuration option --with-umfpack for using the UMFPack version and enabling the class SparseDirectUMFPACK, both included by Wolfgang. @@ -136,7 +136,7 @@ inconvenience this causes.

                4. Fixed: None of the formulas in the step-8 tutorial program web page were visible. This is now fixed. -
                  +
                  (WB 2004/06/29)

                  @@ -147,25 +147,25 @@ inconvenience this causes.

                  base

                    -

                  1. +

                  2. New: The MultithreadInfo class now also detects multiple processors on Mac OS X. -
                    +
                    (Helmut Müller 2004/11/29)

                    -

                  3. +

                  4. New: The TableHandler::write_tex now accepts the additional boolean argument with_header which is set to - true by default and tells the function whether to add the latex + true by default and tells the function whether to add the latex header and footer (i.e. the \\documentclass{...}, - \\begin{document} and \\end{document} stuff) to the table.
                    - In addition to this, there are two new members in the above class: + \\begin{document} and \\end{document} stuff) to the table.
                    + In addition to this, there are two new members in the above class: TableHandler::tex_set_table_caption and TableHandler::tex_set_table_label to - add a caption and a label to the tex generated table. -
                    + add a caption and a label to the tex generated table. +
                    (Luca Heltai 2004/10/29)

                    @@ -192,7 +192,7 @@ inconvenience this causes. class="class">Table<N,T> class represents an N-dimensional array and might replace the N-times-nested-use of the std::vector class. + class="class">std::vector                     class.
                    (RH 2004/08/13)

                    @@ -200,14 +200,14 @@ inconvenience this causes.

                  5. New: Class TableIndices now has operators that check for equality and inequality of objects. -
                    +
                    (WB 2004/07/28)

                  6. New: A class PointerComparison for comparing pointers that may or may not be of the same type. -
                    +
                    (WB 2004/06/22)

                    @@ -219,7 +219,7 @@ inconvenience this causes. class="member">ok function. It was never really used for anything, and has thus finally been removed. The ok is consequently gone as well. -
                    +
                    (WB 2004/06/06)

                    @@ -230,7 +230,7 @@ inconvenience this causes. or not. This is particular useful for parallel computations when only one process should print to standard output, while in all other processes we simply want output suppressed. -
                    +
                    (RH 2004/05/26)

                  @@ -246,24 +246,24 @@ inconvenience this causes. prevented deal.II from working with it (it couldn't be compiled at all). We have added checks that make sure that it can now again be compiled with PETSc versions 2.1.6, 2.2.0, and 2.2.1. -
                  +
                  (WB 2004/10/07)

                5. New: A class PreconditionLU which provides a wrapper to the complete LU decomposition - preconditioner of PETSc. Furthermore a class + preconditioner of PETSc. Furthermore a class SolverPreOnly was implemented. It is a wrapper for the PETSc solver type KSPPREONLY, which only applies the preconditioner. In conjunction with PreconditionLU this provides a simple direct solver, which could be used for small to medium sized problems on a single processor machine. -
                  +
                  (Oliver Kayser-Herold 2004/07/27)

                  - +

                6. Improved: VectorTools::point_difference used to use an algorithm to find the cell the given point is in that @@ -271,7 +271,7 @@ inconvenience this causes. to use GridTools::find_active_cell_around_point which is only logarithmic in its complexity. -
                  +
                  (WB 2004/07/07)

                  @@ -280,7 +280,7 @@ inconvenience this causes. (and invalid) states when some of the blocks had empty rows. In this common case, we would frequently skip elements when looping over the elements of a block matrix. These cases should now be fixed. -
                  +
                  (WB 2004/07/07)

                  @@ -290,7 +290,7 @@ inconvenience this causes. the position within a row. However, this was fragile, and has been removed. If you want an ordering of elements within a row, use the operator < to compare iterators. -
                  +
                  (WB 2004/07/07)

                  @@ -299,14 +299,14 @@ inconvenience this causes. class="class">PETScWrappers::SolverGMRES::AdditionalData                   class now takes an additional flag indicating the use of left or right preconditioning. -
                  +
                  (RH 2004/06/24)

                7. Improved: The SparseDirectMA27 class can now handle float as well as double input matrices and vectors. -
                  +
                  (WB 2004/06/23)

                  @@ -318,7 +318,7 @@ inconvenience this causes. and output vectors, but were only instantiated in case the arguments were the same, and could also not be compiled if they weren't. Both problems are now fixed. -
                  +
                  (WB 2004/06/22)

                  @@ -333,7 +333,7 @@ inconvenience this causes. average. This should significantly reduce the total amount of memory required as well as memory fragmentation. It also cuts run-time for element addition by more than half. -
                  +
                  (WB 2004/06/21)

                  @@ -342,7 +342,7 @@ inconvenience this causes. class="member">CompressedSparsityPattern::max_entries_per_row() ignored the first row and thus sometimes returned a value that was too low. This is now fixed. -
                  +
                  (WB 2004/06/21)

                  @@ -352,7 +352,7 @@ inconvenience this causes. removed them, but it still kept the number of blocks unchanged. Subsequent accesses to these blocks, or to their information yielded segmentation faults. -
                  +
                  (WB 2004/06/02)

                  @@ -362,7 +362,7 @@ inconvenience this causes. still exist in all their functionality, this allowed us to now also have block matrices and vectors for PETSc sequential and parallel objects. -
                  +
                  (WB 2004/06/02)

                  @@ -378,7 +378,7 @@ inconvenience this causes. temporaries without our ado. This bug is now detected during configuration time of the library, and these constructors are available whenever the compiler does not contain this bug. -
                  +
                  (WB 2004/06/02)

                  @@ -387,7 +387,7 @@ inconvenience this causes. now also have member functions local_range, in_local_range, and local_size. -
                  +
                  (WB 2004/06/02)

                  @@ -395,7 +395,7 @@ inconvenience this causes. New: Parallel PETSc matrix and vector classes now have member functions get_mpi_communicator that returns the MPI communicator object these objects operate on. -
                  +
                  (WB 2004/06/02)

                  @@ -404,7 +404,7 @@ inconvenience this causes. than a nonconstant reference to the MPI communicator to be used. This prevents some unnecessary compiler problems in conjunction with the new get_mpi_communicator function. -
                  +
                  (WB 2004/06/02)

                  @@ -413,7 +413,7 @@ inconvenience this causes. initialized (via either constructor or reinit functions) with a compressed sparsity pattern object, allowing for more efficient preallocation of nonzero entries. -
                  +
                  (WB 2004/06/02)

                @@ -508,7 +508,7 @@ inconvenience this causes. places in the library use or touch the user pointers. That is wrong, the SolutionTransfer class actually does. This is now properly documented. -
                +
                (WB 2004/09/15)

                @@ -517,7 +517,7 @@ inconvenience this causes. class="member">DerivativeApproximation::approximate_second_derivative                 function produced wrong results ("not a number", or an exception instead of "zero") if the field it was given was constant. This is now fixed. -
                +
                (WB 2004/08/05)

                @@ -525,7 +525,7 @@ inconvenience this causes. New: The MatrixTools::apply_boundary_values that works on block matrices and vectors is now templatized over the number type, i.e. it also works for float matrices and vectors. -
                +
                (WB 2004/06/22)

                @@ -533,7 +533,7 @@ inconvenience this causes. New: The new FEValuesBase::get_cell function returns the current cell, i.e. the latest cell the FEValues object was reinited with. -
                +
                (RH 2004/06/22)

                @@ -548,7 +548,7 @@ inconvenience this causes. of information, but the cases where this applies and the strategies to work with this problem anyway are now well documented in the documentation of the MatrixTools class. -
                +
                (WB 2004/06/07)

                @@ -558,7 +558,7 @@ inconvenience this causes. Jacobians. In usual finite element computations this simply leads to all components of the linear system being negated, so it is not harmful. It is fixed now anyway. -
                +
                (WB 2004/06/07)

              diff --git a/doc/news/5.1.0-vs-5.2.0.h b/doc/news/5.1.0-vs-5.2.0.h index 1888fbfcbd..e7d10b1c4e 100644 --- a/doc/news/5.1.0-vs-5.2.0.h +++ b/doc/news/5.1.0-vs-5.2.0.h @@ -141,7 +141,7 @@ inconvenience this causes.

            79. New: The step-19 tutorial demonstrates handling of parameters from a parameter file, as well as some simple techniques for merging output - from parallel computations. + from parallel computations.
              (WB 2005/09/09)

              @@ -178,7 +178,7 @@ inconvenience this causes. might issue error messages about multiple defined symbols. This is now detected, and the linker is forced to ignore these errors. However, if you accidentally defined symbols twice you might have a hard time - debugging now... In this case remove the -Xlinker + debugging now... In this case remove the -Xlinker --allow-multiple-definition flag from Make.global_options.
              (Ralf B. Schulz, 2005/07/13) @@ -236,7 +236,7 @@ inconvenience this causes.

            80. Fixed: When compiling shared libraries on CygWin systems, warnings concerning the -fPIC option were issued by the compiler. - This is now fixed. + This is now fixed. Also, configure now issues a message at the end that you should include the DLL-path in your .bash_profile file on these systems.
              @@ -254,7 +254,7 @@ inconvenience this causes. systems. A new preprocessor variable, DEAL_II_BROKEN_SOCKETS has been added to base/config.h which is defined on affected systems. -
              +
              (Ralf B. Schulz, WB, 2005/03/02)

              @@ -262,7 +262,7 @@ inconvenience this causes. Fixed: The step-16 example program wasn't listed in the navigation bar of the tutorial section, although it was in the table of contents. This is fixed now. -
              +
              (WB, 2005/02/09)

            @@ -278,7 +278,7 @@ inconvenience this causes. a file in a sequence of directories and by appending suffixes. The class generates the complete file name including directory prefix and suffix such that it can be used for subsequently opening the file. -
            +
            (GK, 2005/09/14)

            @@ -306,10 +306,10 @@ inconvenience this causes.
            (Ralf B. Schulz, 2005/07/19)

            - +

          24. Removed: The write_multigrid flag in DataOutBase::DXFlags + class="member">DataOutBase::DXFlags has been removed, since it wasn't used anywhere.
            (WB, 2005/07/14) @@ -323,7 +323,7 @@ inconvenience this causes.
            (Ralf B. Schulz, 2005/07/13)

            - +

          25. Improved: The QProjector now has functions project_to_face and double_contract contracts two tensors of rank 4 and 2 into a tensor of rank 2, by contracting over two indices at the same time. -
            +
            (WB, 2005/03/29)

            @@ -480,14 +480,14 @@ inconvenience this causes. class="member">TableIndicesBase::sort             allows to sort the indices in ascending order. This is useful for cases where the order of indices is irrelevant (for example in symmetric tables). -
            +
            (WB, 2005/03/29)

          26. New: There is a new class SymmetricTensor that provides storage and operations for symmetric tensors. -
            +
            (WB, 2005/03/28)

            @@ -497,27 +497,27 @@ inconvenience this causes. easily. The additional feature is being incorporated into SmartPointer constructors throughout the library. -
            +
            (GK, 2005/03/16)

          27. New: Class FunctionParser. Wrapper - class for the fparser library (see + class for the fparser library (see http://warp.povusers.org/FunctionParser/). -
            +
            (Luca Heltai, 2005/03/07).

          28. Fixed: The class MultipleParameterLoop::UserClass had only + class="class">MultipleParameterLoop::UserClass had only virtual abstract functions but no virtual destructor. This caused warnings with some compilers, and is generally bad practice anyway. This is now fixed. The same holds with respect to the class DataOutInterface. -
            +
            (WB, 2005/02/20)

          @@ -532,7 +532,7 @@ inconvenience this causes. New: The new function PetscWrappers::VectorBase::set allows to set several vector elements at once. -
          +
          (WB, 2005/08/10)

          @@ -542,7 +542,7 @@ inconvenience this causes. class="member">clear_rows           that allow to set the elements of a row of a matrix to zero, without having to traverse the individual elements. -
          +
          (WB, 2005/08/10)

          @@ -562,14 +562,14 @@ inconvenience this causes. has the complete interface of a preconditioner class. Therefore, it can be used in iterative solvers and in multigrid smoothers. -
          +
          (GK, 2005/05/10)

        26. Fixed: The PETSc matrix iterators had trouble when some rows of a matrix were empty. This has now been mostly fixed. -
          +
          (WB, 2005/05/02)

          @@ -582,7 +582,7 @@ inconvenience this causes. about its effectiveness. This has now been fixed: The code now properly initializes these elements, and makes the resulting matrix much faster to use. -
          +
          (WB, 2005/04/04)

          @@ -590,14 +590,14 @@ inconvenience this causes. New: The ProductSparseMatrix implements the product of two rectangular sparse matrices with the same value_type -
          +
          (GK, 2005/03/11)

        27. New: The PreconditionRichardson implements a Richardson preconditioner. -
          +
          (GK, 2005/03/10)

          @@ -607,7 +607,7 @@ inconvenience this causes. made it a little awkward to use in some places. This has now been fixed. -
          +
          (WB, 2005/03/03)

          @@ -679,7 +679,7 @@ inconvenience this causes. sometimes declared to iterators equal if only they had the same triangulation, refinement level, and index. Comparing iterators into different containers is now completely disallowed. -
          +
          (WB, 2005/08/08)

          @@ -689,7 +689,7 @@ inconvenience this causes. vector-valued. It then makes up names for the individual components by adding numbers to the name, just like the DataOut class already does for a long time. -
          +
          (WB, 2005/07/29)

          @@ -697,7 +697,7 @@ inconvenience this causes. New: The DataOutStack class can now also be used to stack two-dimensional time or parameter dependent data into a 3d output. -
          +
          (WB, 2005/07/25)

          @@ -708,10 +708,10 @@ inconvenience this causes. assumption that the coarse grid space is embedded into the fine grid space. In particular, no interpolation points are required.

          - +

          Using this function, constraint matrices can be computed in a general way. -
          +
          (GK, 2005/07/14)

          @@ -778,7 +778,7 @@ inconvenience this causes.
          (GK 2005/06/29)

          - +

        28. New: Added function FiniteElementBase::component_to_system_index @@ -814,7 +814,7 @@ inconvenience this causes. also for the case of non-standard oriented faces in 3d. This avoids several awful pieces of code including questioning face_orientation and using child_switch_tables. -
          +
          (RH, 2005/06/16)

          @@ -825,13 +825,13 @@ inconvenience this causes. a FE_Q object. Now this function can also be called by the FE_Q constructor which avoids code duplication. -
          +
          (RH, 2005/06/13)

        29. New: The method create_mass_matrix - in class MatrixCreator can now handle + in class MatrixCreator can now handle vector valued finite elements. A similar change was applied to create_right_hand_side and create_boundary_right_hand_side @@ -839,7 +839,7 @@ inconvenience this causes. now make the project function work also for Raviart-Thomas elements and other vector valued FEs. This is very useful, if some initial conditions have to be specified. -
          +
          (Oliver Kayser-Herold, 2005/06/03)

          @@ -850,7 +850,7 @@ inconvenience this causes. now shows the solution also on the deformed mesh. This is an option and requires the mapping to be specified as additional parameter to build_patches. -
          +
          (Oliver Kayser-Herold, 2005/05/31)

          @@ -870,7 +870,7 @@ inconvenience this causes. Gauss quadrature points on edges and in the interior for its node values. The implementation is restricted to Cartesian mesh cells right now, but works in 2D and 3D. -
          +
          (GK, 2005/05/30)

          @@ -878,14 +878,14 @@ inconvenience this causes. Improved: The Mapping::transform_* functions accept VectorSlice instead of Vector, thus allowing more flexibility. -
          +
          (GK, 2005/05/24)

        30. New: The MatrixTools::apply_boundary_values function now also works for PETSc sequential and parallel matrices. -
          +
          (WB, 2005/05/05)

          @@ -895,7 +895,7 @@ inconvenience this causes. mechanism provided by the class PathSearch. Furthermore, a library of input meshes has been started in lib/meshes. -
          +
          (GK, 2005/05/03)

          @@ -906,7 +906,7 @@ inconvenience this causes. overloaded and cell data was to be output; in that case, data from the wrong cells was written out. This is now fixed. In contrast to this, nodal data was never affected. -
          +
          (WB, 2005/04/20)

          @@ -930,7 +930,7 @@ inconvenience this causes. New: The new GeometryInfo::line_to_cell_vertices function maps line vertex numbers to cell vertex numbers. -
          +
          (RH, 2005/03/11)

          @@ -938,7 +938,7 @@ inconvenience this causes. New: The new GeometryInfo::face_to_cell_lines function maps face line numbers to cell line numbers. -
          +
          (RH, 2005/03/11)

          @@ -946,7 +946,7 @@ inconvenience this causes. New: The new GeometryInfo::face_to_cell_vertices function maps face vertex numbers to cell vertex numbers. -
          +
          (RH, 2005/03/11)

          @@ -955,7 +955,7 @@ inconvenience this causes. class="class">KellyErrorEstimator           class that resulted in assertions being thrown when run with multithreading enabled. This is now fixed. -
          +
          (WB, 2005/03/10)

          @@ -967,7 +967,7 @@ inconvenience this causes. vertices. This leads to a change in the ordering of vertices in output files generated by GridOut for refined grids. -
          +
          (RH, 2005/03/09)

          @@ -977,7 +977,7 @@ inconvenience this causes. that happens when one coarsens an existing triangulation. In that case, it would throw unjustified exceptions. This is now fixed. -
          +
          (WB, 2005/03/01)

          @@ -986,7 +986,7 @@ inconvenience this causes. virtual abstract functions but no virtual destructor. This caused warnings with some compilers, and is generally bad practice anyway. This is now fixed. -
          +
          (WB, 2005/02/22)

          @@ -996,15 +996,15 @@ inconvenience this causes. automatic computation of embedding matrices under the sole assumption that the coarse grid space is embedded into the fine grid space. In particular, no interpolation points are required. -
          +
          (GK, 2005/02/08)

        31. Fixed: Several wrong assertions in the Raviart-Thomas finite element class have been fixed, that were triggered when integrating face terms. -
          - (Oliver Kayser-Herold, 2005/01/24; +
          + (Oliver Kayser-Herold, 2005/01/24; WB, 2005/01/31)

        diff --git a/doc/news/5.2.0-vs-6.0.0.h b/doc/news/5.2.0-vs-6.0.0.h index 845e2a8b50..2c8461135f 100644 --- a/doc/news/5.2.0-vs-6.0.0.h +++ b/doc/news/5.2.0-vs-6.0.0.h @@ -68,7 +68,7 @@ inconvenience this causes. namespace dealii;         declaration at the top of each file, or qualify each deal.II class and function explicitly with dealii:: namespace access. -
        +
        (WB 2006/10/22)

        @@ -76,8 +76,8 @@ inconvenience this causes. Changed: Indices, such as vertex indices, are usually represented by unsigned integers in deal.II. One place where we didn't do this was in the CellData structure that can be used to describe cells - when building a triangulation. This has now been rectified. -
        + when building a triangulation. This has now been rectified. +
        (WB 2006/09/06)

        @@ -107,7 +107,7 @@ inconvenience this causes. elements, the ordering of boundary DoFs returned by DoFTools::map_dof_to_boundary_indices has been changed. Fortunately, this is a rarely used function so that the effect should be limited to only a few programs. -
        +
        (WB 2006/04/26)

        @@ -119,7 +119,7 @@ inconvenience this causes. that you can't call these functions for face or edge iterators any more, but only cells. Since this is what is usually desired, this should not be too severe a restriction. -
        +
        (WB 2006/04/26)

        @@ -127,7 +127,7 @@ inconvenience this causes. Changed: The template argument of the InterGridMap class has been changed. Code like e.g. InterGridMap<DoFHandler,2> must be replaced by InterGridMap<DoFHandler<2> >. -
        +
        (RH 2006/02/27)

        @@ -138,7 +138,7 @@ inconvenience this causes. argument is replaced by the type of DoFHandler they correspond to. This may be ::DoFHandler or hp::DoFHandler. -
        +
        (RH 2006/02/10, WB 2005/12/20)

        @@ -146,7 +146,7 @@ inconvenience this causes. Removed: Support for gcc2.95 in particular, and all compilers that do not support the std::ostringstream class in general, has been removed. -
        +
        (WB 2006/02/03)

        @@ -158,7 +158,7 @@ inconvenience this causes. problems to application programs. On the other hand, it moves common names like Line and Quad out of the global namespace. -
        +
        (WB 2006/01/13)

        @@ -177,7 +177,7 @@ inconvenience this causes. action; if you really want the old behavior back, cast the argument to the base class before the call, like so: DoFRenumbering::component_wise(static_cast<DoFHandler<dim>&>(mg_dof_handler))) -
        +
        (WB 2005/12/15)

        @@ -195,8 +195,8 @@ inconvenience this causes. old vertex ordering. However, as this function might not be supported forever users are advised to change their code to the new numbering scheme and to use the Triangulation::create_triangulation - function. -
        + function. +
        (RH 2005/11/02)

      @@ -219,7 +219,7 @@ inconvenience this causes.

    14. New: The step-27 tutorial program has been added. It solves a Laplace - equation with hp finite elements + equation with hp finite elements and shows how to set finite element degrees, assemble matrices on cells with varying polynomial degrees, and how to compute a simple criterion for estimating the local Sobolev smoothness of a function. @@ -243,12 +243,12 @@ inconvenience this causes. been extended by new flags face_flip and face_rotation, denoting a face which is rotated against the 'standard face' by 180 and 90 degrees, respectively. Furthermore, there is a new flag - line_orientation with obvious meaning. + line_orientation with obvious meaning.
      These flags have to be respected during creation and refinement of a triangulation, when projecting quadrature points to faces or when the dof indices on a cell are extracted. Furthermore, asking for vertices and lines of cells is in some cases a bit more complicated. The same applies, - for example, + for example, to the extraction of the information, which child of a neighbor is behind a given subface. However, this information is supplied by various functions in GeometryInfo. As a rule-of-thumb: @@ -298,7 +298,7 @@ inconvenience this causes. libraries that would contain illegal instructions. This is now fixed.
      (WB 2006/08/09) -

      +

    15. Changed: The default number of subdivisions in the build_patches functions of the DataOut classes is now part of the parameters read by parse_parameters. This default value is used @@ -312,7 +312,7 @@ inconvenience this causes. library instead of the contributed.
      (GK 2006/03/23) -

      +

    16. New: The step-20 tutorial program was added. It shows how to use Raviart-Thomas elements to solve a mixed formulation of the Laplace @@ -367,7 +367,7 @@ inconvenience this causes. the API manual (and the other way round) and leads to a generally much nicer output. In particular, formulas embedded in the documentation of the programs are now properly displayed. -
      +
      (WB 2006/01/16)

      @@ -375,7 +375,7 @@ inconvenience this causes. Improved: The link to the manual now points directly to Doxygen's module list, and almost all classes are now grouped into modules that capture related functionality. -
      +
      (WB 2006/01/16)

      @@ -385,8 +385,8 @@ inconvenience this causes. PETSC_ARCH environment variables but do not wish deal.II to be configured for PETSc use, you should specify --with-petsc=no as a flag during - configuration. -
      + configuration. +
      (WB 2006/01/16)

      @@ -402,7 +402,7 @@ inconvenience this causes. impossible to figure out if you didn't know what was going on. This mechanism has now been robustified and should yield better error messages. -
      +
      (WB 2005/11/23)

      @@ -410,14 +410,14 @@ inconvenience this causes. New: The dynamic libraries, which is the name of shared libs under Apples OSX, are now supported on these platforms and enabled by default. They should safe a lot of harddisk space. -
      +
      (Oliver Kayser-Herold 2005/10/20)

    17. Fixed: The Tecplot library (tecio.a) was detected but not added to LIBS. This is now fixed. -
      +
      (RH 2005/09/23)

      @@ -428,7 +428,7 @@ inconvenience this causes. NetCDF installation directory can also be specified through the --with-netcdf=/path/to/netcdf configure option. -
      +
      (RH 2005/09/23)

      @@ -436,7 +436,7 @@ inconvenience this causes. Fixed: The PETSc libraries have been relinked each time make was called. Now, the PETSc libraries will only be relinked if necessary. -
      +
      (RH 2005/09/15)

      @@ -451,11 +451,11 @@ inconvenience this causes.

    18. New: There is a new class: Functions::FEFieldFunction which is a Function - interface to a finite element solution. -
      + interface to a finite element solution. +
      (Luca Heltai 2007/08/29) - +

    19. Improved: FunctionDerivative is now derived from AutoDerivativeFunction and implements gradients as well, giving you automatic second derivatives of a function. @@ -468,7 +468,7 @@ inconvenience this causes. n is a constant known at compile time. It allows to calculate powers efficiently at compile time, most often things like a number to the power dim. -
      +
      (WB 2007/06/23)

      @@ -478,20 +478,20 @@ inconvenience this causes. be of no concern to users. However, this restriction was previously undocumented, even if implied. The documentation for this has now been updated. -
      +
      (WB 2007/02/08)

    20. New: The new Functions::Monomial class implements monomials as a function object. -
      +
      (WB 2006/12/15)

    21. Fixed: If no substring is found with a width smaller than the given threshold, the Utilities::break_text_into_lines function now returns the smallest possible substring (larger than the threshold). -
      +
      (Tobias Leicht 2006/12/13)

      @@ -523,7 +523,7 @@ inconvenience this causes. tensors. There is now a new version of this function, that contracts a tensor of rank three with a second one of rank two over given indices index1 and index2 of the first and second tensor, - respectively, resulting in a tensor of rank three. + respectively, resulting in a tensor of rank three.
      (Tobias Leicht 2006/09/27)

      @@ -559,7 +559,7 @@ inconvenience this causes. desirable, for example here: 
              
-          void f() 
+          void f()
           {
 	    Triangulation tria;
 	    DoFHandler *dh = new DoFHandler(tria);
@@ -601,7 +601,7 @@ inconvenience this causes.
        distance of a given point to the unit cell, and
        project_to_unit_cell returning the projection of a point
        onto the unit cell. Also, a new member vertex_to_face allow
-       to determine to which faces of a cell a vertex belongs. 
+       to determine to which faces of a cell a vertex belongs.
        
      
        (Ralf B. Schulz 2006/05/10)
        
      
@@ -648,7 +648,7 @@ inconvenience this causes.
        (GK 2006/03/08)
        
      
 
-  
    22.  
      Fixed: Writing a denormal "NaN" through LogStream objects such as 
+  
    23.  
      Fixed: Writing a denormal "NaN" through LogStream objects such as
        deallog erroneously printed zero, rather
        than "nan". This is now fixed.
        
      
@@ -721,7 +721,7 @@ inconvenience this causes.
 
   
    24.  
      
        New: There are new functions
-       Utilities::match_at_string_start and 
+       Utilities::match_at_string_start and
        Utilities::get_integer_at_position.
        
      
        (WB 2005/12/19)
@@ -747,7 +747,7 @@ inconvenience this causes.
        Fixed: The tecplot_binary OutputFormat has been added to DataOutBase::get_output_format_names. Now
        an exception will be raised if write_tecplot_binary is invoked without
        specifying the filename through the DataOutBase::TecplotFlags interface.
-       
       
+       
      
        (RH 2005/09/23)
        
      
 
@@ -756,7 +756,7 @@ inconvenience this causes.
        Utilities::System namespace. In case
        of a code not running in parallel, they simply return 1 and 0,
        respectively.
-       
       
+       
      
        (RH 2005/09/20)
    @@ -803,13 +803,13 @@ inconvenience this causes. (WB 2007/02/09)

    -

  • Improved: A simple print_formatted +

  • Improved: A simple print_formatted function has been added to SparseMatrixEZ.
    (Moritz Allmaras 2007/02/08)

    -

  • Fixed: The SparseDirectMA27 +

  • Fixed: The SparseDirectMA27 class works for symmetric matrices and had a check to make sure the matrix is indeed symmetric. However, the check compared entries for equality, something one should not do for floating point numbers. It now @@ -818,7 +818,7 @@ inconvenience this causes. (WB 2006/12/21)

    -

  • Fixed: The FullMatrix::invert +

  • Fixed: The FullMatrix::invert function would return wrong results if one tried to invert a matrix of dimension smaller than 5 in situ. This is now fixed.
    @@ -853,7 +853,7 @@ inconvenience this causes. now estimate the condition number of the linear system using TridiagonalMatrix and LAPACK.
    (GK 2006/09/06) -

    +

  • New: the class TridiagonalMatrix has been introduced together with its basic methods, including an @@ -863,8 +863,8 @@ inconvenience this causes.

  • Improved: PETSc 2.3.1 (build 16) is now supported by the - linear preconditioner classes. The new PETSc functions - PCFactorSetXXX are used.
    + linear preconditioner classes. The new PETSc functions + PCFactorSetXXX are used.
    (Florian Prill, 2006/08/04)

    @@ -874,43 +874,43 @@ inconvenience this causes. the transpose of the matrix it points to.
    (GK 2006/07/07) -

    +

  • New: There is now a function FullMatrix::trace that does what its name suggests it does.
    (WB 2006/06/16)

    - +

  • Improved: PointerMatrixAux now has a default constructor and a function for setting the VectorMemory object.
    (GK 2006/06/14)

    - +

  • Fixed: FullMatrix::print would yield a link error when used with std::ofstream since an explicit instantiation was missing. The function has now been moved to the header file and made inline so that it is always visible, whatever the type of the output stream is. -
    +
    (WB 2006/06/07)

    - +

  • Improved: The SparseDirectUMFPACK solver can now also be used with sparse matrices with elements of type float, as well as with block matrices with types float and double. -
    +
    (WB 2006/04/25)

  • New: The function BlockSparsityPattern::row_length adds up the row lengths of the individual blocks of a block matrix for a given row. -
    +
    (WB 2006/04/25)

    - +

  • New: There is a new class IdentityMatrix that represents an efficient version of the matrix with ones on the diagonal and zeros everywhere else. The main usefulness of this matrix lies @@ -918,10 +918,10 @@ inconvenience this causes. assignment operators and copy constructors that allow to conveniently fill a (sparse, full) matrix with the identity matrix. -
    +
    (WB 2006/04/24)

    - +

  • New: There are now assignment operators from BlockVector to Vector and back.
    (WB 2006/03/30) @@ -942,7 +942,7 @@ inconvenience this causes. the linear solver fails.
    (Stephan Kramer, WB 2006/03/15) -

    +

  • Changed: There are new FullMatrix::equ functions which assign this @@ -951,7 +951,7 @@ inconvenience this causes. function for three vectors.
    (RH 2006/02/21) -

    +

  • Fixed: The SolverMinRes class did not work @@ -959,27 +959,27 @@ inconvenience this causes. This is now fixed.
    (Luca Heltai 2006/02/19) -

    +

  • Changed: There are now new FullMatrix::add functions which add two and three scaled matrices.
    (RH 2006/02/16) -

    +

  • Changed: The matrix classes FullMatrix, SparseMatrix, SparseMatrixEZ and BlockMatrixBase now have an add function analogous to the add of vector classes. The old add_scaled functions are now deprecated.
    (RH 2006/02/16) -

    +

    -

  • +

  • Improved: BlockMatrixArray::enter_aux allows using matrices without adding vector multiplication by using PointerMatrixAux.
    (GK 2006/02/02) -

    +

  • New: The class PointerMatrixAux was @@ -994,10 +994,10 @@ inconvenience this causes. Improved: The FilteredMatrix class was able to filter only the SparseMatrix matrix class. - A new (faster) version is now in its place with the same interface - that is able to perform such a filter on anything that provides + A new (faster) version is now in its place with the same interface + that is able to perform such a filter on anything that provides the usual matrix vector operations. -
    +
    (Luca Heltai 2006/01/09)

    @@ -1014,7 +1014,7 @@ inconvenience this causes. specifically use a different memory allocation class, have been changed to not specify anything at all, and thus fall back to the default. -
    +
    (WB 2005/11/23)

    @@ -1024,7 +1024,7 @@ inconvenience this causes. (i.e. with a zero integer, rather than a floating point number on the right), in that that opened up a second conversion sequence and the compiler complained about an ambiguity. This is now fixed. -
    +
    (WB 2005/10/17)

    @@ -1033,7 +1033,7 @@ inconvenience this causes. also the Tvmult method. This feature allows the straightforward use of SparseILU as a multigrid smoother within the framework. -
    +
    (Oliver Kayser-Herold 2005/09/15)

    @@ -1047,11 +1047,11 @@ inconvenience this causes.

  • New: There is a new class: Functions::ParsedFunction which is friendly wrapper to the FunctionParser class. -
    +
    (Luca Heltai 2007/08/29) - +

  • Fixed: the function - DataOut::build_patches + DataOut::build_patches had a quadratic algorithm when generatic cell-data (as opposed to DoF data). This algorithm became a bottleneck when generating output on meshes with large number of cells. This is @@ -1061,14 +1061,14 @@ inconvenience this causes.

  • New: the function - DoFTools::get_active_fe_indices + DoFTools::get_active_fe_indices extracts for each cell the active finite element index used on it.
    (WB 2007/08/07)

  • Extended: the function - Triangulation::copy_triangulation + Triangulation::copy_triangulation copies all members of a triangulation except for the list of RefinementListeners. In most cases this is exactly the intended behavior. However, if a RefinementListener should be copied to @@ -1080,7 +1080,7 @@ inconvenience this causes.

  • New: the function - DoFTools::make_sparsity_pattern + DoFTools::make_sparsity_pattern now takes an optional constraint matrix argument that can be used to avoid the subsequent call to condense the sparsity pattern. In effect, the sparsity pattern is generated condensed right away. For problems in @@ -1091,7 +1091,7 @@ inconvenience this causes.

  • New: the new function - ConstraintMatrix::add_entries_local_to_global + ConstraintMatrix::add_entries_local_to_global can be used to add entries to a matrix where entries that will appear if the current entry corresponds to a constrained degree of freedom are also added. @@ -1100,7 +1100,7 @@ inconvenience this causes.

  • Fixed: the function - GridTools::find_cells_adjacent_to_vertex + GridTools::find_cells_adjacent_to_vertex was not detecting properly the coarse cells adjacent to refined cells.
    @@ -1110,9 +1110,9 @@ inconvenience this causes.

  • Fixed: the two tools DoFTools::count_dofs_per_component and DoFTools::count_dofs_per_block where changing the - size of the destination vector. Consistently with (most of) the - rest of the library, now the vectors are expected to be the - right size before calling these functions. + size of the destination vector. Consistently with (most of) the + rest of the library, now the vectors are expected to be the + right size before calling these functions.
    (Luca Heltai 2007/05/15)

    @@ -1180,9 +1180,9 @@ inconvenience this causes. (WB 2007/02/20)

    -

  • New: Added function GridGenerator::hyper_cube_with_cylindrical_hole that produces +

  • New: Added function GridGenerator::hyper_cube_with_cylindrical_hole that produces a square with a circular hole in the middle in 2d, and extrudes it - along the z-direction between 0 and L. + along the z-direction between 0 and L.
    (Luca Heltai 2007/02/15)

    @@ -1192,7 +1192,7 @@ inconvenience this causes. be properly visualized. The boundary indicator was added to the material flag of the faces (which is ignored when reading back the mesh) in order for the Gmsh reader to be able to display the boundary - indicator in a proper way. + indicator in a proper way.
    (Luca Heltai 2007/02/15)

    @@ -1214,8 +1214,8 @@ inconvenience this causes.

  • Fixed: MatrixCreator::create_mass_matrix and - create_laplace_matrix computed wrong values for the right - hand sides. This has been fixed. + create_laplace_matrix computed wrong values for the right + hand sides. This has been fixed.
    (Moritz Allmaras 2007/02/08)

    @@ -1311,13 +1311,13 @@ inconvenience this causes.

  • New: There are now two new functions GridGenerator::subdivided_hyper_rectangle that produces a non-uniformly subdivided rectangle, ideally suited for graded - meshes. One of these functions is able to create meshes with holes. + meshes. One of these functions is able to create meshes with holes.
    (Yaqi Wang 2006/11/15, 2006/12/29)

    -

  • Fixed: Corrected clone method - of FE_DGQ class for non-equidistant +

  • Fixed: Corrected clone method + of FE_DGQ class for non-equidistant support points.
    (Florian Prill 2006/10/31) @@ -1335,7 +1335,7 @@ inconvenience this causes. New: There is a new functions GridTools::create_union_triangulation that generates a triangulation that contains the respectively finest cells of two input triangulations. -
    +
    (WB 2006/10/23)

    @@ -1347,14 +1347,14 @@ inconvenience this causes. of constraints are resolved at the time the ConstraintMatrix::close() function is called. The only thing that is not allowed are cycles in such constraints. -
    +
    (WB 2006/09/19)

  • New: There are new functions GridTools::minimal_cell_diameter and GridTools::maximal_cell_diameter, with obvious - functionality. -
    + functionality. +
    (WB 2006/09/06)

    @@ -1368,14 +1368,14 @@ inconvenience this causes. in particular did not allow to check for the number of matrices in the array. The functions now take a reference to an array of the correct length. -
    +
    (WB 2006/08/14)

  • Extended: The VectorTools::project functions are now also implemented for 1d. -
    +
    (WB 2006/08/08)

    @@ -1386,7 +1386,7 @@ inconvenience this causes. norm of this tensor is required later on, the new DerivativeApproximation::derivative_norm function can be used. Note, that for second order derivatives, this returns the largest eigenvalue instead of the Frobenius norm, which is returned by the Tensor<rank_,dim>::norm function. -
    +
    (Tobias Leicht 2006/08/03)

    @@ -1397,7 +1397,7 @@ inconvenience this causes. symmetrized instead of an intermediate tensor. This should improve the results slightly, but cause no problems otherwise, as this is completely internal to the class. -
    +
    (Tobias Leicht 2006/08/03)

    @@ -1407,7 +1407,7 @@ inconvenience this causes. zero as the second argument (denoting the number of threads to use if multithreading is enabled). This led to no output being created at all. This is now fixed by throwing an exception in this case. -
    +
    (WB 2006/07/31)

    @@ -1417,7 +1417,7 @@ inconvenience this causes. dofs_per_quad, ..., depending on the explicitly specified function template argument. This is often useful for template trickery. -
    +
    (WB, 2006/07/28)

    @@ -1430,7 +1430,7 @@ inconvenience this causes. allowed (if all children are flagged for coarsening). This leeds to triangulations with a slightly reduced number of cells. In some cases older references will have to be updated. -
    +
    (Tobias Leicht 2006/06/22)

    @@ -1447,7 +1447,7 @@ inconvenience this causes. of a Dirac pulse on the base functions. This models a point source as used in the calculations of Green's functions and can also be used to extract the value of a finite element solution in a single point. -
    +
    (Ralf B. Schulz, 2006/05/15)

    @@ -1455,7 +1455,7 @@ inconvenience this causes. Changed: Functions VectorTools::point_value and VectorTools::point_difference using the old interface without boundary mapping were replaced by wrapper functions calling the new versions. -
    +
    (Ralf B. Schulz, 2006/05/15)

    @@ -1466,14 +1466,14 @@ inconvenience this causes. version as it automatically delivers also the local coordinate of the point (so it can save some computation time in most cases as you don't have to calculate that again). -
    +
    (Ralf B. Schulz, 2006/05/12)

  • Improved: The functions VectorTools::point_value and VectorTools::point_difference now can also use arbitrary mappings, using the new GridTools::find_active_cell_around_point algorithm. -
    +
    (Ralf B. Schulz, 2006/05/11)

    @@ -1488,7 +1488,7 @@ inconvenience this causes. determine the active cell in which a given point is located. For points located on boundaries and edges, it is in most cases also able to give the finest cell. -
    +
    (Ralf B. Schulz 2006/05/10)

    @@ -1502,10 +1502,10 @@ inconvenience this causes. moved to the DoFCellAccessor class that provides access to cells (i.e. lines in 1d, quads in 2d, and hexes in 3d) for which this operation is actually useful. -
    +
    (WB 2006/05/01)

    - +

  • Fixed: second derivatives where not computed correctly in FEFaceValuesBase, i.e. when evaluating second derivatives on faces of cells. This is now fixed. Using second derivatives evaluated at quadrature points within a cell @@ -1519,7 +1519,7 @@ inconvenience this causes. Triangulation::clear_user_flags_quad, and Triangulation::clear_user_flags_hex can be used to selectively clear only some of the user flags as needed. -
    +
    (WB 2006/04/25)

    @@ -1527,7 +1527,7 @@ inconvenience this causes. New: The function VectorTools::project functions can now also be used for vector arguments of type other than Vector<double>. -
    +
    (WB 2006/04/17)

    @@ -1538,7 +1538,7 @@ inconvenience this causes. to integrate the solution on one mesh against the shape functions on another mesh, a situation that frequently happens in time-dependent but also in nonlinear problems. -
    +
    (WB 2006/04/14)

    @@ -1546,7 +1546,7 @@ inconvenience this causes. New: The function GridTools::have_same_coarse_mesh figures out whether two triangulations, two DoFHandlers, etc, are built on the same coarse mesh. -
    +
    (WB 2006/04/14)

    @@ -1555,7 +1555,7 @@ inconvenience this causes. fairly frequent operation (called about 7 times per cell in step-14, but much more often in more complicated programs), the results of this function are now cached for faster access. -
    +
    (WB 2006/03/29)

    @@ -1565,7 +1565,7 @@ inconvenience this causes. element that also has non-primitive base elements (for example, trying to interpolate boundary values for a the last component of a RT x Q1 element). This is now fixed. -
    +
    (WB 2006/03/27)

    @@ -1573,14 +1573,14 @@ inconvenience this causes. New: There is a new function FiniteElement::face_to_equivalent_cell_index that can convert a face index of a degree of freedom into a corresponding cell index. -
    +
    (WB 2006/03/27)

  • New: There are now functions VectorTools::point_value that evaluate the value of a finite element function at a given point inside the domain. -
    +
    (WB 2006/03/06)

    @@ -1594,14 +1594,14 @@ inconvenience this causes. Improved: The Triangulation, PersistentTriangulation, DoFHandler, hp::DoFHandler and MGDoFHandler classes now all have a dimension variable which allows to ask the template argument dim by SomeClass::dimension. -
    +
    (RH 2006/02/27)

  • Fixed: When used, the copy constructor of MappingQ would lead to memory corruption. This is now fixed. -
    +
    (RH 2006/02/23)

    @@ -1615,9 +1615,9 @@ inconvenience this causes.

  • - New: There is now a GridOut::write_gmsh function to write in the gmsh - format. It has the same features of the write_ucd one. -
    + New: There is now a GridOut::write_gmsh function to write in the gmsh + format. It has the same features of the write_ucd one. +
    (Luca Heltai 2006/02/17)

    @@ -1626,15 +1626,15 @@ inconvenience this causes. the standard operator[] function. Similarly, the FECollection::n_finite_elements, QCollection::n_quadratures and MappingCollection::n_mappings functions are now renamed to the standard size() function. -
    +
    (RH 2006/02/10)

  • - Improved: GridGenerator::half_hyper_ball now is implemented also - in three dimensions, and the boundary now is colored with 0 and one + Improved: GridGenerator::half_hyper_ball now is implemented also + in three dimensions, and the boundary now is colored with 0 and one respectively on the curved and plane. -
    +
    (Luca Heltai 2006/02/07)

    @@ -1651,7 +1651,7 @@ inconvenience this causes. Fixed: The MGDoFHandler::distribute_dofs and renumber functions could not handle coarsened grids (unused vertices, faces and cells). This is now fixed. -
    +
    (RH 2006/01/23)

    @@ -1659,7 +1659,7 @@ inconvenience this causes. New: The Mapping class and derived classes now have functions clone() that return a new object of the same (derived) type. -
    +
    (WB 2006/1/8)

    @@ -1667,7 +1667,7 @@ inconvenience this causes. Improved: The KellyErrorEstimator class now also allows to select the cells on which it is supposed to work by giving a material ID, instead of only a subdomain ID. -
    +
    (WB 2006/1/4)

    @@ -1675,7 +1675,7 @@ inconvenience this causes. Improved: A new TriaAccessor::ExcCellHasNoChildren exception will be raised if the TriaObjectAccessor::child_index function is invoked for cells without children. -
    +
    (RH 2005/12/09)

    @@ -1685,14 +1685,14 @@ inconvenience this causes. thrown. In particular, this happened when the step-14 program was run on dual processor machines and the library was compiled for multithreading. This is now fixed. -
    +
    (WB 2005/10/20)

  • New: There is now a new Triangulation::get_boundary_indicators function. -
    +
    (RH 2005/09/30)

    @@ -1700,7 +1700,7 @@ inconvenience this causes. New: There is now a new GridTools::delete_unused_vertices function. Previously a private function in GridIn it has now been moved to and made public in GridTools. -
    +
    (RH 2005/09/28)

    @@ -1709,7 +1709,7 @@ inconvenience this causes. &filename)     function reads grids from NetCDF files. The only data format currently supported is the TAU grid format. -
    +
    (RH 2005/09/23)

    @@ -1718,7 +1718,7 @@ inconvenience this causes. function ran into an exception when called with Default format and a filename which does not include /. This is now fixed. -
    +
    (RH 2005/09/21)

    diff --git a/doc/news/6.3.0-vs-7.0.0.h b/doc/news/6.3.0-vs-7.0.0.h index 090e576bf0..7e443c401a 100644 --- a/doc/news/6.3.0-vs-7.0.0.h +++ b/doc/news/6.3.0-vs-7.0.0.h @@ -441,7 +441,7 @@ independent of the dimension.
    (WB, 2010/12/20)

    • - +

  • New: When computing errors using VectorTools::integrate_difference in codimension one problems, if you specified a norm that requires the computation of the gradients, @@ -452,7 +452,7 @@ independent of the dimension.
    (Luca Heltai, 2010/12/05)

    • - +

  • New: The VectorTools::interpolate_boundary_values function can now also be used to interpolate boundary values on meshes embedded in a higher dimensional space. diff --git a/doc/news/8.2.1-vs-8.3.0.h b/doc/news/8.2.1-vs-8.3.0.h index a8ca05497a..4421af5157 100644 --- a/doc/news/8.2.1-vs-8.3.0.h +++ b/doc/news/8.2.1-vs-8.3.0.h @@ -554,8 +554,8 @@ inconvenience this causes.

    1. New: VectorTools::get_position_vector now works with arbitrary - FESystems, provided that the geometrical components are primitive, - and that you provide a component mask to select what components of + FESystems, provided that the geometrical components are primitive, + and that you provide a component mask to select what components of the finite element to use for the geometrical interpolation.
      (Luca Heltai, 2015/07/25) diff --git a/doc/news/8.4.1-vs-8.4.2.h b/doc/news/8.4.1-vs-8.4.2.h index 651060e771..98a05f67f0 100644 --- a/doc/news/8.4.1-vs-8.4.2.h +++ b/doc/news/8.4.1-vs-8.4.2.h @@ -53,7 +53,7 @@ author. (David Wells, 2016/07/07)
      2. -
    2. Fixed: Fix various warnings introduced by GCC 6 +
    3. Fixed: Fix various warnings introduced by GCC 6
      (David Wells, 2016/05/07)
      4. diff --git a/doc/news/8.4.2-vs-8.5.0.h b/doc/news/8.4.2-vs-8.5.0.h index c8df8d98f5..304763185e 100644 --- a/doc/news/8.4.2-vs-8.5.0.h +++ b/doc/news/8.4.2-vs-8.5.0.h @@ -772,13 +772,13 @@ inconvenience this causes.
    4. - Fixed: The GridOut::write_mesh_per_processor_as_vtu() function now works for a mesh whose multilevel hierarchy is not distributed, as well as a mesh whose level_subdomain_ids do not necessarily match its subdomain_ids for every active cell. + Fixed: The GridOut::write_mesh_per_processor_as_vtu() function now works for a mesh whose multilevel hierarchy is not distributed, as well as a mesh whose level_subdomain_ids do not necessarily match its subdomain_ids for every active cell.
      (Conrad Clevenger, 2017/02/09)
    5. - Fixed: Patterns::Selection now ignores spaces at the beginning and the end + Fixed: Patterns::Selection now ignores spaces at the beginning and the end of the sequence string.
      (Rajat Arora, 2017/02/09) @@ -910,7 +910,7 @@ inconvenience this causes.
    6. Fixed: A bug in the rotation matrix used in step-18 has now been corrected. This tutorial now uses the function - Physics::Transformations::Rotations::rotation_matrix_3d to compute the 3d + Physics::Transformations::Rotations::rotation_matrix_3d to compute the 3d rotation matrix.
      (Jean-Paul Pelteret, Paul Kuberry, 2017/01/09) @@ -946,7 +946,7 @@ inconvenience this causes.
    7. - Improved: The MPI_Comm used in MatrixFree is not configurable via + Improved: The MPI_Comm used in MatrixFree is not configurable via AdditionalData anymore but set to the MPI_Comm of the Triangulation.
      (Daniel Arndt, 2017/01/08) @@ -1102,7 +1102,7 @@ inconvenience this causes.
    8. - New: Automatically recreate changes.h from files in + New: Automatically recreate changes.h from files in subfolders of ./doc/news
      (Daniel Arndt, 2016/11/18) @@ -2092,7 +2092,7 @@ inconvenience this causes.
    9. Fixed: Double contraction of two SymmetricTensor<..,VectorizedArray> now - works. Introduced internal::NumberType with static member + works. Introduced internal::NumberType with static member internal::Numbertype::value to be called instead of the constructor Number() in symmetric_tensor.h.
      diff --git a/doc/news/8.5.0-vs-9.0.0.h b/doc/news/8.5.0-vs-9.0.0.h index a60598ff28..5962772767 100644 --- a/doc/news/8.5.0-vs-9.0.0.h +++ b/doc/news/8.5.0-vs-9.0.0.h @@ -966,8 +966,8 @@ inconvenience this causes.
      1. - New: A new tutorial program, step-60, shows how to deal with non-matching discretizations using - Distributed Lagrange Multipliers. + New: A new tutorial program, step-60, shows how to deal with non-matching discretizations using + Distributed Lagrange Multipliers.
        (Luca Heltai, Giovanni Alzetta, 2018/05/07)
        2. diff --git a/doc/news/CMakeLists.txt b/doc/news/CMakeLists.txt index 1389345763..be72a8d5f5 100644 --- a/doc/news/CMakeLists.txt +++ b/doc/news/CMakeLists.txt @@ -30,7 +30,7 @@ IF(DEAL_II_COMPONENT_DOCUMENTATION) COMMAND ${CMAKE_COMMAND} -DOUTPUT_FILE=${CMAKE_CURRENT_BINARY_DIR}/changes.h -P ${CMAKE_CURRENT_SOURCE_DIR}/changes/create_changes_h.cmake WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/changes - DEPENDS + DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/changes/header ${CMAKE_CURRENT_SOURCE_DIR}/changes/header_incompatibilities ${CMAKE_CURRENT_SOURCE_DIR}/changes/header_major diff --git a/doc/readme.html b/doc/readme.html index 4367bc7aa3..2a673c5ade 100644 --- a/doc/readme.html +++ b/doc/readme.html @@ -191,7 +191,7 @@
        • The part "/path/to/install/dir" in the command above needs to be replaced by the path to the directory which deal.II should be installed into. This can be a directory in your home directory (e.g., ~/bin/deal.II) or a directory such as /usr/local if you have root privileges. - Another option is to use something like `pwd`/../installed/ (note the backticks). + Another option is to use something like `pwd`/../installed/ (note the backticks).
        • make test automatically runs in parallel and no -jN flag should be supplied to it. @@ -453,7 +453,7 @@ while providing a multitude of linear solvers and preconditioners and extension to other linear operators with minimal changes required in the code. To enable Ginkgo, pass -DGINKGO_DIR=/path/to/ginkgo to CMake when - configuring deal.II. For more detailed instructions, one can refer to + configuring deal.II. For more detailed instructions, one can refer to this page.

          @@ -622,7 +622,7 @@ -DSUNDIALS_DIR=/path/to/sundials to the deal.II CMake call.

          - +
          SymEngine
          diff --git a/examples/CMakeLists.txt b/examples/CMakeLists.txt index ac9b9a11d5..ed164e20e7 100644 --- a/examples/CMakeLists.txt +++ b/examples/CMakeLists.txt @@ -52,7 +52,7 @@ IF(DEAL_II_COMPONENT_EXAMPLES) # # Set up all executables: # - FILE(GLOB _steps + FILE(GLOB _steps ${CMAKE_CURRENT_SOURCE_DIR}/step-*/step-*.cc ${CMAKE_CURRENT_SOURCE_DIR}/step-*/step-*.cu) FOREACH(_step ${_steps}) diff --git a/examples/step-1/CMakeLists.txt b/examples/step-1/CMakeLists.txt index 3fe152e654..d3d1a18cc8 100644 --- a/examples/step-1/CMakeLists.txt +++ b/examples/step-1/CMakeLists.txt @@ -11,7 +11,7 @@ SET(TARGET "step-1") # you may want to either replace the following statement by something like # FILE(GLOB_RECURSE TARGET_SRC "source/*.cc") # FILE(GLOB_RECURSE TARGET_INC "include/*.h") -# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) +# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) # or switch altogether to the large project CMakeLists.txt file discussed # in the "CMake in user projects" page accessible from the "User info" # page of the documentation. diff --git a/examples/step-1/doc/results.dox b/examples/step-1/doc/results.dox index 518493175c..65d5f8b659 100644 --- a/examples/step-1/doc/results.dox +++ b/examples/step-1/doc/results.dox @@ -1,6 +1,6 @@

          Results

          -Running the program produces graphics of two grids (grid-1.svg and grid-2.svg). +Running the program produces graphics of two grids (grid-1.svg and grid-2.svg). You can open these with most every web browser -- in the simplest case, just open the current directory in your file system explorer and click on the file. If you like working on the command line, you call your @@ -94,7 +94,7 @@ Rather than postponing learning how to use a debugger till you really can't see any other way to find a bug, here's the one piece of advice we will provide in this program: learn how to use a debugger as soon as possible. It will be time well invested. -(@dealiiVideoLectureSeeAlso{25}) The deal.II Frequently Asked +(@dealiiVideoLectureSeeAlso{25}) The deal.II Frequently Asked Questions (FAQ) page linked to from the top-level deal.II webpage also provides a good number of hints on debugging deal.II programs. diff --git a/examples/step-14/doc/intro.dox b/examples/step-14/doc/intro.dox index c9b7b975ef..a0a806f608 100644 --- a/examples/step-14/doc/intro.dox +++ b/examples/step-14/doc/intro.dox @@ -19,12 +19,12 @@ estimation and adaptivity for general functional output for the Laplace equation, while the second gives many examples of applications of these concepts to a large number of other, more complicated equations. For applications to individual types of equations, see also the publications by -Becker @cite Bec95, @cite Bec98, Kanschat @cite Kan96, @cite FK97, Suttmeier -@cite Sut96, @cite RS97, @cite RS98c, @cite RS99, Bangerth @cite BR99b, +Becker @cite Bec95, @cite Bec98, Kanschat @cite Kan96, @cite FK97, Suttmeier +@cite Sut96, @cite RS97, @cite RS98c, @cite RS99, Bangerth @cite BR99b, @cite Ban00w, @cite BR01a, @cite Ban02, and Hartmann @cite Har02, @cite HH01, -@cite HH01b. All of these works, from the original introduction by Becker and -Rannacher to individual contributions to particular equations, have later been -summarized in a book by Bangerth and Rannacher that covers all of these topics, +@cite HH01b. All of these works, from the original introduction by Becker and +Rannacher to individual contributions to particular equations, have later been +summarized in a book by Bangerth and Rannacher that covers all of these topics, see @cite BR03. diff --git a/examples/step-15/doc/intro.dox b/examples/step-15/doc/intro.dox index 7ac01edd58..7794162e0c 100644 --- a/examples/step-15/doc/intro.dox +++ b/examples/step-15/doc/intro.dox @@ -190,13 +190,13 @@ eigenvalue $a_n$. Since all eigenvalues are positive, $B$ is positive definite and so is $A$. We can thus use the CG method for solving the Newton steps. (The fact that the matrix $A$ is symmetric and positive definite should not come as a surprise. It results from taking the derivative of an operator that -results from taking the derivative of an energy functional: the minimal +results from taking the derivative of an energy functional: the minimal surface equation simply minimizes some non-quadratic energy. Consequently, the Newton matrix, as the matrix of second derivatives of a scalar energy, must be symmetric since the derivative with regard to the $i$th and $j$th degree of freedom should clearly commute. Likewise, if the energy functional is convex, then the matrix of second derivatives must be positive definite, -and the direct calculation above simply reaffirms this.) +and the direct calculation above simply reaffirms this.) It is worth noting, however, that the positive definiteness degenerates for problems where $\nabla u$ becomes large. In other words, if we simply multiply diff --git a/examples/step-17/doc/intro.dox b/examples/step-17/doc/intro.dox index 3a91bd3387..79b432bf6a 100644 --- a/examples/step-17/doc/intro.dox +++ b/examples/step-17/doc/intro.dox @@ -30,11 +30,11 @@ near-equivalents PETScWrappers::MPI::Vector and every processor in the MPI network only stores a part of the matrix or vector. More specifically, each processor will only store those rows of the matrix that correspond to a degree of -freedom it "owns". For vectors, they either store only elements that +freedom it "owns". For vectors, they either store only elements that correspond to degrees of freedom the processor owns (this is what is necessary for the right hand side), or also some additional elements that make sure that every processor has access the solution components -that live on the cells the processor owns (so-called +that live on the cells the processor owns (so-called @ref GlossLocallyActiveDof "locally active DoFs") or also on neighboring cells (so-called @ref GlossLocallyRelevantDof "locally relevant DoFs"). @@ -55,7 +55,7 @@ single machine if PETSc was configured without MPI. Developing software to run in %parallel via MPI requires a bit of a change in mindset because one typically has to split up all data structures so that every processor only stores a piece of the entire problem. As a consequence, -you can't typically access all components of a solution vector on each +you can't typically access all components of a solution vector on each processor -- each processor may simply not have enough memory to hold the entire solution vector. Because data is split up or "distributed" across processors, we call the programming model used by MPI "distributed memory @@ -63,15 +63,15 @@ computing" (as opposed to "shared memory computing", which would mean that multiple processors can all access all data within one memory space, for example whenever multiple cores in a single machine work on a common task). Some of the fundamentals of distributed memory -computing are discussed in the +computing are discussed in the @ref distributed "Parallel computing with multiple processors using distributed memory" documentation module, which is itself a sub-module of the -@ref Parallel "Parallel computing" module. +@ref Parallel "Parallel computing" module. In general, to be truly able to scale to large numbers of processors, one needs to split between the available processors every data structure whose size scales with the size of the overall problem. (For a definition -of what it means for a program to "scale", see +of what it means for a program to "scale", see @ref GlossParallelScaling "this glossary entry".) This includes, for example, the triangulation, the matrix, and all global vectors (solution, right hand side). If one doesn't split all of these objects, one of those will be @@ -134,7 +134,7 @@ wait for this return message but the original receiver was distracted and not paying attention, then you're out of luck: you'll simply have to wait until your requested over there will be worked on. In some cases, bugs will lead the original receiver to never check your mail, and in that -case you will wait forever -- this is called a deadlock. +case you will wait forever -- this is called a deadlock. (@dealiiVideoLectureSeeAlso{39,41,41.25,41.5}) In practice, one does not usually program at the level of sending and @@ -177,7 +177,7 @@ philosophy behind MPI as outlined above. The techniques this program then demonstrates are: - How to use the PETSc wrapper classes; this will already be visible in the declaration of the principal class of this program, ElasticProblem. -- How to partition the mesh into subdomains; this happens in the +- How to partition the mesh into subdomains; this happens in the ElasticProblem::setup_system() function. - How to parallelize operations for jobs running on an MPI network; here, this is something one has to pay attention to in a number of places, most diff --git a/examples/step-17/doc/results.dox b/examples/step-17/doc/results.dox index f8d96b5cd3..5d732f136a 100644 --- a/examples/step-17/doc/results.dox +++ b/examples/step-17/doc/results.dox @@ -104,7 +104,7 @@ relevant to when the code was initially written, in 2004.) I lost the timing information for the last step, though, but you get the idea. All this is after release mode has been enabled by running make release, and with the generation of graphical output switched off for the reasons stated in -the program comments above. +the program comments above. (@dealiiVideoLectureSeeAlso{18}) The biggest 2d computations I did had roughly 7.1 million unknowns, and were done on 32 processes. It took about 40 minutes. @@ -237,7 +237,7 @@ the right one shows the x-displacement along two cutplanes through the cube. The program keeps a complete copy of the Triangulation and DoFHandler objects on every processor. It also creates complete copies of the solution vector, and it creates output on only one processor. All of this is obviously -the bottleneck as far as parallelization is concerned. +the bottleneck as far as parallelization is concerned. Internally, within deal.II, parallelizing the data structures used in hierarchic and unstructured triangulations is a hard diff --git a/examples/step-18/doc/intro.dox b/examples/step-18/doc/intro.dox index 79669864c2..222436a664 100644 --- a/examples/step-18/doc/intro.dox +++ b/examples/step-18/doc/intro.dox @@ -196,7 +196,7 @@ such that (\mathbf{f}, \varphi)_{\Omega(t_{n-1})} -(\sigma^{n-1},\varepsilon(\varphi))_{\Omega(t_{n-1})} \\ - &\qquad + &\qquad +(\mathbf{b}(\mathbf{x},t_n)-\mathbf{b}(\mathbf{x},t_{n-1}), \varphi)_{\Gamma_N} +(\sigma^{n-1} \mathbf{n}, \varphi)_{\Gamma_N} \\ @@ -367,8 +367,8 @@ the correct files and allow moving around in time, both support record files that reference all files for a given timestep. Sadly, the record files have a different format between VisIt and Paraview, so we write out both formats. -The code will generate the files solution-TTTT.NNN.vtu, -where TTTT is the timestep number (starting from 1) and +The code will generate the files solution-TTTT.NNN.vtu, +where TTTT is the timestep number (starting from 1) and NNN is the process rank (starting from 0). These files contain the locally owned cells for the timestep and processor. The files solution-TTTT.visit is the visit record @@ -401,14 +401,14 @@ partitions itself among all involved processes (which it knows about because you have to tell it about the @ref GlossMPICommunicator "MPI communicator" that connects these processes upon construction of the triangulation). Otherwise, the parallel::shared::Triangulation looks, for all practical -purposes, like a regular Triangulation object. +purposes, like a regular Triangulation object. The convenience of using this class does not only result from being able to avoid the manual call to GridTools::partition(). Rather, the DoFHandler class now also knows that you want to use it in a parallel context, and by default automatically enumerates degrees of freedom in such a way that all DoFs owned by process zero come before all DoFs owned by process 1, -etc. In other words, you can also avoid the call to +etc. In other words, you can also avoid the call to DoFRenumbering::subdomain_wise(). There are other benefits. For example, because the triangulation knows that @@ -424,7 +424,7 @@ using the syntax @endcode This knowledge extends to the DoFHandler object built on such triangulations, which can then identify which degrees of freedom are locally owned -(see @ref GlossLocallyOwnedDofs) via calls such as +(see @ref GlossLocallyOwnedDofs) via calls such as DoFHandler::compute_n_locally_owned_dofs_per_processor() and DoFTools::extract_locally_relevant_dofs(). Finally, the DataOut class also knows how to deal with such triangulations and will simply skip diff --git a/examples/step-18/doc/results.dox b/examples/step-18/doc/results.dox index 80a08a9cdb..e647b34585 100644 --- a/examples/step-18/doc/results.dox +++ b/examples/step-18/doc/results.dox @@ -472,7 +472,7 @@ solution of such problems, and stabilization techniques have to be employed for a stable and accurate solution. The book and paper cited above give indications as to how to do this, but there is also a large volume of literature on this subject; a good start to get an overview of the topic can -be found in the references of the paper by H.-Y. Duan and Q. Lin; @cite DL05. +be found in the references of the paper by H.-Y. Duan and Q. Lin; @cite DL05.
          Refinement during timesteps
          diff --git a/examples/step-2/CMakeLists.txt b/examples/step-2/CMakeLists.txt index 5544dab656..218afe0804 100644 --- a/examples/step-2/CMakeLists.txt +++ b/examples/step-2/CMakeLists.txt @@ -11,7 +11,7 @@ SET(TARGET "step-2") # you may want to either replace the following statement by something like # FILE(GLOB_RECURSE TARGET_SRC "source/*.cc") # FILE(GLOB_RECURSE TARGET_INC "include/*.h") -# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) +# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) # or switch altogether to the large project CMakeLists.txt file discussed # in the "CMake in user projects" page accessible from the "User info" # page of the documentation. diff --git a/examples/step-2/doc/intro.dox b/examples/step-2/doc/intro.dox index 3d1fc7128a..5df6a4f4f1 100644 --- a/examples/step-2/doc/intro.dox +++ b/examples/step-2/doc/intro.dox @@ -60,7 +60,7 @@ corresponding to a particular differential equation using this finite element and mesh. We will keep this step for the step-3 program and rather talk about one practical aspect of a finite element program, namely that finite element matrices are always very sparse: almost all entries in these -matrices are zero. +matrices are zero. To be more precise, we say that a matrix is sparse if the number of nonzero entries per row in the matrix is @@ -72,7 +72,7 @@ total size of the matrix. For more complicated problems -- say, the Stokes problem of step-22 -- and in particular in 3d, the number of entries per row may be several hundred. But the important point is that this number is independent of the overall size of the problem: If you refine the mesh, the -maximal number of unknowns per row remains the same. +maximal number of unknowns per row remains the same. Sparsity is one of the distinguishing feature of the finite element method compared to, say, approximating the solution of a @@ -91,7 +91,7 @@ values of all $N$ unknowns with optimal complexity, i.e., with a total of ${\cal O}(N)$ operations. It is clear that this wouldn't be possible if the matrix were not sparse (because then the number of entries in the matrix would have to be ${\cal O}(N^s)$ with some $s>1$, and doing a fixed number of -matrix-vector products would take ${\cal O}(N^s)$ operations), +matrix-vector products would take ${\cal O}(N^s)$ operations), but it also requires very specialized solvers such as multigrid methods to satisfy the requirement that the solution requires only a fixed number of matrix-vector multiplications. We will frequently look at the @@ -121,7 +121,7 @@ demonstrate a simple way to output the "sparsity pattern" that corresponds to a DoFHandler, i.e., an object that represents all of the potentially nonzero elements of a matrix one may build when discretizing a partial differential equation on a mesh and its DoFHandler. This lack of structure in the sparsity -pattern will be apparent from the pictures we show below. +pattern will be apparent from the pictures we show below. For most applications and algorithms, the exact way in which degrees of freedom are numbered does not matter. For example, the Conjugate Gradient method we diff --git a/examples/step-20/doc/intro.dox b/examples/step-20/doc/intro.dox index 85f8a39b0f..22b5ea333e 100644 --- a/examples/step-20/doc/intro.dox +++ b/examples/step-20/doc/intro.dox @@ -45,11 +45,11 @@ if you have free flow in a large domain, say a pipe, a river, or in the air. On the other hand, if the fluid is confined in pores, then friction forces exerted by the pore walls on the fluid become more and more important and internal viscous friction becomes less and less important. Modeling this -then first leads to the +then first leads to the Brinkman model if both effects are important, and in the limit of very small pores to the Darcy equations. -The latter is just a different name for the Poisson or Laplace equation, +The latter is just a different name for the Poisson or Laplace equation, connotating it with the area to which one wants to apply it: slow flow in a porous medium. In essence it says that the velocity is proportional to the pressure gradient that drives the fluid through the porous medium. @@ -363,7 +363,7 @@ it. The problem here is: the matrix has a zero block at the bottom right pressure test function $q$), and it is indefinite. At least it is symmetric. In other words: the Conjugate Gradient method is not going to work since it is only applicable to problems in which the matrix is -symmetric and positive definite. +symmetric and positive definite. We would have to resort to other iterative solvers instead, such as MinRes, SymmLQ, or GMRES, that can deal with indefinite systems. However, then the next problem immediately surfaces: due to the zero block, there are zeros @@ -419,8 +419,8 @@ second row from it): B^TM^{-1}B P &=& B^TM^{-1} F - G, \\ MU &=& F - BP. @f} -Here, the matrix $S=B^TM^{-1}B$ (called the -Schur complement +Here, the matrix $S=B^TM^{-1}B$ (called the +Schur complement of $A$) is obviously symmetric and, owing to the positive definiteness of $M$ and the fact that $B$ has full column rank, $S$ is also positive @@ -430,12 +430,12 @@ Consequently, if we could compute $S$, we could apply the Conjugate Gradient method to it. However, computing $S$ is expensive because it requires us to compute the inverse of the (possibly large) matrix $M$; and $S$ is in fact also a full matrix because even though $M$ is sparse, its inverse $M^{-1}$ -will generally be a dense matrix. +will generally be a dense matrix. On the other hand, the CG algorithm doesn't require us to actually have a representation of $S$: It is sufficient to form matrix-vector products with it. We can do so in steps, using the fact that matrix products are associative (i.e., we can set parentheses in such a -way that the product is more convenient to compute): +way that the product is more convenient to compute): To compute $Sv=(B^TM^{-1}B)v=B^T(M^{-1}(Bv))$, we
          1. compute $w = B v$; @@ -448,10 +448,10 @@ avoid matrix-matrix products; this way, all we have to do is evaluate matrix-vector products. In the following, we will then have to come up with ways to represent the -matrix $S$ so that it can be used in a Conjugate Gradient solver, +matrix $S$ so that it can be used in a Conjugate Gradient solver, as well as to define ways in which we can precondition the solution of the linear system involving $S$, and deal with solving linear systems -with the matrix $M$ (the second step above). +with the matrix $M$ (the second step above). @note The key point in this consideration is to recognize that to implement an iterative solver such as CG or GMRES, we never actually need the actual diff --git a/examples/step-21/doc/intro.dox b/examples/step-21/doc/intro.dox index a2e8125b3a..dee926f149 100644 --- a/examples/step-21/doc/intro.dox +++ b/examples/step-21/doc/intro.dox @@ -78,7 +78,7 @@ of course is going to change as the fluids move around. The second part of the equations is the description of the dynamics of the saturation, i.e., how the relative concentration of the -two fluids changes with time. The saturation equation for the displacing +two fluids changes with time. The saturation equation for the displacing fluid (water) is given by the following conservation law: @f{eqnarray*} S_{t} + \nabla \cdot (F(S) \mathbf{u}) = q_{w}, @@ -86,7 +86,7 @@ fluid (water) is given by the following conservation law: which can be rewritten by using the product rule of the divergence operator in the previous equation: @f{eqnarray*} - S_{t} + F(S) \left[\nabla \cdot \mathbf{u}\right] + S_{t} + F(S) \left[\nabla \cdot \mathbf{u}\right] + \mathbf{u} \cdot \left[ \nabla F(S)\right] = S_{t} + F(S) q + \mathbf{u} \cdot \nabla F(S) = q_{w}. @f} diff --git a/examples/step-22/doc/intro.dox b/examples/step-22/doc/intro.dox index 06c0c2beec..f8f5664ffa 100644 --- a/examples/step-22/doc/intro.dox +++ b/examples/step-22/doc/intro.dox @@ -597,7 +597,7 @@ module), for example because we use adaptively refined meshes and continuous pressure finite elements so that there are hanging nodes. Another cause for such constraints are Dirichlet boundary conditions on the pressure. Then the AffineConstraints -class, upon copying the local contributions to the matrix into the +class, upon copying the local contributions to the matrix into the global linear system will zero out rows and columns corresponding to constrained degrees of freedom and put a positive entry on the diagonal. (You can think of this entry as being one for @@ -854,10 +854,10 @@ comparison of their results. Apart from this, many other algorithms have been tested and improved during the creation of this program. For example, in building the sparsity pattern, -we originally used a (now no longer existing) BlockCompressedSparsityPattern +we originally used a (now no longer existing) BlockCompressedSparsityPattern object that added one element at a time; however, its data structures were poorly -adapted for the large numbers of nonzero entries per row created by our -discretization in 3d, leading to a quadratic behavior. Replacing the internal +adapted for the large numbers of nonzero entries per row created by our +discretization in 3d, leading to a quadratic behavior. Replacing the internal algorithms in deal.II to set many elements at a time, and using a BlockCompressedSimpleSparsityPattern (which has, as of early 2015, been in turn replaced by BlockDynamicSparsityPattern) as a better adapted data structure, diff --git a/examples/step-24/doc/intro.dox b/examples/step-24/doc/intro.dox index 62dd817ff3..9d4f12848b 100644 --- a/examples/step-24/doc/intro.dox +++ b/examples/step-24/doc/intro.dox @@ -180,7 +180,7 @@ c_0^2\,k\,\theta\,A+c_0\,B & M \\ \end{array}\right)=\\ \left(\begin{array}{l} G_1 \\ - G_2 -(\theta F^{n}+(1-\theta)F ^{n-1})c_{0}^{2}k \\ + G_2 -(\theta F^{n}+(1-\theta)F ^{n-1})c_{0}^{2}k \\ \end{array}\right) @f] @@ -191,7 +191,7 @@ G_1 \\ G_2 \\ \end{array} \right)=\\ \left(\begin{array}{l} - M\bar{p}^{n-1}+k(1-\theta)Mv^{n-1}\\ + M\bar{p}^{n-1}+k(1-\theta)Mv^{n-1}\\ (-c_{0}^{2}k (1-\theta)A+c_0 B)\bar{p}^{n-1} +Mv^{n-1} \end{array}\right) @f] @@ -199,10 +199,10 @@ G_2 \\ By simple transformations, one then obtains two equations for the pressure potential and its derivative, just as in the previous tutorial program: @f{eqnarray*} -(M+(k\,\theta\,c_{0})^{2}A+c_0k\theta B)\bar{p}^{n} & = & +(M+(k\,\theta\,c_{0})^{2}A+c_0k\theta B)\bar{p}^{n} & = & G_{1}+(k\, \theta)G_{2}-(c_0k)^2\theta (\theta F^{n}+(1-\theta)F^{n-1}) \\ -Mv^n & = & -(c_0^2\,k\, \theta\, A+c_0B)\bar{p}^{n}+ G_2 - -c_0^2k(\theta F^{n}+(1-\theta)F^{n-1}) +Mv^n & = & -(c_0^2\,k\, \theta\, A+c_0B)\bar{p}^{n}+ G_2 - +c_0^2k(\theta F^{n}+(1-\theta)F^{n-1}) @f} diff --git a/examples/step-26/doc/intro.dox b/examples/step-26/doc/intro.dox index de58294e16..b4db15be54 100644 --- a/examples/step-26/doc/intro.dox +++ b/examples/step-26/doc/intro.dox @@ -13,7 +13,7 @@ This program implements the heat equation &= f(\mathbf x, t), \qquad\qquad && - \forall \mathbf x \in \Omega, t\in (0,T), + \forall \mathbf x \in \Omega, t\in (0,T), \\ u(\mathbf x, 0) &= u_0(\mathbf x) && \forall \mathbf x \in \Omega, \\ @@ -45,7 +45,7 @@ like $u^n(\mathbf x)$ to approximate $u(\mathbf x, t_n)$ at some time $t_n$: (1-\theta)f(\mathbf x, t_{n-1}) + \theta f(\mathbf x, t_n) - \right]. + \right]. @f} Here, $k_n=t_n-t_{n-1}$ is the time step size. The theta-scheme generalizes the explicit Euler ($\theta=0$), implicit Euler ($\theta=1$) and @@ -168,12 +168,12 @@ compared to the stationary case. Let us go through them in turn: (1-\theta)f(\mathbf x, t_{n-1}) + \theta f(\mathbf x, t_n) - \right]. + \right]. @f} We can here consider $u^{n-1}$ as data since it has presumably been computed - before. Now, let us replace + before. Now, let us replace @f{align*} - u^n(\mathbf x)\approx u_h^n(\mathbf x) + u^n(\mathbf x)\approx u_h^n(\mathbf x) = \sum_j U^n \varphi_j(\mathbf x), @f} @@ -400,7 +400,7 @@ we choose @f} Here, @f{align*} - \chi_1(\mathbf x) &= + \chi_1(\mathbf x) &= \left\{ \begin{array}{ll} 1 @@ -411,7 +411,7 @@ Here, \end{array} \right. \\ - \chi_2(\mathbf x) &= + \chi_2(\mathbf x) &= \left\{ \begin{array}{ll} 1 diff --git a/examples/step-26/doc/results.dox b/examples/step-26/doc/results.dox index 892ab181aa..088630b289 100644 --- a/examples/step-26/doc/results.dox +++ b/examples/step-26/doc/results.dox @@ -94,7 +94,7 @@ program, but a more systematic treatment is also given in step-52. If you look at the meshes in the movie above, it is clear that they are not particularly well suited to the task at hand. In fact, they look rather -random. +random. There are two factors at play. First, there are some islands where cells have been refined but that are surrounded by non-refined cells (and there @@ -103,12 +103,12 @@ as they most of the time do not affect the approximation quality of the mesh, but they also don't help because so many of their additional degrees of freedom are in fact constrained by hanging node constraints. That said, this is easy to fix: the Triangulation class takes an argument to its -constructor indicating a level of "mesh smoothing". Passing one of many -possible flags, this instructs the triangulation to refine some additional -cells, or not to refine some cells, so that the resulting mesh does not have +constructor indicating a level of "mesh smoothing". Passing one of many +possible flags, this instructs the triangulation to refine some additional +cells, or not to refine some cells, so that the resulting mesh does not have these artifacts. -The second problem is more severe: the mesh appears to lag the solution. +The second problem is more severe: the mesh appears to lag the solution. The underlying reason is that we only adapt the mesh once every fifth time step, and only allow for a single refinement in these cases. Whenever a source switches on, the solution had been very smooth in this area before and @@ -201,13 +201,13 @@ double mass_matrix_min_diag = std::numeric_limits::max(), SparseMatrixIterators::Iterator row_it (&mass_matrix, 0); -for(unsigned int m = 0; mvalue(), mass_matrix_min_diag); ++row_it; - + // check the off-diagonal elements for(; row_it != mass_matrix.end(m); ++row_it) mass_matrix_max_offdiag = std::max(row_it->value(), mass_matrix_max_offdiag); diff --git a/examples/step-3/CMakeLists.txt b/examples/step-3/CMakeLists.txt index ca2dc7dc5f..8187568a28 100644 --- a/examples/step-3/CMakeLists.txt +++ b/examples/step-3/CMakeLists.txt @@ -11,7 +11,7 @@ SET(TARGET "step-3") # you may want to either replace the following statement by something like # FILE(GLOB_RECURSE TARGET_SRC "source/*.cc") # FILE(GLOB_RECURSE TARGET_INC "include/*.h") -# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) +# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) # or switch altogether to the large project CMakeLists.txt file discussed # in the "CMake in user projects" page accessible from the "User info" # page of the documentation. diff --git a/examples/step-3/doc/results.dox b/examples/step-3/doc/results.dox index 607c098a75..e69746fc90 100644 --- a/examples/step-3/doc/results.dox +++ b/examples/step-3/doc/results.dox @@ -121,7 +121,7 @@ suggestions: GridGenerator::hyper_cube(), as before: @code for (auto &face : triangulation.active_face_iterators()) - if (std::fabs(face->center()(1) - (-1.0)) < 1e-12 || + if (std::fabs(face->center()(1) - (-1.0)) < 1e-12 || std::fabs(face->center()(1) - (1.0)) < 1e-12) face->set_boundary_id(1); @endcode @@ -227,14 +227,14 @@ suggestions: %HDF5 is a commonly used format that can be read by many scripting languages (e.g. R or Python). It is not difficult to get deal.II to produce some %HDF5 files that can then be used in external scripts to -postprocess some of the data generated by this program. Here are some +postprocess some of the data generated by this program. Here are some ideas on what is possible.

            Changing the output to .h5

            -To fully make use of the automation we first need to introduce a private variable for the number of -global refinement steps unsigned int n_refinement_steps , which will be used for the output filename. +To fully make use of the automation we first need to introduce a private variable for the number of +global refinement steps unsigned int n_refinement_steps , which will be used for the output filename. In make_grid() we then replace triangulation.refine_global(5); with @code n_refinement_steps = 5; @@ -243,8 +243,8 @@ triangulation.refine_global(n_refinement_steps); The deal.II library has two different %HDF5 bindings, one in the HDF5 namespace (for interfacing to general-purpose data files) and another one in DataOut (specifically for writing files for the -visualization of solutions). -Although the HDF5 deal.II binding supports both serial and MPI, the %HDF5 DataOut binding +visualization of solutions). +Although the HDF5 deal.II binding supports both serial and MPI, the %HDF5 DataOut binding only supports parallel output. For this reason we need to initialize an MPI communicator with only one processor. This is done by adding the following code. @@ -269,7 +269,7 @@ the original version of the tutorial produces; but, since %HDF5 is a more general file format, it can also easily be processed in scripting languages for other purposes. - +

            Adding the point value and the mean (see extension above) into the .h5 file

            After outputing the solution, the file can be opened again to include @@ -280,10 +280,10 @@ processed by some postprocessing script. information on the possible output options.) To make this happen, we first include the necessary header into our file: -@code +@code #include @endcode -Adding the following lines to the end +Adding the following lines to the end of our output routine adds the information about the value of the solution at a particular point, as well as the mean value of the solution, to our %HDF5 file: @@ -310,9 +310,9 @@ how this can, in particular, be done with the R programming language, a widely used language in statistical data analysis. (Similar things can also be done in Python, for example.) -If you are unfamiliar with R and ggplot2 you could check out the data carpentry course on R +If you are unfamiliar with R and ggplot2 you could check out the data carpentry course on R here. -Furthermore, since most search engines struggle with searches of the form "R + topic", +Furthermore, since most search engines struggle with searches of the form "R + topic", we recommend using the specializes service RSeek instead. @@ -334,15 +334,15 @@ print(h5f) @endcode This gives the following output @code{.unparsed} -HDF5 FILE +HDF5 FILE name / -filename +filename name otype dclass dim 0 cells H5I_DATASET INTEGER x 1024 -1 mean_value H5I_DATASET FLOAT 1 +1 mean_value H5I_DATASET FLOAT 1 2 nodes H5I_DATASET FLOAT x 1089 -3 point_value H5I_DATASET FLOAT 1 +3 point_value H5I_DATASET FLOAT 1 4 solution H5I_DATASET FLOAT x 1089 @endcode The datasets can be accessed by h5f\$name. The function @@ -350,8 +350,8 @@ The datasets can be accessed by h5f\$name. The function that is used to store our cells. We can see the following three matrices, as well as the two additional data points we added. -
              -
            • cells: a 4x1024 matrix that stores the (C++) vertex indices for each cell +
                +
              • cells: a 4x1024 matrix that stores the (C++) vertex indices for each cell
              • nodes: a 2x1089 matrix storing the position values (x,y) for our cell vertices
              • solution: a 1x1089 matrix storing the values of our solution at each vertex
              @@ -359,7 +359,7 @@ Now we can use this data to generate various plots. Plotting with ggplot2 usuall At first the data needs to be manipulated and added to a data.frame. After that, a ggplot object is constructed and manipulated by adding plot elements to it. -nodes and cells contain all the information we need to plot our grid. +nodes and cells contain all the information we need to plot our grid. The following code wraps all the data into one dataframe for plotting our grid: @code{.r} # Counting in R starts at 1 instead of 0, so we need to increment all @@ -383,7 +383,7 @@ With the finished dataframe we have everything we need to plot our grid: @code{.r} pdf (paste("grid_",refinement,".pdf",sep=""),width = 5,height = 5) # Open new PDF file plt <- ggplot(meshdata,aes(x=x,y=y,group=id)) # Construction of our plot - # object, at first only data + # object, at first only data plt <- plt + geom_polygon(fill="white",colour="black") # Actual plotting of the grid as polygons plt <- plt + ggtitle(paste("grid at refinement level #",refinement)) @@ -406,7 +406,7 @@ We can also visualize the solution itself, and this is going to look more interesting. To make a 2D pseudocolor plot of our solution we will use geom_raster. This function needs a structured grid, i.e. uniform in x and y directions. -Luckily our data at this point is structured in the right way. +Luckily our data at this point is structured in the right way. The following code plots a pseudocolor representation of our surface into a new PDF: @code{.r} pdf (paste("pseudocolor_",refinement,".pdf",sep=""),width = 5,height = 4.2) # Open new PDF file @@ -428,10 +428,10 @@ This is now going to look as follows: -
            • +
            • For plotting the converge curves we need to re-run the C++ code multiple times with different values for n_refinement_steps -starting from 1. +starting from 1. Since every file only contains a single data point we need to loop over them and concatenate the results into a single vector. @code{.r} n_ref <- 8 # Maximum refinement level for which results are existing @@ -492,5 +492,5 @@ to zero: - +
            diff --git a/examples/step-33/doc/results.dox b/examples/step-33/doc/results.dox index f728f4d0fd..7b423499e0 100644 --- a/examples/step-33/doc/results.dox +++ b/examples/step-33/doc/results.dox @@ -261,7 +261,7 @@ faster.

            Cache the explicit part of residual

            The residual calculated in ConservationLaw::assemble_cell_term function -reads +reads $R_i = \left(\frac{\mathbf{w}^{k}_{n+1} - \mathbf{w}_n}{\delta t} , \mathbf{z}_i \right)_K + \theta \mathbf{B}({\mathbf{w}^{k}_{n+1}})(\mathbf{z}_i)_K + diff --git a/examples/step-34/doc/intro.dox b/examples/step-34/doc/intro.dox index 70dce2996a..37858f099a 100644 --- a/examples/step-34/doc/intro.dox +++ b/examples/step-34/doc/intro.dox @@ -275,7 +275,7 @@ The reason why this is possible can be understood if we consider the fact that the solution of a pure Neumann problem is known up to an arbitrary constant $c$, which means that, if we set the Neumann data to be zero, then any constant $\phi = \phi_\infty$ will be a solution. -Inserting the constant solution and the Neumann boundary condition in the +Inserting the constant solution and the Neumann boundary condition in the boundary integral equation, we have @f{align*} \alpha\left(\mathbf{x}\right)\phi\left(\mathbf{x}\right) @@ -287,7 +287,7 @@ boundary integral equation, we have +\int_{\Gamma}\frac{ \partial G(\mathbf{y}-\mathbf{x}) }{\partial \mathbf{n}_y} \, ds_y \right] @f} -The integral on $\Gamma_\infty$ is unity, see above, so division by the constant $\phi_\infty$ gives us the explicit +The integral on $\Gamma_\infty$ is unity, see above, so division by the constant $\phi_\infty$ gives us the explicit expression above for $\alpha(\mathbf{x})$. While this example program is really only focused on the solution of the diff --git a/examples/step-36/doc/intro.dox b/examples/step-36/doc/intro.dox index 6c99ce5fef..d6d97f6008 100644 --- a/examples/step-36/doc/intro.dox +++ b/examples/step-36/doc/intro.dox @@ -3,7 +3,7 @@ This program was contributed by Toby D. Young and Wolfgang Bangerth. - +

            Preamble

            The problem we want to solve in this example is an eigenspectrum @@ -30,7 +30,7 @@ Under suitable conditions, the above equations have a set of solutions $\Psi_\ell,\varepsilon_\ell$, $\ell\in {\cal I}$, where $\cal I$ can be a finite or infinite set (and in the latter case it may be a discrete or sometimes at least in part a continuous set). In either case, let us note that -there is +there is no longer just a single solution, but a set of solutions (the various eigenfunctions and corresponding eigenvalues) that we want to compute. The problem of numerically finding all eigenvalues @@ -59,8 +59,8 @@ function $\Psi(\mathbf x)$ that satisfies a relation of the (nondimensionalized) form @f{align*} [-\Delta + V(\mathbf x)] \Psi(\mathbf x) &= \varepsilon \Psi(\mathbf x) \qquad &&\text{in}\ -\Omega\quad, \\ \Psi &= 0 &&\text{on}\ \partial\Omega\quad. -@f} +\Omega\quad, \\ \Psi &= 0 &&\text{on}\ \partial\Omega\quad. +@f} As a consequence, this particle can only exist in a certain number of eigenstates that correspond to the energy eigenvalues $\varepsilon_\ell$ admitted as solutions of this equation. The @@ -99,23 +99,23 @@ are forced to have a zero value, after all. On the other hand, the finite element method gains much of its power and simplicity from the fact that we just do the same thing on every cell, without having to think too much about where a cell is, whether it bounds -on a less refined cell and consequently has a hanging node, or is +on a less refined cell and consequently has a hanging node, or is adjacent to the boundary. All such checks would make the assembly of finite element linear systems unbearably difficult to write and -even more so to read. +even more so to read. Consequently, of course, when you distribute degrees of freedom with your DoFHandler object, you don't care whether some of the degrees of freedom you enumerate are at a Dirichlet boundary. They all get numbers. We just have to take care of these degrees of freedom at a later time when we apply boundary values. There are two basic ways -of doing this (either using MatrixTools::apply_boundary_values() +of doing this (either using MatrixTools::apply_boundary_values() after assembling the linear system, or using AffineConstraints::distribute_local_to_global() during assembly; see the @ref constraints "constraints module" for more information), but both result in the same: a linear system that has a total number of rows equal to the number of all degrees of freedom, -including those that lie on the boundary. However, degrees of +including those that lie on the boundary. However, degrees of freedom that are constrained by Dirichlet conditions are separated from the rest of the linear system by zeroing out the corresponding row and column, putting a single positive entry on the diagonal, @@ -137,7 +137,7 @@ a right hand side would look like this: F_i \\ F_b \end{pmatrix}. @f} -Here, subscripts $i$ and $b$ correspond to interior and boundary +Here, subscripts $i$ and $b$ correspond to interior and boundary degrees of freedom, respectively. The interior degrees of freedom satisfy the linear system $A_i U_i=F_i$ which yields the correct solution in the interior, and boundary values are determined by @@ -145,10 +145,10 @@ $U_b = D_b^{-1} F_b$ where $D_b$ is a diagonal matrix that results from the process of eliminating boundary degrees of freedom, and $F_b$ is chosen in such a way that $U_{b,j}=D_{b,jj}^{-1} F_{b,j}$ has the correct boundary values for every boundary degree of freedom -$j$. (For the curious, the entries of the +$j$. (For the curious, the entries of the matrix $D_b$ result from adding modified local contributions to the -global matrix where for the local matrices the diagonal elements, if non-zero, -are set to their absolute value; otherwise, they are set to the average of +global matrix where for the local matrices the diagonal elements, if non-zero, +are set to their absolute value; otherwise, they are set to the average of absolute values of the diagonal. This process guarantees that the entries of $D_b$ are positive and of a size comparable to the rest of the diagonal entries, ensuring that the resulting matrix does not incur unreasonable @@ -207,7 +207,7 @@ On the other hand, it may happen that we find that one of the eigenvalues we compute in this program happens to be in this interval, and in that case we would not know immediately whether it is a spurious or a true eigenvalue. In that case, one could simply scale the diagonal elements of -either matrix after computing the two matrices, +either matrix after computing the two matrices, thus shifting them away from the frequency of interest in the eigen-spectrum. This can be done by using the following code, making sure that all spurious eigenvalues are exactly equal to $1.234\cdot 10^5$: @@ -218,18 +218,18 @@ eigenvalues are exactly equal to $1.234\cdot 10^5$: stiffness_matrix.set(i, i, 1.234e5); mass_matrix.set(i, i, 1); } -@endcode +@endcode However, this strategy is not pursued here as the spurious eigenvalues -we get from our program as-is happen to be greater than the lowest +we get from our program as-is happen to be greater than the lowest five that we will calculate and are interested in.

            Implementation details

            -The program below is essentially just a slightly modified version of +The program below is essentially just a slightly modified version of step-4. The things that are different are the following: -
              +
              • The main class (named EigenvalueProblem) now no longer has a single solution vector, but a whole set of vectors for @@ -265,5 +265,5 @@ formula.
              -The rest of the program follows in a pretty straightforward way from +The rest of the program follows in a pretty straightforward way from step-4. diff --git a/examples/step-4/CMakeLists.txt b/examples/step-4/CMakeLists.txt index ed79dc0ff3..dcc243e2a0 100644 --- a/examples/step-4/CMakeLists.txt +++ b/examples/step-4/CMakeLists.txt @@ -11,7 +11,7 @@ SET(TARGET "step-4") # you may want to either replace the following statement by something like # FILE(GLOB_RECURSE TARGET_SRC "source/*.cc") # FILE(GLOB_RECURSE TARGET_INC "include/*.h") -# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) +# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) # or switch altogether to the large project CMakeLists.txt file discussed # in the "CMake in user projects" page accessible from the "User info" # page of the documentation. diff --git a/examples/step-4/doc/results.dox b/examples/step-4/doc/results.dox index f5bd1906de..2973128a2a 100644 --- a/examples/step-4/doc/results.dox +++ b/examples/step-4/doc/results.dox @@ -31,7 +31,7 @@ solution steps when you actually run the program. The program produces two files: solution-2d.vtk and solution-3d.vtk, which can be viewed using the programs Visit or Paraview (in case you do not have these programs, you can easily -change the +change the output format in the program to something which you can view more easily). Visualizing solutions is a bit of an art, but it can also be fun, so you should play around with your favorite visualization tool to get familiar @@ -90,7 +90,7 @@ used to generate these pictures, Visit, by default puts tick marks on every axis, puts a big fat label "X Axis" on the $x$ axis and similar for the other axes, shows the file name from which the data was taken in the top left and the name of the user doing so and the time and date on the bottom right. None -of this is important +of this is important here: the axes are equally easy to make out because the tripod at the bottom left is still visible, and we know from the program that the domain is $[-1,1]^3$, so there is no need for tick marks. As a consequence, I have diff --git a/examples/step-42/doc/intro.dox b/examples/step-42/doc/intro.dox index aaabb4fbc7..527516706d 100644 --- a/examples/step-42/doc/intro.dox +++ b/examples/step-42/doc/intro.dox @@ -413,7 +413,7 @@ Other than that, let us comment only on the following aspects:
            • The program allows you to select from two different coarse meshes through the parameter file. These are either a cube $[0,1]^3$ or a half sphere with the open side facing the positive $z$ direction. - +
            • In either case, we will assume the convention that the part of the boundary that may be in contact with the obstacle has boundary indicator one. For both kinds of meshes, we assume that this is a free diff --git a/examples/step-42/doc/results.dox b/examples/step-42/doc/results.dox index 09d74c6a2d..67a79e6626 100644 --- a/examples/step-42/doc/results.dox +++ b/examples/step-42/doc/results.dox @@ -13,29 +13,29 @@ box as domain) on 16 cores produces output like this: Cycle 0: Number of active cells: 512 Number of degrees of freedom: 2187 - + Newton iteration 1 Updating active set... Size of active set: 1 - Assembling system... - Solving system... + Assembling system... + Solving system... Error: 173.076 -> 1.64265e-06 in 7 Bicgstab iterations. Accepting Newton solution with residual: 1.64265e-06 - + Newton iteration 2 Updating active set... Size of active set: 1 - Assembling system... - Solving system... + Assembling system... + Solving system... Error: 57.3622 -> 3.23721e-07 in 8 Bicgstab iterations. Accepting Newton solution with residual: 24.9028 Active set did not change! - + Newton iteration 3 Updating active set... Size of active set: 1 - Assembling system... - Solving system... + Assembling system... + Solving system... Error: 24.9028 -> 9.94326e-08 in 7 Bicgstab iterations. Residual of the non-contact part of the system: 1.63333 with a damping parameter alpha = 1 @@ -46,8 +46,8 @@ Cycle 0: Newton iteration 6 Updating active set... Size of active set: 1 - Assembling system... - Solving system... + Assembling system... + Solving system... Error: 1.43188e-07 -> 3.56218e-16 in 8 Bicgstab iterations. Residual of the non-contact part of the system: 4.298e-14 with a damping parameter alpha = 1 @@ -82,22 +82,22 @@ Contact force = 37.3058 Cycle 3: Number of active cells: 14652 Number of degrees of freedom: 52497 - + Newton iteration 1 Updating active set... Size of active set: 145 - Assembling system... - Solving system... + Assembling system... + Solving system... Error: 296.309 -> 2.72484e-06 in 10 Bicgstab iterations. Accepting Newton solution with residual: 2.72484e-06 - + ... Newton iteration 10 Updating active set... Size of active set: 145 - Assembling system... - Solving system... + Assembling system... + Solving system... Error: 2.71541e-07 -> 1.5428e-15 in 27 Bicgstab iterations. Residual of the non-contact part of the system: 1.89261e-13 with a damping parameter alpha = 1 @@ -172,11 +172,11 @@ inequality is active): The picture shows the adaptive refinement and as well how much a cell is plastified during the contact with the ball. Remember that we consider the norm of the deviator part of the stress in each quadrature point to -see if there is elastic or plastic behavior. +see if there is elastic or plastic behavior. The blue color means that this cell contains only elastic quadrature points in contrast to the red cells in which all quadrature points are plastified. -In the middle of the top surface - +In the middle of the top surface - where the mesh is finest - a very close look shows the dimple caused by the obstacle. This is the result of the move_mesh() function. However, because the indentation of the obstacles we consider here diff --git a/examples/step-44/doc/intro.dox b/examples/step-44/doc/intro.dox index 95ce4fe00d..a105f1faef 100644 --- a/examples/step-44/doc/intro.dox +++ b/examples/step-44/doc/intro.dox @@ -3,7 +3,7 @@ This program was contributed by Jean-Paul Pelteret and Andrew McBride.
              This material is based upon work supported by the German Science Foundation (Deutsche -Forschungsgemeinschaft, DFG), grant STE 544/39-1, and the National Research Foundation of South Africa. +Forschungsgemeinschaft, DFG), grant STE 544/39-1, and the National Research Foundation of South Africa.               @dealiiTutorialDOI{10.5281/zenodo.439772,https://zenodo.org/badge/DOI/10.5281/zenodo.439772.svg} @@ -11,10 +11,10 @@ Forschungsgemeinschaft, DFG), grant STE 544/39-1, and the National Research Fou

              Introduction

              -The subject of this tutorial is nonlinear solid mechanics. -Classical single-field approaches (see e.g. step-18) can not correctly describe the response of quasi-incompressible materials. +The subject of this tutorial is nonlinear solid mechanics. +Classical single-field approaches (see e.g. step-18) can not correctly describe the response of quasi-incompressible materials. The response is overly stiff; a phenomenon known as locking. -Locking problems can be circumvented using a variety of alternative strategies. +Locking problems can be circumvented using a variety of alternative strategies. One such strategy is the three-field formulation. It is used here to model the three-dimensional, fully-nonlinear (geometrical and material) response of an isotropic continuum body. The material response is approximated as hyperelastic. @@ -29,21 +29,21 @@ Step-18 does, however, describe many of the key concepts to implement elasticity We begin with a crash-course in nonlinear kinematics. For the sake of simplicity, we restrict our attention to the quasi-static problem. Thereafter, various key stress measures are introduced and the constitutive model described. -We then describe the three-field formulation in detail prior to explaining the structure of the class used to manage the material. +We then describe the three-field formulation in detail prior to explaining the structure of the class used to manage the material. The setup of the example problem is then presented. @note This tutorial has been developed (and is described in the introduction) for the problem of elasticity in three dimensions. While the space dimension could be changed in the main() routine, care needs to be taken. Two-dimensional elasticity problems, in general, exist only as idealizations of three-dimensional ones. - That is, they are either plane strain or plane stress. - The assumptions that follow either of these choices needs to be consistently imposed. + That is, they are either plane strain or plane stress. + The assumptions that follow either of these choices needs to be consistently imposed. For more information see the note in step-8.

              List of references

              The three-field formulation implemented here was pioneered by Simo et al. (1985) and is known as the mixed Jacobian-pressure formulation. Important related contributions include those by Simo and Taylor (1991), and Miehe (1994). -The notation adopted here draws heavily on the excellent overview of the theoretical aspects of nonlinear solid mechanics by Holzapfel (2001). +The notation adopted here draws heavily on the excellent overview of the theoretical aspects of nonlinear solid mechanics by Holzapfel (2001). A nice overview of issues pertaining to incompressible elasticity (at small strains) is given in Hughes (2000).
                @@ -276,7 +276,7 @@ The fictitious Kirchhoff stress tensor $\overline{\boldsymbol{\tau}}$ is defined pressure in solid mechanics as $p = - 1/3 \textrm{tr} \boldsymbol{\sigma} = - 1/3 J^{-1} \textrm{tr} \boldsymbol{\tau}$. Here $p$ is the hydrostatic pressure. -We make use of the pressure response throughout this tut (although we refer to it as the pressure). +We make use of the pressure response throughout this tut (although we refer to it as the pressure).

                Neo-Hookean materials

                @@ -408,14 +408,14 @@ for all virtual displacements $\delta \mathbf{u} \in H^1(\Omega)$ subject to the One should note that the definitions of the volumetric Kirchhoff stress in the three field formulation $\boldsymbol{\tau}_{\textrm{vol}} \equiv \widetilde{p} J \mathbf{I}$ - and the subsequent volumetric tangent differs slightly from the general form given in the section on hyperelastic materials where + and the subsequent volumetric tangent differs slightly from the general form given in the section on hyperelastic materials where $\boldsymbol{\tau}_{\textrm{vol}} \equiv p J\mathbf{I}$. This is because the pressure $\widetilde{p}$ is now a primary field as opposed to a constitutively derived quantity. -One needs to carefully distinguish between the primary fields and those obtained from the constitutive relations. +One needs to carefully distinguish between the primary fields and those obtained from the constitutive relations. @note Although the variables are all expressed in terms of spatial quantities, the domain of integration is the initial configuration. This approach is called a total-Lagrangian formulation . -The approach given in step-18, where the domain of integration is the current configuration, could be called an updated Lagrangian formulation . +The approach given in step-18, where the domain of integration is the current configuration, could be called an updated Lagrangian formulation . The various merits of these two approaches are discussed widely in the literature. It should be noted however that they are equivalent. @@ -439,28 +439,28 @@ The third is the definition of the pressure $\widetilde{p}$. \int_{\Omega} [-\mathrm{grad}\delta \mathbf{u}:\boldsymbol{\sigma} + \delta \mathbf{u} \cdot\mathbf{b}^\text{p}]~\mathrm{d}v + \int_{\partial \Omega} \delta \mathbf{u} \cdot \mathbf{t}^\text{p}~\mathrm{d}a \\ &= -- \int_{\Omega_0} \mathrm{grad}\delta \mathbf{u}:\boldsymbol{\tau}~\mathrm{d}V +- \int_{\Omega_0} \mathrm{grad}\delta \mathbf{u}:\boldsymbol{\tau}~\mathrm{d}V + \int_{\Omega_0} \delta \mathbf{u} \cdot J\mathbf{b}^\text{p}~\mathrm{d}V + \int_{\partial \Omega_0} \delta \mathbf{u} \cdot \mathbf{T}^\text{p}~\mathrm{d}A \\ &= -- \int_{\Omega_0} \mathrm{grad}\delta \mathbf{u}:\boldsymbol{\tau}~\mathrm{d}V +- \int_{\Omega_0} \mathrm{grad}\delta \mathbf{u}:\boldsymbol{\tau}~\mathrm{d}V + \int_{\Omega_0} \delta \mathbf{u} \cdot \mathbf{B}^\text{p}~\mathrm{d}V + \int_{\partial \Omega_{0,\sigma}} \delta \mathbf{u} \cdot \mathbf{T}^\text{p}~\mathrm{d}A \\ &= -- \int_{\Omega_0} [\mathrm{grad}\delta\mathbf{u}]^{\text{sym}} :\boldsymbol{\tau}~\mathrm{d}V +- \int_{\Omega_0} [\mathrm{grad}\delta\mathbf{u}]^{\text{sym}} :\boldsymbol{\tau}~\mathrm{d}V + \int_{\Omega_0} \delta \mathbf{u} \cdot \mathbf{B}^\text{p}~\mathrm{d}V + \int_{\partial \Omega_{0,\sigma}} \delta \mathbf{u} \cdot \mathbf{T}^\text{p}~\mathrm{d}A \, , @f} -where +where $[\mathrm{grad}\delta\mathbf{u}]^{\text{sym}} = 1/2[ \mathrm{grad}\delta\mathbf{u} + [\mathrm{grad}\delta\mathbf{u}]^T] $. We will use an iterative Newton-Raphson method to solve the nonlinear residual equation $R$. For the sake of simplicity we assume dead loading, i.e. the loading does not change due to the deformation. The change in a quantity between the known state at $t_{\textrm{n}-1}$ -and the currently unknown state at $t_{\textrm{n}}$ is denoted +and the currently unknown state at $t_{\textrm{n}}$ is denoted $\varDelta \{ \bullet \} = { \{ \bullet \} }^{\textrm{n}} - { \{ \bullet \} }^{\textrm{n-1}}$. -The value of a quantity at the current iteration $\textrm{i}$ is denoted +The value of a quantity at the current iteration $\textrm{i}$ is denoted ${ \{ \bullet \} }^{\textrm{n}}_{\textrm{i}} = { \{ \bullet \} }_{\textrm{i}}$. The incremental change between iterations $\textrm{i}$ and $\textrm{i}+1$ is denoted $d \{ \bullet \} \dealcoloneq \{ \bullet \}_{\textrm{i}+1} - \{ \bullet \}_{\textrm{i}}$. @@ -537,7 +537,7 @@ The three-field formulation used here is effective for quasi-incompressible mate that is where $\nu \rightarrow 0.5$ (where $\nu$ is Poisson's ratio), subject to a good choice of the interpolation fields for $\mathbf{u},~\widetilde{p}$ and $\widetilde{J}$. -Typically a choice of $Q_n \times DGPM_{n-1} \times DGPM_{n-1}$ is made. +Typically a choice of $Q_n \times DGPM_{n-1} \times DGPM_{n-1}$ is made. Here $DGPM$ is the FE_DGPMonomial class. A popular choice is $Q_1 \times DGPM_0 \times DGPM_0$ which is known as the mean dilatation method (see Hughes (2000) for an intuitive discussion). This code can accommodate a $Q_n \times DGPM_{n-1} \times DGPM_{n-1}$ formulation. @@ -586,11 +586,11 @@ where \end{bmatrix}}_{ \mathbf{\mathsf{F}}(\mathbf{\Xi}_{\textrm{i}}) } \, . @f} -There are no derivatives of the pressure and dilatation (primary) variables present in the formulation. +There are no derivatives of the pressure and dilatation (primary) variables present in the formulation. Thus the discontinuous finite element interpolation of the pressure and dilatation yields a block diagonal matrix for $\mathbf{\mathsf{K}}_{\widetilde{p}\widetilde{J}}$, -$\mathbf{\mathsf{K}}_{\widetilde{J}\widetilde{p}}$ and +$\mathbf{\mathsf{K}}_{\widetilde{J}\widetilde{p}}$ and $\mathbf{\mathsf{K}}_{\widetilde{J}\widetilde{J}}$. Therefore we can easily express the fields $\widetilde{p}$ and $\widetilde{J}$ on each cell simply by inverting a local matrix and multiplying it by the local right hand @@ -635,10 +635,10 @@ where Note that due to the choice of $\widetilde{p}$ and $\widetilde{J}$ as discontinuous at the element level, all matrices that need to be inverted are defined at the element level. The procedure to construct the various contributions is as follows: -- Construct $\mathbf{\mathsf{K}}$. +- Construct $\mathbf{\mathsf{K}}$. - Form $\mathbf{\mathsf{K}}_{\widetilde{p}\widetilde{J}}^{-1}$ for element and store where $\mathbf{\mathsf{K}}_{\widetilde{p}\widetilde{J}}$ was stored in $\mathbf{\mathsf{K}}$. - Form $\overline{\overline{\mathbf{\mathsf{K}}}}$ and add to $\mathbf{\mathsf{K}}_{uu}$ to get $\mathbf{\mathsf{K}}_{\textrm{con}}$ -- The modified system matrix is called ${\mathbf{\mathsf{K}}}_{\textrm{store}}$. +- The modified system matrix is called ${\mathbf{\mathsf{K}}}_{\textrm{store}}$. That is @f[ \mathbf{\mathsf{K}}_{\textrm{store}} @@ -655,10 +655,10 @@ The procedure to construct the various contributions is as follows:

                The material class

                -A good object-oriented design of a Material class would facilitate the extension of this tutorial to a wide range of material types. +A good object-oriented design of a Material class would facilitate the extension of this tutorial to a wide range of material types. In this tutorial we simply have one Material class named Material_Compressible_Neo_Hook_Three_Field. Ideally this class would derive from a class HyperelasticMaterial which would derive from the base class Material. -The three-field nature of the formulation used here also complicates the matter. +The three-field nature of the formulation used here also complicates the matter. The Helmholtz free energy function for the three field formulation is $\Psi = \Psi_\text{vol}(\widetilde{J}) + \Psi_\text{iso}(\overline{\mathbf{b}})$. The isochoric part of the Kirchhoff stress ${\boldsymbol{\tau}}_{\text{iso}}(\overline{\mathbf{b}})$ is identical to that obtained using a one-field formulation for a hyperelastic material. @@ -666,10 +666,10 @@ However, the volumetric part of the free energy is now a function of the primary Thus, for a three field formulation the constitutive response for the volumetric part of the Kirchhoff stress ${\boldsymbol{\tau}}_{\text{vol}}$ (and the tangent) is not given by the hyperelastic constitutive law as in a one-field formulation. One can label the term $\boldsymbol{\tau}_{\textrm{vol}} \equiv \widetilde{p} J \mathbf{I}$ -as the volumetric Kirchhoff stress, but the pressure $\widetilde{p}$ is not derived from the free energy; it is a primary field. +as the volumetric Kirchhoff stress, but the pressure $\widetilde{p}$ is not derived from the free energy; it is a primary field. -In order to have a flexible approach, it was decided that the Material_Compressible_Neo_Hook_Three_Field would still be able to calculate and return a volumetric Kirchhoff stress and tangent. -In order to do this, we choose to store the interpolated primary fields $\widetilde{p}$ and $\widetilde{J}$ in the Material_Compressible_Neo_Hook_Three_Field class associated with the quadrature point. +In order to have a flexible approach, it was decided that the Material_Compressible_Neo_Hook_Three_Field would still be able to calculate and return a volumetric Kirchhoff stress and tangent. +In order to do this, we choose to store the interpolated primary fields $\widetilde{p}$ and $\widetilde{J}$ in the Material_Compressible_Neo_Hook_Three_Field class associated with the quadrature point. This decision should be revisited at a later stage when the tutorial is extended to account for other materials. @@ -691,6 +691,6 @@ For such a choice of material properties a conventional single-field $Q_1$ appro That is, the response would be overly stiff. The initial and final configurations are shown in the image above. Using symmetry, we solve for only one quarter of the geometry (i.e. a cube with dimension $0.001$). -The inner-quarter of the upper surface of the domain is subject to a load of $p_0$. - - +The inner-quarter of the upper surface of the domain is subject to a load of $p_0$. + + diff --git a/examples/step-44/doc/results.dox b/examples/step-44/doc/results.dox index 6f2ad7882c..2cf55417d3 100644 --- a/examples/step-44/doc/results.dox +++ b/examples/step-44/doc/results.dox @@ -298,9 +298,9 @@ There are a number of obvious extensions for this work: (detection and stress calculations) itself. An alternative to additional penalty terms in the free-energy functional would be to use active set methods such as the one used in step-41. -- The complete condensation procedure using LinearOperators has been - coded into the linear solver routine. This could also have been - achieved through the application of the schur_complement() +- The complete condensation procedure using LinearOperators has been + coded into the linear solver routine. This could also have been + achieved through the application of the schur_complement() operator to condense out one or more of the fields in a more automated manner. - Finally, adaptive mesh refinement, as demonstrated in step-6 and diff --git a/examples/step-5/CMakeLists.txt b/examples/step-5/CMakeLists.txt index 80388c2b36..bf8e5b4686 100644 --- a/examples/step-5/CMakeLists.txt +++ b/examples/step-5/CMakeLists.txt @@ -11,7 +11,7 @@ SET(TARGET "step-5") # you may want to either replace the following statement by something like # FILE(GLOB_RECURSE TARGET_SRC "source/*.cc") # FILE(GLOB_RECURSE TARGET_INC "include/*.h") -# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) +# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) # or switch altogether to the large project CMakeLists.txt file discussed # in the "CMake in user projects" page accessible from the "User info" # page of the documentation. diff --git a/examples/step-5/doc/results.dox b/examples/step-5/doc/results.dox index fdea08db7a..65eb360255 100644 --- a/examples/step-5/doc/results.dox +++ b/examples/step-5/doc/results.dox @@ -74,7 +74,7 @@ format. They are depicted in the following: Due to the variable coefficient (the curvature there is reduced by the same factor by which the coefficient is increased), the top region of the solution is flattened. The gradient of the solution is -discontinuous along the interface, although this is not very clearly +discontinuous along the interface, although this is not very clearly visible in the pictures above. We will look at this in more detail in the next example. diff --git a/examples/step-51/doc/intro.dox b/examples/step-51/doc/intro.dox index 9b687ccea0..85b4bbce94 100644 --- a/examples/step-51/doc/intro.dox +++ b/examples/step-51/doc/intro.dox @@ -29,7 +29,7 @@ for systems of equations in 2 or 3 dimensions.

                Reducing the size of the linear system

                To alleviate the computational cost of solving such large linear systems, the hybridizable discontinuous Galerkin (HDG) methodology was introduced -by Cockburn and co-workers (see the references in the recent HDG overview +by Cockburn and co-workers (see the references in the recent HDG overview article by Nguyen and Peraire @cite Ngu2012). The HDG method achieves this goal by formulating the mathematical problem using @@ -50,7 +50,7 @@ The Dirichlet-to-Neumann map concept then permits the following solution procedu skeleton of the triangulation. The global problem is then to solve for the trace values, which are the only globally coupled unknowns.
              1. Use the known skeleton values as Dirichlet data for solving local -element-level solutions. This is known as the 'local solver', and is an +element-level solutions. This is known as the 'local solver', and is an embarrassingly parallel element-by-element solution process.
              @@ -58,17 +58,17 @@ element-level solutions. This is known as the 'local solver', and is an The above procedure also has a linear algebra interpretation---referred to as static condensation---that was exploited to reduce the size of the global linear system by Guyan in the context of continuous Finite Elements -@cite G65, and by Fraeijs de Veubeke for mixed methods @cite F65. In the +@cite G65, and by Fraeijs de Veubeke for mixed methods @cite F65. In the latter case (mixed formulation), the system reduction was achieved through the use of discontinuous fluxes combined with the introduction of an additional -auxiliary hybrid variable that approximates the trace of the unknown +auxiliary hybrid variable that approximates the trace of the unknown at the boundary of every element. This procedure became known as hybridization and---by analogy---is the reason why the local discontinuous Galerkin method -introduced by Cockburn, Gopalakrishnan, and Lazarov in 2009 @cite CGL2009, and -subsequently developed by their collaborators, eventually came to be known as +introduced by Cockburn, Gopalakrishnan, and Lazarov in 2009 @cite CGL2009, and +subsequently developed by their collaborators, eventually came to be known as the hybridizable discontinuous Galerkin (HDG) method. -Let us write the complete linear system associated to the HDG problem as a +Let us write the complete linear system associated to the HDG problem as a block system with the discrete DG (cell interior) variables $U$ as first block and the skeleton (face) variables $\Lambda$ as the second block: @f{eqnarray*} diff --git a/examples/step-52/doc/intro.dox b/examples/step-52/doc/intro.dox index 4164ba63e9..da38d817aa 100644 --- a/examples/step-52/doc/intro.dox +++ b/examples/step-52/doc/intro.dox @@ -13,7 +13,7 @@ This program shows how to use Runge-Kutta methods to solve a time-dependent problem. It solves a small variation of the heat equation discussed first in step-26 but, since the purpose of this program is only to demonstrate using more advanced ways to interface with deal.II's time stepping algorithms, only -solves a simple problem on a uniformly refined mesh. +solves a simple problem on a uniformly refined mesh.

              Problem statement

              @@ -32,10 +32,10 @@ fissible and therefore, the neutron flux satisfies the following equation: @f} augmented by appropriate boundary conditions. Here, $v$ is the velocity of neutrons (for simplicity we assume it is equal to 1 which can be achieved by -simply scaling the time variable), $D$ is the diffusion coefficient, +simply scaling the time variable), $D$ is the diffusion coefficient, $\Sigma_a$ is the absorption cross section, and $S$ is a source. Because we are only interested in the time dependence, we assume that $D$ and $\Sigma_a$ are -constant. +constant. Since this program only intends to demonstrate how to use advanced time stepping algorithms, we will only look for the solutions of relatively simple @@ -84,7 +84,7 @@ of nodal coefficients $U(t)$ for a variable of the form u_h(x,t) = \sum_j U_j(t) \varphi_j(x) @f} with spatial shape functions $\varphi_j(x)$, then multiplying an equation of -the form +the form @f{eqnarray*} \frac{\partial u(x,t)}{\partial t} = q(t,u(x,t)) @f} @@ -98,7 +98,7 @@ where $M$ is the mass matrix and $f(t,U)$ is the spatially discretized version of $q(t,u(x,t))$ (where $q$ is typically the place where spatial derivatives appear, but this is not of much concern for the moment given that we only consider time derivatives). In other words, this form fits the general -scheme above if we write +scheme above if we write @f{eqnarray*} \frac{dy}{dt} = g(t,y) = M^{-1}f(t,y). @f} @@ -131,14 +131,14 @@ $a_{ii}=0, i=1,\ldots,s$.
            • Implicit Runge-Kutta; this class of methods require the solution of a possibly nonlinear system the stages $k_i$ above, i.e., they have $a_{ii}\neq 0$ for at least one of the stages $i=1,\ldots,s$. -
          +
      Many well known time stepping schemes that one does not typically associate with the names Runge or Kutta can in fact be written in a way so that they, too, can be expressed in these categories. They oftentimes represent the lowest-order members of these families. -

      Explicit Runge-Kutta methods

      +

      Explicit Runge-Kutta methods

      These methods, only require a function to evaluate $M^{-1}f(t,y)$ but not (as implicit methods) to solve an equation that involves @@ -163,7 +163,7 @@ This class of methods include Heun-Euler, Bogacki-Shampine, Dormand-Prince (ode4 Matlab and often abbreviated as RK45 to indicate that the lower and higher order methods used here are 4th and 5th order Runge-Kutta methods, respectively), Fehlberg, and Cash-Karp. - + At the time of the writing, only embedded explicit methods have been implemented. @@ -174,8 +174,8 @@ form $\alpha y = f(t,y)$ for $y$ in each (sub-)timestep. Internally, this is done using a Newton-type method and, consequently, they require that the user provide functions that can evaluate $M^{-1}f(t,y)$ and -$\left(I-\tau M^{-1} \frac{\partial f}{\partial y}\right)^{-1}$ or equivalently -$\left(M - \tau \frac{\partial f}{\partial y}\right)^{-1} M$. +$\left(I-\tau M^{-1} \frac{\partial f}{\partial y}\right)^{-1}$ or equivalently +$\left(M - \tau \frac{\partial f}{\partial y}\right)^{-1} M$. The particular form of this operator results from the fact that each Newton step requires the solution of an equation of the form @@ -183,7 +183,7 @@ step requires the solution of an equation of the form \left(M - \tau \frac{\partial f}{\partial y}\right) \Delta y = -M h(t,y) @f} -for some (given) $h(t,y)$. Implicit methods are +for some (given) $h(t,y)$. Implicit methods are always stable, regardless of the time step size, but too large time steps of course affect the accuracy of the solution, even if the numerical solution remains stable and bounded. @@ -241,7 +241,7 @@ important to remember the following issues:
      1. You will need to project the solution to the new mesh when the mesh is changed. Of course, - the mesh + the mesh used should be the same from the beginning to the end of each time step, a question that arises because Runge-Kutta methods use multiple evaluations of the equations within each time step. diff --git a/examples/step-53/doc/intro.dox b/examples/step-53/doc/intro.dox index cb06647009..35f52a320e 100644 --- a/examples/step-53/doc/intro.dox +++ b/examples/step-53/doc/intro.dox @@ -36,7 +36,7 @@ these cases: One could cite many more examples of complicated geometries in which one wants to pose and solve a partial differential equation. What this shows is that the "real" world is much more complicated than what we have shown in almost all of -the tutorial programs preceding this one. +the tutorial programs preceding this one. This program is therefore devoted to showing how one deals with complex geometries using a concrete application. In particular, what it shows is how @@ -100,7 +100,7 @@ the domain as a whole is not a chart (e.g., the surface of a sphere), then it can often be described as a collection of charts (e.g., the northern hemisphere and the southern hemisphere are each charts) and the domain can then be describe by an atlas. +href="http://en.wikipedia.org/wiki/Atlas_%28topology%29">atlas. If a domain can be decomposed into an atlas, all we need to do is provide the pull-back and push-forward functions for each of the charts. In deal.II, this @@ -122,14 +122,14 @@ the geometry we want to describe looks like this: In particular, though you cannot see this here, the top surface is not -just colored by the elevation but is, in fact, deformed to follow the +just colored by the elevation but is, in fact, deformed to follow the correct topography. While the actual application is not relevant here, the geometry is. The domain we are interested in is a part of the Earth that ranges from the surface to a depth of 500km, from 26 to 35 degrees East of the Greenwich meridian, and from 5 degrees North of the equator to 10 degrees South. -This description of the geometry suggests to start with a box +This description of the geometry suggests to start with a box $\hat U=[26,35]\times[-10,5]\times[-500000,0]$ (measured in degrees, degrees, and meters) and to provide a map $\varphi$ so that $\varphi^{-1}(\hat U)=\Omega$ where $\Omega$ is the domain we @@ -157,7 +157,7 @@ of the sphere. However, the Earth is not a sphere: this using the WGS 84 reference standard for the Earth shape. The formula used in WGS 84 to obtain a position in Cartesian coordinates from longitude, latitude, and elevation - is + is @f[ \mathbf x = \varphi_\text{WGS84}^{-1}(\phi,\theta,d) = \left( @@ -169,7 +169,7 @@ of the sphere. However, the Earth is not a sphere: \right), @f] where $\bar R(\theta)=\frac{R}{\sqrt{1-(e \sin\theta)^2}}$, and radius and - ellipticity are given by $R=6378137\text{m}, e=0.081819190842622$. In this formula, + ellipticity are given by $R=6378137\text{m}, e=0.081819190842622$. In this formula, we assume that the arguments to sines and cosines are evaluated in degree, not radians (though we will have to change this assumption in the code). @@ -177,7 +177,7 @@ of the sphere. However, the Earth is not a sphere: this using real topography data (see below for a description of where this data comes from). Using this data set, we can look up elevations on a latitude-longitude mesh laid over the surface of the Earth. Starting with - the box $\hat U=[26,35]\times[-10,5]\times[-500000,0]$, we will therefore + the box $\hat U=[26,35]\times[-10,5]\times[-500000,0]$, we will therefore first stretch it in vertical direction before handing it off to the WGS 84 function: if $h(\hat\phi,\hat\theta)$ is the height at longitude $\hat\phi$ and latitude $\hat\theta$, then we define @@ -198,8 +198,8 @@ of the sphere. However, the Earth is not a sphere: Using these two functions, we can then define the entire push-forward function $\varphi^{-1}: \hat U \rightarrow \Omega$ as @f[ - \mathbf x - = + \mathbf x + = \varphi^{-1}(\hat\phi,\hat\theta,\hat d) = \varphi_\text{WGS84}^{-1}(\varphi_\text{topo}^{-1}(\hat\phi,\hat\theta,\hat d)). @@ -208,7 +208,7 @@ In addition, we will have to define the inverse of this function, the pull-back operation, which we can write as @f[ (\hat\phi,\hat\theta,\hat d) - = + = \varphi(\mathbf x) = \varphi_\text{topo}(\varphi_\text{WGS84}(\mathbf x)). @@ -230,7 +230,7 @@ in the program.

        Implementation

        -There are a number of issues we need to address in the program. At the largest scale, +There are a number of issues we need to address in the program. At the largest scale, we need to write a class that implements the interface of ChartManifold. This involves a function push_forward() that takes a point in the reference domain $\hat U$ and transform it into real space using the function @@ -255,8 +255,8 @@ that looks, in essence, like this: @endcode The transformations above have two parts: the WGS 84 transformations and the topography -transformation. Consequently, the AfricaGeometry class will have -additional (non-virtual) member functions +transformation. Consequently, the AfricaGeometry class will have +additional (non-virtual) member functions AfricaGeometry::push_forward_wgs84() and AfricaGeometry::push_forward_topo() that implement these two pieces, and corresponding pull back functions. @@ -289,7 +289,7 @@ looks like this: @endcode The data is formatted as latitude longitude elevation where the first two columns are provided in degrees North of the equator and degrees East of the Greenwich -meridian. The final column is given in meters above the WGS 84 zero elevation. +meridian. The final column is given in meters above the WGS 84 zero elevation. In the transformation functions, we need to evaluate $h(\hat\phi,\hat\theta)$ for a given longitude $\hat\phi$ and latitude $\hat\theta$. In general, this data point will not be @@ -298,11 +298,11 @@ interpolation routine is not particularly difficult, but it is a bit tedious and prone. Fortunately, we can somehow shoehorn this data set into an existing class: Functions::InterpolatedUniformGridData . Unfortunately, the class does not fit the bill quite exactly and so we need to work around it a bit. The problem comes from the way -we initialize this class: in its simplest form, it takes a stream of values that it +we initialize this class: in its simplest form, it takes a stream of values that it assumes form an equispaced mesh in the $x-y$ plane (or, here, the $\phi-\theta$ plane). Which is what they do here, sort of: they are ordered latitude first, longitude second; and more awkwardly, the first column starts at the largest values and counts down, -rather than the usual other way around. +rather than the usual other way around. Now, while tutorial programs are meant to illustrate how to code with deal.II, they do not necessarily have to satisfy the same quality standards as one would have to do @@ -316,11 +316,11 @@ Functions::InterpolatedUniformGridData class. On the other hand, tutorial programs are best if they are short and demonstrate key points rather than dwell on unimportant aspects and, thereby, obscure what we really want to show. Consequently, we will allow ourselves a bit of leeway: -- since this program is intended solely for a particular geometry around the area - of the East-African rift and since this is precisely the area described by the data - file, we will hardcode in the program that there are +- since this program is intended solely for a particular geometry around the area + of the East-African rift and since this is precisely the area described by the data + file, we will hardcode in the program that there are $1139\times 660$ pieces of data; -- we will hardcode the boundaries of the data +- we will hardcode the boundaries of the data $[-11.98333^\circ,6.983333^\circ]\times[25^\circ,35.98333^\circ]$; - we will lie to the Functions::InterpolatedUniformGridData class: the class will only see the data in the last column of this data file, and we will pretend that @@ -331,7 +331,7 @@ want to show. Consequently, we will allow ourselves a bit of leeway: interpolating table class for a value at $-\hat\theta$. With this little trick, we can avoid having to switch around the order of data as read from file. - + All of this then calls for a class that essentially looks like this: @code class AfricaTopography diff --git a/examples/step-53/doc/results.dox b/examples/step-53/doc/results.dox index d953814176..7143ab3236 100644 --- a/examples/step-53/doc/results.dox +++ b/examples/step-53/doc/results.dox @@ -7,7 +7,7 @@ to see anything that doesn't just look like a perfectly round piece of a sphere (though if one modified the program so that it does produce a sphere and looked at them at the same time, the difference between the overall sphere and WGS 84 shape is quite apparent). Apparently, Earth is actually quite a flat place. -Of course we already know this from satellite pictures. +Of course we already know this from satellite pictures. However, we can tease out something more by coloring cells by their volume. This both produces slight variations in hue along the top surface and something for the visualization programs to apply @@ -25,7 +25,7 @@ this, with an incredible amount of detail: A zoom-in of this picture shows the vertical displacement quite clearly (here, looking from the West-Northwest over the rift valley, the triple peaks -of +of Mount Stanley, Mount Speke, and Mount Baker @@ -39,7 +39,7 @@ and toward the great flatness of -These image were produced with three small modifications: +These image were produced with three small modifications:
        1. An additional seventh mesh refinement towards the top surface for the first of these two pictures, and a total of nine for the second. In the @@ -47,8 +47,8 @@ These image were produced with three small modifications: under 1km in vertical direction. (The picture was also created using a more resolved data set; however, it is too big to distribute as part of the tutorial.) - -
        2. The addition of the following function that, given a point + +
        3. The addition of the following function that, given a point x computes the elevation by converting the point to reference WGS 84 coordinates and only keeping the depth variable (the function is, consequently, a simplified version of the @@ -93,7 +93,7 @@ double get_elevation (const Point<3> &x) 5, ScalarFunctionFromFunctionObject<3>(get_elevation), boundary_values); - for (std::map::const_iterator p = boundary_values.begin(); + for (std::map::const_iterator p = boundary_values.begin(); p!=boundary_values.end(); ++p) elevation[p->first] = p->second; } @@ -115,7 +115,7 @@ ScalarFunctionFromFunctionObject class to make a regular C++ function look like an object of a class derived from the Function class that we want to use in VectorTools::interpolate_boundary_values(). Having so gotten a list of degrees of freedom located at the top boundary and corresponding elevation -values, we just go down this list and set these elevations in the +values, we just go down this list and set these elevations in the elevation vector (leaving all interior degrees of freedom at their original zero value). This vector is then output using DataOut as usual and can be visualized as shown above. diff --git a/examples/step-54/doc/intro.dox b/examples/step-54/doc/intro.dox index 136d2459f4..3352ba3d04 100644 --- a/examples/step-54/doc/intro.dox +++ b/examples/step-54/doc/intro.dox @@ -66,7 +66,7 @@ the OpenCASCADE framework. From a TopoDS_Shape, it is then possible to access all the sub-shapes (such as vertices, edges and faces) composing it, along with their geometrical description. In the deal.II framework, the topological entities composing a shape are used to create a corresponding -Manifold representation. In step-6 we saw how to use GridGenerator::hyper_sphere() +Manifold representation. In step-6 we saw how to use GridGenerator::hyper_sphere() to create a hyper sphere, which automatically attaches a SphericalManifold to all boundary faces. This guarantees that boundary faces stay on a sphere or circle during mesh refinement. The functions of the CAD modeling interface diff --git a/examples/step-54/doc/results.dox b/examples/step-54/doc/results.dox index fee51db117..de6f91d648 100644 --- a/examples/step-54/doc/results.dox +++ b/examples/step-54/doc/results.dox @@ -1,8 +1,8 @@

          Results

          -The program execution produces a series of mesh files 3d_mesh_*.vtk +The program execution produces a series of mesh files 3d_mesh_*.vtk that we can visualize with any of the usual visualization programs that can read the VTK -file format. +file format. The following table illustrates the results obtained employing the normal projection strategy. The first two rows of the table show side views of the grids obtained for progressive levels @@ -17,17 +17,17 @@ same grids shown in the second row. - + - + - +
          @@ -46,41 +46,41 @@ is indicated with a small yellow arrow at the bottom left of each image). - + - + - +
          The images confirm that the quality of the mesh obtained with a directional projection is sensibly higher than that obtained projecting along the surface normal. Yet, a number of elements elongated in the y-direction are observed around the bottom of the bulb, where the surface is almost parallel to the -direction chosen for the projection. +direction chosen for the projection. The final test shows results using instead the projection normal to the faces: - + - + - +
          @@ -88,5 +88,5 @@ The final test shows results using instead the projection normal to the faces: The pictures confirm that the normal to mesh projection approach leads to grids that remain evenly spaced throughtout the refinement steps. At the same time, these meshes represent rather well the original geometry even in the bottom region of the bulb, which is not well recovered employing the directional projector or the normal projector. - + diff --git a/examples/step-56/doc/intro.dox b/examples/step-56/doc/intro.dox index fcf4269a28..42250c4f23 100644 --- a/examples/step-56/doc/intro.dox +++ b/examples/step-56/doc/intro.dox @@ -13,7 +13,7 @@ undertaken. This work was supported by EPSRC grant no EP/K032208/1. @dealiiTutorialDOI{10.5281/zenodo.400995,https://zenodo.org/badge/DOI/10.5281/zenodo.400995.svg} - +

          Introduction

          Stokes Problem

          @@ -36,7 +36,7 @@ and $p \in L_*^2 = \{ p \in L^2(\Omega), \int_\Omega p = 0 @f{eqnarray*} - 2 \text{div} \frac {1}{2} \left[ (\nabla \textbf{u}) + (\nabla \textbf{u})^T\right] + \nabla p & =& f \\ - - \nabla \cdot u &=& 0 + - \nabla \cdot u &=& 0 @f} Note that we are using the deformation tensor instead of $\Delta u$ (a @@ -49,10 +49,10 @@ well as more expensive). The weak form of the discrete equations naturally leads to the following linear system for the nodal values of the velocity and pressure fields: -@f{eqnarray*} +@f{eqnarray*} \left(\begin{array}{cc} A & B^T \\ B & 0 \end{array}\right) \left(\begin{array}{c} U \\ P \end{array}\right) = -\left(\begin{array}{c} F \\ 0 \end{array}\right). +\left(\begin{array}{c} F \\ 0 \end{array}\right). @f} Our goal is to compare several solution approaches. While step-22 @@ -61,10 +61,10 @@ separate steps, we instead attack the block system at once using FMGRES with an efficient preconditioner, in the spirit of the approach outlined in the "Results" section of step-22. The idea is as follows: if we find a block -preconditioner $P$ such that the matrix +preconditioner $P$ such that the matrix @f{eqnarray*} -\left(\begin{array}{cc} A & B^T \\ B & 0 \end{array}\right) P^{-1} +\left(\begin{array}{cc} A & B^T \\ B & 0 \end{array}\right) P^{-1} @f} is simple, then an iterative solver with that preconditioner will @@ -74,12 +74,12 @@ we find that @f{eqnarray*} P^{-1} = \left(\begin{array}{cc} A & B^T \\ 0 & - S \end{array}\right)^{-1} + S \end{array}\right)^{-1} @f} is a good choice. Let $\widetilde{A^{-1}}$ be an approximation of $A^{-1}$ and $\widetilde{S^{-1}}$ of $S^{-1}$, we see -@f{eqnarray*} +@f{eqnarray*} P^{-1} = \left(\begin{array}{cc} A^{-1} & 0 \\ 0 & I \end{array}\right) \left(\begin{array}{cc} I & B^T \\ 0 & -I \end{array}\right) @@ -103,7 +103,7 @@ Multigrid as described in step-16) as a preconditioner, or just performing a sin of GMG. As a comparison, instead of FGMRES, we also use the direct solver -UMFPACK on the whole system to compare our results with. If you want to use +UMFPACK on the whole system to compare our results with. If you want to use a direct solver (like UMFPACK), the system needs to be invertible. To avoid the one dimensional null space given by the constant pressures, we fix the first pressure unknown to zero. This is not necessary for the iterative solvers. @@ -137,18 +137,18 @@ the "Method of Manufactured Solutions" of step-7, we need to find $\bf f$ such that: @f{align*} -{\bf f} = - 2 \text{div} \frac {1}{2} \left[ (\nabla \textbf{u}) + (\nabla \textbf{u})^T\right] + \nabla p. +{\bf f} = - 2 \text{div} \frac {1}{2} \left[ (\nabla \textbf{u}) + (\nabla \textbf{u})^T\right] + \nabla p. @f} Using the reference solution above, we obtain: -@f{eqnarray*} +@f{eqnarray*} {\bf f} &=& (2 \pi^2 \sin (\pi x),- \pi^3 y \cos(\pi x),- \pi^3 z \cos(\pi x))\\ & & + (\pi \cos(\pi x) \cos(\pi y) \sin(\pi z) ,- \pi \sin(\pi y) \sin(\pi x) \sin(\pi z), \pi \cos(\pi z) \sin(\pi x) \cos(\pi y)) @f} -

          Computing Errors

          +

          Computing Errors

          Because we do not enforce the mean pressure to be zero for our numerical solution in the linear system, @@ -183,7 +183,7 @@ the same sequence of DoFRenumbering operations on both.

          Differences from the Step 22 tutorial

          - + The main difference between step-56 and step-22 is that we use block solvers instead of the Schur Complement approach used in step-22. Details of this approach can be found under the "Block Schur diff --git a/examples/step-6/CMakeLists.txt b/examples/step-6/CMakeLists.txt index a4c9c021e9..b4af06998b 100644 --- a/examples/step-6/CMakeLists.txt +++ b/examples/step-6/CMakeLists.txt @@ -11,7 +11,7 @@ SET(TARGET "step-6") # you may want to either replace the following statement by something like # FILE(GLOB_RECURSE TARGET_SRC "source/*.cc") # FILE(GLOB_RECURSE TARGET_INC "include/*.h") -# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) +# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) # or switch altogether to the large project CMakeLists.txt file discussed # in the "CMake in user projects" page accessible from the "User info" # page of the documentation. diff --git a/examples/step-6/doc/intro.dox b/examples/step-6/doc/intro.dox index 1f1ff6b100..c3a17dba26 100644 --- a/examples/step-6/doc/intro.dox +++ b/examples/step-6/doc/intro.dox @@ -35,7 +35,7 @@ For reasons that are probably lost to history (maybe that these functions used to be implemented in FORTRAN, a language that does not care about whether something is spelled in lower or UPPER case letters, with programmers often choosing upper case letters habitually), the loop above is often -referenced in publications about mesh adaptivity as the +referenced in publications about mesh adaptivity as the SOLVE-ESTIMATE-MARK-REFINE loop (with this spelling). Beyond this structure, however, there are a variety of ways to achieve @@ -53,7 +53,7 @@ two essential possibilities: neighbor to the opposite vertex; otherwise a slightly more involved construction is necessary that adds more new vertices on at least one other edge of the neighboring cell, and then may propagate to the neighbors - of the neighbor until the algorithm terminates. This is hard to describe + of the neighbor until the algorithm terminates. This is hard to describe in words, and because deal.II does not use triangles not worth the time here. But if you're curious, you can always watch video lecture 15 at the link shown at the top of this introduction. @@ -317,7 +317,7 @@ locally refined meshes for a wide range of equations, not even restricted to elliptic only problems. Although it will create non-optimal meshes for other equations, it is often a good way to quickly produce meshes that are well adapted to the features of solutions, such as regions of great -variation or discontinuities. +variation or discontinuities. @@ -332,17 +332,17 @@ simply yields the constraint $U_j=g({\mathbf x}_j)$. The AffineConstraints class can handle such constraints as well, which makes it convenient to let the same object we use for hanging node constraints also deal with these Dirichlet boundary conditions. -This way, we don't need to apply the boundary conditions after assembly +This way, we don't need to apply the boundary conditions after assembly (like we did in the earlier steps). All that is necessary is that we call the variant of VectorTools::interpolate_boundary_values() that returns its information in an AffineConstraints object, rather than the `std::map` we have used in previous tutorial programs. - +

          Other things this program shows

          - - + + Since the concepts used for locally refined grids are so important, we do not show much other material in this example. The most important exception is that we show how to use biquadratic elements diff --git a/examples/step-6/doc/results.dox b/examples/step-6/doc/results.dox index 6aae992d33..c622d26075 100644 --- a/examples/step-6/doc/results.dox +++ b/examples/step-6/doc/results.dox @@ -475,7 +475,7 @@ would be one; bad cells have values much larger than one. An example of the latter kind would consider the gradient (the "Jacobian") of the mapping from the reference cell $\hat K=[0,1]^d$ to the real cell $K$; this gradient is a matrix, and a quantity that enters into error estimates -is the maximum over all points on the reference cell of the ratio of the +is the maximum over all points on the reference cell of the ratio of the largest to the smallest eigenvalue of this matrix. It is again not difficult to see that this ratio is constant if the cell $K$ is an affine image of $\hat K$, and that it is one for squares and cubes. @@ -530,7 +530,7 @@ solution will not go to infinity. That means, that the solution is at least still in the Sobolev space $W^{1,\infty}$ (i.e., roughly speaking, in the space of functions whose derivatives are bounded). On the other hand, -we know that in the most +we know that in the most extreme cases -- i.e., where the domain has reentrant corners, the right hand side only satisfies $f\in H^{-1}$, or the coefficient $a$ is only in $L^\infty$ -- all we can expect is that $u\in H^1$ (i.e., the diff --git a/examples/step-61/CMakeLists.txt b/examples/step-61/CMakeLists.txt index 8ddf6dd852..3bea21351d 100644 --- a/examples/step-61/CMakeLists.txt +++ b/examples/step-61/CMakeLists.txt @@ -11,7 +11,7 @@ SET(TARGET "step-61") # you may want to either replace the following statement by something like # FILE(GLOB_RECURSE TARGET_SRC "source/*.cc") # FILE(GLOB_RECURSE TARGET_INC "include/*.h") -# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) +# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) # or switch altogether to the large project CMakeLists.txt file discussed # in the "CMake in user projects" page accessible from the "User info" # page of the documentation. diff --git a/examples/step-61/doc/intro.dox b/examples/step-61/doc/intro.dox index b8b45dc282..f2609ee172 100644 --- a/examples/step-61/doc/intro.dox +++ b/examples/step-61/doc/intro.dox @@ -3,13 +3,13 @@ This program was contributed by Zhuoran Wang. Some more information about this program, as well as more numerical -results, are presented in @cite Wang2019 . +results, are presented in @cite Wang2019 .

          Introduction

          -This tutorial program presents an implementation of the "weak Galerkin" +This tutorial program presents an implementation of the "weak Galerkin" finite element method for the Poisson equation. In some sense, the motivation for considering this method starts from the same point as in step-51: We would like to consider discontinuous shape functions, but then need to address the fact that @@ -49,27 +49,27 @@ has the advantage that it does not lead to a proliferation of unknowns due to rewriting the equation as a first-order system, but it is also not quite as easy to implement. However, as we will see in the following, this additional effort is not prohibitive. - +

          Weak Galerkin finite element methods

          -Weak Galerkin Finite Element Methods (WGFEMs) use discrete weak functions -to approximate scalar unknowns, and discrete weak gradients to -approximate classical gradients. -The method was originally introduced by Junping Wang and Xiu Ye -in the paper +Weak Galerkin Finite Element Methods (WGFEMs) use discrete weak functions +to approximate scalar unknowns, and discrete weak gradients to +approximate classical gradients. +The method was originally introduced by Junping Wang and Xiu Ye +in the paper -A weak Galerkin finite element method for second order elliptic problems, -J. Comput. Appl. Math., 103-115, 2013. -Compared to the continuous Galerkin method, -the weak Galerkin method satisfies important physical properties, namely -local mass conservation and bulk normal flux continuity. -It results in a SPD linear system, and optimal convergence rates can +A weak Galerkin finite element method for second order elliptic problems, +J. Comput. Appl. Math., 103-115, 2013. +Compared to the continuous Galerkin method, +the weak Galerkin method satisfies important physical properties, namely +local mass conservation and bulk normal flux continuity. +It results in a SPD linear system, and optimal convergence rates can be obtained with mesh refinement.

          The equation to solve

          -This program solves the Poisson equation +This program solves the Poisson equation using the weak Galerkin finite element method: @f{align*}{ \nabla \cdot \left( -\mathbf{K} \nabla p \right) @@ -77,18 +77,18 @@ using the weak Galerkin finite element method: \qquad \mathbf{x} \in \Omega, \\ p &= p_D,\qquad \mathbf{x} \in \Gamma^D, \\ \mathbf{u} \cdot \mathbf{n} &= u_N, - \qquad \mathbf{x} \in \Gamma^N, + \qquad \mathbf{x} \in \Gamma^N, @f} -where $\Omega \subset \mathbb{R}^n (n=2,3)$ is a bounded domain. +where $\Omega \subset \mathbb{R}^n (n=2,3)$ is a bounded domain. In the context of the flow of a fluid through a porous medium, -$p$ is the pressure, $\mathbf{K}$ is a permeability tensor, +$p$ is the pressure, $\mathbf{K}$ is a permeability tensor, $f$ is the source term, and $p_D, u_N$ represent Dirichlet and Neumann boundary conditions. -We can introduce a flux, $\mathbf{u} = -\mathbf{K} \nabla p$, that corresponds +We can introduce a flux, $\mathbf{u} = -\mathbf{K} \nabla p$, that corresponds to the Darcy velocity (in the way we did in step-20) and this variable will be important in the considerations below. -In this program, we will consider a test case where the exact pressure +In this program, we will consider a test case where the exact pressure is $p = \sin \left( \pi x\right)\sin\left(\pi y \right)$ on the unit square domain, with homogeneous Dirichelet boundary conditions and $\mathbf{K}$ the identity matrix. Then we will calculate $L_2$ errors of pressure, velocity, and flux. @@ -106,17 +106,17 @@ for all test functions $q$, where \mathcal{A}\left(p,q\right) \dealcoloneq \int_\Omega \left(\mathbf{K} \nabla p\right) \cdot \nabla q \;\mathrm{d}x, @f} -and +and @f{equation*} \mathcal{F}\left(q\right) \dealcoloneq \int_\Omega f \, q \;\mathrm{d}x - \int_{\Gamma^N} u_N q \; \mathrm{d}x. @f} -Here, we have integrated by parts in the bilinear form, and we are evaluating +Here, we have integrated by parts in the bilinear form, and we are evaluating the gradient of $p,p$ in the interior and the values of $q$ on the boundary of the domain. All of this is well defined because we assume that the solution is in $H^1$ for which taking the gradient and evaluating boundary values -are valid operations. +are valid operations. The idea of the weak Galerkin method is now to approximate the exact $p$ solution with a discontinuous function $p_h$. This function may only be @@ -144,7 +144,7 @@ for all discrete test functions $q_h$, where \dealcoloneq \sum_{K \in \mathbb{T}} \int_K \mathbf{K} \nabla_{w,d} p_h \cdot \nabla_{w,d} q_h \;\mathrm{d}x, @f} -and +and @f{equation*} \mathcal{F}\left(q_h\right) \dealcoloneq \sum_{K \in \mathbb{T}} \int_K f \, q_h^\circ \;\mathrm{d}x @@ -153,7 +153,7 @@ and The key point is that here, we have replaced the gradient $\nabla p_h$ by the discrete weak gradient operator $\nabla_{w,d} p_h$ that makes sense for our peculiarly defined approximation $p_h$. - + The question is then how that operator works. For this, let us first say how we think of the discrete approximation $p_h$ of the pressure. As mentioned above, the "function" $p_h$ actually consists of two parts: the values $p_h^\circ$ in @@ -170,7 +170,7 @@ of the pair $(p_h^\circ|_K,p_h^\partial|_{\partial K})$. In essence, we can think of $\nabla_{w,d} p_h$ of some function defined on $K$ that approximates the gradient; in particular, if $p_h|_K$ was the restriction of a differentiable function (to the interior and boundary of $K$ -- which would make it continuous -between the interior and boundary), then +between the interior and boundary), then $\nabla_{w,d} p_h$ would simply be the exact gradient $\nabla p_h$. But, since $p_h|_K$ is not continuous between interior and boundary of $K$, we need a more general definition; furthermore, we can not deal with arbitrary functions, and @@ -182,17 +182,17 @@ The way this is done is to define this weak gradient operator $\nabla_{w,d}|_K : DGQ_k(K) \times DGQ_r(\partial K) \rightarrow RT_s(K)$ (where $RT_s(K)$ is the vector-valued Raviart-Thomas space of order $s$ on cell $K$) in the following way: @f{equation*}{ - \int_K \mathbf v_h \cdot (\nabla_{w,d} p_h) + \int_K \mathbf v_h \cdot (\nabla_{w,d} p_h) = -\int_K (\nabla \cdot \mathbf v_h) p_h^\circ +\int_{\partial K} (\mathbf v_h \cdot \mathbf n) p_h^\partial, -@f} +@f} for all test functions $\mathbf v_h \in RT_s(K)$. This is, in essence, simply an application of the integration-by-parts formula. In other words, for a given $p_h=(p^\circ_h,p^\partial_h)$, we need to think of $\nabla_{w,d} p_h|_K$ as that Raviart-Thomas function of degree $s$ for which the left hand side and right hand side -are equal for all test functions. +are equal for all test functions. @note It may be worth pointing out that while the weak discrete gradient is an element of the Raviart-Thomas space $RT_s(K)$ on each @@ -224,7 +224,7 @@ Since $p_h$ is an element of a finite element space, we can expand it in a basis as we always do, i.e., we can write @f{equation*}{ p_h(\mathbf x) = \sum_j P_j \varphi_j(\mathbf x). -@f} +@f} Here, since $p_h$ has two components (the interior and the interface components), the same must hold true for the basis functions $\varphi_j(\mathbf x)$, which we can write as $\varphi_j = (\varphi_j^\circ,\varphi_j^\partial)$. If you've @@ -235,7 +235,7 @@ zero, whereas for other values of $j$, $\varphi_j^\partial$ will be zero -- i.e. shape functions will be of either one or the other kind. That is not important, here, however. What is important is that we need to wonder how we can represent $\nabla_{w,d} \varphi_j$ because that is clearly what will appear in the -problem when we want to implement the bilinear form +problem when we want to implement the bilinear form @f{equation*} \mathcal{A}_h\left(p_h,q_h\right) = \sum_{K \in \mathbb{T}} @@ -250,7 +250,7 @@ represent (on each cell $K$ separately) = \sum_k C_{jk}^K \mathbf v_k|_K @f} where the functions $\mathbf v_k \in DGRT_s$, and where $C^K$ is a matrix of -dimension +dimension @f{align*}{ \text{dim}\left(DGQ_k(K) \times DGQ_r(K)\right) &\times \text{dim}\left(RT_s(K)\right) \\ @@ -269,7 +269,7 @@ space.) Using this expansion, we can easily use the definition of the weak discrete gradient above to define what the matrix is going to be: @f{equation*}{ - \int_K \mathbf v_i \cdot \left(\sum_k C_{jk}^K \mathbf v_k\right) + \int_K \mathbf v_i \cdot \left(\sum_k C_{jk}^K \mathbf v_k\right) = -\int_K (\nabla \cdot \mathbf v_i) \varphi_j^\circ +\int_{\partial K} (\mathbf v_i \cdot \mathbf n) \varphi_j^\partial, @@ -278,24 +278,24 @@ for all test functions $\mathbf v_i \in DGRT_s$. This clearly leads to a linear system of the form @f{equation*}{ - \sum_k M_{ik}^K C_{jk}^K + \sum_k M_{ik}^K C_{jk}^K = G_{ij}^K @f} with @f{equation*}{ M_{ik}^K = \int_K \mathbf v_i \cdot \mathbf v_k, - \qquad\qquad + \qquad\qquad G_{ij}^K = -\int_K (\nabla \cdot \mathbf v_i) \varphi_j^\circ +\int_{\partial K} (\mathbf v_i \cdot \mathbf n) \varphi_j^\partial, @f} -and consequently +and consequently @f{equation*}{ \left(C^K\right)^T = \left(M^K\right)^{-1} G^K. @f} (In this last step, we have assumed that the indices $i,j,k$ only range over those degrees of freedom active on cell $K$, -thereby ensuring that the mass matrix on the space $RT_s(K)$ is invertible.) +thereby ensuring that the mass matrix on the space $RT_s(K)$ is invertible.) Equivalently, using the symmetry of the matrix $M$, we have that @f{equation*}{ C^K = \left(G^K\right)^{T} \left(M^K\right)^{-1}. @@ -314,27 +314,27 @@ local contribution to the global matrix, @f{equation*}{ A^K_{ij} = \int_K \left({\mathbf K} \nabla_{w,d} \varphi_i\right) \cdot \nabla_{w,d} \varphi_j. @f} -As explained above, we can expand $\nabla_{w,d} \varphi_i$ in terms of the +As explained above, we can expand $\nabla_{w,d} \varphi_i$ in terms of the Raviart-Thomas basis on each cell, and similarly for $\nabla_{w,d} \varphi_j$: @f{equation*}{ - A^K_{ij} = \int_K + A^K_{ij} = \int_K \left( - {\mathbf K} + {\mathbf K} \sum_k C_{ik}^K \mathbf v_k|_K - \right) - \cdot + \right) + \cdot \sum_l C_{jl}^K \mathbf v_l|_K. @f} By re-arranging sums, this yields the following expression: @f{equation*}{ A^K_{ij} = \sum_k \sum_l C_{ik}^K C_{jl}^K - \int_K + \int_K \left( - {\mathbf K} + {\mathbf K} \mathbf v_k|_K - \right) - \cdot + \right) + \cdot \mathbf v_l|_K. @f} So, if we have the matrix $C^K$ for each cell $K$, then we can easily compute @@ -351,12 +351,12 @@ the contribution $A^K$ for cell $K$ to the matrix $A$ as follows: Here, @f{equation*}{ H^K_{kl} = - \int_K + \int_K \left( - {\mathbf K} + {\mathbf K} \mathbf v_k|_K - \right) - \cdot + \right) + \cdot \mathbf v_l|_K, @f} which is really just the mass matrix on cell $K$ using the Raviart-Thomas @@ -394,38 +394,38 @@ As discussed above, on each element the gradient of the numerical pressure $\nabla p$ can be approximated by discrete weak gradients $ \nabla_{w,d}\phi_i$: @f{equation*} -\nabla_{w,d} p_h -= \nabla_{w,d} \left(\sum_{i} P_i \phi_i\right) +\nabla_{w,d} p_h += \nabla_{w,d} \left(\sum_{i} P_i \phi_i\right) = \sum_{i} P_i \nabla_{w,d}\phi_i. @f} On cell $K$, the numerical velocity $ \mathbf{u}_h = -\mathbf{K} \nabla_{w,d}p_h$ can be written as @f{align*}{ - \mathbf{u}_h - &= -\mathbf{K} \nabla_{w,d} p_h + \mathbf{u}_h + &= -\mathbf{K} \nabla_{w,d} p_h = -\mathbf{K}\sum_{i} \sum_{j} P_i C^K_{ij}\mathbf{v}_j, @f} where $C^K$ is the expansion matrix from above, and $\mathbf{v}_j$ is the basis function of the $RT$ space on a cell. Unfortunately, $\mathbf{K} \mathbf{v}_j$ may not be in the $RT$ space -(unless, of course, if $\mathbf K$ is constant times the identity matrix). +(unless, of course, if $\mathbf K$ is constant times the identity matrix). So, in order to represent it in a finite element program, we need to project it back into a finite dimensional space we can work with. Here, we will use the $L_2$-projection to project it back to the (broken) $RT$ -space. - -We define the projection as -$ \mathbf{Q}_h \left( \mathbf{K}\mathbf{v}_j \right) = -\sum_{k} d_{jk}\mathbf{v}_k$ on each cell $K$. -For any $j$, -$\left( \mathbf{Q}_h \left( \mathbf{Kv}_j \right),\mathbf{v}_k \right)_K = -\left( \mathbf{Kv}_j,\mathbf{v}_k \right)_K.$ +space. + +We define the projection as +$ \mathbf{Q}_h \left( \mathbf{K}\mathbf{v}_j \right) = +\sum_{k} d_{jk}\mathbf{v}_k$ on each cell $K$. +For any $j$, +$\left( \mathbf{Q}_h \left( \mathbf{Kv}_j \right),\mathbf{v}_k \right)_K = +\left( \mathbf{Kv}_j,\mathbf{v}_k \right)_K.$ So, rather than the formula shown above, the numerical velocity on cell $K$ instead becomes @f{equation*} -\mathbf{u}_h = \mathbf{Q}_h \left( -\mathbf{K}\nabla_{w,d}p_h \right) = +\mathbf{u}_h = \mathbf{Q}_h \left( -\mathbf{K}\nabla_{w,d}p_h \right) = -\sum_i \sum_j P_i B^K_{ij}\mathbf{Q}_h \left( \mathbf{K}\mathbf{v}_j \right), @f} and we have the following system to solve for the coefficients $d_{jk}$: @@ -436,12 +436,12 @@ and we have the following system to solve for the coefficients $d_{jk}$: = \left( \mathbf{Kv}_j,\mathbf{v}_k \right). @f} -In the implementation below, the matrix with elements +In the implementation below, the matrix with elements $ d_{jk} $ is called cell_matrix_D, -whereas the matrix with elements +whereas the matrix with elements $ \left( \mathbf{Kv}_j,\mathbf{v}_k \right) $ @@ -449,14 +449,14 @@ is called cell_matrix_E. Then the elementwise velocity is @f{equation*} -\mathbf{u}_h = -\sum_{i} \sum_{j}P_ic_{ij}\sum_{k}d_{jk}\mathbf{v}_k = +\mathbf{u}_h = -\sum_{i} \sum_{j}P_ic_{ij}\sum_{k}d_{jk}\mathbf{v}_k = \sum_{k}- \left(\sum_{j} \sum_{i} P_ic_{ij}d_{jk} \right)\mathbf{v}_k, @f} -where $-\sum_{j} \sum_{i} P_ic_{ij}d_{jk}$ is called +where $-\sum_{j} \sum_{i} P_ic_{ij}d_{jk}$ is called `cell_velocity` in the code. Using this velocity obtained by "postprocessing" the solution, we can -define the $L_2$-errors of pressure, velocity, and flux +define the $L_2$-errors of pressure, velocity, and flux by the following formulas: @f{align*}{ \|p-p_h^\circ\|^2 @@ -467,8 +467,8 @@ by the following formulas: &= \sum_{K \in \mathbb{T}} \sum_{\gamma \subset \partial K} \frac{|K|}{|\gamma|} \|\mathbf{u} \cdot \mathbf{n} - \mathbf{u}_h \cdot \mathbf{n}\|_{L_2(\gamma)}^2, @f} -where $| K |$ is the area of the element, -$\gamma$ are faces of the element, +where $| K |$ is the area of the element, +$\gamma$ are faces of the element, $\mathbf{n}$ are unit normal vectors of each face. The last of these norms measures the accuracy of the normal component of the velocity vectors over the interfaces between the cells of the mesh. The scaling diff --git a/examples/step-61/doc/results.dox b/examples/step-61/doc/results.dox index d77f37291e..7b2b90d311 100644 --- a/examples/step-61/doc/results.dox +++ b/examples/step-61/doc/results.dox @@ -37,17 +37,17 @@ pressures $p^\circ$ on the two adjacent cells. -From the figures, we can see that with the mesh refinement, the maximum and -minimum pressure values are approaching the values we expect. -Since the mesh is a rectangular mesh and numbers of cells in each direction is even, we -have symmetric solutions. From the 3d figures on the right, +From the figures, we can see that with the mesh refinement, the maximum and +minimum pressure values are approaching the values we expect. +Since the mesh is a rectangular mesh and numbers of cells in each direction is even, we +have symmetric solutions. From the 3d figures on the right, we can see that on $\mbox{WG}(Q_0,Q_0;RT_{[0]})$, the pressure is a constant in the interior of the cell, as expected.

          Convergence table

          We run the code with differently refined meshes (chosen in the `make_grid()` function) -and get the following convergence rates of pressure, +and get the following convergence rates of pressure, velocity, and flux (as defined in the introduction). @@ -79,8 +79,8 @@ This, of course, matches our theoretical expectations. We can repeat the experiment from above using the next higher polynomial degree: -The following figures are interior pressures and face pressures implemented using -$\mbox{WG}(Q_1,Q_1;RT_{[1]})$. The mesh is refined 4 times. Compared to the +The following figures are interior pressures and face pressures implemented using +$\mbox{WG}(Q_1,Q_1;RT_{[1]})$. The mesh is refined 4 times. Compared to the previous figures using $\mbox{WG}(Q_0,Q_0;RT_{[0]})$, on each cell, the solution is no longer constant on each cell, as we now use bilinear polynomials to do the approximation. @@ -102,7 +102,7 @@ interior pressures $p^\circ$ on the adjacent cells.

          Convergence table

          -The following are the convergence rates of pressure, velocity, and flux +The following are the convergence rates of pressure, velocity, and flux we obtain from using the $\mbox{WG}(Q_1,Q_1;RT_{[1]})$ element combination:
          @@ -133,7 +133,7 @@ The convergence rates of $WG(Q_1,Q_1;RT_{[1]})$ are around 2, as expected.

          Test results on WG(Q2,Q2;RT[2])

          Let us go one polynomial degree higher. -The following are interior pressures and face pressures implemented using +The following are interior pressures and face pressures implemented using $WG(Q_2,Q_2;RT_{[2]})$, with mesh size $h = 1/32$ (i.e., 5 global mesh refinement steps). In the program, we use `data_out_face.build_patches(fe.degree)` when generating graphical output @@ -151,7 +151,7 @@ visualization of the quadratic polynomials.

          Convergence table

          As before, we can generate convergence data for the -$L_2$ errors of pressure, velocity, and flux +$L_2$ errors of pressure, velocity, and flux using the $\mbox{WG}(Q_2,Q_2;RT_{[2]})$ combination:
          diff --git a/examples/step-62/CMakeLists.txt b/examples/step-62/CMakeLists.txt index c3dfcd0b54..56d4dd837f 100644 --- a/examples/step-62/CMakeLists.txt +++ b/examples/step-62/CMakeLists.txt @@ -11,7 +11,7 @@ SET(TARGET "step-62") # you may want to either replace the following statement by something like # FILE(GLOB_RECURSE TARGET_SRC "source/*.cc") # FILE(GLOB_RECURSE TARGET_INC "include/*.h") -# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) +# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) # or switch altogether to the large project CMakeLists.txt file discussed # in the "CMake in user projects" page accessible from the "User info" # page of the documentation. diff --git a/examples/step-62/doc/intro.dox b/examples/step-62/doc/intro.dox index 67bcad9988..a7eb26ffbc 100644 --- a/examples/step-62/doc/intro.dox +++ b/examples/step-62/doc/intro.dox @@ -173,7 +173,7 @@ to set up the parameters and run the simulation. First we create a HDF5 file where we store the parameters and the results of the simulation. -Each of the simulations (displacement and calibration) is stored in a separate HDF5 group: +Each of the simulations (displacement and calibration) is stored in a separate HDF5 group: @code{.py} import numpy as np import h5py @@ -197,15 +197,15 @@ for group in [displacement, calibration]: group.attrs['dimension_x'] = 2e-5 # The waveguide width is equal to dimension_y group.attrs['dimension_y'] = 2e-8 - + # Position of the probe that we use to measure the flux group.attrs['probe_pos_x'] = 8e-6 group.attrs['probe_pos_y'] = 0 group.attrs['probe_width_y'] = 2e-08 - + # Number of points in the probe group.attrs['nb_probe_points'] = 5 - + # Global refinement group.attrs['grid_level'] = 1 @@ -220,7 +220,7 @@ for group in [displacement, calibration]: if group == displacement: group.attrs['material_b_rho'] = 2000 else: - group.attrs['material_b_rho'] = 3200 + group.attrs['material_b_rho'] = 3200 group.attrs['lambda'] = (group.attrs['youngs_modulus'] * group.attrs['poissons_ratio'] / ((1 + group.attrs['poissons_ratio']) * (1 - 2 * group.attrs['poissons_ratio']))) @@ -256,6 +256,6 @@ for group in [displacement, calibration]: else: group.attrs['simulation_name'] = 'phononic_cavity_calibration' group.attrs['save_vtu_files'] = False - + h5_file.close() @endcode diff --git a/examples/step-62/doc/results.dox b/examples/step-62/doc/results.dox index 04cbc1af6c..a4170afaa5 100644 --- a/examples/step-62/doc/results.dox +++ b/examples/step-62/doc/results.dox @@ -2,7 +2,7 @@

          Resonance frequency and bandgap

          -The results are analyzed in the +The results are analyzed in the [jupyter notebook](https://github.com/dealii/dealii/blob/phononic-cavity/examples/step-62/step-62.ipynb) with the following code @code{.py} @@ -74,7 +74,7 @@ Q = \frac{f_r}{\Delta f} = \frac{\omega_r}{\Delta \omega} = @f] The square of the amplitude of the mechanical resonance $a^2$ as a function of the frequency -has a gaussian shape +has a gaussian shape @f[ a^2 = a_\textrm{max}^2\frac{\omega^2\Gamma^2}{(\omega_r^2-\omega^2)^2+\Gamma^2\omega^2} @f] @@ -106,7 +106,7 @@ through the device.

          Mode profile

          -We can inspect the mode profile with Paraview or Visit. +We can inspect the mode profile with Paraview or Visit. As we have discussed, at resonance all the mechanical energy is transmitted and the amplitude of motion is amplified inside the cavity. It can be observed that the PMLs are quite effective to truncate the solution. diff --git a/examples/step-63/doc/intro.dox b/examples/step-63/doc/intro.dox index 201c8824ae..be6026c290 100644 --- a/examples/step-63/doc/intro.dox +++ b/examples/step-63/doc/intro.dox @@ -249,7 +249,7 @@ with a circle of radius 0.3 centered at the origin removed. In addition, we use $\varepsilon=0.005$, $\boldsymbol{\beta} = [-\sin(\pi/6),\,\cos(\pi/6)]$, $f=0$, and Dirichlet boundary values @f{align*}{ -g = \left\{\begin{array}{ll} 1 & \text{if } x=-1 \text{ or } y=-1,\,x\geq 0.5 \\ +g = \left\{\begin{array}{ll} 1 & \text{if } x=-1 \text{ or } y=-1,\,x\geq 0.5 \\ 0 & \text{otherwise} \end{array}\right. @f} diff --git a/examples/step-63/doc/results.dox b/examples/step-63/doc/results.dox index 6784e06ad1..9adfa505ee 100644 --- a/examples/step-63/doc/results.dox +++ b/examples/step-63/doc/results.dox @@ -69,11 +69,11 @@ the number of iterations necessary to obtain convergence from GMRES: @@ -82,10 +82,10 @@ the number of iterations necessary to obtain convergence from GMRES: + + @@ -97,7 +97,7 @@ the number of iterations necessary to obtain convergence from GMRES: @@ -105,11 +105,11 @@ the number of iterations necessary to obtain convergence from GMRES: @@ -117,11 +117,11 @@ the number of iterations necessary to obtain convergence from GMRES: @@ -129,11 +129,11 @@ the number of iterations necessary to obtain convergence from GMRES: @@ -141,11 +141,11 @@ the number of iterations necessary to obtain convergence from GMRES:
          48 3 3 - 3 + 3 3 3 - 3 + 3
          1286 6 6 - 6 6 6 - 6
          512 9 9 - 9 + 9
          20482176 15 15 - 15 + 15 13 13 - 13 + 13
          81928448 18 18 - 18 + 18 15 15 - 15 + 15
          3276833280 20 20 - 20 + 20 16 16 - 16 + 16
          131072132096 20 20 - 20 + 20 16 16 - 16 + 16
          @@ -200,11 +200,11 @@ On the other hand, the situation is different for multiplicative smoothers: 48 2 2 - 3 + 3 2 2 - 3 + 3 128 @@ -213,10 +213,10 @@ On the other hand, the situation is different for multiplicative smoothers: 5 5 7 - + 5 5 - 7 + 7 512 @@ -228,7 +228,7 @@ On the other hand, the situation is different for multiplicative smoothers: 7 7 - 12 + 12 2048 @@ -237,10 +237,10 @@ On the other hand, the situation is different for multiplicative smoothers: 10 12 15 - + 8 10 - 17 + 17 8192 @@ -248,11 +248,11 @@ On the other hand, the situation is different for multiplicative smoothers: 8448 11 15 - 19 + 19 10 11 - 20 + 20 32768 @@ -260,11 +260,11 @@ On the other hand, the situation is different for multiplicative smoothers: 33280 12 16 - 20 + 20 10 12 - 21 + 21 131072 @@ -272,11 +272,11 @@ On the other hand, the situation is different for multiplicative smoothers: 132096 12 16 - 19 + 19 11 12 - 21 + 21 @@ -448,7 +448,7 @@ smoother over another. Obviously we must examine the cost of an iteration. Block smoothers here are at a disadvantage as they are having to construct and invert a cell matrix for each cell. Here is a comparison of solve times for a $Q_3$ element with 74,496 DoFs: - + diff --git a/examples/step-64/doc/intro.dox b/examples/step-64/doc/intro.dox index 8cfb61a6c9..368f4513c4 100644 --- a/examples/step-64/doc/intro.dox +++ b/examples/step-64/doc/intro.dox @@ -104,7 +104,7 @@ which is similar but the `import()` stage may involve MPI communication: @code IndexSet locally_owned_dofs, locally_relevant_dofs; ...fill the two IndexSet objects... - + // Create the ReadWriteVector using an IndexSet instead of the size LinearAlgebra::ReadWriteVector owned_rw_vector(locally_owned_dofs); @@ -130,7 +130,7 @@ elements of the vector. Typically, these are the which implies that they overlap between different MPI processes. Consequently, the elements stored in that vector on one machine may not coincide with the ones stored by the GPU on that -machine, requiring MPI communication to import them. +machine, requiring MPI communication to import them. In all of these cases, while importing a vector, values can either be inserted (using VectorOperation::insert) or added to prior content of diff --git a/examples/step-64/doc/results.dox b/examples/step-64/doc/results.dox index fbd4a395b3..b622aa0eae 100644 --- a/examples/step-64/doc/results.dox +++ b/examples/step-64/doc/results.dox @@ -40,7 +40,7 @@ like ${\cal O}(h^{-2})$.) This is of course rather inefficient, as an optimal solver would have a number of iterations that is independent of the size of the problem. But having such a solver would require using a better preconditioner than the identity matrix we have used here. - +

          Possible extensions

          diff --git a/examples/step-65/doc/intro.dox b/examples/step-65/doc/intro.dox index c5a79d1074..609e2c08ff 100644 --- a/examples/step-65/doc/intro.dox +++ b/examples/step-65/doc/intro.dox @@ -86,7 +86,7 @@ describe how exactly this should work. Here are a couple of examples: would not produce reasonable new points. In fact, defining a manifold description for things that are supposed "to look round" but might have points at or close to the origin is surprisingly very - difficult. + difficult. - A similar thing happens at the origin of the three-dimensional ball when one tries to attach a spherical manifold to the whole volume – in this case, the computation of new manifold points @@ -195,7 +195,7 @@ when a higher order mapping (such as MappingQGeneric or MappingC1) is evaluated on a given cell subject to this manifold. Using this manifold on the shaded cells of the coarse grid of the disk (i.e., not only in the outer-most layer of -cells) produces the following mesh upon four global +cells) produces the following mesh upon four global steps of refinement: @image html circular_mesh_transfinite_interpolation.png "" diff --git a/examples/step-7/CMakeLists.txt b/examples/step-7/CMakeLists.txt index b66178cc38..a8e88b6995 100644 --- a/examples/step-7/CMakeLists.txt +++ b/examples/step-7/CMakeLists.txt @@ -11,7 +11,7 @@ SET(TARGET "step-7") # you may want to either replace the following statement by something like # FILE(GLOB_RECURSE TARGET_SRC "source/*.cc") # FILE(GLOB_RECURSE TARGET_INC "include/*.h") -# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) +# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) # or switch altogether to the large project CMakeLists.txt file discussed # in the "CMake in user projects" page accessible from the "User info" # page of the documentation. diff --git a/examples/step-7/doc/intro.dox b/examples/step-7/doc/intro.dox index a2cd24487b..ef4f02a3c7 100644 --- a/examples/step-7/doc/intro.dox +++ b/examples/step-7/doc/intro.dox @@ -8,7 +8,7 @@ In this program, we will mainly consider two aspects:
        4. Non-homogeneous Neumann boundary conditions for the Helmholtz equation. Besides these topics, again a variety of improvements and tricks will be -shown. +shown.

          Verification of correctness

          @@ -43,7 +43,7 @@ triangulation: \\ {| u-u_h |}_{H^1(K)} &=& \left( \int_K |\nabla(u-u_h)|^2 \; dx \right)^{1/2}, \\ - {\| u-u_h \|}_{H^1(K)} &=& \left( {\| u-u_h \|}^2_{L_2(K)} + {\| u-u_h \|}_{H^1(K)} &=& \left( {\| u-u_h \|}^2_{L_2(K)} +{| u-u_h |}^2_{H^1(K)} \right)^{1/2}. @f} (All these norms and semi-norms can also be evaluated with weighting functions, @@ -57,7 +57,7 @@ only at the quadrature points; one should then not try to use a quadrature rule with points only at points where super-convergence might occur, such as the Gauss points of the lowest-order Gauss quadrature formula for which the integrals in the assembly of the matrix is correct (e.g., for linear elements, -do not use the QGauss(2) quadrature formula). In fact, this is generally good +do not use the QGauss(2) quadrature formula). In fact, this is generally good advice also for the other norms: if your quadrature points are fortuitously chosen at locations where the error happens to be particularly small due to superconvergence, the computed error will look like it is much smaller than @@ -116,12 +116,12 @@ In our particular testcase, we will use $\Gamma_1=\Gamma \cap\{\{x=1\} \cup \{y= Because we want to verify the convergence of our numerical solution $u_h$, we want a setup so that we know the exact solution $u$. This is where -the Method of Manufactured Solutions comes in. To this end, let us +the Method of Manufactured Solutions comes in. To this end, let us choose a function @f[ \bar u(x) = \sum_{i=1}^3 \exp\left(-\frac{|x-x_i|^2}{\sigma^2}\right) @f] -where the centers $x_i$ of the exponentials are +where the centers $x_i$ of the exponentials are $x_1=(-\frac 12,\frac 12)$, $x_2=(-\frac 12,-\frac 12)$, and $x_3=(\frac 12,-\frac 12)$, diff --git a/examples/step-7/doc/results.dox b/examples/step-7/doc/results.dox index fdc5e9a67b..6b806a1dce 100644 --- a/examples/step-7/doc/results.dox +++ b/examples/step-7/doc/results.dox @@ -52,16 +52,16 @@ Cycle 8: Number of active cells: 15196 Number of degrees of freedom: 15912 -cycle cells dofs L2 H1 Linfty - 0 64 81 1.840e+00 2.858e+00 1.835e+00 - 1 124 157 5.190e-02 1.200e+00 1.344e-01 - 2 280 341 1.439e-02 7.892e-01 7.554e-02 - 3 577 690 8.627e-03 5.061e-01 2.805e-02 - 4 1099 1264 3.217e-03 3.030e-01 1.073e-02 - 5 2191 2452 1.445e-03 2.097e-01 5.073e-03 - 6 4165 4510 8.387e-04 1.460e-01 2.013e-03 - 7 7915 8440 7.051e-04 1.053e-01 1.804e-03 - 8 15196 15912 2.774e-04 7.463e-02 6.911e-04 +cycle cells dofs L2 H1 Linfty + 0 64 81 1.840e+00 2.858e+00 1.835e+00 + 1 124 157 5.190e-02 1.200e+00 1.344e-01 + 2 280 341 1.439e-02 7.892e-01 7.554e-02 + 3 577 690 8.627e-03 5.061e-01 2.805e-02 + 4 1099 1264 3.217e-03 3.030e-01 1.073e-02 + 5 2191 2452 1.445e-03 2.097e-01 5.073e-03 + 6 4165 4510 8.387e-04 1.460e-01 2.013e-03 + 7 7915 8440 7.051e-04 1.053e-01 1.804e-03 + 8 15196 15912 2.774e-04 7.463e-02 6.911e-04 Solving with Q1 elements, global refinement =========================================== @@ -82,19 +82,19 @@ Cycle 4: Number of active cells: 16384 Number of degrees of freedom: 16641 -cycle cells dofs L2 H1 Linfty - 0 64 81 1.840e+00 2.858e+00 1.835e+00 - 1 256 289 3.570e-02 1.199e+00 1.307e-01 - 2 1024 1089 1.192e-02 7.565e-01 7.168e-02 - 3 4096 4225 3.047e-03 3.823e-01 2.128e-02 - 4 16384 16641 7.660e-04 1.917e-01 5.554e-03 +cycle cells dofs L2 H1 Linfty + 0 64 81 1.840e+00 2.858e+00 1.835e+00 + 1 256 289 3.570e-02 1.199e+00 1.307e-01 + 2 1024 1089 1.192e-02 7.565e-01 7.168e-02 + 3 4096 4225 3.047e-03 3.823e-01 2.128e-02 + 4 16384 16641 7.660e-04 1.917e-01 5.554e-03 -n cells H1 L2 -0 64 2.858e+00 - - 1.840e+00 - - -1 256 1.199e+00 2.38 1.25 3.570e-02 51.54 5.69 -2 1024 7.565e-01 1.58 0.66 1.192e-02 2.99 1.58 -3 4096 3.823e-01 1.98 0.98 3.047e-03 3.91 1.97 -4 16384 1.917e-01 1.99 1.00 7.660e-04 3.98 1.99 +n cells H1 L2 +0 64 2.858e+00 - - 1.840e+00 - - +1 256 1.199e+00 2.38 1.25 3.570e-02 51.54 5.69 +2 1024 7.565e-01 1.58 0.66 1.192e-02 2.99 1.58 +3 4096 3.823e-01 1.98 0.98 3.047e-03 3.91 1.97 +4 16384 1.917e-01 1.99 1.00 7.660e-04 3.98 1.99 Solving with Q2 elements, global refinement =========================================== @@ -115,19 +115,19 @@ Cycle 4: Number of active cells: 16384 Number of degrees of freedom: 66049 -cycle cells dofs L2 H1 Linfty - 0 64 289 1.606e-01 1.278e+00 3.029e-01 - 1 256 1089 7.638e-03 5.248e-01 4.816e-02 - 2 1024 4225 8.601e-04 1.086e-01 4.827e-03 - 3 4096 16641 1.107e-04 2.756e-02 7.802e-04 - 4 16384 66049 1.393e-05 6.915e-03 9.971e-05 +cycle cells dofs L2 H1 Linfty + 0 64 289 1.606e-01 1.278e+00 3.029e-01 + 1 256 1089 7.638e-03 5.248e-01 4.816e-02 + 2 1024 4225 8.601e-04 1.086e-01 4.827e-03 + 3 4096 16641 1.107e-04 2.756e-02 7.802e-04 + 4 16384 66049 1.393e-05 6.915e-03 9.971e-05 -n cells H1 L2 -0 64 1.278e+00 - - 1.606e-01 - - -1 256 5.248e-01 2.43 1.28 7.638e-03 21.03 4.39 -2 1024 1.086e-01 4.83 2.27 8.601e-04 8.88 3.15 -3 4096 2.756e-02 3.94 1.98 1.107e-04 7.77 2.96 -4 16384 6.915e-03 3.99 1.99 1.393e-05 7.94 2.99 +n cells H1 L2 +0 64 1.278e+00 - - 1.606e-01 - - +1 256 5.248e-01 2.43 1.28 7.638e-03 21.03 4.39 +2 1024 1.086e-01 4.83 2.27 8.601e-04 8.88 3.15 +3 4096 2.756e-02 3.94 1.98 1.107e-04 7.77 2.96 +4 16384 6.915e-03 3.99 1.99 1.393e-05 7.94 2.99 Solving with Q2 elements, adaptive refinement =========================================== @@ -160,16 +160,16 @@ Cycle 8: Number of active cells: 14212 Number of degrees of freedom: 64731 -cycle cells dofs L2 H1 Linfty - 0 64 289 1.606e-01 1.278e+00 3.029e-01 - 1 124 577 7.891e-03 5.256e-01 4.852e-02 - 2 289 1353 1.070e-03 1.155e-01 4.868e-03 - 3 547 2531 5.962e-04 5.101e-02 1.876e-03 - 4 1057 4919 1.977e-04 3.094e-02 7.923e-04 - 5 2059 9223 7.738e-05 1.974e-02 7.270e-04 - 6 3913 17887 2.925e-05 8.772e-03 1.463e-04 - 7 7441 33807 1.024e-05 4.121e-03 8.567e-05 - 8 14212 64731 3.761e-06 2.108e-03 2.167e-05 +cycle cells dofs L2 H1 Linfty + 0 64 289 1.606e-01 1.278e+00 3.029e-01 + 1 124 577 7.891e-03 5.256e-01 4.852e-02 + 2 289 1353 1.070e-03 1.155e-01 4.868e-03 + 3 547 2531 5.962e-04 5.101e-02 1.876e-03 + 4 1057 4919 1.977e-04 3.094e-02 7.923e-04 + 5 2059 9223 7.738e-05 1.974e-02 7.270e-04 + 6 3913 17887 2.925e-05 8.772e-03 1.463e-04 + 7 7441 33807 1.024e-05 4.121e-03 8.567e-05 + 8 14212 64731 3.761e-06 2.108e-03 2.167e-05 @endcode @@ -204,7 +204,7 @@ function of the number of unknowns. To see this, create a plot in log-log style with the number of unknowns on the x axis and the L2 error on the y axis. You can add reference lines for $h^2=N^{-1}$ and $h^3=N^{-3/2}$ and check that global and adaptive refinement -follow those. +follow those. Note that changing the half width of the peaks influences if adaptive or global refinement is more efficient (if the solution is very smooth, local diff --git a/examples/step-71/CMakeLists.txt b/examples/step-71/CMakeLists.txt index 47734969c2..4c8c92b21f 100644 --- a/examples/step-71/CMakeLists.txt +++ b/examples/step-71/CMakeLists.txt @@ -11,7 +11,7 @@ SET(TARGET "step-71") # you may want to either replace the following statement by something like # FILE(GLOB_RECURSE TARGET_SRC "source/*.cc") # FILE(GLOB_RECURSE TARGET_INC "include/*.h") -# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) +# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) # or switch altogether to the large project CMakeLists.txt file discussed # in the "CMake in user projects" page accessible from the "User info" # page of the documentation. diff --git a/examples/step-71/doc/intro.dox b/examples/step-71/doc/intro.dox index 7c27edcaf0..37f0360353 100644 --- a/examples/step-71/doc/intro.dox +++ b/examples/step-71/doc/intro.dox @@ -317,7 +317,7 @@ the following terms: -\sum_{e \in \mathbb{F}} \int_{e} \average{\frac{\partial^2 v_h}{\partial \mathbf n^2}} \jump{\frac{\partial u_h}{\partial \mathbf n}} -+ \sum_{e \in \mathbb{F}} ++ \sum_{e \in \mathbb{F}} \frac{\sigma}{h_e}\int_e \jump{\frac{\partial v_h}{\partial \mathbf n}} \jump{\frac{\partial u_h}{\partial \mathbf n}}. @@ -340,13 +340,13 @@ where \average{\frac{\partial^2 v_h}{\partial \mathbf n^2}} \jump{\frac{\partial u_h}{\partial \mathbf n}} \ ds \\ -&+ \sum_{e \in \mathbb{F}} +&+ \sum_{e \in \mathbb{F}} \frac{\gamma}{h_e} \int_e \jump{\frac{\partial v_h}{\partial \mathbf n}} \jump{\frac{\partial u_h}{\partial \mathbf n}} \ ds, @f} -and +and @f{align*}{ \mathcal{F}(v_h)&:=\sum_{K \in \mathbb{T}}\int_{K} v_h f \ dx + @@ -466,8 +466,8 @@ $\mathcal{O}(h^{p})$. There is probably a paper somewhere that proves this, but we also verify that this conjecture is experimentally true below. - - + +

          Other Boundary Conditions

          We remark that the derivation of the $C^0$ IP method for the diff --git a/examples/step-8/CMakeLists.txt b/examples/step-8/CMakeLists.txt index 11d85fd111..406cc6b360 100644 --- a/examples/step-8/CMakeLists.txt +++ b/examples/step-8/CMakeLists.txt @@ -11,7 +11,7 @@ SET(TARGET "step-8") # you may want to either replace the following statement by something like # FILE(GLOB_RECURSE TARGET_SRC "source/*.cc") # FILE(GLOB_RECURSE TARGET_INC "include/*.h") -# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) +# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) # or switch altogether to the large project CMakeLists.txt file discussed # in the "CMake in user projects" page accessible from the "User info" # page of the documentation. diff --git a/examples/step-9/CMakeLists.txt b/examples/step-9/CMakeLists.txt index fb50cb6f31..c98058cd4f 100644 --- a/examples/step-9/CMakeLists.txt +++ b/examples/step-9/CMakeLists.txt @@ -11,7 +11,7 @@ SET(TARGET "step-9") # you may want to either replace the following statement by something like # FILE(GLOB_RECURSE TARGET_SRC "source/*.cc") # FILE(GLOB_RECURSE TARGET_INC "include/*.h") -# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) +# SET(TARGET_SRC ${TARGET_SRC} ${TARGET_INC}) # or switch altogether to the large project CMakeLists.txt file discussed # in the "CMake in user projects" page accessible from the "User info" # page of the documentation. diff --git a/include/deal.II/base/hdf5.h b/include/deal.II/base/hdf5.h index 75a2965706..64526f52c0 100644 --- a/include/deal.II/base/hdf5.h +++ b/include/deal.II/base/hdf5.h @@ -101,7 +101,7 @@ DEAL_II_NAMESPACE_OPEN * not write any data at all, the process should call the function * DataSet::write_none() because the operation is *collective* and all the MPI * processes have to contribute to the call, even if they don't have data to - * write. + * write. * @code * std::vector dataset_dimensions = {50, 30}; * auto dataset = group.create_dataset("name", dataset_dimensions); diff --git a/include/deal.II/matrix_free/cuda_fe_evaluation.h b/include/deal.II/matrix_free/cuda_fe_evaluation.h index a36434fecc..9aa02d4403 100644 --- a/include/deal.II/matrix_free/cuda_fe_evaluation.h +++ b/include/deal.II/matrix_free/cuda_fe_evaluation.h @@ -288,7 +288,7 @@ namespace CUDAWrappers * CUDAWrappers::FEEvaluation *fe_eval, * const unsigned int q_point) const; * \endcode - * + * * @deprecated Use apply_for_each_quad_point() instead. */ // clang-format on @@ -298,7 +298,7 @@ namespace CUDAWrappers // clang-format off /** - * Same as above, except that the functor @func only takes a single input + * Same as above, except that the functor @func only takes a single input * argument (fe_eval) and computes the quadrature point from the thread id. * * @p func needs to define
          5. $Q_3$