diff --git a/_plugins/googlescholar.rb.bak b/_plugins/googlescholar.rb.bak
new file mode 100644
index 0000000000..3c05a3a28c
--- /dev/null
+++ b/_plugins/googlescholar.rb.bak
@@ -0,0 +1,31 @@
+# Attribution: Jonathan Chang
+# https://jonathanchang.org/blog/easily-showcase-your-google-scholar-metrics-in-jekyll
+
+require 'open-uri'
+require 'nokogiri'
+
+module Jekyll
+  class ScholarStats < Generator
+    # ID for PreCICE v2 paper
+    CITATION_ID = '17974677460269868025'.freeze
+    SCHOLAR_URL = 'http://scholar.google.com/scholar?hl=en&cites='.freeze
+    def generate(site)
+      begin
+        doc = Nokogiri::HTML(URI.parse(SCHOLAR_URL + CITATION_ID).open)
+        # Search for string saying 'About 123 results (0,03 sec)'
+        # Split and take second value '123'
+        citations = doc.css('#gs_ab_md .gs_ab_mdw').text.split[1]
+        data = { 'id' => CITATION_ID,
+                 'citations' => citations }
+      rescue OpenURI::HTTPError, SocketError => e
+        Jekyll.logger.warn "Fetching citation data failed with: #{e.message}"
+        data = {}
+      end
+      site.data['scholar'] = data
+    end
+  end
+end
+
+# Usage in jekyll
+# {{ site.data.scholar.id }}
+# {{ site.data.scholar.citations }}
diff --git a/content/docs/configuration/basics/configuration-mapping.md b/content/docs/configuration/basics/configuration-mapping.md
index e8c1ba9d91..033acc2e62 100644
--- a/content/docs/configuration/basics/configuration-mapping.md
+++ b/content/docs/configuration/basics/configuration-mapping.md
@@ -228,6 +228,20 @@ Configuration:
   * `"collect"`: aggregates data from multiple interface vertices of the higher-dimensional participant to the lower-dimensional interface.
 * `multiscale-axis`: the common axis of the two domains, i.e., the principal axis of the coupled participants.
 
+## Volume coupling
+
+While preCICE is frequently used for surface coupling (where solvers exchange data at a 2D boundary), it also fully supports volume coupling. In volume coupling, the domains of the coupled solvers overlap in 3D space, and data is exchanged across this overlapping volume. 
+
+Several preCICE adapters currently support volume coupling natively, including the **OpenFOAM adapter** (for `Pressure`, `Velocity`, and `Temperature` over internal fields or `cellSets`) and the **DuMuX adapter**. You can explore practical examples of this in the [Volume-coupled diffusion](tutorials-volume-coupled-diffusion.html), [Volume-coupled flow](tutorials-volume-coupled-flow.html), and [Two-scale heat conduction](tutorials-two-scale-heat-conduction.html) tutorials.
+
+When configuring data mapping for volume coupling, keep in mind that mapping across a 3D volume involves significantly more data points than a 2D surface, making it computationally more expensive. 
+
+**Recommended Mapping Methods for Volumes:**
+* **`nearest-neighbor`**: This is usually the best starting point for volume coupling. It is extremely fast, robust, and requires very little memory, making it highly suitable for massive 3D meshes.
+* **`linear-cell-interpolation`**: If you have volumetric connectivity information defined (e.g., tetrahedra in 3D or triangles in 2D), this projection-based method provides a great balance between speed and accuracy for 3D spaces.
+* **`mapping:rbf` (Specifically `rbf-pum-direct`)**: If your physics require higher accuracy than a nearest-neighbor approach, the Partition of Unity Method (PUM) is the recommended kernel method. It breaks the massive 3D problem into smaller, localized clusters, keeping the computational cost and memory footprint manageable.
+
+*Note: It is highly recommended to avoid global RBF methods (`rbf-global-direct` or `rbf-global-iterative`) for large volume coupling setups. Assembling and solving a global system for a dense 3D volume mesh will likely exceed your available memory and compute time.*
 ## Restrictions for parallel participants
 
 As stated above, for parallel participants only `read`-`consistent` and `write`-`conservative` are valid combinations. If want to find out why, have a look at [Benjamin's thesis](https://mediatum.ub.tum.de/doc/1320661/document.pdf), page 85. But what to do if you want a `write`-`consistent` mapping? The trick is to move the mapping to the other participant, then `write` becomes `read`: