CINTROINI · Sep 13, 2026 · Sep 12, 2026 · Sep 12, 2026 · Sep 12, 2026 · Sep 12, 2026
diff --git a/doc/docs/Documentation/User/Aliases/index.md b/doc/docs/Documentation/User/Aliases/index.md
@@ -0,0 +1,55 @@
+# Aliases
+
+Every `SLOTH` test needs the same handful of type aliases (finite element collection, variables, post-processing, mesh, boundary conditions...) plus a couple of factory functions. Instead of declaring them one by one, a single line brings in everything for a given spatial dimension:
+
+```c++
+using namespace Sloth2D;   // or Sloth1D / Sloth3D
+```
+
+That's it — no need to write out `FECollection`, `VARS`, `SPA`, etc. by hand anymore.
+
+## What you get with `using namespace SlothND`
+
+| Alias                   | Description                                         | Typical use                                                                                          |
+| ----------------------- | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
+| `DIM`                   | Spatial dimension                                   | Passed to many objects...                                                                            |
+| `FECollection`          | Finite element collection (`mfem::H1_FECollection`) | Passed to `SPA`/`BCS` if you need it explicitly                                                      |
+| `VARS`                  | Collection of variables                             | `VARS vars(var1, var2, ...)`                                                                         |
+| `VAR`                   | A single variable                                   | `VAR phi(&spatial, bcs, "phi", ...)`                                                                 |
+| `PST`                   | Post-processing object                              | `PST pst(&spatial, pst_parameters)`                                                                  |
+| `SPA`                   | Spatial discretization                              | `SPA spatial(mesh_type, ...)`                                                                        |
+| `SPAS`                  | `std::vector<SPA*>`                                 | Returned by the [SpatialDiscretization factories](../SpatialDiscretization/Meshing/index.md#factory) |
+| `BCS`                   | Boundary conditions                                 | `BCS bcs(&spatial, boundaries)`                                                                      |
+| `PB_MPI`                | `MPI_Problem<VARS, PST>`                            | 0D / lumped-parameter problems                                                                       |
+| `PB_CALPHAD<CALPHAD>`   | `Calphad_Problem<CALPHAD, VARS, PST>`               | Calphad-driven problems                                                                              |
+| `PB_PROPERTY<PROPERTY>` | `Property_problem<PROPERTY, VARS, PST>`             | Property-driven problems                                                                             |
+
+None of these depend on whether the problem is transient or steady — that's why one `using namespace` is enough to get all of them, regardless of the scheme used.
+
+## PDE aliases
+
+`TransientOPE`/`TransientPB`/`SteadyOPE`/`SteadyPB` are already included in the single `using namespace Sloth2D;` shown above — no extra namespace is required:
+
+```c++
+using namespace Sloth2D;
+```
+
+| Alias          | Description                                                |
+| -------------- | ---------------------------------------------------------- |
+| `TransientOPE` | The operator (`TransientOperator<...>`)                    |
+| `SteadyOPE`    | The operator (`SteadyOperator<...>`)                       |
+| `TransientPB`  | The transient problem (`Problem<TransientOPE, VARS, PST>`) |
+| `SteadyPB`     | The steady problem (`Problem<SteadyOPE, VARS, PST>`)       |
+
+
+
+## Practical cheat sheet
+
+- **One scheme only, minimal setup** → `using namespace Sloth2D;` 
+- **Both schemes in the same file** → use `TransientPB`/`SteadyPB`, `TransientOPE`/`SteadyOPE`.
+- **1D or 3D** → replace `2D` with `1D`/`3D` everywhere above.
+- **Building many spatial discretizations / boundary conditions / a coupling** :
+  - `setSpatialDiscretization(N, args...)` : builds `N` spatial discretizations sharing a single **non-periodic** mesh — see [Meshing](../SpatialDiscretization/Meshing/index.md#factory).
+  - `setPeriodicSpatialDiscretization(N, args...)` : same as above, for a **periodic** mesh — see [Meshing](../SpatialDiscretization/Meshing/index.md#factory).
+  - `setBoundaryConditions(N, spatials, boundaries)` : builds `N` boundary conditions, one per spatial discretization, from a single shared list of `Boundary` objects — see [Boundary Conditions](../SpatialDiscretization/BoundaryConditions/index.md#factory).
+  - `setCoupling<N>(name, problems)` : couples `N` `Problem` objects of the same type into a single `Coupling`, without repeating the type by hand — see [Couplings](../MultiPhysicsCouplingScheme/Couplings/index.md#factory).
diff --git a/doc/docs/Documentation/User/MultiPhysicsCouplingScheme/Convergence/index.md b/doc/docs/Documentation/User/MultiPhysicsCouplingScheme/Convergence/index.md
@@ -29,7 +29,7 @@ The `PhysicalConvergence` objects are defined by:
 
     auto conv_criteria = Convergence(phi_cvg, mu_cvg);
 
-    Problem<OPE, VARS, PST> my_problem(my_operator, my_variables, my_post_processing, conv_criteria);
+    TransientPB my_problem(my_operator, my_variables, my_post_processing, conv_criteria);
     ```
 
 !!! note "On the use of `Convergence` objects"

diff --git a/doc/docs/Documentation/User/MultiPhysicsCouplingScheme/Couplings/index.md b/doc/docs/Documentation/User/MultiPhysicsCouplingScheme/Couplings/index.md
@@ -2,6 +2,9 @@
 
 This page described how to define and manage couplings in `SLOTH`.
 
+
+## __Coupling different problems__ {#coupling}
+
 Couplings for `SLOTH` are made with a C++ object of type `Coupling`. 
 They must be defined by:
 
@@ -23,6 +26,28 @@ They must be defined by:
     ```
 
 
+## __Coupling N identical problems__ {#factory}
+
+This approach work naturally when each problem has a distinct role, but becomes impractical when coupling `N` problems of the **same** type `PB`, as encountered for multiphase-field simulations. 
+In that case, it is recommended to use `setCoupling<N>`, which enables building repeated type from a `std::vector<PB>`, with `N` given explicitly as a template parameter:
+
+!!! example "Coupling 30 identical problems"
+    In this example, 30 identical Allen-Cahn problems for simulating polycristaline microstructure are used to define a `Coupling`
+
+    ```c++
+        std::vector<PB> ac_pbs;
+        ac_pbs.reserve(30);
+        // ... fill ac_pbs with 30 Problem objects ...
+
+        auto cc = setCoupling<30>("Multigrains", ac_pbs);
+    ```
+    This is equivalent to `Coupling("Multigrains", ac_pbs[0], ac_pbs[1], ..., ac_pbs[29])`, without writing out the repeated type or the 30 arguments by hand.
+
+!!! warning "Consistency between N and the size of the vector"
+    `N` must match the size of the vector exactly
+
+
+
 
 
 
diff --git a/doc/docs/Documentation/User/MultiPhysicsCouplingScheme/Problems/0D/index.md b/doc/docs/Documentation/User/MultiPhysicsCouplingScheme/Problems/0D/index.md
@@ -9,10 +9,8 @@ Definition of CALPHAD problems for `SLOTH` is made with a C++ object of type `Ca
 `Calphad_Problem` is a template class instantiated with three template parameters: first, a CALPHAD object, second, the `Variables` object, and third, the `Postprocessing` object.
 
 !!! example "Alias declaration for `Calphad_Problem` class template"
-    ```c++
-    using CalphadProblem = Calphad_Problem<CALPHAD, VARS, PST>;
-    ```
-
+    The alias `PB_CALPHAD<CALPHAD>` is provided by `SLOTH` namespaces (see the [Aliases page](../../../Aliases/index.md)). 
+    In this alias, `CALPHAD` refers to a Calphad-type model. 
 
 `Calphad_Problem` objects are defined by
 
@@ -123,7 +121,7 @@ where $`R`$ is the  molar gas constant, $`T`$ the temperature and $`x`$ the mola
     In this example, a fictitious `Calphad_Problem` based on `AnalyticalIdealSolution<mfem::Vector>` is defined with `Parameters` (see `calphad_parameters`), outputs (primary `Variables`) and inputs (auxiliary `Variables`, here T, P, composition)
 
     ```c++
-    Calphad_Problem<AnalyticalIdealSolution<mfem::Vector>, VARS, PST>  my_calphad_problem = CalphadProblem(calphad_parameters, outputs, calphad_pst, T, P, composition);
+    PB_CALPHAD<AnalyticalIdealSolution<mfem::Vector>>  my_calphad_problem = CalphadProblem(calphad_parameters, outputs, calphad_pst, T, P, composition);
 
     ```
 
@@ -216,6 +214,6 @@ The parameters associated with `CalphadInformedNeuralNetwork<mfem::Vector>` are
                                         own_mobility_model, input_composition_order, 
                                         element_removed_from_nn_inputs) 
 
-    Calphad_Problem<CalphadInformedNeuralNetwork<mfem::Vector>, VARS, PST>  my_calphad_problem = CalphadProblem(calphad_parameters, outputs, calphad_pst, T, P, composition);
+    PB_CALPHAD<CalphadInformedNeuralNetwork<mfem::Vector>>  my_calphad_problem = CalphadProblem(calphad_parameters, outputs, calphad_pst, T, P, composition);
 
     ```