From: hartmann Date: Tue, 8 Jul 2008 15:39:46 +0000 (+0000) Subject: Move news entries from anisotropic.html to changes.h. X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3ea29e543030c504eda0ef6da9552bbaaf2e7348;p=dealii-svn.git Move news entries from anisotropic.html to changes.h. git-svn-id: https://svn.dealii.org/trunk@16433 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/doc/news/anisotropic.html b/deal.II/doc/news/anisotropic.html deleted file mode 100644 index 3d63a1b7bf..0000000000 --- a/deal.II/doc/news/anisotropic.html +++ /dev/null @@ -1,385 +0,0 @@ -/** - * @page anisotropic_changes Changes between the trunk and branch_anisotropic - -

-This is the list of changes between the subversion trunk and the -anisotropic branch of the deal.II library. It is subdivided into -changes made to the three sub-libraries base, lac, and deal.II, as well as -changes to the general infrastructure, -documentation, etc. -

- -

-All entries are signed with the names of the author. Regular -contributor's names are abbreviated by WB (Wolfgang Bangerth), GK -(Guido Kanschat), RH (Ralf Hartmann). -

- - - -

Incompatibilities

- -

-Following are a few modifications to the library that unfortunately -are incompatible with previous versions of the library, but which we -deem necessary for the extension of the library to anisotropic -refinement. -

- - -
    -
  1. - Changed: The FiniteElement::get_prolongation_matrix and - FiniteElement::get_restriction_matrix functions now have an - additional argument of type RefinementCase 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 GeometryInfo::max_children_per_cell, which - represents the maximum number of children a cell might have, - i.e. the number of children in the case of isotropic - refinement. But note, that this number will rarely be needed in - user codes. In general, the number of children of a cell varies - from cell to cell and can be obtained by - cell->n_children(), which gives the number of - children of a specific cell which is refined iso- - or anisotropically. -
    - (RH 2005/02/26) -

    - -
  3. - Changed: The analogous change applies to the number of children - of a face. GeometryInfo::subfaces_per_face has - been replaced by GeometryInfo::max_children_per_face, which - represents the maximum number of children a face might have, - i.e. the number of children in the case of an isotropic refined - face. But note, that this number will rarely be needed in user - codes. In general, the number of children of a face varies from - face to face and can be obtained by - face->n_children(), which gives the number of - children of a specific face which is refined iso- - or anisotropically. -
    - (RH 2005/02/26) -

    - -
  4. - Changed: The GeometryInfo::child_cell_on_face function is - generalized to anisotropic refinement and has now an additional - RefinementCase argument. This function will rarely be used in - user codes, as e.g. the neighbor's child at a specific face and - subface should be accessed through - cell->neighbor_child_on_subface rather than - through the GeometryInfo::child_cell_on_face function. -
    - (RH 2005/02/27) -

    -
- - - -

General

- -
    -
  1. - New but temporarily: A global - anisotropic_refinement flag has been introduced - (defined in geometry_info.h, initialized in - geometry_info.cc) indicating whether an - anisotropic refinement has been performed or not. This flag is - checked throughout the code and throws an exception in all - parts of the library which are not yet generalized to - anisotropic refinement. This flag can be removed once - anisotropic refinement is fully incorporated into deal.II. -
    - (RH 2005/02/26) -

    -
- - - - -

base

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

    - -
  2. - New: There is now a new GeometryInfo::line_refinement_case - function which returns the RefinementCase 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(refinement_case) - function returns the number of children a cell/face has when - refined with the RefinementCase refinement_case. -
    - (RH 2005/11/07) -

    - -
  4. - New: Given a RefinementCase of a cell the new - GeometryInfo::face_refinement_case function returns the - RefinementCase of a face. -
    - (RH 2005/11/07) -

    - -
  5. - New: There is now a new RefinementCase - GeometryInfo::isotropic_refinement representing the isotropic - refinement case in dim dimensions, - i.e. GeometryInfo<1>::isotropic_refinement=RefinementCase::cut_x, - GeometryInfo<2>::isotropic_refinement=RefinementCase::cut_xy - and - GeometryInfo<3>::isotropic_refinement=RefinementCase::cut_xyz. -
    - (RH 2005/03/03) -

    -
- - - - -

lac

- - - - -

deal.II

- -
    -
  1. - New: There is now a new - Triangulation::prevent_distorted_boundary_cells function which - only useful in case of anisotropic refinement. At the boundary - of the domain, the new point on the face may be far inside the - current cell, if the boundary has a strong curvature. If we - allow anistropic refinement here, the resulting cell may be - strongly distorted, especially if it is refined again later - on. To prevent this problem, this function flags such cells for - isotropic refinement. It is called automatically from - Triangulation::prepare_coarsening_and_refinement. Therefore - this should have no effect on user codes. -
    - (Tobias Leicht 2006/08/02) -

    - -
  2. - New: There is now a new Triangulation::create_children function - which actually sets up the children of a cell and updates the - neighbor information. This work has been done in - Triangulation::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::execute_coarsening_and_refinement will be all - you need. -
    - (Tobias Leicht 2006/06/29) -

    - -
  3. - - New: A part of the functionality of Triangulation::execute_coarsening has been implemented in a new way - and shifted to the new function Triangulation::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) -

    - -
  4. - New: There is now a new CellAccessor::neighbor_is_coarser function, - 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) -

    - -
  5. - New: There is now a new - Triangulation::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) -

    - -
  6. - New: There is now a new - TriaObjectAccessor::clear_refinement_case function. -
    - (RH 2005/12/19) -

    - -
  7. - Extended: The CellAccessor::neighbor_of_neighbor function is - now extended to anisotropic refinement. -
    - (RH 2005/12/15) -

    - -
  8. - Extended (internal): Lines on level>0 have always - been stored pairwise. In order to allow the creation of 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=2, respectively. -
    - (RH 2005/12/15) -

    - -
  9. - Changed: When allowing anisotropic refinement it cannot be - guaranteed that all children of a cell are stored in - consecutive components of the TriaLevel::cells vector, - respectively. It is only known that children are stored at - least in pairs. Therefore, it is not sufficient any more to - store the index of the first child of a cell, only. Now the - indices of every second child, i.e. of the even numbered - children, must be stored. For this, the - TriaObjectAccessor::set_children function for cells now has a - new argument representing the number of the child for which the - index shall be set. This function can only be called for even - numbered children. The same applies to the respective function - for faces. -
    - Finally, we note that these functions are for internal use, - only. -
    - (RH 2005/03/03) -

    - -
  10. - Changed: The CellAccessor::refine_flag_set function now returns - a RefinementCase argument instead of a boolean. Be aware, that - you now still can ask if(!cell->refine_flag_set()) - , if(cell->refine_flag_set()==false) and - if(cell->refine_flag_set()) , but you cannot ask - if(cell->refine_flag_set()==true) any more. -
    - (RH 2005/03/03) -

    - -
  11. - Extended: The CellAccessor::set_refine_flag function now has a - new RefinementCase argument which defaults to - GeometryInfo::isotropic_refinement. -
    - (RH 2005/03/03) -

    - -
  12. - New: There is now a new class RefinementCase defined in - geometry_info.h, which allows to describe all - possible (anisotropic and isotropic) refinement cases in (1,) 2 - and 3 dimensions. -
    - (RH 2005/02/26) -

    - -
  13. - New: There is now a new TriaObjectAccessor::n_children function - which returns the number of children of the cell or face it was - invoked for. -
    - (RH 2005/02/26) -

    - -
  14. - New: There is now a new TriaObjectAccessor::refinement_case - function which returns the RefinementCase a cell or face is - refined with. -
    - (RH 2005/02/26) -

    - -
  15. - New (for internal use only): There is now a new - TriaObjectAccessor::set_refinement_case function. This function - is mainly for internal use (required by - Triangulation::execute_coarsening_and_refinement). It is not - provided for dim=1 as there the refinement case - defaults to isotropic refinement. -
    - Note, that users should still use the - CellAccessor::set_refine_flag function for setting the - RefinementCase of cells to be refined within the next - Triangulation::execute_coarsening_and_refinement function. -
    - (RH 2005/02/26) -

    - -
  16. - - New: New vector@ refinement_cases - vectors have been introduced in TriaObjects. For memory - efficiency (but with a penalty on run-time) they might be - replaced by vector@ @> (dim, vector@ - (n_quads/n_hexes)), later. -
    - (RH 2005/02/26) -

    -
- -*/ diff --git a/deal.II/doc/news/changes.h b/deal.II/doc/news/changes.h index 78c41006c5..106ef13d9a 100644 --- a/deal.II/doc/news/changes.h +++ b/deal.II/doc/news/changes.h @@ -35,6 +35,64 @@ inconvenience this causes.
  1. +

    + Changed: The FiniteElement::get_prolongation_matrix and + FiniteElement::get_restriction_matrix functions now have an + additional argument of type RefinementCase 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 2008/07/08 as of branch_anisotropic at 2006/07/04) +

    + +
  2. +

    + Changed: GeometryInfo::children_per_cell has been + replaced by GeometryInfo::max_children_per_cell, which + represents the maximum number of children a cell might have, + i.e. the number of children in the case of isotropic + refinement. But note, that this number will rarely be needed in + user codes. In general, the number of children of a cell varies + from cell to cell and can be obtained by + cell->n_children(), which gives the number of + children of a specific cell which is refined iso- + or anisotropically. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/02/26) +

    + +
  3. +

    + Changed: The analogous change applies to the number of children + of a face. GeometryInfo::subfaces_per_face has + been replaced by GeometryInfo::max_children_per_face, which + represents the maximum number of children a face might have, + i.e. the number of children in the case of an isotropic refined + face. But note, that this number will rarely be needed in user + codes. In general, the number of children of a face varies from + face to face and can be obtained by + face->n_children(), which gives the number of + children of a specific face which is refined iso- + or anisotropically. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/02/26) +

    + +
  4. +

    + Changed: The GeometryInfo::child_cell_on_face function is + generalized to anisotropic refinement and has now an additional + RefinementCase argument. This function will rarely be used in + user codes, as e.g. the neighbor's child at a specific face and + subface should be accessed through + cell->neighbor_child_on_subface rather than + through the GeometryInfo::child_cell_on_face function. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/02/27) +

@@ -81,6 +139,62 @@ inconvenience this causes.
  1. +

    + New: There are now a new + GeometryInfo::min_cell_refinement_case_for_face_refinement + (resp. GeometryInfo::min_cell_refinement_case_for_line_refinement) + function which returns the RefinementCase representing the + smallest refinement case of a cell for a given refinement of + one of its faces (resp. lines). In 2D for example a cell has to + be refined at least with RefinementCase::cut_y if the left line + (line 0) shall be refined. Another refinement possibility for + the cell would be RefinementCase::cut_xy, but that + is not the minimal case. +
    + (Tobias Leicht 2008/07/08 as of branch_anisotropic at 2006/06/28) +

    + +
  2. +

    + New: There is now a new GeometryInfo::line_refinement_case + function which returns the RefinementCase representing the + refinement case of a line for a given refinement case of the + corresponding cell. +
    + (Tobias Leicht 2008/07/08 as of branch_anisotropic at 2006/06/28) +

    + +
  3. +

    + New: The new + GeometryInfo::n_children(refinement_case) + function returns the number of children a cell/face has when + refined with the RefinementCase refinement_case. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/11/07) +

    + +
  4. +

    + New: Given a RefinementCase of a cell the new + GeometryInfo::face_refinement_case function returns the + RefinementCase of a face. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/11/07) +

    + +
  5. +

    + New: There is now a new RefinementCase + GeometryInfo::isotropic_refinement representing the isotropic + refinement case in dim dimensions, + i.e. GeometryInfo<1>::isotropic_refinement=RefinementCase::cut_x, + GeometryInfo<2>::isotropic_refinement=RefinementCase::cut_xy + and + GeometryInfo<3>::isotropic_refinement=RefinementCase::cut_xyz. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/03/03) +

@@ -98,6 +212,224 @@ inconvenience this causes.

deal.II

    +
  1. +

    + New: There is now a new + Triangulation::prevent_distorted_boundary_cells function which + only useful in case of anisotropic refinement. At the boundary + of the domain, the new point on the face may be far inside the + current cell, if the boundary has a strong curvature. If we + allow anistropic refinement here, the resulting cell may be + strongly distorted, especially if it is refined again later + on. To prevent this problem, this function flags such cells for + isotropic refinement. It is called automatically from + Triangulation::prepare_coarsening_and_refinement. Therefore + this should have no effect on user codes. +
    + (Tobias Leicht 2008/07/08 as of branch_anisotropic at 2006/08/02) +

    + +
  2. +

    + New: There is now a new Triangulation::create_children function + which actually sets up the children of a cell and updates the + neighbor information. This work has been done in + Triangulation::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::execute_coarsening_and_refinement will be all + you need. +
    + (Tobias Leicht 2008/07/08 as of branch_anisotropic at 2006/06/29) +

    + +
  3. +

    + New: A part of the functionality of Triangulation::execute_coarsening has been implemented in a new way + and shifted to the new function Triangulation::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 2008/07/08 as of branch_anisotropic at 2006/06/28) +

    + +
  4. +

    + New: There is now a new CellAccessor::neighbor_is_coarser function, + 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 2008/07/08 as of branch_anisotropic at 2006/06/28) +

    + +
  5. +

    + New: There is now a new + Triangulation::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 2008/07/08 as of branch_anisotropic at 2006/06/28) +

    + +
  6. +

    + New: There is now a new + TriaObjectAccessor::clear_refinement_case function. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/12/19) +

    + +
  7. +

    + Extended: The CellAccessor::neighbor_of_neighbor function is + now extended to anisotropic refinement. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/12/15) +

    + +
  8. +

    + Extended (internal): Lines on level>0 have always + been stored pairwise. In order to allow the creation of 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=2, respectively. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/12/15) +

    + +
  9. +

    + Changed: When allowing anisotropic refinement it cannot be + guaranteed that all children of a cell are stored in + consecutive components of the TriaLevel::cells vector, + respectively. It is only known that children are stored at + least in pairs. Therefore, it is not sufficient any more to + store the index of the first child of a cell, only. Now the + indices of every second child, i.e. of the even numbered + children, must be stored. For this, the + TriaObjectAccessor::set_children function for cells now has a + new argument representing the number of the child for which the + index shall be set. This function can only be called for even + numbered children. The same applies to the respective function + for faces. +
    + Finally, we note that these functions are for internal use, + only. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/03/03) +

    + +
  10. +

    + Changed: The CellAccessor::refine_flag_set function now returns + a RefinementCase argument instead of a boolean. Be aware, that + you now still can ask if(!cell->refine_flag_set()) + , if(cell->refine_flag_set()==false) and + if(cell->refine_flag_set()) , but you cannot ask + if(cell->refine_flag_set()==true) any more. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/03/03) +

    + +
  11. +

    + Extended: The CellAccessor::set_refine_flag function now has a + new RefinementCase argument which defaults to + GeometryInfo::isotropic_refinement. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/03/03) +

    + +
  12. +

    + New: There is now a new class RefinementCase defined in + geometry_info.h, which allows to describe all + possible (anisotropic and isotropic) refinement cases in (1,) 2 + and 3 dimensions. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/02/26) +

    + +
  13. +

    + New: There is now a new TriaObjectAccessor::n_children function + which returns the number of children of the cell or face it was + invoked for. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/02/26) +

    + +
  14. +

    + New: There is now a new TriaObjectAccessor::refinement_case + function which returns the RefinementCase a cell or face is + refined with. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/02/26) +

    + +
  15. +

    + New (for internal use only): There is now a new + TriaObjectAccessor::set_refinement_case function. This function + is mainly for internal use (required by + Triangulation::execute_coarsening_and_refinement). It is not + provided for dim=1 as there the refinement case + defaults to isotropic refinement. +
    + Note, that users should still use the + CellAccessor::set_refine_flag function for setting the + RefinementCase of cells to be refined within the next + Triangulation::execute_coarsening_and_refinement function. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/02/26) +

    + +
  16. +

    + New: New vector@ refinement_cases + vectors have been introduced in TriaObjects. For memory + efficiency (but with a penalty on run-time) they might be + replaced by vector@ @> (dim, vector@ + (n_quads/n_hexes)), later. +
    + (RH 2008/07/08 as of branch_anisotropic at 2005/02/26) +

    +
  17. Fixed: When using a higher order mapping of degree at least 3 (i.e.