From c0a95a56a19a2f2d1d95fa200e7a10692f799955 Mon Sep 17 00:00:00 2001
From: IvBu <ivan.buntic@iws.uni-stuttgart.de>
Date: Fri, 28 Feb 2025 12:12:33 +0100
Subject: [PATCH] [doc] Fix formatting of new pages.

---
 doc/doxygen/DoxygenDumuxLayout.xml            |  2 +-
 doc/doxygen/pages/changing-property-name.md   | 58 +++++++++----------
 doc/doxygen/pages/custom-input-data.md        |  2 +-
 doc/doxygen/pages/gmsh-with-alugrid.md        |  8 +--
 doc/doxygen/pages/printing-system-matrix.md   |  6 +-
 ...grading-dumux-programs-to-version-three.md |  6 +-
 6 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/doc/doxygen/DoxygenDumuxLayout.xml b/doc/doxygen/DoxygenDumuxLayout.xml
index 7ef44acde6..3af082a246 100644
--- a/doc/doxygen/DoxygenDumuxLayout.xml
+++ b/doc/doxygen/DoxygenDumuxLayout.xml
@@ -37,7 +37,7 @@ SPDX-License-Identifier: GPL-3.0-or-later
       <tab type="user" url="@ref custom-input-data" visible="yes" title="Custom input data" intro=""/>
       <tab type="user" url="@ref gmsh-with-alugrid" visible="yes" title="Gmsh with ALUGrid" intro=""/>
       <tab type="user" url="@ref printing-system-matrix" visible="yes" title="Printing system matrix" intro=""/>
-      <tab type="user" url="@ref upgrading-dumux-programs-to-version-three" visible="yes" title="Upgrading Dumux programs to v.3.0" intro=""/>
+      <tab type="user" url="@ref upgrading-dumux-programs-to-version" visible="yes" title="Upgrading to Dumux 3" intro=""/>
     </tab>
     <tab type="user" url="@ref citelist" visible="yes" title="Bibliography" intro=""/>
     <tab type="namespaces" visible="yes" title="">
diff --git a/doc/doxygen/pages/changing-property-name.md b/doc/doxygen/pages/changing-property-name.md
index 673a2e64bf..7175802a21 100644
--- a/doc/doxygen/pages/changing-property-name.md
+++ b/doc/doxygen/pages/changing-property-name.md
@@ -6,17 +6,17 @@ The only working possibility is to have two properties `OldProperty` and `NewPro
 
 ## Actions to be done in the module `dumux` before release
 
-#### Deprecate the old property
+__Deprecate the old property__
 
-```c++
+```cpp
 template<class TypeTag, class MyTypeTag>
 struct [[deprecated("Use OldProperty instead.")]] OldProperty { using type = UndefinedProperty; };
 ```
 Properties are usually defined in `dumux/common/properties.hh`.
 
-#### Define the new property
+__Define the new property__
 
-```c++
+```cpp
 #pragma GCC diagnostic push
 #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
 
@@ -39,9 +39,9 @@ struct NewProperty
 The ignore pragmas avoid the emission of deprecation warnings for using the old property inside.
 The indirection via the helper class is required to allow specializing the new property with an undefined/unspecialized old one.
 
-#### Treat specializations
+__Treat specializations__
 
-```c++
+```cpp
 #pragma GCC diagnostic push
 #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
 
@@ -54,28 +54,28 @@ struct OldProperty<TypeTag, TTag::SpecialModel> {
 Specializations still have to be performed in terms of the old property, otherwise
 user code can't employ the old name. Only the ignore pragmas have to be added.
 
-#### Use the new name
+__Use the new name__
 
 Change all
-```c++
+```cpp
 using MyOldFavoriteName = GetPropType<TypeTag, Properties::OldProperty>;
 ```
 to
-```c++
+```cpp
 using MyNewFavoriteName = GetPropType<TypeTag, Properties::NewProperty>;
 ```
 
-#### Export the new name
+__Export the new name__
 
 Very often, `MyOldFavoriteName` in the snippet above coincides with `OldProperty`. In this case, it is advisable
 to set `MyNewFavoriteName` to `NewProperty`. While this is unproblematic if the alias is local,
 take special care for exported names:
-```c++
+```cpp
 public:
     using OldProperty = GetPropType<TypeTag, Properties::OldProperty>;
 ```
 should become
-```c++
+```cpp
 public:
     using NewProperty = GetPropType<TypeTag, Properties::NewProperty>;
     using OldProperty [[deprecated("Use NewProperty instead.")]] = NewProperty;
@@ -83,29 +83,29 @@ public:
 
 ## Actions to be done in derived modules and user code
 
-#### Change using declarations
+__Change using declarations__
 
 Change all
-```c++
+```cpp
 using MyOldFavoriteName = GetPropType<TypeTag, Properties::OldProperty>;
 ```
 to
-```c++
+```cpp
 using MyNewFavoriteName = GetPropType<TypeTag, Properties::NewProperty>;
 ```
 If `MyOldFavoriteName` is exported and you care about backwards compatibility, consider
 deprecating it as outlined above.
 
-#### Treat specializations
+__Treat specializations__
 
 Change all
-```c++
+```cpp
 struct OldProperty<TypeTag, TTag::SpecialModel> {
     using type = SpecialType<...>;
 };
 ```
 to
-```c++
+```cpp
 struct NewProperty<TypeTag, TTag::SpecialModel> {
     using type = SpecialType<...>;
 };
@@ -114,37 +114,37 @@ This should work because everywhere we now get the new property, so it is possib
 
 ## Actions to be done in the module `dumux` after release
 
-#### Only define the new property
+__Only define the new property__
 
 Replace the two snippets "Deprecate the old property" and "Define the new property" by
-```c++
+```cpp
 template<class TypeTag, class MyTypeTag>
 struct NewProperty { using type = UndefinedProperty; };
 ```
 
-#### Only specialize the new property
+__Only specialize the new property__
 
 Replace the dumux code base snippet "Treat specializations" by
-```c++
+```cpp
 struct NewProperty<TypeTag, TTag::SpecialModel> {
     using type = SpecialType<...>;
 };
 ```
 
-#### Remove exports of the old name
+__Remove exports of the old name__
 
 Remove the line containing the deprecation from the snippet "Export the new name".
 
-### Known limitation
+__Known limitation__
 
 Unfortunately, clang emits false positives when invoking the outlined strategy.
 A workaround is to prevent clang from emitting deprecation warnings triggered
 by using `GetPropType` and `getPropValue()`. To this end, the line
-```c++
+```cpp
      using LastType = Property<TypeTag, LastTypeTag>;
 ```
 in `GetDefined` in `dumux/common/properties/propertysystem.hh` has to be augmented to
-```c++
+```cpp
 #ifdef __clang__
 #pragma clang diagnostic push
 #pragma clang diagnostic ignored "-Wdeprecated-declarations"
@@ -155,11 +155,11 @@ in `GetDefined` in `dumux/common/properties/propertysystem.hh` has to be augment
 #endif
 ```
 The lines
-```c++
+```cpp
      using FirstType = Property<TypeTag, FirstTypeTag>;
 ```
 and
-```c++
+```cpp
 template<class TypeTag, template<class,class> class Property>
 using GetPropType = typename Properties::Detail::GetPropImpl<TypeTag, Property>::type::type;
 
@@ -169,7 +169,7 @@ constexpr auto getPropValue() { return Properties::Detail::GetPropImpl<TypeTag,
 have to be treated in the same way.
 
 This should be augmented by a general warning message that is put best before the deprecation of the old property in `dumux/common/properties.hh`:
-```c++
+```cpp
 #if defined(__clang__) && !defined(DONT_EMIT_CLANG_NEWPROPERTY_WARNING)
 #warning "The property `OldProperty` is deprecated in favor of `NewProperty` \
 and will be removed after release X.Y. \
diff --git a/doc/doxygen/pages/custom-input-data.md b/doc/doxygen/pages/custom-input-data.md
index c29f7c17c9..7ab1934ce1 100644
--- a/doc/doxygen/pages/custom-input-data.md
+++ b/doc/doxygen/pages/custom-input-data.md
@@ -84,4 +84,4 @@ and read fields like this
 const tinyxml2::XMLElement* inputData = xmlData.FirstChildElement("InputData");
 std::stringstream injectionData(inputData->FirstChildElement("InjectionRates")->GetText());
 const auto injectionRates = readStreamToContainer<std::vector<double>>(injectionData);
-```
\ No newline at end of file
+```
diff --git a/doc/doxygen/pages/gmsh-with-alugrid.md b/doc/doxygen/pages/gmsh-with-alugrid.md
index ca5c59f8f3..7e374a6698 100644
--- a/doc/doxygen/pages/gmsh-with-alugrid.md
+++ b/doc/doxygen/pages/gmsh-with-alugrid.md
@@ -2,7 +2,7 @@
 
 If you are using Gmsh to create more complex grids and are using "Physical groups" to mark different boundary segments, you can normally access these inside your definition of the `neumann` function (solution dependent von Neumann boundaries) in your problem file by using something like the following:
 
-```c++
+```cpp
 NumEqVector neumann(const Element& element,
                     const FVElementGeometry& fvGeometry,
                     const ElementVolumeVariables& elemVolVars,
@@ -27,7 +27,7 @@ BoundarySegments = 1
 Unfortunately `ALUGrid` uses boundary flags differently, therefore you have to adapt your `FVGridGeometry` to use the class `BoundarySegmentIndexFlag` instead of the normal `BoundaryFlag` class.
 This can be done in your property settings, where you need to add the following:
 
-```c++
+```cpp
 #include <dumux/common/boundaryflag.hh>
 
 namespace Properties {
@@ -65,7 +65,7 @@ public:
 ```
 This was how to do it when using the Box discretization, for CCTpfa it works similarly:
 
-```c++
+```cpp
 namespace Properties {
 
 // other property settings
@@ -98,4 +98,4 @@ public:
 } // end namespace properties
 ```
 
-Then you can access the boundary marker/physical group in the same way as shown above
\ No newline at end of file
+Then you can access the boundary marker/physical group in the same way as shown above.
diff --git a/doc/doxygen/pages/printing-system-matrix.md b/doc/doxygen/pages/printing-system-matrix.md
index 3c98c94539..dc4275588f 100644
--- a/doc/doxygen/pages/printing-system-matrix.md
+++ b/doc/doxygen/pages/printing-system-matrix.md
@@ -6,7 +6,7 @@ The following example shows a possible way to achieve this for a staggered-grid
 
 We add the output within the `solveLinearSystem_` overload for `Dune::MultiTypeBlockMatrix` Jacobians in `newtonsolver.hh`:
 
-```c++
+```cpp
     //  MultiTypeBlockMatrix is not supported for printing, needs to be converted first
 
     // create the bcrs matrix the IterativeSolver backend can handle
@@ -51,6 +51,6 @@ Keep in mind that the `MatrixMarket`format uses indices starting with `1` instea
 
 For rather small matrices, you may also directly print the output to the terminal, giving you a graphical impression of the structure:
 
-```c++
+```cpp
 Dune::printmatrix(std::cout, M, "", "", 10/*width*/, 2/*precision*/);
-```
\ No newline at end of file
+```
diff --git a/doc/doxygen/pages/upgrading-dumux-programs-to-version-three.md b/doc/doxygen/pages/upgrading-dumux-programs-to-version-three.md
index 8d5a6c8f43..bd2afc29ee 100644
--- a/doc/doxygen/pages/upgrading-dumux-programs-to-version-three.md
+++ b/doc/doxygen/pages/upgrading-dumux-programs-to-version-three.md
@@ -1,4 +1,4 @@
-# Upgrading dumux programs to version three
+# Upgrading dumux programs to version 3.0
 
 The major version update from DuMuX 2.12 to DuMuX 3.0 included some backward-incompatible changes. For the 3-series backward-compatibility will again be assured from one minor version update to the next.
 
@@ -72,7 +72,7 @@ The base classes for problems, originally `ImplicitPorousMediaProblem` and `Impl
 
 `grid()`, `gridView()`, `bBoxMin()`, `bBoxMax()`, `vertexMapper()`, `elementMapper()`, `dofMapper()`
 
-The `FVGridGeometry` and it's element-wise local counter part `FVElementGeometry` provide the abtractions of sub control volumes and sub control volume faces. For instance it it now possible given an instance of `FVElementGeometry` called `fvGeometry` to iterate over all sub control volumes associated with this element
+The `FVGridGeometry` and it's element-wise local counter part `FVElementGeometry` provide the abstractions of sub control volumes and sub control volume faces. For instance it it now possible given an instance of `FVElementGeometry` called `fvGeometry` to iterate over all sub control volumes associated with this element
 
 ```cpp
 for (const auto& scv : scvs(fvGeometry))
@@ -181,4 +181,4 @@ The `MaterialLaw` is no longer a dumux _property_, which is why you now have to
 using MaterialLaw = RegularizedVanGenuchten<Scalar>;
 using MaterialLawParams = typename MaterialLaw::Params;
 using PermeabilityType = Scalar;
-```
\ No newline at end of file
+```
-- 
GitLab