From 540e4a75c7588c1dffde1dfabfc7c8301073d166 Mon Sep 17 00:00:00 2001 From: leicht Date: Fri, 14 Jul 2006 11:06:05 +0000 Subject: [PATCH] aniso: doc updates for the anisotropic_branch git-svn-id: https://svn.dealii.org/trunk@13386 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/doc/news/anisotropic.html | 167 +++++++++++++++++++++++++++--- 1 file changed, 153 insertions(+), 14 deletions(-) diff --git a/deal.II/doc/news/anisotropic.html b/deal.II/doc/news/anisotropic.html index f95ae2e3ee..02b4a83127 100644 --- a/deal.II/doc/news/anisotropic.html +++ b/deal.II/doc/news/anisotropic.html @@ -40,6 +40,19 @@ refinement.
    +
  1. + Changed: The FiniteElement<dim>::get_prolongation_matrix and FiniteElement<dim>::get_restriction_matrix functions now have an + additional argument of type RefineCase::Type to enable a + meaningful use of these matrices in case of anisotropic refinement. These + matrices are used for solution transfer and multigrid operations, but + there should be no need to use them in user codes directly. Note, that + the matrices are not fully implemented for all finite elements up to now. +
    (Tobias Leicht 2006/07/04) +

    +
  2. Changed: GeometryInfo::children_per_cell has been replaced by @@ -115,6 +128,30 @@ refinement.

    base

      +
    1. + New: There is now a new GeometryInfo<dim>::min_cell_refine_case function which returns the + RefineCase::Type representing the smallest refinement case + of a cell for a given refinement of one of its faces. In 2D for example a + cell has to be refined at least with RefineCase::cut_y if + the left line (line 0) shall be refined. Another refinement possibility + for the cell would be RefineCase::cut_xy, but that is not + the minimal case. +
      + (Tobias Leicht 2006/06/28) +

      + +
    2. + New: There is now a new GeometryInfo<dim>::line_refine_case function which returns the + RefineCase::Type representing the refinement case of a line + for a given refinement case of the corresponding cell. +
      + (Tobias Leicht 2006/06/28) +

      +
    3. New: The new GeometryInfo::n_children(ref_case) function returns the @@ -160,6 +197,119 @@ refinement.

      deal.II

        +
      1. + New: There is now a new Triangulation<dim>::tria_post_processing function which is only useful + in case of anisotropic refinement. It is possible, that a cell is refined + only in one direciton and later all the children are refined in another + one. Summing up, this would be the same as isotropic refinement, but with + a higher number of cells, faces and levels involved. Therefore, after the + refinement process, this function is called automatically and catches + cells, for which the described conditions apply. They are coarsened and + refined isotropically again. However, this is really something + internal to the library and there should never be the need to use this + function in user_codes. Calling Triangulation<dim>::execute_coarsening_and_refinement will be all you + need. +
        + (Tobias Leicht 2006/06/29) +

        + +
      2. + Extended: TheTriangulation<dim>::delete_children now takes an additional argument + keep_outer_faces of type bool which has a + default value of false. If set to true, the + children of the cells faces are never deleted, even if the neighbor does + not need them. Normally, this would leed to wasted memory, therefore + this should only be done, if they are needed afterwards, e.g. if the cell + is refined again. However, this is really something + internal to the library and there should never be the need to use this + function in user_codes. Calling Triangulation<dim>::execute_coarsening_and_refinement will be all you + need. +
        + (Tobias Leicht 2006/06/29) +

        + +
      3. + New: There is now a new Triangulation<dim>::create_children function which actually sets up the + children of a cell and updates the neighbor information. This work has + been done in Triangulation<dim>::execute_refinement so far. Memory allocation has to + be done prior to the function call. However, this is really something + internal to the library and there should never be the need to use this + function in user_codes. Calling Triangulation<dim>::execute_coarsening_and_refinement will be all you + need. +
        + (Tobias Leicht 2006/06/29) +

        + +
      4. + New: A part of the functionality of Triangulation<dim>::execute_coarsening has been implemented in a new way + and shifted to the new function Triangulation<dim>::coarsening_allowed. This function decides, + depending on the refinement situation of all a cells neighbors, if the + cell may be coarsened, in which case the bool value true is + returned. This is a functionality which is partly dimension dependend. +
        + However, there should never be any reason to use this function in user codes. +
        + (Tobias Leicht 2006/06/28) +

        + +
      5. + New: There is now a new accessor function coarser_neighbor, which returns a bool value + true, if the requested neighbor is a coarser one and + false if the neighbor is as refined as the current cell. This new + functionality is needed in the internals of the library to decide, if + neighbor_of_neighbor or + neighbor_of_coarser_neighbor has to be called. This decision + is trivial in case of isotropic refinement, where the level of the cell + and its neighbor is all the information needed. In case of aniostropic + refinement, this new function can be used. +
        + (Tobias Leicht 2006/06/28) +

        + +
      6. + New: There is now a new Triangulation<dim>::MeshSmoothing::allow_anisotropic_smoothing + smoothing flag for triangulations. An important part of the smoothing + process for refinement and coarsen flags is to ensure, that no double + refinement takes places at any face. If a cell is refined twice, its + neighbor has to be refined at least once. However, technically it is not + always necessary to refine the neighbor isotropically, it may be + sufficient to choose only one direction for the refinement. While this + allows to reduce the number of newly created cells to a minimum, it is incompatible + with older versions of the library, as anisotropic refinement takes + place, even if all the explicitly set refinement flags ask for + isotropic refinement. +
        + Therefore this functionality is off by default. However, in order to use + the new feature of anisotropic refinement to full extend, this flag should + be set explicitly. +
        + Note, that for reasons of backwards compatibility this flag is NOT + included in the general + MeshSmoothing::maximum_smoothing flag. +
        + (Tobias Leicht 2006/06/28) +

        +
      7. New: There is now a new TriaObjectAccessor:: -

      8. - Extended: The TriaAccessor<1>::operator == function is now overloaded by - TriaObjectAccessor<1,dim> for - dim>1 to allow the identification of a line with - its duplicate. -
        - (RH 2005/12/15) -

        -
      9. Extended (internal): Lines on level>0 have always been stored pairwise. In order to allow the creation of - duplicate lines we now also allow storage of single lines. The + single interior lines we now also allow storage of single lines. The TriangulationLevel<1>::reserve_space function now takes an additional n_consecutive_lines parameter which allows to create new single as well as pairs for lines (n_consecutive_lines=1 or - n_consecutive_lines=1, respectively. + n_consecutive_lines=2, respectively.
        (RH 2005/12/15)

      10. Changed: When allowing anisotropic refinement it cannot be - garantueed that all children of a cell are stored in + guaranteed that all children of a cell are stored in consecutive components of the quads.quads or the hexes.hexes vector, respectively. It is only known that children are stored at least in pairs. Therefore, it is -- 2.39.5