iterorganization · hetsko · Sep 16, 2026 · Sep 16, 2026 · Sep 16, 2026 · Sep 16, 2026
diff --git a/docs/Contribute.md b/docs/Contribute.md
@@ -41,7 +41,7 @@ Our tutorials are written in [Markdown](https://www.markdownguide.org/cheat-shee
 - **Respect the existing documentation structure.** Before you write a tutorial, figure out if an equivalent is already present, and amend that if necessary.
     - *My first SOLPS-ITER simulation*: A beginner's first contact with SOLPS-ITER, step-by-step instructions toward creating one's first SOLPS-ITER simulation with the narrow grids version. Keep it simple. Document frequently encountered problems, but don't explain anything in depth. If needed, describe the issue at length elsewhere (e.g. in [Common pitfalls](supplementary/Common_pitfalls.md)) and link to it.
     - *Feature blog*: Largely independent ways to make a SOLPS simulation more complicated. Explain why one would want to adopt a particular feature, what are the benefits and costs, and how to do it. You can go into detail, but don't paraphrase or copy-paste existing documentation. Link to it instead.
-    - *Supplementary material*: Everything that didn't fit in the first two categories. 
+    - *Supplementary material*: Everything that didn't fit in the first two categories.
 
 - **Do not duplicate.** If something is explained elsewhere (SOLPS manual, ITER SharePoint...) and you find yourself paraphrasing it or, God forbid, copy-pasting it, link to it instead.
 
@@ -69,7 +69,7 @@ First, clean your local copy of SOLPS Tutorials.
     cd SOLPS-Tutorials
     git fetch
     git status
-    
+
 If you see you're up-to-date with `master`, you're good to go. If you are on `master` but you're missing the last updates, download them to your local copy.
 
     git pull
@@ -80,16 +80,16 @@ Usually I find myself a different, long-forgotten branch, from the last time I w
     git clone git@github.com:iterorganization/SOLPS-Tutorials.git
 
 Then proceed according to the instructions below. At the point where you're supposed to start writing your contributions, copy over the files from your old folder `SOLPS-Tutorials_definitely_not`. More on that below.
-    
+
 Once you are on the latest update of the `master` branch, your work table is clean. You can start on your latest contribution.
-    
+
 1. Visit the [list of `SOLPS-Tutorials` branches](https://github.com/iterorganization/SOLPS-Tutorials/branches)<span class="material-symbols-outlined">open_in_new</span> on its GitHub page. On the upper right, click `New branch`. Select `master` as the source. Name the branch using the [common conventions](https://medium.com/@abhay.pixolo/naming-conventions-for-git-branches-a-cheatsheet-8549feca2534)<span class="material-symbols-outlined">open_in_new</span>, using branch prefixes such as `feature/`, `fix/` or `refactor/`.
 
 2. Switch to the new branch on your local machine.
 
         git fetch  # this downloads the information that there is a new remote branch
         git checkout -b feature/my_new_branch origin/feature/my_new_branch
-    
+
     The `-b` will create your own local branch which tracks the remote branch. It prevents the detached HEAD state.
 
 3. If you have any accumulated past changes, integrate them. Simply copy all the contents of `SOLPS-Tutorials_definitely_not` and paste them into your new shiny `SOLPS-Tutorials`. **Immediately** after that, resolve conflicts/deletions. The `Source Control` tab in our editor of choice, [Visual Studio Code](#recommended-editors), works well. Compare your old files with the newest `master`, get familiar with what has been done while you were sleeping and modify your past contributions accordingly. Use the `Revert` button/option to undo your "deletions". You don't want to overwrite any work others have done in the meantime. I know you're impatient to get started on the actual work, but if you postpone dealing with the conflicts, they will become a headache. You'll invest effort into rewriting documentation that's out-of-date. At the end of it, when you're making your commits and merging into `master`, you will have to deal with the conflicts anyway. And it will be harder, because you've *just* polished your contribution, you want to send it out there already, and now not only you are bogged down by Git conflicts, but you also have to rewrite your contribution to accommodate the work of others.
@@ -110,7 +110,7 @@ Once you are on the latest update of the `master` branch, your work table is cle
 6. Once you have a series of commits, ideally acknowledging all the changes you've made to the tutorials, upload them to the central GitLab repository.
 
         git push
-    
+
     (You can also do this in Visual Studio Code `Source Control` tab.)
 
 7. On the [`SOLPS-Tutorials` GitHub page](https://github.com/iterorganization/SOLPS-Tutorials/pulls)<span class="material-symbols-outlined">open_in_new</span>, create a new pull request which merges your new branch back into `master`. Add Katka as a reviewer so she can check the changes and give you a deserved pat on the back. Expect a response within 3 days.
@@ -119,7 +119,7 @@ Once you are on the latest update of the `master` branch, your work table is cle
 
         git checkout master
         git pull
-    
+
     Thank you for contributing to SOLPS Tutorials!
 
 
@@ -350,13 +350,11 @@ Katka's PhD thesis
 ```
 
 
-## Render SOLPS Tutorials locally with MkDocs
-
-Quick edits of SOLPS Tutorials are best done in a [Markdown editor](#recommended-editors), which will render the files in real time. However, most of the fancy [extensions](#markdown-extensions) will not be rendered in that way. There are two options to view the final result before it goes live with a Git pull request into the `master` branch:
+## Preview your changes to SOLPS Tutorials
 
-> **TODO** <span class="material-symbols-outlined">construction</span>: Update the pipeline artifact information.
+Quick edits of SOLPS Tutorials are best done in a [Markdown editor](#recommended-editors), which will render the files in real time. However, most of the fancy [extensions](#markdown-extensions) will not be rendered in that way. There are two options to view the final result before it goes live after merging a pull request into the `master` branch:
 
-- A complete build of pages is generated after each push as a downloadable artifact in the automatic [Pipelines](https://repo.tok.ipp.cas.cz/solps/solps-doc/-/pipelines)<span class="material-symbols-outlined">open_in_new</span> (see download button on the right).
+- A complete webpage preview is generated once you open a [pull request](https://github.com/iterorganization/SOLPS-Tutorials/pulls)<span class="material-symbols-outlined">open_in_new</span> to `master`. Simply wait a couple of minutes for the ReadTheDocs bot to post the link in the pull request's thread.
 
 - Build the pages locally:
 

diff --git a/docs/feature_blog/Drifts.md b/docs/feature_blog/Drifts.md
@@ -117,7 +117,7 @@ It's hard to say what are sensible values (1.5, 1.1, 1.0001) for any of the ramp
 
 ## Modify boundary conditions in `b2.boundary.parameters`
 
-This is the most complicated step, but at the same time, it might not be important to make the simulation stable (Honza's conjecture). It is, at any rate, important for the simulation to be physically correct. Most of the information here is based on the documentation of the boundary conditions and on the official example `ITER_2588_Donly_standalone_drifts` from the `solps-iter/examples` directory. Refer to that example for more details. See the [B2.5 switches](/solps-doc/extras/b2input) for a documentation on the boundary conditions. The main idea is:
+This is the most complicated step, but at the same time, it might not be important to make the simulation stable (Honza's conjecture). It is, at any rate, important for the simulation to be physically correct. Most of the information here is based on the documentation of the boundary conditions and on the official example `ITER_2588_Donly_standalone_drifts` from the `solps-iter/examples` directory. Refer to that example for more details. See the [B2.5 switches](/extras/b2input) for a documentation on the boundary conditions. The main idea is:
 
 - There are special versions of the sheath boundary conditions that are modified to properly account for drifts.
 - It is advisable to use leakage conditions instead of decay lengths for the radial boundaries. But I'm not sure if that is important for drifts or just a good idea in general.

diff --git a/docs/feature_blog/Gas_puffing_and_pumping.md b/docs/feature_blog/Gas_puffing_and_pumping.md
@@ -150,7 +150,7 @@ Deuterium is just the most common main ion species in SOLPS-ITER simulations.
 If one has [implemented a pump](#gas-pumping), the lost particles must be compensated for. Under default boundary conditions, where the plasma density is controlled by the D<sup>1+</sup> density at the core boundary $n_{i,core}$ (`BCCON = 1`), this refuelling is done mainly through the particle flux from the core. The flux is automatically adjusted to such a value that matches the density required in `CONPAR`. To get a proper particle balance, however, one needs to control the plasma density is through the *gas puff throughput* $\Gamma_{\text{puff}}$.
 
 /// tip | When gas puff is off in experiment
-In short, low-density tokamak discharges, experimental density feedback system can find that it does not need to puff gas into the plasma to maintain the desired plasma density. Recycling is sustained by the pre-filled particles and pumping only removes them slowly (due to low neutral pressure). In the corresponding interpretative SOLPS-ITER simulation, gas puff throughput should still be non-zero. Even though your experimental plasma was not entirely steady-state, your simulation is. If you turn the gas puff off and introduce no additional fuelling, the particle content in your simulation will go down over time and you won't achieve convergence. 
+In short, low-density tokamak discharges, experimental density feedback system can find that it does not need to puff gas into the plasma to maintain the desired plasma density. Recycling is sustained by the pre-filled particles and pumping only removes them slowly (due to low neutral pressure). In the corresponding interpretative SOLPS-ITER simulation, gas puff throughput should still be non-zero. Even though your experimental plasma was not entirely steady-state, your simulation is. If you turn the gas puff off and introduce no additional fuelling, the particle content in your simulation will go down over time and you won't achieve convergence.
 ///
 
 
@@ -273,7 +273,7 @@ Examples of gas puff feedback schemes among the SOLPS examples include:
 - `ITER_2588_D+He+N`: feedback on the deuterium gas puff intensity to preserve "the total particle content for that species" (not clear whether deuterium ions or neutrals) summed over a given rectangle of B2.5 cells
 - `ITER_2308_Honly_20MW`: feedback on the core boundary hydrogen particle (not clear whether neutrals or ions) flux to preserve the neutral hydrogen particle flux through the core boundary
 
-All available feedback schemes are documented primarily in the description of switches specified in the `b2.feedback_control.parameters` file (refer to the [B2.5 switch database](/solps-doc/extras/b2input)<span class="material-symbols-outlined">open_in_new</span>).
+All available feedback schemes are documented primarily in the description of switches specified in the `b2.feedback_control.parameters` file (refer to the [B2.5 switch database](/extras/b2input)<span class="material-symbols-outlined">open_in_new</span>).
 
 /// warning | The NEW and OLD feedback scheme switches
 Historically, there are two ways how to set up feedback schemes. You might run into a number of switches in `b2mn.dat`, which are documented as "feedback switches", e.g. `b2stbc_isfeedback` - those are the old-style switches and they are redundant in SOLPS-ITER 3.0.8+. The new-style configuration of feedback is done almost entirely in the `b2.feedback_control.parameters` file.
@@ -348,7 +348,7 @@ At low plasma densities, enabling density control using gas puff feedback can le
 
 This section discusses how such oscillations come to be and how to control them.
 
-**Feedback formula example**: Using `NA_FEEDBACK_OPTION = 1` in `b2.feedback_control.parameters` (see the [switch description](/solps-doc/extras/b2input/b2.parameters.html#b2.feedback_control.parameters)) translates into the following formula:
+**Feedback formula example**: Using `NA_FEEDBACK_OPTION = 1` in `b2.feedback_control.parameters` (see the [switch description](/extras/b2input/develop/b2.parameters.html#b2.feedback_control.parameters)) translates into the following formula:
 
 $$\Gamma_{\text{puff,new}} = \Gamma_{\text{puff,old}} \cdot \frac{1 + \alpha \cdot \frac{\text{target } n_{e,sep}}{\text{current } n_{e,sep}}}{1 + \alpha}$$
 
@@ -385,4 +385,4 @@ Lower $\alpha$ increases the oscillations magnitude and decreases the period. At
 
 *Three consequent simulations, gradually decreasing requested separatrix electron density. At 2.2 ms, $\alpha$ was increased from 0.1 to 1.0 to prompt faster convergence.*
 
-I am not sure how (or if) this trick gets around the non-linearity described by Kukushkin and Krasheninnikov. On occasion, relaunching a converged low-density simulation with different parameters renews the oscillations. In the worst case, always start from a high-density case.
+I am not sure how (or if) this trick gets around the non-linearity described by Kukushkin and Krasheninnikov. On occasion, relaunching a converged low-density simulation with different parameters renews the oscillations. In the worst case, always start from a high-density case.
diff --git a/docs/feature_blog/Wide_grids.md b/docs/feature_blog/Wide_grids.md
@@ -438,7 +438,7 @@ After nearly two years of using Wide Grids SOLPS-ITER to model the COMPASS Upgra
     - Limiting maximum allowed velocities (`b2npmo_ion_vlct_restrict` and `b2npmo_ion_vlct_restrict_M` in `b2mn.dat`)
     - Decreasing or turning off viscous heating (`b2sihs_phm0`-`b2sihs_phm8` in `b2mn.dat`)
 
-**Switches in `b2mn.dat` relevant to divergence** (find their meaning in our [B2.5 switch documentation](https://solps.pages.tok.ipp.cas.cz/solps-doc/extras/b2input/)):
+**Switches in `b2mn.dat` relevant to divergence** (find their meaning in our [B2.5 switch documentation](/extras/b2input/)):
 
 - Decrease time step.
 

diff --git a/docs/img/Comparing_experiment_to_model-image3.png b/docs/img/Comparing_experiment_to_model-image3.png
diff --git a/docs/img/Hall_of_fame.jpg b/docs/img/Hall_of_fame.jpg
diff --git a/docs/img/Processing_SOLPS-ITER_output-image1.png b/docs/img/Processing_SOLPS-ITER_output-image1.png
diff --git a/docs/img/Questions_and_answers-image1.png b/docs/img/Questions_and_answers-image1.png
diff --git a/docs/img/b2time_nesep.png b/docs/img/b2time_nesep.png
diff --git a/docs/img/compass_17588_baseline.png b/docs/img/compass_17588_baseline.png
diff --git a/docs/img/danger.png b/docs/img/danger.png
diff --git a/docs/img/downloadable_file.png b/docs/img/downloadable_file.png
diff --git a/docs/img/eq1.png b/docs/img/eq1.png
diff --git a/docs/img/equation.png b/docs/img/equation.png
diff --git a/docs/img/external_link.png b/docs/img/external_link.png
diff --git a/docs/img/fancy_block.png b/docs/img/fancy_block.png
diff --git a/docs/img/file_contents.png b/docs/img/file_contents.png
diff --git a/docs/img/hint.png b/docs/img/hint.png
diff --git a/docs/img/mail.png b/docs/img/mail.png
diff --git a/docs/img/restart_after_crash.png b/docs/img/restart_after_crash.png
diff --git a/docs/img/solps-doc_logo.png b/docs/img/solps-doc_logo.png
diff --git a/docs/img/solps-doc_logo.svg b/docs/img/solps-doc_logo.svg
diff --git a/docs/img/tip.png b/docs/img/tip.png
diff --git a/docs/img/under_construction.png b/docs/img/under_construction.png
diff --git a/docs/img/warning.png b/docs/img/warning.png