To build the documentation locally, install sphinx and other dependencies by running
+
To build the documentation locally, in the doc folder, install sphinx and other dependencies by running
pipinstall-rrequirements.txt
diff --git a/chore/developer_guide/_images/PBM_Part_I.png b/chore/developer_guide/_images/PBM_Part_I.png
new file mode 100644
index 000000000..7870c34ce
Binary files /dev/null and b/chore/developer_guide/_images/PBM_Part_I.png differ
diff --git a/chore/developer_guide/_images/architecture_libcadet_classes.png b/chore/developer_guide/_images/architecture_libcadet_classes.png
index d03f219ce..e2e79ae28 100644
Binary files a/chore/developer_guide/_images/architecture_libcadet_classes.png and b/chore/developer_guide/_images/architecture_libcadet_classes.png differ
diff --git a/chore/developer_guide/_sources/README.md.txt b/chore/developer_guide/_sources/README.md.txt
index bc3717077..8a82e81ab 100644
--- a/chore/developer_guide/_sources/README.md.txt
+++ b/chore/developer_guide/_sources/README.md.txt
@@ -1,7 +1,7 @@
## CADET Documentation
-To build the documentation locally, install sphinx and other dependencies by running
+To build the documentation locally, in the `doc` folder, install sphinx and other dependencies by running
```
pip install -r requirements.txt
diff --git a/chore/developer_guide/_sources/developer_guide/build_options.rst.txt b/chore/developer_guide/_sources/developer_guide/build_options.rst.txt
index 4706161ac..efc70dd00 100644
--- a/chore/developer_guide/_sources/developer_guide/build_options.rst.txt
+++ b/chore/developer_guide/_sources/developer_guide/build_options.rst.txt
@@ -46,8 +46,13 @@ The following build arguments can be set in the cmakeSettings.json or from the c
- ``DENABLE_PACKAGED_SUNDIALS``: Uses packaged SUNDIALS code.
- ``DENABLE_IPO``: Enables interprocedural optimization if the compiler supports it.
- ``DCMAKE_INSTALL_RPATH_USE_LINK_PATH``: Adds paths to linker search and installed rpath.
+- ``DNUM_MAX_AD_DIRS``: Specifies the number of allowed AD directions (default value is 80). Increasing this value can decrease performance when AD is being used.
The following build arguments are exclusive to builds on MS windows:
- ``DVCPKG_TARGET_TRIPLET``: We use ``vcpkg`` to manage our dependencies. This triplet specifies which version of the dependencies should be installed. It takes the form of ``architecture-os-linking``, so ``x64-windows-static`` for our use cases.
+The following build arguments can only be used with the Clang or GCC compilers:
+
+- ``DENABLE_ASAN``: enables the address sanitizer.
+- ``DENABLE_UBSAN``: enables the undefined behaviour sanitizer.
diff --git a/chore/developer_guide/_sources/developer_guide/debugging.rst.txt b/chore/developer_guide/_sources/developer_guide/debugging.rst.txt
index be41856a8..c8cddb071 100644
--- a/chore/developer_guide/_sources/developer_guide/debugging.rst.txt
+++ b/chore/developer_guide/_sources/developer_guide/debugging.rst.txt
@@ -11,3 +11,5 @@ To run a specific simulation with the Visual Studio debugguer, you can add the l
.. literalinclude:: launch.vs.json
:language: json
+
+To debug memory related issues, you can compile the code with the address sanitizer ASAN and the undefined behaviour sanitizer UBSAN by enabling the cmake arguments `DENABLE_ASAN` and `DENABLE_UBSAN`.
\ No newline at end of file
diff --git a/chore/developer_guide/_sources/developer_guide/index.rst.txt b/chore/developer_guide/_sources/developer_guide/index.rst.txt
index 8afb1ff93..57f98abba 100644
--- a/chore/developer_guide/_sources/developer_guide/index.rst.txt
+++ b/chore/developer_guide/_sources/developer_guide/index.rst.txt
@@ -6,7 +6,7 @@ Developer Guide
This developer guide is intended to help expand and maintain CADET-Core and is written to serve developers with diverse backgrounds.
If you find any gaps or have suggestions for improvement, your input is valuable in refining our documentation for better comprehension by all developers.
-Please feel free to open an `issue on GitHub `_ or, even better, write a draft and create a pull request.
+Please feel free to open an `issue on GitHub `_ or, even better, write a draft and create a pull request.
When planning to extend or contribute to CADET-Core, please adhere to our notation style and research software engineering (RSE) best practices.
For detailed guidance, you can e.g. refer to the `RSE guidelines `_.
@@ -22,3 +22,4 @@ Since some developers may be new to collaborative software development using Git
model_expansion
debugging
testing
+ release_new_version
diff --git a/chore/developer_guide/_sources/developer_guide/release_new_version.rst.txt b/chore/developer_guide/_sources/developer_guide/release_new_version.rst.txt
new file mode 100644
index 000000000..051373f8d
--- /dev/null
+++ b/chore/developer_guide/_sources/developer_guide/release_new_version.rst.txt
@@ -0,0 +1,54 @@
+.. _release_new_version:
+
+CADET-Core version release
+==========================
+
+CADET-Core releases follow the semantic versioning system, which is documented `here `_.
+
+Release checklist
+-----------------
+
+- Run the release tests:
+
+ - The release tests contain extensive testing that is not included in our CI, such as EOC tests.
+ Running these tests might take a while and this should be done on the server.
+ - Some tests are implemented in CADET-Core, and can be run with the [ReleaseCI] flag.
+ - More tests are implemented in Python, the code can be found in `CADET-Verification `_
+ Compare the results with the previous run.
+ The release process can only be continued if the results are reasonable.
+
+- Run performance benchmarks:
+
+ - If numerical algorithms were refactored or if performance-critical infrastructure was changed, you should run performance benchmarks to compare the latest release with the planned new one.
+ To this end, you can refer to the performance benchmark templates in CADET-Reference, e.g. the `benchmark for the modified Newton method `_
+
+- Create a version bump commit, which will be the target commit for the release.
+ The bump commit contains:
+
+ - Update of the version number in the `version.txt` and in the zenodo.json
+ - Update of the authors list if needed: CONTRIBUTING.md and zenodo.json
+ - Update of the copyright (years)
+ - Update of the file format if needed
+
+- Create the release on github `here `_.
+
+ - Add the version number according to the semantic versioning system as the tag and set the master branch as target.
+ - Add release notes with these categories:
+
+ - Added: New features, enhancements, or functionalities introduced in this release.
+ - Fixed: Bug fixes and corrections made to resolve issues from previous versions.
+ - Changed: Modifications to existing features and breaking changes for major releases including changes in the interface.
+ - Updated: Improvements to documentation, minor tweaks, or other updates that don’t fit into the other categories.
+
+ - Attach the (zipped) source code.
+
+- Check success of zenodo archiving:
+
+ - Upon release, Zenodo automatically archives the release, generating a version-specific DOI (Digital Object Identifier) for it and storing a copy of the source code, along with any associated files.
+ The `concept DOI `_, which is also given in the repository README, does not change but represents the repository as a whole and always points to the latest version.
+
+Release of binaries on conda-forge
+----------------------------------
+
+To ensure CADET-Core is accessible to a broad community, it is available as a Python package on conda-forge.
+Other software, such as our Python interface, `CADET-Python`, and the frontend, `CADET-Process`, import this package.
diff --git a/chore/developer_guide/_sources/developer_guide/testing.rst.txt b/chore/developer_guide/_sources/developer_guide/testing.rst.txt
index 890a7b85d..b0473a686 100644
--- a/chore/developer_guide/_sources/developer_guide/testing.rst.txt
+++ b/chore/developer_guide/_sources/developer_guide/testing.rst.txt
@@ -53,7 +53,8 @@ Unit tests
Unit tests are designed to verify the correctness of individual units or components of code in isolation.
Unit tests in CADET-Core typically encompass tests for the Jacobian implementation and consistent initialization of the model, which can be adapted from corresponding existing tests.
-We generally recommend testing every of your model individually.
+Testing the Jacobian typically involves comparing the analytical Jacobian to the AD Jacobian to verify that the residual implementation is consistent to the analytical Jacobian.
+To this end, it might be necessary to increase the maximum number of AD directions for your test case, which can be done via the cmake argument `NUM_MAX_AD_DIRS`, as described in the :ref:`build_options`.
Numerical reference tests
^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -62,7 +63,7 @@ Every major feature of the model or numerical method should be tested in a separ
This section provides a guide on creating reference tests, including convergence tables and research data management (RDM).
We strongly emphasize that the procedure described here should be taken into consideration not just as part of the software testing but also for method/model validation, especially when a paper publication is planned.
-We utilize `CADET-Database `_ and `CADET-Reference `_ to ensure reproducibility of the tests.
+We utilize `CADET-Database `_ and `CADET-Verification `_ to ensure reproducibility of the tests.
We recommend using this procedure not only for the tests but also for the publication to make good standards regarding RDM.
@@ -74,15 +75,15 @@ You can create this json config file by translating the standard CADET h5 file t
Make sure to give your model setup a meaningful and unique name (follow the naming logic of other setups in that folder).
Note that the return data should only specify the output required for the reference test, i.e. usually the outlet of a single unit.
-**2. Add a CADET-Reference script:**
+**2. Add a CADET-Verification script:**
This python script reads the model setup from CADET-Database and generates all the reference data that will be used in your tests.
This includes a specific low resolution reference solution as well as convergence (EOC) tables computed using a high precision solution.
If analytical solutions are available for the considered model, you should use that as the high precision solution.
Otherwise, you additionally need to generate a very high resolution numerical reference solution, preferably with an accuracy of at least :math:`\mathcal{L}_\text{inf} \approx 1e-8`.
**3. Add numerical reference tests to CADET-Core:**
-These tests should read the model setups previously defined in CADET-Database and run them with the same numerical specification as used to compute the reference solutions computed by the CADET-Reference script.
-The resulta are compared to the reference solution generated by CADET-Reference.
+These tests should read the model setups previously defined in CADET-Database and run them with the same numerical specification as used to compute the reference solutions computed by the CADET-Verification script.
+The resulta are compared to the reference solution generated by CADET-Verification.
This type of tests ensures that the model is still functional and that the numerics for this model have not changed.
Hence, every major feature of the model should be tested in a separete tests.
This way, we make sure that ongoing CADET-Core development doesnt break the model and these tests should be included in the CI pipeline by adding the [CI] flag as described in the implementation procedure section.
@@ -91,7 +92,7 @@ This way, we make sure that ongoing CADET-Core development doesnt break the mode
These tests should be part of the paper publication which introduces the new model implemented in CADET-Core and can also be included in the CADET-Core tests.
Verifying the experimental order of convergence (EOC) is widely considered the most rigorous and best scientific practice in model and method validation, which is why we recommend including the EOC tables in your publication.
The convergence tests should not be added to the standard CI but only be rerun on release, i.e. by adding the [releaseCI] flag.
-Details on how to compute EOC tables can be found elsewhere, please also refer to the already implemented EOC tests in CADET-Reference.
+Details on how to compute EOC tables can be found elsewhere, please also refer to the already implemented EOC tests in CADET-Verification.
Manufactured solution
^^^^^^^^^^^^^^^^^^^^^
diff --git a/chore/developer_guide/_sources/index.rst.txt b/chore/developer_guide/_sources/index.rst.txt
index fb1b7907d..d54b536ac 100644
--- a/chore/developer_guide/_sources/index.rst.txt
+++ b/chore/developer_guide/_sources/index.rst.txt
@@ -4,11 +4,11 @@
|
-.. image:: https://img.shields.io/github/release/modsim/cadet.svg
- :target: https://github.com/modsim/CADET/releases
+.. image:: https://img.shields.io/github/release/cadet/cadet-core.svg
+ :target: https://github.com/cadet/cadet-core/releases
-.. image:: https://github.com/modsim/CADET/actions/workflows/ci.yml/badge.svg?branch=master
- :target: https://github.com/modsim/CADET/actions/workflows/ci.yml?query=branch%3Amaster
+.. image:: https://github.com/cadet/cadet-core/actions/workflows/ci.yml/badge.svg?branch=master
+ :target: https://github.com/cadet/cadet-core/actions/workflows/ci.yml?query=branch%3Amaster
.. image:: https://anaconda.org/conda-forge/cadet/badges/downloads.svg
:target: https://anaconda.org/conda-forge/cadet
@@ -16,6 +16,8 @@
.. image:: https://zenodo.org/badge/DOI/10.5281/zenodo.8179015.svg
:target: https://doi.org/10.5281/zenodo.8179015
+.. image:: https://img.shields.io/badge/JuRSE_Code_Pick-Oct_2024-blue.svg
+ :target: https://www.fz-juelich.de/en/rse/community-initiatives/jurse-code-of-the-month/october-2024
|
CADET
@@ -27,7 +29,7 @@ CADET can handle arbitrary sequences and networks of unit operations, including
The resulting models are solved with state-of-the-art mathematical algorithms and scientific computing techniques.
- **Forum:** https://forum.cadet-web.de
-- **Source:** https://github.com/modsim/cadet
+- **Source:** https://github.com/cadet/cadet-core
- **Demo:** http://cadet-web.de
- **Newsletter:** https://cadet-web.de/newsletter/
@@ -68,7 +70,7 @@ For non-developers, it is recommended to upgrade from release to release instead
Bugs
----
-Please report any bugs that you find `here `_. Or, even better, fork the repository on `GitHub `_ and create a pull request (PR) with the fix.
+Please report any bugs that you find `here `_. Or, even better, fork the repository on `GitHub `_ and create a pull request (PR) with the fix.
Donations
---------
@@ -79,17 +81,33 @@ Donations
Citing
------
-To cite CADET please use the following publication:
+The development of CADET has been a collaborative effort, with multiple dedicated individuals contributing their expertise to create a powerful and versatile open-source software tool.
+Countless hours of hard work have been invested to provide the scientific community with a valuable resource.
+As an open-source project, CADET relies on the support and recognition from users and researchers to thrive.
+Therefore, we kindly ask that any publications or projects leveraging the capabilities of CADET acknowledge its creators and their contributions by citing an adequate selection of our publications.
-* Leweke, S.; von Lieres, E.: `Chromatography Analysis and Design Toolkit (CADET) `_, Computers and Chemical Engineering 113 (2018), 274–294.
-* Püttmann, A.; Schnittert, S.; Leweke, S.; von Lieres, E.: `Utilizing algorithmic differentiation to efficiently compute chromatograms and parameter sensitivities `_, Chemical Engineering Science, 139 (2016), 152–162.
-* Püttmann, A.; Schnittert, S.; Naumann, U.; von Lieres, E.: `Fast and accurate parameter sensitivities for the general rate model of column liquid chromatography `_, Computers and Chemical Engineering 56,13 (2013), 46-57.
-* von Lieres, E.; Andersson, J.: `A fast and accurate solver for the general rate model of column liquid chromatography `_, Computers and Chemical Engineering 34,8 (2010), 1180–1191.
+**General:**
+
+- Leweke, S.; von Lieres, E.: `Chromatography Analysis and Design Toolkit (CADET) `_, Computers and Chemical Engineering **113** (2018), 274–294.
+
+- von Lieres, E.; Andersson, J.: `A fast and accurate solver for the general rate model of column liquid chromatography `_, Computers and Chemical Engineering **34,8** (2010), 1180–1191.
+
+**Numerics:**
+
+- Breuer, J. M.; Leweke, S.; Schmölder, J.; Gassner, G.; von Lieres, E.: `Spatial discontinuous Galerkin spectral element method for a family of chromatography models in CADET `_, Computers and Chemical Engineering **177** (2023), 108340.
+
+- Leweke, S.; von Lieres, E.: `Fast arbitrary order moments and arbitrary precision solution of the general rate model of column liquid chromatography with linear isotherm `_, Computers and Chemical Engineering **84** (2016), 350–362.
+
+- Püttmann, A.; Schnittert, S.; Naumann, U.; von Lieres, E.: `Fast and accurate parameter sensitivities for the general rate model of column liquid chromatography `_, Computers and Chemical Engineering **56** (2013), 46–57.
+
+Additionally, to ensure reproducibility of your work, we recommend citing the `zenodo doi `_ corresponding to the specific CADET release that you used.
+
+Selected applications that demonstrate the capabilities and use-cases of CADET are highlighted `here `_.
Acknowledgments
---------------
-Please refer to the `list of contributors `_ who helped building and funding this project.
+Please refer to the `list of contributors `_ who helped building and funding this project.
.. toctree::
@@ -105,6 +123,6 @@ Please refer to the `list of contributors
license
zbibliography
- Legal notice
+ Legal notice
diff --git a/chore/developer_guide/_sources/interface/binding/freundlich_ldf.rst.txt b/chore/developer_guide/_sources/interface/binding/freundlich_ldf.rst.txt
index f145624ca..9e84bbae5 100644
--- a/chore/developer_guide/_sources/interface/binding/freundlich_ldf.rst.txt
+++ b/chore/developer_guide/_sources/interface/binding/freundlich_ldf.rst.txt
@@ -32,7 +32,7 @@ For information on model equations, refer to :ref:`freundlich_ldf_model`.
``FLDF_KF``
Freundlich coefficient for each component
-**Unit:** :math:`m_{MP}^3~mol^{-1}`
+**Unit:** :math:`m_{MP}^{3/n}~m_{SP}^{-3}~mol^{1-1/n}`
=================== ========================= ==================================
**Type:** double **Range:** :math:`\ge 0` **Length:** 1/NTOTALBND
@@ -41,7 +41,7 @@ For information on model equations, refer to :ref:`freundlich_ldf_model`.
``FLDF_N``
Freundlich exponent for each component
-**Unit:** :[-]
+**Unit:** [-]
=================== ========================= ==================================
**Type:** double **Range:** :math:`> 0` **Length:** 1/NTOTALBND
diff --git a/chore/developer_guide/_sources/interface/flux_reconstruction.rst.txt b/chore/developer_guide/_sources/interface/flux_reconstruction.rst.txt
index 5e56477eb..d9dddd68d 100644
--- a/chore/developer_guide/_sources/interface/flux_reconstruction.rst.txt
+++ b/chore/developer_guide/_sources/interface/flux_reconstruction.rst.txt
@@ -1,9 +1,9 @@
-.. _flux_restruction_methods:
+.. _flux_reconstruction_methods:
Flux reconstruction methods
===========================
-Group /input/model/unit_XXX/discretization/weno - WENO Parameters
+Group /input/model/unit_XXX/discretization/reconstruction = WENO
-----------------------------------------------------------------
``BOUNDARY_MODEL``
@@ -37,3 +37,17 @@ Group /input/model/unit_XXX/discretization/weno - WENO Parameters
**Type:** int **Range:** :math:`\{1, 2, 3\}` **Length:** 1
============= ============================== =============
+
+Group /input/model/unit_XXX/discretization/reconstruction = KOREN
+-----------------------------------------------------------------
+
+The Koren scheme implemented in CADET intrinsically uses a van Leer flux limiter. It can reach a maximum order of 2 depending on the smoothness of the solution. The
+BOUNDARY_MODEL is intrinsically set to 0 (stable).
+
+``KOREN_EPS``
+
+ Set :math:`\varepsilon` in the van Leer flux limiter
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\qe 0\` **Length:** 1
+ ================ ========================= =============
\ No newline at end of file
diff --git a/chore/developer_guide/_sources/interface/input_group.rst.txt b/chore/developer_guide/_sources/interface/input_group.rst.txt
index 9859c0a0d..e23e52457 100644
--- a/chore/developer_guide/_sources/interface/input_group.rst.txt
+++ b/chore/developer_guide/_sources/interface/input_group.rst.txt
@@ -9,13 +9,13 @@ Input Group
system
unit_operations/index
binding/index
+ population_balance_model
reaction/index
- spatial_discretization_methods
flux_reconstruction
consistent_initialization
return_data
sensitivities
solver
parameter_dependencies
-
+ spatial_discretization_methods
diff --git a/chore/developer_guide/_sources/interface/parameter_dependencies.rst.txt b/chore/developer_guide/_sources/interface/parameter_dependencies.rst.txt
index c632de17a..862801ff4 100644
--- a/chore/developer_guide/_sources/interface/parameter_dependencies.rst.txt
+++ b/chore/developer_guide/_sources/interface/parameter_dependencies.rst.txt
@@ -73,7 +73,108 @@ Here, :math:`p_{dep}` is the dependent parameter and :math:`p_{on}` is the param
Parameter-State Dependencies
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Currently, the dependence of surface diffusion on the particle liquid salt component is the only available parameter-state dependence.
+
Group /input/model/unit_XXX
---------------------------
-Parameter-State Dependencies are not fully implemented yet.
+``PAR_SURFDIFFUSION_DEP``
+
+ Parameter dependence of :math:`\texttt{PAR_SURFDIFFUSION}` on the particle liquid salt component (i.e. component with index 0). Valid dependencies are:
+
+ - :math:`\texttt{NONE}` Original parameter is used unmodified.
+ - :math:`\texttt{LIQUID_SALT_EXPONENTIAL}` Original parameter is modified by exponential law of liquid phase salt concentration.
+ - :math:`\texttt{LIQUID_SALT_POWER}` Original parameter is modified by power law of liquid phase salt concentration.
+ - :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}` Original parameter is modified by colloidal binding affinity based on liquid phase salt concentration.
+
+ Optional: If left out, no parameter dependence is assumed and the original surface diffusion coefficients are used unmodified.
+
+ ================ =========================================
+ **Type:** string **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ =========================================
+
+``PAR_SURFDIFFUSION_EXPFACTOR``
+
+ Factor :math:`\texttt{p1}` in exponential law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} exp \left(p_{2, i, m} c_{0}^{p} \right)`, where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient.
+ Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_EXPONENTIAL}`.
+
+ ================ ========================= ===================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NBOUND}`
+ ================ ========================= ===================================
+
+ ``PAR_SURFDIFFUSION_EXPFACTOR``
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
+ :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
+ Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
+ ================ ============================= ===================================
+
+``PAR_SURFDIFFUSION_EXPARGMULT``
+
+ Factor :math:`\texttt{p2}` in exponential law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} exp \left(p_{2, i, m} c_{0}^{p} \right)`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient. Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_EXPONENTIAL}`.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
+ ================ ============================= ===================================
+
+``PAR_SURFDIFFUSION_POWFACTOR``
+
+ Factor :math:`\texttt{p1}` in power law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} \left( c_{0}^{p} \right)^{p_{2, i, m}}`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient. Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_POWER}`.
+
+ ================ ========================= ===================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NBOUND}`
+ ================ ========================= ===================================
+
+``PAR_SURFDIFFUSION_POWEXP``
+
+ Fjactor :math:`\texttt{p2}` in power law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} \left( c_{0}^{p} \right)^{p_{2, i, m}}`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient. Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_POWER}`.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
+ ================ ============================= ===================================
+
+``PAR_SURFDIFFUSION_LOGKEQFACTOR``
+
+ Factor :math:`\texttt{p1}` in colloidal affinity law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
+ :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
+ Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
+ ================ ============================= ===================================
+
+``PAR_SURFDIFFUSION_LOGKEQEXP``
+
+ Factor :math:`\texttt{p2}` in colloidal affinity law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
+ :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
+ Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
+ ================ ============================= ===================================
+
+``PAR_SURFDIFFUSION_LOGKEQCONST``
+
+ Factor :math:`\texttt{p3}` in colloidal affinity law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
+ :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
+ Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
+ ================ ============================= ===================================
diff --git a/chore/developer_guide/_sources/interface/population_balance_model.rst.txt b/chore/developer_guide/_sources/interface/population_balance_model.rst.txt
new file mode 100644
index 000000000..38babada4
--- /dev/null
+++ b/chore/developer_guide/_sources/interface/population_balance_model.rst.txt
@@ -0,0 +1,161 @@
+.. _pbm_config:
+
+Population balance model
+========================
+
+The PBM in CADET is implemented as part of the reaction module and can thus be used in any unit operation that includes reactions.
+Typical applications consider crystallization in a :ref:`cstr_config` or, to model continuous processes, in a Dispersive Plug-Flow Reactor (DPFR), which is modelled by a :ref:`lumped_rate_model_without_pores_config`.
+
+The particle size domain (internal coordinate) is discretized by the FV method, giving us a finite set of particle sizes under consideration :math:`\{x_1, \dots, x_{N_x}\}`.
+Every particle size considered is treated as an individual component of the unit operation and the field ``NCOMP`` of that unit operation in which the crystallization happens, must be specified accordingly as :math:`N_x + 2`.
+The two additional components account for the solute :math:`c` and solubility :math:`c_\text{eq}`.
+*That is, by setting the ``NCOMP`` field, you specify the number of FV cells for the internal coordinate.*
+
+Note that the first component must be solute :math:`c` and the last component must be the solubility :math:`c_\text{eq}`.
+
+Example code to configure the PBM can be found in `CADET-Verification `_ .
+
+Group /input/model/unit_XXX
+---------------------------
+
+``NCOMP``
+
+ Number of components, which is given by two plus the number discrete particle sizes, which is given by the number of FV cells discretizing the internal coordinate
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 3` **Length:** 1
+ ============= ========================= =============
+
+``REACTION_MODEL``
+
+ The crystallization code is implemented as a reaction module, which is why crystallization needs to be specified here
+
+ ================ ======================================== =============
+ **Type:** String **Range:** :math:`\{ CRYSTALLIZATION \}` **Length:** 1
+ ================ ======================================== =============
+
+Group /input/model/unit_XXX/reaction_bulk - REACTION_MODEL = CRYSTALLIZATION - UNIT_TYPE = CSTR
+-----------------------------------------------------------------------------------------------
+
+*The following parameters need to be specified under Group /input/model/unit_XXX/reaction/reaction_bulk/ for CSTR units, and Group /input/model/unit_XXX/reaction/reaction/ for transport units like the LRM.*
+
+``CRY_BINS``
+
+ Coordinates of the cell faces, e.g. equidistant or logarithmic discretization of the internal coordinate :math:`x \in [x_c, x_\text{end}]`, including the end points.
+
+ ================ ========================= =====================================
+ **Type:** double **Range:** :math:`\geq 1` **Length:** :math:`\mathrm{N_x} + 1`
+ ================ ========================= =====================================
+
+``CRY_NUCLEI_MASS_DENSITY``
+
+ Nulcei mass density
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_VOL_SHAPE_FACTOR``
+
+ Volumetric shape factor of the particles
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_PRIMARY_NUCLEATION_RATE``
+
+ Primary nucleation rate constant :math:`k_p`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_SECONDARY_NUCLEATION_RATE``
+
+ Secondary nucleation rate :math:`k_b`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_GROWTH_RATE_CONSTANT``
+
+ Growth rate constant :math:`k_g`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_GROWTH_CONSTANT``
+
+ Growth constant :math:`\gamma`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_A``
+
+ Defines constant :math:`a` used to determine the growth rate
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_G``
+
+ Defines constant :math:`g` used to determine the growth rate
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_P``
+
+ Defines constant :math:`p` used to determine the growth rate
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_GROWTH_DISPERSION_RATE``
+
+ Growth dispersion rate :math:`D_g`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_U``
+
+ Defines constant :math:`u` used to determine the primary nucleation
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_B``
+
+ Defines constant :math:`b` used to determine the secondary nucleation
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_K``
+
+ Defines constant :math:`k` used to determine the secondary nucleation
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_GROWTH_SCHEME_ORDER``
+
+ Defines the growth flux FV reconstruction scheme. It can only be :math:`1`: upwind scheme; :math:`2`: HR Koren scheme; :math:`3`: WENO23 scheme; :math:`4`: WENO35 scheme.
+ We recommend using the HR Koren scheme, which showed to be the most performant in our benchmarks.
+
+ ============= ================================ =============
+ **Type:** int **Range:** :math:`[1, \dots, 4]` **Length:** 1
+ ============= ================================ =============
diff --git a/chore/developer_guide/_sources/interface/spatial_discretization_methods.rst.txt b/chore/developer_guide/_sources/interface/spatial_discretization_methods.rst.txt
index 453b4b2fc..d0b9e8be4 100644
--- a/chore/developer_guide/_sources/interface/spatial_discretization_methods.rst.txt
+++ b/chore/developer_guide/_sources/interface/spatial_discretization_methods.rst.txt
@@ -8,39 +8,38 @@ Group /input/model/unit_XXX/discretization/SPATIAL_METHOD - Details on the metho
CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG).
While both methods approximate the same solution to the underlying models, they may differ in terms of computational performance.
-Generally, FV can be more performant for small problem sizes and solutions with steep gradients, while DG excels for large problem sizes and smooth solutions.
+Generally, FV can perform better for small problem sizes and solutions with steep gradients, while DG excels for large problem sizes and smooth solutions.
-In the following, we give a brief introduction to the numerical theory that is most relevant for the computational performance of the methods.
-Based on that theory and our experience, we give advice on which method to use in which scenario, how to identify the more performant method, and how to specify the discretization parameters.
-For a comprehensive description on the FV and DG methods as they are implemented in CADET, we refer to our publications on `CADET-FV `_ and `CADET-DG `_.
+In the following, we give a brief introduction to the numerical theory w.r.t. the computational performance of the methods.
+Based on that theory and our experience, we give advice on which method to use in which scenario, how to identify the computationally best performing method, and how to specify discretization parameters.
+For a comprehensive description of the FV and DG variants that are implemented in CADET, we refer to our publications on `CADET-FV `_ and `CADET-DG `_.
Discrete system size
--------------------
-Numerical methods discretize the continuous (here: spatial) domain of the equations into a finite set of discrete points.
-Then, a system of equations is formulated for those points, and both system size and number of unknowns / degrees of freedom (DoF) are given by the number of discrete points.
-This system can be linear or non-linear, depending on the method (this will become important again in the section on smooth solutions).
-The wall clock time to compute the solution depends on the system size and, thus, on the number of discrete points.
-Conversely, the numerical solution is more accurate with more discrete points.
-Thus, we trade computation time for approximation accuracy by specifying the parameters that determine the number of discrete points.
-For the FV scheme, the number of axial discrete points in the column is given by the number of volume cells ``NCOL``.
-For the DG scheme, the number of axial discrete points in the column is given by the number of polynomial interpolation nodes (= ``POLYDEG`` + 1) times the number of DG elements ``NELEM``.
-The LRMP and GRM additionally consider particle equations that are also discretized.
-In the spatially discretized equations, a single particle is incorporated at each axial discrete point, which increases the total number of DOF per axial point, especially for the GRM where particles are fully resolved.
-The parameters for the GRM particle discretization are given for FV in ``NPAR`` and for DG in ``PAR_POLYDEG`` and ``PAR_NELEM``.
+FV and DG discretize the continuous spatial domain of the partial differential algebraic equations (PDAE) into a finite set of discrete points.
+Then, a system of (semi-discrete) equations is formulated on those points, resulting in a system of ordinary differential algebraic equations (ODAE).
+The system size and number of unknowns, are also referred to as degrees of freedom (DoF), is given by the number of (spatial) discrete points (times the number of components for multi-component systems).
+
+The numerical solution becomes more accurate with more discrete points used, but the compute time required to solve the equations also increases.
+That is, we trade compute time for approximation accuracy.
+
+For the FV method, the number of axial discrete points in the column is specified by the number of volume cells ``NCOL``.
+For the DG method, the number of axial discrete points in the column is specified by the number of polynomial interpolation nodes (= ``POLYDEG`` + 1) times the number of DG elements ``NELEM``.
+The GRM additionally comprises a transport equation along the radial coordinate of the particles which is also spatially discretized and the particle discrete points are correspondingly given by ``NPAR`` for FV and for DG via ``PAR_POLYDEG`` and ``PAR_NELEM``.
Order of convergence
--------------------
The computational performance of a numerical method depends on its theoretical order of convergence.
-The order of convergence refers to the rate at which the method's approximation approaches the exact solution under refinement of the spatial grid.
+The order of convergence refers to the rate at which the numerical approximation approaches the exact solution under refinement of the spatial grid.
+Consequently, higher order methods often require less spatial discrete points to compute an approximation of the desired accuracy and can thus be computationally more efficient.
-A higher-order method can be faster than a low-order method:
-Imagine a high- and a low-order method's approximation to exhibit similarly bad approximation accuracy due to a coarse spatial resolution.
-Refining the grid for both methods by the same number of discrete points improves the approximation accuracy of the higher-order method more than the other one.
-Thus, the low-order method requires more DOFs and ultimately more compute time to compute a solution of the same accuracy.
+The theoretical order of convergence for the CADET-FV method is globally limited to 2.
+It is locally (except column boundaries) limited to 3, with an improved order of up to 5 for smooth solutions, and can be varied by specifying the parameters described in the :ref:`flux_reconstruction_methods` section.
+For the CADET-DG method, the theoretical order of convergence is :math:`N_d + 1` with :math:`N_d` denoting the polynomial degree, and can thus be user-defined by specifying the field ``POLYDEG`` (and ``PAR_POLYDEG`` for the particles in the GRM).
-The theoretical order of convergence is an asymptotic property, however.
+The theoretical order of convergence is an asymptotic property, i.e. holds for infinite refinements, but can be numerivcally observed for finite refinements as well.
Having the exact solution, we can compute an experimental order of convergence (EOC) via the formula
.. math::
@@ -50,43 +49,42 @@ Having the exact solution, we can compute an experimental order of convergence (
EOC_k = \frac{log(\varepsilon_{k+1} / \varepsilon_{k}) }{log(n_{k} / n_{k+1})},
\end{aligned}
-with :math:`\varepsilon_{k}` and :math:`n_{k}` denoting some error norm and the degrees of freedom of the kth approximation.
+with :math:`\varepsilon_{k}` and :math:`n_{k}` denoting some error norm and the degrees of freedom of the $k$th approximation.
The EOC approaches the theoretical order of convergence for :math:`k \rightarrow \infty` but is typically lower for underresolved problems.
-High-order methods typically suffer from start-off problems, i.e. they typically won't exhibit their high order until the grid is fine enough and a certain accuracy is already reached.
-That is, increasing the number of discrete points from, e.g., 2 to 4 typically does not improve the solution according to the theoretical order of convergence but by a much smaller EOC.
-The EOC is highly problem-dependent, and it is generally unknown when a high-order method will actually be faster than a lower-order method.
-Experience shows that higher-order methods work well for smooth solutions.
+High-order methods typically do typically not exhibit their theoretical order on very coarse grids.
+That is, increasing the number of discrete points from, e.g., 2 to 4 does often not improve the solution according to the theoretical order of convergence but by a much smaller EOC.
+
+For smooth solutions, we typically observe an EOC of around 2.5 for the default CADET-FV method and around :math:`N_d` for the CADET-DG method.
+To our experience, DG with :math:`N_d>6` does usually not realize an EOC of :math:`>6` for approximation errors within engineering tolerances, i.e. higher rates are achieved only for excessively small error tolerances that are not relevant for most applications.
+We thus recommend to choose :math:`3 \leq N_d \leq 5` for the DG method.
-The theoretical order of convergence for the CADET-FV scheme is fixed at 2.
-For the CADET-DG scheme, it is :math:`N_d + 1` with :math:`N_d` denoting the polynomial degree, and can thus be user-defined by specifying the field ``POLYDEG`` (and ``PAR_POLYDEG`` for the GRM).
-As a convergence order of :math:`\gt 6` is hardly realized within the approximation error of engineering tolerance (due to start-off problems), we recommend a maximum polynomial order of 5.
-As the FV scheme oftentimes yields an EOC of around 2.5 and is computationally more enhanced (less arithmetic operations per DOF and customized factorization) than the DG code, we recommend a polynomial degree of at least 3 to top this.
+One could still think that the higher the order of the method, the better the performance, but that is unfortunately not generally true, as the numerical solver performance can strongly depend on the smoothness of the approximated solution.
Smooth solutions
----------------
-Smoothness in functions is characterized by the absence of sudden changes, reflected in the continuity and differentiability of the function and its derivatives.
+The smoothness of a function indicates the absence of sudden changes, reflected in the continuity and differentiability of the function and its derivatives.
In numerical simulation, smoothness indicators are often based on derivatives or moments of the solution.
-That is, strong gradients and high frequencies are used to identify non-smooth parts of the solution.
+That is, the occurrence of strong gradients and high frequencies are used to identify non-smooth parts of the solution.
Godunov's order barrier theorem shows why the concept of smoothness plays a crucial role in the deployment of numerical methods.
It states that linear high-order methods that are monotonous are at most first-order accurate.
Linear higher-order (:math:`\gt 1`) methods thus suffer from artificial oscillations at non-smooth parts of the solution, specifically at discontinuities and strong gradients.
-Some higher-order methods, such as CADET-FV (2nd order), contain a non-linear mechanism to suppress these oscillations.
-The non-linear WENO mechanism employed in CADET-FV can be fine-tuned via the fields specified here :ref:`flux_restruction_methods`.
-Unfortunately, non-linear higher-order methods (order :math:`\geq 3`) are either not applicable (e.g., undefined boundary treatment) or have other shortcomings, such as more highly problem-dependent parameters.
+Some higher-order methods, such as the FV variants implemented in CADET, contain a non-linear mechanism to suppress these oscillations.
+The non-linear WENO mechanism employed in CADET-FV can be fine-tuned via the parameters specified in the :ref:`flux_reconstruction_methods` section.
+Unfortunately, non-linear higher-order methods (here :math:`\geq 3`) are either not applicable (e.g., undefined boundary treatment) or have other shortcomings, such as parameters whose optimal values can be highly proplem-specific.
-CADET-DG is a linear high-order method (arbitrary order) and thus exhibits oscillatory behaviour at strong gradients, which increases the approximation error and results in a smaller EOC for lower resolutions.
-As strong gradients are a local phenomena that can be captured by employing more discrete points, DG becomes more performant again for higher resolutions.
+The DG variant that is implemented in CADET is a linear high-order method (arbitrary order) and can thus exhibit oscillatory behaviour at strong gradients, which increases the approximation error and results in a smaller EOC for lower resolutions.
+Since strong gradients are local phenomena which can be captured by employing more discrete points, DG performs better again for higher spatial resolutions.
This, however, might happen after the engineering error tolerance is by far surpassed.
-Hence, CADET-FV as a stabilized lower-order method can be more performant, depending on the setting.
-The DG scheme reduces its oscillatory behaviour by adding artificial numerical dispersion at element interfaces.
-Thus, the use of a lower polynomial degree and more elements is recommended for rather non-smooth problems.
+Hence, CADET-FV as a stabilized lower-order method can perform better, depending on the smoothness of the approximated solution.
+The DG method reduces its oscillatory behaviour by adding artificial numerical dispersion at element interfaces.
+Thus, the use of a lower polynomial degree and more elements is recommended for non-smooth solutions.
In Chromatography, mathematical discontinuities never happen, as there are always some dispersive effects in reality.
Chromatography models, however, allow for discontinuities if dispersion parameters are set to zero.
-Moreover, steep and self-sharpening concentration fronts might appear due to binding.
-Binding models that might cause self-sharpening concentration fronts are often associated with competitive Langmuir type isotherms for components with differently strong binding properties.
-Nonetheless, a lot of chromatography settings yield rather smooth concentration profiles, for which DG is the better choice in terms of computational performance.
+Moreover, steep and self-sharpening concentration fronts might appear due to competitive adsorption.
+Examples that can cause self-sharpening concentration fronts are often associated with competitive Langmuir type isotherms for components with differently strong binding properties.
+Nonetheless, many chromatography settings yield rather smooth concentration profiles, for which DG is the better choice in terms of computational performance.
Recommendations on the choice of spatial discretization methods
---------------------------------------------------------------
@@ -94,21 +92,21 @@ Recommendations on the choice of spatial discretization methods
We recommend the FV method for
- Small problem sizes, e.g., low spatial resolution with the LRM
-- Problems with strong gradients, e.g., no or low dispersion and bindings that create sharp fronts
-- Bindings that mathematically require positive values or exhibit strange behaviour with negative concentration values
+- Problems with strong gradients, e.g., no or low dispersion and binding model parameters that create sharp fronts
+- Binding models that mathematically require positive values or exhibit strange behaviour with negative concentration values
We recommend the DG method for
-- Large problem sizes, e.g., high resolutions and more complex models (i.e. the LRMP and specifically the GRM)
-- Smooth problems, e.g., sufficient dispersion
+- Large problem sizes, e.g., high spatial resolutions and more complex models (i.e. the LRMP and specifically the GRM)
+- Smooth problems, i.e., sufficient band broadening
Recommendations on DG discretization parameters
-----------------------------------------------
- Employ an axial polynomial degree between 3 and 5
-- Select a lower axial polynomial degree for non smooth tendency and employ more elements instead. Converse choice for smooth problems
-- Adjust the DG particle polynomial degree to control approximation accuracy; leave the number of elements at one. Make exceptions if very steep gradients occur inside the particles or when specific parts of the particle domain are more interesting (here, you can resolve more interesting parts by a user-defined spacing of multiple elements)
-- The field ``EXACT_INTEGRATION`` specifies the DG polynomial integration method. The default value of 0 (collocation DG) is expected to be slightly more performant in most settings
+- Select a lower axial polynomial degree for approximating functions that tend to be less smooth and employ more elements instead. Converse choice for smooth problems
+- Adjust the DG particle polynomial degree to control approximation accuracy; leave the number of elements at one. Make exceptions if very steep gradients occur inside the particles or when specific regions of the particle domain are more interesting (the spatial resolution of certain regions can be refined by a user-defined spacing of multiple elements)
+- The field ``EXACT_INTEGRATION`` specifies the DG polynomial integration method. The default value of $0$ (collocation DG) is expected to be slightly more performant in most settings
Refinement strategy
-------------------
@@ -116,6 +114,7 @@ Refinement strategy
A common problem in numerical simulation is that the number of discrete points required to yield an accurate approximation within a specific tolerance is unknown.
We thus recommend determining the approximation error via comparison with a refined reference approximation.
Both the theoretical order of convergence and the EOC can be used to estimate the required number of discrete points.
+An EOC that is significantly lower than the theoretical order indicates that the problem is numerically underresolved.
Note on DG solution vector
--------------------------
diff --git a/chore/developer_guide/_sources/interface/unit_operations/2d_general_rate_model.rst.txt b/chore/developer_guide/_sources/interface/unit_operations/2d_general_rate_model.rst.txt
index ab81c7eb5..43fa62af0 100644
--- a/chore/developer_guide/_sources/interface/unit_operations/2d_general_rate_model.rst.txt
+++ b/chore/developer_guide/_sources/interface/unit_operations/2d_general_rate_model.rst.txt
@@ -284,9 +284,9 @@ For information on model equations, refer to :ref:`2d_general_rate_model_model`.
**Unit:** :math:`\mathrm{m}_{\mathrm{MP}}^{2}\,\mathrm{s}^{-1}`
- ================ ========================= ========================================================
- **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{PAR_DIFFUSION_MULTIPLEX}`
- ================ ========================= ========================================================
+ ================ ====================== ========================================================
+ **Type:** double **Range:** :math:`> 0` **Length:** see :math:`\texttt{PAR_DIFFUSION_MULTIPLEX}`
+ ================ ====================== ========================================================
``PAR_DIFFUSION_MULTIPLEX``
diff --git a/chore/developer_guide/_sources/interface/unit_operations/general_rate_model.rst.txt b/chore/developer_guide/_sources/interface/unit_operations/general_rate_model.rst.txt
index 354718226..996dc42f0 100644
--- a/chore/developer_guide/_sources/interface/unit_operations/general_rate_model.rst.txt
+++ b/chore/developer_guide/_sources/interface/unit_operations/general_rate_model.rst.txt
@@ -232,9 +232,9 @@ For information on model equations, refer to :ref:`general_rate_model_model`.
**Unit:** :math:`\mathrm{m}_{\mathrm{MP}}^{2}\,\mathrm{s}^{-1}`
- ================ ========================= ========================================================
- **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{PAR_DIFFUSION_MULTIPLEX}`
- ================ ========================= ========================================================
+ ================ ====================== ========================================================
+ **Type:** double **Range:** :math:`> 0` **Length:** see :math:`\texttt{PAR_DIFFUSION_MULTIPLEX}`
+ ================ ====================== ========================================================
``PAR_DIFFUSION_MULTIPLEX``
@@ -275,141 +275,7 @@ For information on model equations, refer to :ref:`general_rate_model_model`.
``PAR_SURFDIFFUSION_DEP``
- Parameter dependence of :math:`\texttt{PAR_SURFDIFFUSION}`. Valid dependencies are:
-
- - :math:`\texttt{NONE}` Original parameter is used unmodified.
- - :math:`\texttt{LIQUID_SALT_EXPONENTIAL}` Original parameter is modified by exponential law of liquid phase salt concentration.
- - :math:`\texttt{LIQUID_SALT_POWER}` Original parameter is modified by power law of liquid phase salt concentration.
- - :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}` Original parameter is modified by colloidal binding affinity based on liquid phase salt concentration.
-
- Optional: If left out, no parameter dependence is assumed and the original surface diffusion coefficients are used unmodified.
-
-
- ================ =========================================
- **Type:** string **Length:** :math:`1 / \texttt{NPARTYPE}`
- ================ =========================================
-
-``PAR_SURFDIFFUSION_EXPFACTOR``
-
- Factor :math:`\texttt{p1}` in exponential law particle surface diffusion relation
- :math:`D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} exp \left(p_{2, i, m} c_{0}^{p} \right)`
- where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient. Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_EXPONENTIAL}`.
-
- ================ ========================= ===================================
- **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NBOUND}`
- ================ ========================= ===================================
-
-``PAR_SURFDIFFUSION_EXPARGMULT``
-
- Factor :math:`\texttt{p2}` in exponential law particle surface diffusion relation
- :math:`D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} exp \left(p_{2, i, m} c_{0}^{p} \right)`
- where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient. Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_EXPONENTIAL}`.
-
- ================ ============================= ===================================
- **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
- ================ ============================= ===================================
-
-``PAR_SURFDIFFUSION_POWFACTOR``
-
- Factor :math:`\texttt{p1}` in power law particle surface diffusion relation
- :math:`D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} \left( c_{0}^{p} \right)^{p_{2, i, m}}`
- where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient. Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_POWER}`.
-
- ================ ========================= ===================================
- **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NBOUND}`
- ================ ========================= ===================================
-
-``PAR_SURFDIFFUSION_POWEXP``
-
- Fjactor :math:`\texttt{p2}` in power law particle surface diffusion relation
- :math:`D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} \left( c_{0}^{p} \right)^{p_{2, i, m}}`
- where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient. Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_POWER}`.
-
- ================ ============================= ===================================
- **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
- ================ ============================= ===================================
-
-``PAR_SURFDIFFUSION_LOGKEQFACTOR``
-
- Factor :math:`\texttt{p1}` in colloidal affinity law particle surface diffusion relation
- :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
- where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
- :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
- Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
-
- ================ ============================= ===================================
- **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
- ================ ============================= ===================================
-
-``PAR_SURFDIFFUSION_LOGKEQEXP``
-
- Factor :math:`\texttt{p2}` in colloidal affinity law particle surface diffusion relation
- :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
- where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
- :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
- Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
-
- ================ ============================= ===================================
- **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
- ================ ============================= ===================================
-
-``PAR_SURFDIFFUSION_LOGKEQCONST``
-
- Factor :math:`\texttt{p3}` in colloidal affinity law particle surface diffusion relation
- :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
- where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
- :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
- Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
-
- ================ ============================= ===================================
- **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
- ================ ============================= ===================================
-
-``PAR_SURFDIFFUSION_POWFACTOR``
-
- Factor :math:`\texttt{p4}` in colloidal affinity law particle surface diffusion relation
- :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
- where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
- :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
- Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
-
- ================ ============================= ===================================
- **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
- ================ ============================= ===================================
-
-``PAR_SURFDIFFUSION_POWEXP``
-
- Factor :math:`\texttt{p5}` in colloidal affinity law particle surface diffusion relation
- :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
- where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
- :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
- Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
-
- ================ ============================= ===================================
- **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
- ================ ============================= ===================================
-
- ``PAR_SURFDIFFUSION_EXPFACTOR``
- :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
- where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
- :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
- Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
-
- ================ ============================= ===================================
- **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
- ================ ============================= ===================================
-
-``PAR_SURFDIFFUSION_POWEXP``
-
- Factor :math:`\texttt{p5}` in colloidal affinity law particle surface diffusion relation
- :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
- where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
- :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
- Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
-
- ================ ============================= ===================================
- **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
- ================ ============================= ===================================
+ Parameter dependence of :math:`\texttt{PAR_SURFDIFFUSION}`, please refer to :ref:`parameter_dependencies`, section parameter-state dependencies, for more information.
``VELOCITY``
@@ -484,10 +350,11 @@ Group /input/model/unit_XXX/discretization - UNIT_TYPE - GENERAL_RATE_MODEL
Spatial discretization - Numerical Methods
------------------------------------------
-CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Only the input fields for the chosen method need to be specified.
+CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Each method has it's own set of input fields.
While both methods approximate the same solution to the same underlying model, they may differ in terms of computational performance.
-Generally, FV is more performant for solutions with steep gradients or discontinuities, while DG excels for rather smooth solutions.
-We note that DG is only faster in the sense that less spatial discrete points are required to achieve the same accuracy as FV. For the same number of discrete points, DG will be slower, but more accurate.
+With our currently implemented variants of FV and DG, FV perform better for solutions with steep gradients or discontinuities, while DG can be much faster for rather smooth solutions.
+For the same number of discrete points, DG will generally be slower but often more accurate.
+
For further information on the choice of discretization methods and their parameters, see :ref:`spatial_discretization_methods`.
``SPATIAL_METHOD``
@@ -573,7 +440,7 @@ Finite Volumes (Default)
**Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
============= =========================== =============
-For further discretization parameters, see also :ref:`flux_restruction_methods` (FV specific)), and :ref:`non_consistency_solver_parameters`.
+For further discretization parameters, see also :ref:`flux_reconstruction_methods` (FV specific)), and :ref:`non_consistency_solver_parameters`.
Discontinuous Galerkin
----------------------
diff --git a/chore/developer_guide/_sources/interface/unit_operations/index.rst.txt b/chore/developer_guide/_sources/interface/unit_operations/index.rst.txt
index 1d80a6b36..078802e29 100644
--- a/chore/developer_guide/_sources/interface/unit_operations/index.rst.txt
+++ b/chore/developer_guide/_sources/interface/unit_operations/index.rst.txt
@@ -15,4 +15,5 @@ Unit Operations
cstr
radial_flow_models
multi_channel_transport_model
+ population_balance_model
diff --git a/chore/developer_guide/_sources/interface/unit_operations/lumped_rate_model_with_pores.rst.txt b/chore/developer_guide/_sources/interface/unit_operations/lumped_rate_model_with_pores.rst.txt
index ace7b4c2b..8ac99c96f 100644
--- a/chore/developer_guide/_sources/interface/unit_operations/lumped_rate_model_with_pores.rst.txt
+++ b/chore/developer_guide/_sources/interface/unit_operations/lumped_rate_model_with_pores.rst.txt
@@ -249,10 +249,11 @@ For information on model equations, refer to :ref:`lumped_rate_model_with_pores_
Spatial discretization - Numerical Methods
------------------------------------------
-CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Only the input fields for the chosen method need to be specified.
+CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Each method has it's own set of input fields.
While both methods approximate the same solution to the same underlying model, they may differ in terms of computational performance.
-Generally, FV is more performant for solutions with steep gradients or discontinuities, while DG excels for rather smooth solutions.
-We note that DG is only faster in the sense that less spatial discrete points are required to achieve the same accuracy as FV. For the same number of discrete points, DG will be slower, but more accurate.
+With our currently implemented variants of FV and DG, FV perform better for solutions with steep gradients or discontinuities, while DG can be much faster for rather smooth solutions.
+For the same number of discrete points, DG will generally be slower but often more accurate.
+
For further information on the choice of discretization methods and their parameters, see :ref:`spatial_discretization_methods`.
``SPATIAL_METHOD``
@@ -314,7 +315,7 @@ Finite Volumes (Default)
**Type:** double **Range:** :math:`\geq 0` **Length:** 1
================ ========================= =============
-For further discretization parameters, see also :ref:`flux_restruction_methods` (FV specific)), and :ref:`non_consistency_solver_parameters`.
+For further discretization parameters, see also :ref:`flux_reconstruction_methods` (FV specific)), and :ref:`non_consistency_solver_parameters`.
Discontinuous Galerkin
diff --git a/chore/developer_guide/_sources/interface/unit_operations/lumped_rate_model_without_pores.rst.txt b/chore/developer_guide/_sources/interface/unit_operations/lumped_rate_model_without_pores.rst.txt
index 5afc37821..e32c9b33d 100644
--- a/chore/developer_guide/_sources/interface/unit_operations/lumped_rate_model_without_pores.rst.txt
+++ b/chore/developer_guide/_sources/interface/unit_operations/lumped_rate_model_without_pores.rst.txt
@@ -155,10 +155,11 @@ Group /input/model/unit_XXX/discretization - UNIT_TYPE = LUMPED_RATE_MODEL_WITHO
Spatial discretization - Numerical Methods
------------------------------------------
-CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Only the input fields for the chosen method need to be specified.
+CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Each method has it's own set of input fields.
While both methods approximate the same solution to the same underlying model, they may differ in terms of computational performance.
-Generally, FV is more performant for solutions with steep gradients or discontinuities, while DG excels for rather smooth solutions.
-We note that DG is only faster in the sense that less spatial discrete points are required to achieve the same accuracy as FV. For the same number of discrete points, DG will be slower, but more accurate.
+With our currently implemented variants of FV and DG, FV perform better for solutions with steep gradients or discontinuities, while DG can be much faster for rather smooth solutions.
+For the same number of discrete points, DG will generally be slower but often more accurate.
+
For further information on the choice of discretization methods and their parameters, see :ref:`spatial_discretization_methods`.
``SPATIAL_METHOD``
@@ -188,7 +189,7 @@ Finite Volumes (Default)
**Type:** string **Range:** :math:`\texttt{WENO}` **Length:** 1
================ ================================ =============
-For further discretization parameters, see also :ref:`flux_restruction_methods` (FV specific)), and :ref:`non_consistency_solver_parameters`.
+For further discretization parameters, see also :ref:`flux_reconstruction_methods` (FV specific)), and :ref:`non_consistency_solver_parameters`.
Discontinuous Galerkin
diff --git a/chore/developer_guide/_sources/interface/unit_operations/multi_channel_transport_model.rst.txt b/chore/developer_guide/_sources/interface/unit_operations/multi_channel_transport_model.rst.txt
index 7d058fcdf..3df6a7e73 100644
--- a/chore/developer_guide/_sources/interface/unit_operations/multi_channel_transport_model.rst.txt
+++ b/chore/developer_guide/_sources/interface/unit_operations/multi_channel_transport_model.rst.txt
@@ -131,6 +131,11 @@ For information on model equations, refer to :ref:`multi_channel_transport_model
e^k_{N1} & \dots & e^k_{N(N-1)} & 0
\end{bmatrix}
+ For addressing the exchange rates as a parameter senstivity, the mapping is as follows:
+
+ - :math:`\texttt{SENS_BOUNDPHASE}` *Channel from*
+ - :math:`\texttt{SENS_PARTYPE}` *Channel to*
+
================ ======================== ===============================================
**Type:** double **Range:** :math:`[0,1]` **Length:** :math:`\texttt{NCHANNEL}*\texttt{NCHANNEL}*\texttt{NCOMP}`
================ ======================== ===============================================
diff --git a/chore/developer_guide/_sources/interface/unit_operations/radial_flow_models.rst.txt b/chore/developer_guide/_sources/interface/unit_operations/radial_flow_models.rst.txt
index 4bc99053a..9fdac5fc9 100644
--- a/chore/developer_guide/_sources/interface/unit_operations/radial_flow_models.rst.txt
+++ b/chore/developer_guide/_sources/interface/unit_operations/radial_flow_models.rst.txt
@@ -106,4 +106,4 @@ Accordingly, the following specifications can be left out for radial flow models
**Type:** string **Range:** :math:`\texttt{NONE}` **Length:** 1
================ ================================ =============
-Parameters specified under :ref:`flux_restruction_methods` can also be ignored.
\ No newline at end of file
+Parameters specified under :ref:`flux_restruction_methods` can also be ignored.
diff --git a/chore/developer_guide/_sources/modelling/binding/freundlich_ldf.rst.txt b/chore/developer_guide/_sources/modelling/binding/freundlich_ldf.rst.txt
index 4351ce196..b5a24a07d 100644
--- a/chore/developer_guide/_sources/modelling/binding/freundlich_ldf.rst.txt
+++ b/chore/developer_guide/_sources/modelling/binding/freundlich_ldf.rst.txt
@@ -14,7 +14,7 @@ This variant of the model is based on the linear driving force approximation (se
No interaction between the components is considered when the model has multiple components.
One of the limitation of this isotherm is the first order Jacobian :math:`\left(\frac{dq^*}{dc_p}\right)` tends to infinity as :math:`c_{p} \rightarrow 0` for :math:`n>1`.
To address this issue an approximation of isotherm is considered near the origin.
-This approximation matches the isotherm in such a way that :math:`q=0` at :math:`c_p=0` and also matches the first derivative of the istotherm at :math:`c_p = \epsilon`, where :math:`\epsilon` is a very small number, for example :math:`1e-14`.
+This approximation matches the isotherm in such a way that :math:`q=0` at :math:`c_p=0` and also matches the first derivative of the istotherm at :math:`c_p = \varepsilon`, where :math:`\varepsilon` is a very small number, for example :math:`1e-14`.
The form of approximation and its derivative is given below for :math:`c_p < \varepsilon` and :math:`n>1`:
.. math::
@@ -38,7 +38,7 @@ where :math:`\alpha_0=0` and :math:`\alpha_1` and :math:`\alpha_2` are determine
\alpha_2 = \frac{1-n}{n}k_f \varepsilon^{\frac{1-2 n}{n}}
\end{aligned}
-This approximation can be used for any pore phase cocentration :math:`c_p < \epsilon` given :math:`n>1`.
+This approximation can be used for any pore phase cocentration :math:`c_p < \varepsilon` given :math:`n>1`.
For the case, when :math:`n \le 1` no special treament near the origin is required.
For more information on model parameters required to define in CADET file format, see :ref:`freundlich_ldf_config`.
diff --git a/chore/developer_guide/_sources/modelling/crystallization.rst.txt b/chore/developer_guide/_sources/modelling/crystallization.rst.txt
new file mode 100644
index 000000000..82c276f6b
--- /dev/null
+++ b/chore/developer_guide/_sources/modelling/crystallization.rst.txt
@@ -0,0 +1,174 @@
+.. _pbm_model:
+
+Population Balance Models
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The population balance model (PBM) is given by a particle-number continuity equation which describes the evolution of the number density :math:`n` of the particles over time :math:`t` and with respect to a so-called internal coordinate :math:`x` and external coordinate :math:`z`.
+The internal coordinate can be chosen as any characteristic property of the particles such as the particle size or volume.
+The external coordinate can be a characteristic dimension of the reactor itself, including its axial length.
+
+In CADET, we chose particle size and axial coordinate as the internal and external coodinate respectively.
+The PBM in CADET is implemented so that it can be used in any unit operation that supports reactions.
+Typical applications consider crystallization in a CSTR or, to model continuous processes, in a Dispersive Plug-Flow Reactor (DPFR), which is described by the LRM without solid phase.
+
+In the following, we give a brief overview on the modelling equations, for more information on the PBM as implemented in CADET, please refer to :cite:`zhang2024solving`.
+
+.. figure:: PBM_Part_I.png
+
+ Nucleation, growth and growth rate dispersion in PBM. Note that dispersion is used to model (random) variance in growth speed, not the reduction of particle size, which is feasible for a convection dominated process.
+
+Population Balance Model in a CSTR
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+We assume a well-mixed tank and choose the particle size :math:`x\in (x_c, \infty)` as the internal coodinate, with :math:`x_c>0` being the minimal particle size considered.
+The corresponding PBM is given as
+
+.. math::
+
+ \begin{aligned}
+ \frac{\partial (n V)}{\partial t} = F_{in}n_{in} - F_{out}n - V \left( \frac{\partial (v_{G}n)}{\partial x} - D_g \frac{\partial^2 n}{\partial x^2} - B_0 \delta (x-x_c) \right),
+ \end{aligned}
+
+where :math:`F_{in}, F_{out}\in \mathbb{R}^+` are the volumetric inflow and outflow rates, :math:`V\in\mathbb{R}^+` is the reactor volume,
+:math:`n(t, x)\colon [0, T_\text{end}] \times (x_c, \infty) \mapsto \mathbb{R}^+` is the number density distribution,
+:math:`n_{in}\in\mathbb{R}^+` is the number density distribution of the inlet feed, :math:`v_{G}\in\mathbb{R}^+` is the particle growth rate,
+:math:`D_g\in\mathbb{R}^+` is the growth dispersion rate.
+
+The boundary conditions are given by the regularity boundary condition
+
+.. math::
+ :label: RegularityBC
+
+ \begin{aligned}
+ \left. \left( nv_{G} - D_g \frac{\partial n}{\partial x} \right) \right|_{x \to \infty}=0,
+ \end{aligned}
+
+and the nucleation kinetics boundary condition
+
+.. math::
+ :label: NucleationBC
+
+ \begin{aligned}
+ \left. \left( nv_{G}-D_g \frac{\partial n}{\partial x} \right)\right|_{x=x_c} = B_0,
+ \end{aligned}
+
+where :math:`B_0\in\mathbb{R}^+` is the nucleation kinetics factor representing particle nucleations of size :math:`x_c\in\mathbb{R}^+`.
+
+The model is complemented by the following mass balance equation which accounts for the mass transfer between the particle phase and the solute phase
+
+.. math::
+
+ \begin{aligned}
+ \frac{\partial (cV)}{\partial t} = F_{in}c_{in} - F_{out}c -\rho k_v V \left( B_0x^3_c + 3\int_{x_c}^{\infty} v_{G}n\ x^2 \;\mathrm{d}x \right),
+ \end{aligned}
+
+where :math:`c(t)\colon [0, T_\text{end}] \mapsto \mathbb{R}^+` is the solute concentration in the bulk phase, :math:`c_{in}\in\mathbb{R}^+` is the inlet solute mass concentration, :math:`\rho > 0` is the nuclei mass density and :math:`k_v > 0` is the volumetric shape factor of the particles.
+
+Evolution of the reactor's volume is governed by
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d}V}{\mathrm{d}t} &= F_{\text{in}} - F_{\text{out}}.
+ \end{aligned}
+
+
+Population Balance Model in a DPFR
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The PBM can also be formulated for a DPFR to model continuous processes.
+That is, we choose the axial position within a DPFR as the external coordinate :math:`z\in[0, L]` and formulate the :math:`2D` PBM
+
+.. math::
+
+ \begin{aligned}
+ \frac{\partial n}{\partial t} = -v_\text{ax} \frac{\partial n}{\partial z} +D_{ax} \frac{\partial^2 n}{\partial z^2} - \frac{\partial (v_{G}n)}{\partial x} + D_g \frac{\partial^2 n}{\partial x^2},
+ \end{aligned}
+
+where :math:`n(t, x, z)\colon [0, T_\text{end}] \times (x_c, \infty) \times [0, L] \mapsto \mathbb{R}^+` is the number density distribution,
+:math:`v_\text{ax}\in\mathbb{R}^+` is the axial velocity and :math:`D_{ax}\in\mathbb{R}^+` is the axial dispersion coefficient.
+
+Boundary conditions for the internal coordinate are again given by Eq. :eq:`RegularityBC` and Eq. :eq:`NucleationBC`.
+
+For the external coordinate :math:`z`, Danckwerts boundary conditions are applied:
+
+.. math::
+
+ \begin{aligned}
+ \left. \left( n v_\text{ax}-D_{ax}\frac{\partial n}{\partial z} \right) \right|_{z=0} = v_\text{ax} n_{in,x}, \qquad \left.\frac{\partial n}{\partial z}\right|_{z=L}=0.
+ \end{aligned}
+
+The mass balance equation for the solute :math:`c(t, z)\colon [0,T-\text{end}] \times [0,L] \mapsto \mathbb{R}^+` is given by
+
+.. math::
+
+ \begin{aligned}
+ \frac{\partial c}{\partial t} = -v_\text{ax} \frac{\partial c}{\partial z} +D_{ax} \frac{\partial^2 c}{\partial z^2} -\rho k_v \left( B_0x^3_c + 3\int_{x_c}^{\infty} v_{G}n x^2 \;\mathrm{d}x \right).
+ \end{aligned}
+
+As for the particle phase, the solute mass concentration subjects to the Danckwerts boundary conditions
+
+.. math::
+
+ \begin{aligned}
+ \left.\left( c v_\text{ax}-D_{ax}\frac{\partial c}{\partial z} \right) \right|_{z=0} = v_\text{ax} c_{in}, \qquad \left.\frac{\partial c}{\partial z}\right|_{z=L}=0.
+ \end{aligned}
+
+
+Constitutive equations
+^^^^^^^^^^^^^^^^^^^^^^
+
+Constitutive equations describe the kinetic processes in the governing equations. The relative supersaturation :math:`s>0` is:
+
+.. math::
+
+ \begin{aligned}
+ s=\frac{c-c_{eq}}{c_{eq}},
+ \end{aligned}
+
+where :math:`c_{eq}>0` is the solute solubility in the solvent.
+The nucleation kinetics can be split into primary and secondary nucleation:
+
+.. math::
+
+ \begin{aligned}
+ B_0 = B_p + B_s,
+ \end{aligned}
+
+Which are in turn defined by the following constitutive equations.
+An empirical equation for primary nucleation is given by:
+
+.. math::
+
+ \begin{aligned}
+ B_p=k_ps^u,
+ \end{aligned}
+
+where :math:`k_p\in\mathbb{R}^+` is the primary nucleation rate constant and :math:`u\in\mathbb{R}^+` is a constant.
+An empirical power-law expression is used for the secondary nucleation:
+
+.. math::
+
+ \begin{aligned}
+ B_s=k_bs^bM^k,
+ \end{aligned}
+
+where :math:`k_b\in\mathbb{R}^+` is the secondary nucleation rate constant, :math:`b\in\mathbb{R}^+` and :math:`k\in\mathbb{R}^+` are system-related parameters and :math:`M\in\mathbb{R}^+` is the suspension density defined as
+
+.. math::
+
+ \begin{aligned}
+ M=k_v\rho\int_{0}^{\infty}n\ x^3\;\mathrm{d}x.
+ \end{aligned}
+
+The following expression for the growth rate is implemented:
+
+.. math::
+
+ \begin{aligned}
+ v_{G}=k_gs^g(a+\gamma x^p),
+ \end{aligned}
+
+where :math:`k_g\in\mathbb{R}^+` is the growth rate constant, :math:`\gamma\in\mathbb{R}^+` quantifies the size dependence, and :math:`g, a, p\in\mathbb{R}^+` are system-related constants.
+
+For information on model parameters and how to specify the model interface, see :ref:`pbm_config`.
diff --git a/chore/developer_guide/_sources/modelling/index.rst.txt b/chore/developer_guide/_sources/modelling/index.rst.txt
index 283c9f3a9..8f0beb9b0 100644
--- a/chore/developer_guide/_sources/modelling/index.rst.txt
+++ b/chore/developer_guide/_sources/modelling/index.rst.txt
@@ -10,3 +10,4 @@ This section gives complete information about the supported unit operations, bin
binding/index
reaction/index
networks
+ crystallization
diff --git a/chore/developer_guide/_sources/modelling/unit_operations/general_rate_model.rst.txt b/chore/developer_guide/_sources/modelling/unit_operations/general_rate_model.rst.txt
index b6dd3b6ff..071177948 100644
--- a/chore/developer_guide/_sources/modelling/unit_operations/general_rate_model.rst.txt
+++ b/chore/developer_guide/_sources/modelling/unit_operations/general_rate_model.rst.txt
@@ -72,7 +72,7 @@ Consider a column of length :math:`L>0` filled with spherical beads of (possibly
&+ f_{\text{react},i}^\ell\left(c^\ell\right).
\end{aligned}
-Here, :math:`c^\ell_i\colon \left[0, T_{\text{end}}\right] \times [0, L] \rightarrow \mathbb{R}^{\geq 0}` denotes the concentration in the interstitial column volume, :math:`c^p_{j,i}\colon \left[0, T_{\text{end}}\right] \times [0, L] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}` the liquid phase concentration in the beads, :math:`k_{f,j,i}` the film diffusion coefficient, :math:`D_{\text{ax},i}` the dispersion coefficient, :math:`u` the interstitial velocity, :math:`d_j` the volume fraction of particle type :math:`j`, and :math:`\beta_c = \varepsilon_c / (1 - \varepsilon_c)` the column phase ratio, where :math:`\varepsilon_c` is the column porosity (ratio of interstitial volume to total column volume).
+Here, :math:`c^\ell_i\colon \left[0, T_{\text{end}}\right] \times [0, L] \rightarrow \mathbb{R}^{\geq 0}` denotes the concentration in the interstitial column volume, :math:`c^p_{j,i}\colon \left[0, T_{\text{end}}\right] \times [0, L] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}` the liquid phase concentration in the beads, :math:`k_{f,j,i}\geq 0` the film diffusion coefficient, :math:`D_{\text{ax},i}\geq 0` the dispersion coefficient, :math:`u\in\mathbb{R}` the interstitial velocity, :math:`d_j > 0` the volume fraction of particle type :math:`j`, and :math:`\frac{1}{\beta_c} = (1 - \varepsilon_c) / \varepsilon_c` the column phase ratio, where :math:`\varepsilon_c\in (0,1]` is the column porosity (ratio of interstitial volume to total column volume).
If reactions are considered, the term :math:`f_{\text{react},i}^\ell\left(c^\ell\right)` represents the net change of concentration :math:`c_i` due to reactions involving component :math:`i`.
Danckwerts boundary conditions :cite:`Danckwerts1953` are applied to inlet and outlet of the column:
@@ -106,7 +106,7 @@ In the liquid phase of the porous beads (see :numref:`ModelGRMColumn`) the mass
\end{aligned}
-where :math:`c^s_{j,i,m_{j,i}}\colon \left[0, T_{\text{end}}\right] \times [0,L] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}` denotes the solid phase concentration of the :math:`i`\ th component’s :math:`m_{j,i}`\ th bound state in the beads of :math:`j`\ th type, :math:`D_{p,j,i}` the effective diffusion coefficient in the beads, :math:`D_{s,j,i}` the surface diffusion coefficient, :math:`F_{\text{acc},j,i} \in [0,1]` the pore accessibility factor, and :math:`\varepsilon_{p,j}` the particle porosity (ratio of pore volume to total bead volume).
+where :math:`c^s_{j,i,m_{j,i}}\colon \left[0, T_{\text{end}}\right] \times [0,L] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}` denotes the solid phase concentration of the :math:`i`\ th component’s :math:`m_{j,i}`\ th bound state in the beads of :math:`j`\ th type, :math:`D_{p,j,i}>0` the effective diffusion coefficient in the beads, :math:`D_{s,j,i}\geq 0` the surface diffusion coefficient, :math:`F_{\text{acc},j,i}\geq 0 \in [0,1]` the pore accessibility factor, and :math:`\varepsilon_{p,j}\in (0,1]` the particle porosity (ratio of pore volume to total bead volume).
The inner bead radius :math:`r_{c,j} \in [0, r_{p,j})` is assumed to be :math:`0` by default, but can be positive in order to account for core-shell particles that have an impermeable core.
Reaction terms in liquid and solid phase are collected in :math:`f_{\text{react},j,i}^p( c_j^p, c_j^s)` and :math:`f_{\text{react},j,i}^s(c_j^p, c_j^s)`, respectively.
@@ -302,7 +302,7 @@ The radial flow GRM describes transport of solute molecules through the intersti
The main assumptions are:
-- The shells of the column are homogenous in terms of interstitial volume, fluid flow, and distribution of components.
+- The cylindrical shells of the column are homogenous in terms of interstitial volume, fluid flow, and distribution of components.
Thus, only one spatial coordinate in radial direction :math:`\rho` is needed and axial transport is neglected in the column bulk volume.
- The bead radii :math:`r_{p}` are much smaller than the column radius :math:`\mathrm{P}-\mathrm{P}_c`, with :math:`\mathrm{P}` and :math:`\mathrm{P}_c` being the inner and outer column radius respectively, and the column length :math:`L`.
@@ -314,33 +314,33 @@ The main assumptions are:
Consider a hollow (double walled) column with inner column diameter :math:`\mathrm{P}_c>0` and outer diameter :math:`\mathrm{P}>\mathrm{P}_c`, filled with spherical beads of (possibly) multiple types with radius :math:`r_{p,j} \ll L` (see :numref:`ModelGRMColumn`), where :math:`j` is the particle type index. The mass balance in the interstitial column volume is described by
.. math::
- :label: ModelRadialColumn
+ :label: ModelRadialColumnGRM
\begin{aligned}
\frac{\partial c^\ell_i}{\partial t} = -\frac{u}{\rho} \frac{\partial c^\ell_i}{\partial \rho} + D_{\text{rad},i} \frac{1}{\rho} \frac{\partial}{\partial \rho} \left(\rho \frac{\partial c^\ell_i}{\partial \rho} \right) &- \frac{1}{\beta_c} \sum_j d_j \frac{3}{r_{p,j}} k_{f,j,i} \left[ c^\ell_i - c^p_{j,i}(\cdot, \cdot, r_{p,j}) \right] \\
&+ f_{\text{react},i}^\ell\left(c^\ell\right).
\end{aligned}
-Here, :math:`c^\ell_i\colon \left[0, T_{\text{end}}\right] \times [\mathrm{P}_c, \mathrm{P}] \rightarrow \mathbb{R}^{\geq 0}` denotes the concentration in the interstitial column volume, :math:`c^p_{j,i}\colon \left[0, T_{\text{end}}\right] \times [P_c, P] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}` the liquid phase concentration in the beads, :math:`k_{f,j,i}` the film diffusion coefficient, :math:`D_{\text{rad},i}` the dispersion coefficient, :math:`u` the interstitial velocity, :math:`d_j` the volume fraction of particle type :math:`j`, and :math:`\beta_c = \varepsilon_c / (1 - \varepsilon_c)` the column phase ratio, where :math:`\varepsilon_c` is the column porosity (ratio of interstitial volume to total column volume).
+Here, :math:`c^\ell_i\colon \left[0, T_{\text{end}}\right] \times [\mathrm{P}_c, \mathrm{P}] \rightarrow \mathbb{R}^{\geq 0}` denotes the concentration in the interstitial column volume, :math:`c^p_{j,i}\colon \left[0, T_{\text{end}}\right] \times [P_c, P] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}` the liquid phase concentration in the beads, :math:`k_{f,j,i}\geq 0` the film diffusion coefficient, :math:`D_{\text{rad},i}\geq 0` the dispersion coefficient, :math:`u>0` the interstitial velocity, :math:`d_j>0` the volume fraction of particle type :math:`j`, and :math:`\beta_c = \varepsilon_c / (1 - \varepsilon_c)` the column phase ratio, where :math:`\varepsilon_c\in(0,1)` is the column porosity (ratio of interstitial volume to total column volume).
If reactions are considered, the term :math:`f_{\text{react},i}^\ell\left(c^\ell\right)` represents the net change of concentration :math:`c_i` due to reactions involving component :math:`i`.
Danckwerts boundary conditions :cite:`Danckwerts1953` are applied to inlet and outlet of the column:
.. math::
- :label: BCOutlet
+ :label: BCOutletRadial
\begin{aligned}
u c_{\text{in},i}(t) &= u c^\ell_i(t,0) - D_{\text{rad},i} \frac{\partial c^\ell_i}{\partial \rho}(t, 0) & \forall t > 0,
\end{aligned}
.. math::
- :label: BCInlet
+ :label: BCInletRadial
\begin{aligned}
\frac{\partial c^\ell_i}{\partial \rho}(t, \mathrm{P}) &= 0 & \forall t > 0.
\end{aligned}
-Note that the outlet boundary condition Eq. :eq:`BCOutlet` is also known as “do nothing” or natural outflow condition.
+Note that the outlet boundary condition Eq. :eq:`BCOutletRadial` is also known as “do nothing” or natural outflow condition.
The complementing mass transport and binding equations for the liquid and solid phases of the porous beads are described by the same equations as for the axial GRM.
diff --git a/chore/developer_guide/_sources/modelling/unit_operations/index.rst.txt b/chore/developer_guide/_sources/modelling/unit_operations/index.rst.txt
index d712f21a3..12cc6fae8 100644
--- a/chore/developer_guide/_sources/modelling/unit_operations/index.rst.txt
+++ b/chore/developer_guide/_sources/modelling/unit_operations/index.rst.txt
@@ -53,6 +53,12 @@ is given in :numref:`table_features_unit_operations`.
- ×
- ×
- ×
+ * - :ref:`pbm_model`
+ - ×
+ - ×
+ - ×
+ - ×
+ - ×
Moreover, the pseudo unit operations :ref:`inlet_model`, and :ref:`outlet_model` act as sources and sinks for the system.
diff --git a/chore/developer_guide/_sources/modelling/unit_operations/lumped_rate_model_with_pores.rst.txt b/chore/developer_guide/_sources/modelling/unit_operations/lumped_rate_model_with_pores.rst.txt
index b6877d069..dd091e233 100644
--- a/chore/developer_guide/_sources/modelling/unit_operations/lumped_rate_model_with_pores.rst.txt
+++ b/chore/developer_guide/_sources/modelling/unit_operations/lumped_rate_model_with_pores.rst.txt
@@ -8,6 +8,7 @@ The particle phase :math:`c^p_j` is still there, but no mass transfer happens ex
Hence, the model equations are given by
.. math::
+ :label: ModelColumnGRM
\begin{aligned}
\frac{\partial c^\ell_i}{\partial t} &= -u \frac{\partial c^\ell_i}{\partial z} + D_{\text{ax},i} \frac{\partial^2 c^\ell_i}{\partial z^2} - \frac{1}{\beta_c} \sum_{j} d_j \frac{3}{r_{p,j}} k_{f,j,i}\left[ c^\ell_i - c^p_{j,i} \right] + f_{\text{react},i}^\ell\left(c^\ell\right),
@@ -73,12 +74,13 @@ The main assumptions are:
Consider a hollow (double walled) column with inner column diameter :math:`\mathrm{P}_c>0` and outer diameter :math:`\mathrm{P}>\mathrm{P}_c`, filled with spherical beads of (possibly) multiple types with radius :math:`r_{p,j} \ll L` (see :numref:`ModelGRMColumn`), where :math:`j` is the particle type index. The mass balance in the interstitial column volume is described by
.. math::
+ :label: ModelRadialColumnGRM
\begin{aligned}
\frac{\partial c^\ell_i}{\partial t} &= -\frac{u}{\rho} \frac{\partial c^\ell_i}{\partial \rho} + D_{\text{rad},i} \frac{1}{\rho} \frac{\partial}{\partial \rho} \left( \rho \frac{\partial c^\ell_i}{\partial \rho} \right) - \frac{1}{\beta_c} \sum_{j} d_j \frac{3}{r_{p,j}} k_{f,j,i}\left[ c^\ell_i - c^p_{j,i} \right] + f_{\text{react},i}^\ell\left(c^\ell\right),
\end{aligned}
-The equations are complemented by Eq. :ref:`ModelParticleLRMP` and the Danckwerts boundary conditions :cite:`Danckwerts1953`
+The equations are complemented by Eq. :eq:`ModelParticleLRMP` and the Danckwerts boundary conditions :cite:`Danckwerts1953`
.. math::
diff --git a/chore/developer_guide/_sources/modelling/unit_operations/lumped_rate_model_without_pores.rst.txt b/chore/developer_guide/_sources/modelling/unit_operations/lumped_rate_model_without_pores.rst.txt
index bc959603d..438cd5802 100644
--- a/chore/developer_guide/_sources/modelling/unit_operations/lumped_rate_model_without_pores.rst.txt
+++ b/chore/developer_guide/_sources/modelling/unit_operations/lumped_rate_model_without_pores.rst.txt
@@ -17,6 +17,7 @@ The phase ratio is denoted by :math:`\beta_t = \varepsilon_t / (1 - \varepsilon_
The model equations are given by
.. math::
+ :label: ModelColumnLRM
\begin{aligned}
\frac{\partial c^\ell_i}{\partial t} + \frac{1}{\beta_t} \frac{\partial}{\partial t} \sum_{m_i} c^s_{i,m_i} &= -u \frac{\partial c^\ell_i}{\partial z} + D_{\text{ax},i} \frac{\partial^2 c^\ell_i}{\partial z^2} + f_{\text{react},i}^\ell\left( c^\ell, c^s \right) + \frac{1}{\beta_t} f_{\text{react},i}^s\left( c^\ell, c^s \right),
@@ -73,7 +74,7 @@ The main assumptions are:
Consider a hollow (double walled) column with inner column diameter :math:`\mathrm{P}_c>0` and outer diameter :math:`\mathrm{P}>\mathrm{P}_c`, filled with spherical beads. The mass balance in the interstitial column volume is described by
.. math::
- :label: ModelRadialColumn
+ :label: ModelRadialColumnLRM
\begin{aligned}
\frac{\partial c^\ell_i}{\partial t} + \frac{1}{\beta_t} \frac{\partial}{\partial t} \sum_{m_i} c^s_{i,m_i} &= -\frac{u}{\rho} \frac{\partial c^\ell_i}{\partial \rho} + D_{\text{rad},i} \frac{1}{\rho} \frac{\partial}{\partial \rho} \left( \rho \frac{\partial c^\ell_i}{\partial \rho} \right) + f_{\text{react},i}^\ell\left( c^\ell, c^s \right) + \frac{1}{\beta_t} f_{\text{react},i}^s\left( c^\ell, c^s \right),
diff --git a/chore/developer_guide/_sources/publications.md.txt b/chore/developer_guide/_sources/publications.md.txt
new file mode 100644
index 000000000..22db96e46
--- /dev/null
+++ b/chore/developer_guide/_sources/publications.md.txt
@@ -0,0 +1,28 @@
+
+**General CADET-Core:**
+
+- Leweke, S.; von Lieres, E.: `Chromatography Analysis and Design Toolkit (CADET) `_, Computers and Chemical Engineering **113** (2018), 274294.
+
+- von Lieres, E.; Andersson, J.: `A fast and accurate solver for the general rate model of column liquid chromatography `_, Computers and Chemical Engineering **34,8** (2010), 11801191.
+
+**CADET-Core numerics:**
+
+- Breuer, J. M.; Leweke, S.; Schmlder, J.; Gassner, G.; von Lieres, E.: `Spatial discontinuous Galerkin spectral element method for a family of chromatography models in CADET `_, Computers and Chemical Engineering **177** (2023), 108340.
+
+- Leweke, S.; von Lieres, E.: `Fast arbitrary order moments and arbitrary precision solution of the general rate model of column liquid chromatography with linear isotherm `_, Computers and Chemical Engineering **84** (2016), 350362.
+
+- Pttmann, A.; Schnittert, S.; Naumann, U.; von Lieres, E.: `Fast and accurate parameter sensitivities for the general rate model of column liquid chromatography `_, Computers and Chemical Engineering **56** (2013), 4657.
+
+**Selected applications and use-cases of CADET-Core:**
+
+- Heymann, W.; Glaser, J.; Schlegel, F.; Johnson, W.; Rolandi, P.; von Lieres, E.: `Advanced score system and automated search strategies for parameter estimation in mechanistic chromatography modeling `_, Journal of Chromatography A **1661** (2022): 462693.
+
+- He, Q.-L.; Leweke, S.; von Lieres, E.: `Efficient numerical simulation of simulated moving bed chromatography with a single-column solver `_, Computers and Chemical Engineering **111** (2018), 183198.
+
+- Freier, L.; von Lieres, E.: `Robust multi-objective global optimization of stochastic processes with a case study in gradient elution chromatography `_, Biotechnology Journal **13,1** (2018), 1700257.
+
+- Freier, L.; von Lieres, E.: [Multi-objective global optimization (MOGO): `Algorithm and case study in gradient elution chromatography `_, Biotechnology Journal **12,7** (2017), 1600613.
+
+- Diedrich, J.; Heymann, W.; Leweke, S.; Kunert, C.; Johnson, W.; Hunt, S.; Todd, B.; von Lieres, E.: `Multi-state steric mass-action model and case study on complex high loading behavior of mAb on ion exchange tentacle resin `_, Journal of Chromatography A **1525** (2017), 6070.
+
+- Pttmann, A.; Schnittert, S.; Leweke, S.; von Lieres, E.: `Utilizing algorithmic differentiation to efficiently compute chromatograms and parameter sensitivities `_, Chemical Engineering Science, **139** (2016), 152162.
diff --git a/chore/developer_guide/developer_guide/build_options.html b/chore/developer_guide/developer_guide/build_options.html
index 2b1e4cd79..0ae7723fa 100644
--- a/chore/developer_guide/developer_guide/build_options.html
+++ b/chore/developer_guide/developer_guide/build_options.html
@@ -57,12 +57,13 @@
The following build arguments are exclusive to builds on MS windows:
DVCPKG_TARGET_TRIPLET: We use vcpkg to manage our dependencies. This triplet specifies which version of the dependencies should be installed. It takes the form of architecture-os-linking, so x64-windows-static for our use cases.
+
The following build arguments can only be used with the Clang or GCC compilers:
+
+
DENABLE_ASAN: enables the address sanitizer.
+
DENABLE_UBSAN: enables the undefined behaviour sanitizer.
To debug memory related issues, you can compile the code with the address sanitizer ASAN and the undefined behaviour sanitizer UBSAN by enabling the cmake arguments DENABLE_ASAN and DENABLE_UBSAN.
This developer guide is intended to help expand and maintain CADET-Core and is written to serve developers with diverse backgrounds.
If you find any gaps or have suggestions for improvement, your input is valuable in refining our documentation for better comprehension by all developers.
-Please feel free to open an issue on GitHub or, even better, write a draft and create a pull request.
+Please feel free to open an issue on GitHub or, even better, write a draft and create a pull request.
When planning to extend or contribute to CADET-Core, please adhere to our notation style and research software engineering (RSE) best practices.
For detailed guidance, you can e.g. refer to the RSE guidelines.
Since some developers may be new to collaborative software development using Git and GitHub, we specifically recommend consulting the Git RSE guide.
The release tests contain extensive testing that is not included in our CI, such as EOC tests.
+Running these tests might take a while and this should be done on the server.
+
Some tests are implemented in CADET-Core, and can be run with the [ReleaseCI] flag.
+
More tests are implemented in Python, the code can be found in CADET-Verification
+
+
Compare the results with the previous run.
+The release process can only be continued if the results are reasonable.
+
+
Run performance benchmarks:
+
+
If numerical algorithms were refactored or if performance-critical infrastructure was changed, you should run performance benchmarks to compare the latest release with the planned new one.
+To this end, you can refer to the performance benchmark templates in CADET-Reference, e.g. the benchmark for the modified Newton method
+
+
+
Create a version bump commit, which will be the target commit for the release.
+The bump commit contains:
+
+
Update of the version number in the version.txt and in the zenodo.json
+
Update of the authors list if needed: CONTRIBUTING.md and zenodo.json
Add the version number according to the semantic versioning system as the tag and set the master branch as target.
+
Add release notes with these categories:
+
+
Added: New features, enhancements, or functionalities introduced in this release.
+
Fixed: Bug fixes and corrections made to resolve issues from previous versions.
+
Changed: Modifications to existing features and breaking changes for major releases including changes in the interface.
+
Updated: Improvements to documentation, minor tweaks, or other updates that don’t fit into the other categories.
+
+
+
Attach the (zipped) source code.
+
+
+
Check success of zenodo archiving:
+
+
Upon release, Zenodo automatically archives the release, generating a version-specific DOI (Digital Object Identifier) for it and storing a copy of the source code, along with any associated files.
+The concept DOI, which is also given in the repository README, does not change but represents the repository as a whole and always points to the latest version.
To ensure CADET-Core is accessible to a broad community, it is available as a Python package on conda-forge.
+Other software, such as our Python interface, CADET-Python, and the frontend, CADET-Process, import this package.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/chore/developer_guide/developer_guide/testing.html b/chore/developer_guide/developer_guide/testing.html
index 9dd77a796..dbabbe49b 100644
--- a/chore/developer_guide/developer_guide/testing.html
+++ b/chore/developer_guide/developer_guide/testing.html
@@ -16,7 +16,7 @@
-
+
@@ -59,12 +59,13 @@
Unit tests are designed to verify the correctness of individual units or components of code in isolation.
Unit tests in CADET-Core typically encompass tests for the Jacobian implementation and consistent initialization of the model, which can be adapted from corresponding existing tests.
-We generally recommend testing every of your model individually.
+Testing the Jacobian typically involves comparing the analytical Jacobian to the AD Jacobian to verify that the residual implementation is consistent to the analytical Jacobian.
+To this end, it might be necessary to increase the maximum number of AD directions for your test case, which can be done via the cmake argument NUM_MAX_AD_DIRS, as described in the CADET build options.
Every major feature of the model or numerical method should be tested in a separate test case, preferably recreating examples from literature, including your own publication on the corresponding CADET extension.
This section provides a guide on creating reference tests, including convergence tables and research data management (RDM).
We strongly emphasize that the procedure described here should be taken into consideration not just as part of the software testing but also for method/model validation, especially when a paper publication is planned.
To cite CADET please use the following publication:
+
The development of CADET has been a collaborative effort, with multiple dedicated individuals contributing their expertise to create a powerful and versatile open-source software tool.
+Countless hours of hard work have been invested to provide the scientific community with a valuable resource.
+As an open-source project, CADET relies on the support and recognition from users and researchers to thrive.
+Therefore, we kindly ask that any publications or projects leveraging the capabilities of CADET acknowledge its creators and their contributions by citing an adequate selection of our publications.
The Koren scheme implemented in CADET intrinsically uses a van Leer flux limiter. It can reach a maximum order of 2 depending on the smoothness of the solution. The
+BOUNDARY_MODEL is intrinsically set to 0 (stable).
The global structure (see Fig. 10) is divided into three parts: input, output, and meta.
-Every valid CADET file needs an input group (see Fig. 11) which contains all relevant information for simulating a model.
-It does not need an output (see Fig. 13) or meta (see Fig. 10) group, since those are created when results are written.
+
The global structure (see Fig. 11) is divided into three parts: input, output, and meta.
+Every valid CADET file needs an input group (see Fig. 12) which contains all relevant information for simulating a model.
+It does not need an output (see Fig. 14) or meta (see Fig. 11) group, since those are created when results are written.
Whereas the output group is solely used as output and holds the results of the simulation, the meta group is used for input and output.
Details such as file format version and simulator version are read from and written to the meta group.
If not explicitly stated otherwise, all datasets are mandatory.
@@ -124,25 +125,25 @@
Parameter-State Dependencies are not fully implemented yet.
+
PAR_SURFDIFFUSION_DEP
+
+
Parameter dependence of \(\texttt{PAR_SURFDIFFUSION}\) on the particle liquid salt component (i.e. component with index 0). Valid dependencies are:
+
+
\(\texttt{NONE}\) Original parameter is used unmodified.
+
\(\texttt{LIQUID_SALT_EXPONENTIAL}\) Original parameter is modified by exponential law of liquid phase salt concentration.
+
\(\texttt{LIQUID_SALT_POWER}\) Original parameter is modified by power law of liquid phase salt concentration.
+
\(\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}\) Original parameter is modified by colloidal binding affinity based on liquid phase salt concentration.
+
+
Optional: If left out, no parameter dependence is assumed and the original surface diffusion coefficients are used unmodified.
+
+
+
Type: string
+
Length:\(1 / \texttt{NPARTYPE}\)
+
+
+
+
+
PAR_SURFDIFFUSION_EXPFACTOR
+
+
Factor \(\texttt{p1}\) in exponential law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} exp \left(p_{2, i, m} c_{0}^{p} \right)\), where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient.
+Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_EXPONENTIAL}\).
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
PAR_SURFDIFFUSION_EXPFACTOR
+\(D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient and
+\(k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}\).
+Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}\).
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
+
PAR_SURFDIFFUSION_EXPARGMULT
+
+
Factor \(\texttt{p2}\) in exponential law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} exp \left(p_{2, i, m} c_{0}^{p} \right)\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient. Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_EXPONENTIAL}\).
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
+
PAR_SURFDIFFUSION_POWFACTOR
+
+
Factor \(\texttt{p1}\) in power law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} \left( c_{0}^{p} \right)^{p_{2, i, m}}\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient. Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_POWER}\).
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
+
PAR_SURFDIFFUSION_POWEXP
+
+
Fjactor \(\texttt{p2}\) in power law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} \left( c_{0}^{p} \right)^{p_{2, i, m}}\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient. Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_POWER}\).
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
+
PAR_SURFDIFFUSION_LOGKEQFACTOR
+
+
Factor \(\texttt{p1}\) in colloidal affinity law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient and
+\(k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}\).
+Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}\).
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
+
PAR_SURFDIFFUSION_LOGKEQEXP
+
+
Factor \(\texttt{p2}\) in colloidal affinity law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient and
+\(k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}\).
+Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}\).
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
+
PAR_SURFDIFFUSION_LOGKEQCONST
+
+
Factor \(\texttt{p3}\) in colloidal affinity law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient and
+\(k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}\).
+Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}\).
The PBM in CADET is implemented as part of the reaction module and can thus be used in any unit operation that includes reactions.
+Typical applications consider crystallization in a Continuous stirred tank reactor model or, to model continuous processes, in a Dispersive Plug-Flow Reactor (DPFR), which is modelled by a Lumped Rate Model Without Pores.
+
The particle size domain (internal coordinate) is discretized by the FV method, giving us a finite set of particle sizes under consideration \(\{x_1, \dots, x_{N_x}\}\).
+Every particle size considered is treated as an individual component of the unit operation and the field NCOMP of that unit operation in which the crystallization happens, must be specified accordingly as \(N_x + 2\).
+The two additional components account for the solute \(c\) and solubility \(c_\text{eq}\).
+That is, by setting the ``NCOMP`` field, you specify the number of FV cells for the internal coordinate.
+
Note that the first component must be solute \(c\) and the last component must be the solubility \(c_\text{eq}\).
Number of components, which is given by two plus the number discrete particle sizes, which is given by the number of FV cells discretizing the internal coordinate
+
+
+
Type: int
+
Range:\(\geq 3\)
+
Length: 1
+
+
+
+
+
REACTION_MODEL
+
+
The crystallization code is implemented as a reaction module, which is why crystallization needs to be specified here
+
+
+
Type: String
+
Range:\(\{ CRYSTALLIZATION \}\)
+
Length: 1
+
+
+
+
+
+
+
Group /input/model/unit_XXX/reaction_bulk - REACTION_MODEL = CRYSTALLIZATION - UNIT_TYPE = CSTR¶
+
The following parameters need to be specified under Group /input/model/unit_XXX/reaction/reaction_bulk/ for CSTR units, and Group /input/model/unit_XXX/reaction/reaction/ for transport units like the LRM.
+
CRY_BINS
+
+
Coordinates of the cell faces, e.g. equidistant or logarithmic discretization of the internal coordinate \(x \in [x_c, x_\text{end}]\), including the end points.
+
+
+
Type: double
+
Range:\(\geq 1\)
+
Length:\(\mathrm{N_x} + 1\)
+
+
+
+
+
CRY_NUCLEI_MASS_DENSITY
+
+
Nulcei mass density
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_VOL_SHAPE_FACTOR
+
+
Volumetric shape factor of the particles
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_PRIMARY_NUCLEATION_RATE
+
+
Primary nucleation rate constant \(k_p\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_SECONDARY_NUCLEATION_RATE
+
+
Secondary nucleation rate \(k_b\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_GROWTH_RATE_CONSTANT
+
+
Growth rate constant \(k_g\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_GROWTH_CONSTANT
+
+
Growth constant \(\gamma\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_A
+
+
Defines constant \(a\) used to determine the growth rate
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_G
+
+
Defines constant \(g\) used to determine the growth rate
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_P
+
+
Defines constant \(p\) used to determine the growth rate
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_GROWTH_DISPERSION_RATE
+
+
Growth dispersion rate \(D_g\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_U
+
+
Defines constant \(u\) used to determine the primary nucleation
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_B
+
+
Defines constant \(b\) used to determine the secondary nucleation
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_K
+
+
Defines constant \(k\) used to determine the secondary nucleation
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_GROWTH_SCHEME_ORDER
+
+
Defines the growth flux FV reconstruction scheme. It can only be \(1\): upwind scheme; \(2\): HR Koren scheme; \(3\): WENO23 scheme; \(4\): WENO35 scheme.
+We recommend using the HR Koren scheme, which showed to be the most performant in our benchmarks.
+
+
+
Type: int
+
Range:\([1, \dots, 4]\)
+
Length: 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/chore/developer_guide/interface/reaction/index.html b/chore/developer_guide/interface/reaction/index.html
index 647353fc1..20465d37d 100644
--- a/chore/developer_guide/interface/reaction/index.html
+++ b/chore/developer_guide/interface/reaction/index.html
@@ -17,7 +17,7 @@
-
+
@@ -52,14 +52,15 @@
Group /input/model/unit_XXX/discretization/SPATIAL_METHOD - Details on the methods¶
CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG).
While both methods approximate the same solution to the underlying models, they may differ in terms of computational performance.
-Generally, FV can be more performant for small problem sizes and solutions with steep gradients, while DG excels for large problem sizes and smooth solutions.
-
In the following, we give a brief introduction to the numerical theory that is most relevant for the computational performance of the methods.
-Based on that theory and our experience, we give advice on which method to use in which scenario, how to identify the more performant method, and how to specify the discretization parameters.
-For a comprehensive description on the FV and DG methods as they are implemented in CADET, we refer to our publications on CADET-FV and CADET-DG.
+Generally, FV can perform better for small problem sizes and solutions with steep gradients, while DG excels for large problem sizes and smooth solutions.
+
In the following, we give a brief introduction to the numerical theory w.r.t. the computational performance of the methods.
+Based on that theory and our experience, we give advice on which method to use in which scenario, how to identify the computationally best performing method, and how to specify discretization parameters.
+For a comprehensive description of the FV and DG variants that are implemented in CADET, we refer to our publications on CADET-FV and CADET-DG.
Numerical methods discretize the continuous (here: spatial) domain of the equations into a finite set of discrete points.
-Then, a system of equations is formulated for those points, and both system size and number of unknowns / degrees of freedom (DoF) are given by the number of discrete points.
-This system can be linear or non-linear, depending on the method (this will become important again in the section on smooth solutions).
-The wall clock time to compute the solution depends on the system size and, thus, on the number of discrete points.
-Conversely, the numerical solution is more accurate with more discrete points.
-Thus, we trade computation time for approximation accuracy by specifying the parameters that determine the number of discrete points.
-For the FV scheme, the number of axial discrete points in the column is given by the number of volume cells NCOL.
-For the DG scheme, the number of axial discrete points in the column is given by the number of polynomial interpolation nodes (= POLYDEG + 1) times the number of DG elements NELEM.
-The LRMP and GRM additionally consider particle equations that are also discretized.
-In the spatially discretized equations, a single particle is incorporated at each axial discrete point, which increases the total number of DOF per axial point, especially for the GRM where particles are fully resolved.
-The parameters for the GRM particle discretization are given for FV in NPAR and for DG in PAR_POLYDEG and PAR_NELEM.
+
FV and DG discretize the continuous spatial domain of the partial differential algebraic equations (PDAE) into a finite set of discrete points.
+Then, a system of (semi-discrete) equations is formulated on those points, resulting in a system of ordinary differential algebraic equations (ODAE).
+The system size and number of unknowns, are also referred to as degrees of freedom (DoF), is given by the number of (spatial) discrete points (times the number of components for multi-component systems).
+
The numerical solution becomes more accurate with more discrete points used, but the compute time required to solve the equations also increases.
+That is, we trade compute time for approximation accuracy.
+
For the FV method, the number of axial discrete points in the column is specified by the number of volume cells NCOL.
+For the DG method, the number of axial discrete points in the column is specified by the number of polynomial interpolation nodes (= POLYDEG + 1) times the number of DG elements NELEM.
+The GRM additionally comprises a transport equation along the radial coordinate of the particles which is also spatially discretized and the particle discrete points are correspondingly given by NPAR for FV and for DG via PAR_POLYDEG and PAR_NELEM.
The computational performance of a numerical method depends on its theoretical order of convergence.
-The order of convergence refers to the rate at which the method’s approximation approaches the exact solution under refinement of the spatial grid.
-
A higher-order method can be faster than a low-order method:
-Imagine a high- and a low-order method’s approximation to exhibit similarly bad approximation accuracy due to a coarse spatial resolution.
-Refining the grid for both methods by the same number of discrete points improves the approximation accuracy of the higher-order method more than the other one.
-Thus, the low-order method requires more DOFs and ultimately more compute time to compute a solution of the same accuracy.
-
The theoretical order of convergence is an asymptotic property, however.
+The order of convergence refers to the rate at which the numerical approximation approaches the exact solution under refinement of the spatial grid.
+Consequently, higher order methods often require less spatial discrete points to compute an approximation of the desired accuracy and can thus be computationally more efficient.
+
The theoretical order of convergence for the CADET-FV method is globally limited to 2.
+It is locally (except column boundaries) limited to 3, with an improved order of up to 5 for smooth solutions, and can be varied by specifying the parameters described in the Flux reconstruction methods section.
+For the CADET-DG method, the theoretical order of convergence is \(N_d + 1\) with \(N_d\) denoting the polynomial degree, and can thus be user-defined by specifying the field POLYDEG (and PAR_POLYDEG for the particles in the GRM).
+
The theoretical order of convergence is an asymptotic property, i.e. holds for infinite refinements, but can be numerivcally observed for finite refinements as well.
Having the exact solution, we can compute an experimental order of convergence (EOC) via the formula
with \(\varepsilon_{k}\) and \(n_{k}\) denoting some error norm and the degrees of freedom of the kth approximation.
+
with \(\varepsilon_{k}\) and \(n_{k}\) denoting some error norm and the degrees of freedom of the $k$th approximation.
The EOC approaches the theoretical order of convergence for \(k \rightarrow \infty\) but is typically lower for underresolved problems.
-High-order methods typically suffer from start-off problems, i.e. they typically won’t exhibit their high order until the grid is fine enough and a certain accuracy is already reached.
-That is, increasing the number of discrete points from, e.g., 2 to 4 typically does not improve the solution according to the theoretical order of convergence but by a much smaller EOC.
-The EOC is highly problem-dependent, and it is generally unknown when a high-order method will actually be faster than a lower-order method.
-Experience shows that higher-order methods work well for smooth solutions.
-
The theoretical order of convergence for the CADET-FV scheme is fixed at 2.
-For the CADET-DG scheme, it is \(N_d + 1\) with \(N_d\) denoting the polynomial degree, and can thus be user-defined by specifying the field POLYDEG (and PAR_POLYDEG for the GRM).
-As a convergence order of \(\gt 6\) is hardly realized within the approximation error of engineering tolerance (due to start-off problems), we recommend a maximum polynomial order of 5.
-As the FV scheme oftentimes yields an EOC of around 2.5 and is computationally more enhanced (less arithmetic operations per DOF and customized factorization) than the DG code, we recommend a polynomial degree of at least 3 to top this.
+High-order methods typically do typically not exhibit their theoretical order on very coarse grids.
+That is, increasing the number of discrete points from, e.g., 2 to 4 does often not improve the solution according to the theoretical order of convergence but by a much smaller EOC.
+
For smooth solutions, we typically observe an EOC of around 2.5 for the default CADET-FV method and around \(N_d\) for the CADET-DG method.
+To our experience, DG with \(N_d>6\) does usually not realize an EOC of \(>6\) for approximation errors within engineering tolerances, i.e. higher rates are achieved only for excessively small error tolerances that are not relevant for most applications.
+We thus recommend to choose \(3 \leq N_d \leq 5\) for the DG method.
+
One could still think that the higher the order of the method, the better the performance, but that is unfortunately not generally true, as the numerical solver performance can strongly depend on the smoothness of the approximated solution.
Smoothness in functions is characterized by the absence of sudden changes, reflected in the continuity and differentiability of the function and its derivatives.
+
The smoothness of a function indicates the absence of sudden changes, reflected in the continuity and differentiability of the function and its derivatives.
In numerical simulation, smoothness indicators are often based on derivatives or moments of the solution.
-That is, strong gradients and high frequencies are used to identify non-smooth parts of the solution.
+That is, the occurrence of strong gradients and high frequencies are used to identify non-smooth parts of the solution.
Godunov’s order barrier theorem shows why the concept of smoothness plays a crucial role in the deployment of numerical methods.
It states that linear high-order methods that are monotonous are at most first-order accurate.
Linear higher-order (\(\gt 1\)) methods thus suffer from artificial oscillations at non-smooth parts of the solution, specifically at discontinuities and strong gradients.
-Some higher-order methods, such as CADET-FV (2nd order), contain a non-linear mechanism to suppress these oscillations.
-The non-linear WENO mechanism employed in CADET-FV can be fine-tuned via the fields specified here Flux reconstruction methods.
-Unfortunately, non-linear higher-order methods (order \(\geq 3\)) are either not applicable (e.g., undefined boundary treatment) or have other shortcomings, such as more highly problem-dependent parameters.
-
CADET-DG is a linear high-order method (arbitrary order) and thus exhibits oscillatory behaviour at strong gradients, which increases the approximation error and results in a smaller EOC for lower resolutions.
-As strong gradients are a local phenomena that can be captured by employing more discrete points, DG becomes more performant again for higher resolutions.
+Some higher-order methods, such as the FV variants implemented in CADET, contain a non-linear mechanism to suppress these oscillations.
+The non-linear WENO mechanism employed in CADET-FV can be fine-tuned via the parameters specified in the Flux reconstruction methods section.
+Unfortunately, non-linear higher-order methods (here \(\geq 3\)) are either not applicable (e.g., undefined boundary treatment) or have other shortcomings, such as parameters whose optimal values can be highly proplem-specific.
+
The DG variant that is implemented in CADET is a linear high-order method (arbitrary order) and can thus exhibit oscillatory behaviour at strong gradients, which increases the approximation error and results in a smaller EOC for lower resolutions.
+Since strong gradients are local phenomena which can be captured by employing more discrete points, DG performs better again for higher spatial resolutions.
This, however, might happen after the engineering error tolerance is by far surpassed.
-Hence, CADET-FV as a stabilized lower-order method can be more performant, depending on the setting.
-The DG scheme reduces its oscillatory behaviour by adding artificial numerical dispersion at element interfaces.
-Thus, the use of a lower polynomial degree and more elements is recommended for rather non-smooth problems.
+Hence, CADET-FV as a stabilized lower-order method can perform better, depending on the smoothness of the approximated solution.
+The DG method reduces its oscillatory behaviour by adding artificial numerical dispersion at element interfaces.
+Thus, the use of a lower polynomial degree and more elements is recommended for non-smooth solutions.
In Chromatography, mathematical discontinuities never happen, as there are always some dispersive effects in reality.
Chromatography models, however, allow for discontinuities if dispersion parameters are set to zero.
-Moreover, steep and self-sharpening concentration fronts might appear due to binding.
-Binding models that might cause self-sharpening concentration fronts are often associated with competitive Langmuir type isotherms for components with differently strong binding properties.
-Nonetheless, a lot of chromatography settings yield rather smooth concentration profiles, for which DG is the better choice in terms of computational performance.
+Moreover, steep and self-sharpening concentration fronts might appear due to competitive adsorption.
+Examples that can cause self-sharpening concentration fronts are often associated with competitive Langmuir type isotherms for components with differently strong binding properties.
+Nonetheless, many chromatography settings yield rather smooth concentration profiles, for which DG is the better choice in terms of computational performance.
Recommendations on the choice of spatial discretization methods¶
We recommend the FV method for
Small problem sizes, e.g., low spatial resolution with the LRM
-
Problems with strong gradients, e.g., no or low dispersion and bindings that create sharp fronts
-
Bindings that mathematically require positive values or exhibit strange behaviour with negative concentration values
+
Problems with strong gradients, e.g., no or low dispersion and binding model parameters that create sharp fronts
+
Binding models that mathematically require positive values or exhibit strange behaviour with negative concentration values
We recommend the DG method for
-
Large problem sizes, e.g., high resolutions and more complex models (i.e. the LRMP and specifically the GRM)
-
Smooth problems, e.g., sufficient dispersion
+
Large problem sizes, e.g., high spatial resolutions and more complex models (i.e. the LRMP and specifically the GRM)
Select a lower axial polynomial degree for non smooth tendency and employ more elements instead. Converse choice for smooth problems
-
Adjust the DG particle polynomial degree to control approximation accuracy; leave the number of elements at one. Make exceptions if very steep gradients occur inside the particles or when specific parts of the particle domain are more interesting (here, you can resolve more interesting parts by a user-defined spacing of multiple elements)
-
The field EXACT_INTEGRATION specifies the DG polynomial integration method. The default value of 0 (collocation DG) is expected to be slightly more performant in most settings
+
Select a lower axial polynomial degree for approximating functions that tend to be less smooth and employ more elements instead. Converse choice for smooth problems
+
Adjust the DG particle polynomial degree to control approximation accuracy; leave the number of elements at one. Make exceptions if very steep gradients occur inside the particles or when specific regions of the particle domain are more interesting (the spatial resolution of certain regions can be refined by a user-defined spacing of multiple elements)
+
The field EXACT_INTEGRATION specifies the DG polynomial integration method. The default value of $0$ (collocation DG) is expected to be slightly more performant in most settings
A common problem in numerical simulation is that the number of discrete points required to yield an accurate approximation within a specific tolerance is unknown.
We thus recommend determining the approximation error via comparison with a refined reference approximation.
-Both the theoretical order of convergence and the EOC can be used to estimate the required number of discrete points.
+Both the theoretical order of convergence and the EOC can be used to estimate the required number of discrete points.
+An EOC that is significantly lower than the theoretical order indicates that the problem is numerically underresolved.
CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Only the input fields for the chosen method need to be specified.
+
CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Each method has it’s own set of input fields.
While both methods approximate the same solution to the same underlying model, they may differ in terms of computational performance.
-Generally, FV is more performant for solutions with steep gradients or discontinuities, while DG excels for rather smooth solutions.
-We note that DG is only faster in the sense that less spatial discrete points are required to achieve the same accuracy as FV. For the same number of discrete points, DG will be slower, but more accurate.
-For further information on the choice of discretization methods and their parameters, see Spatial discretization methods.
+With our currently implemented variants of FV and DG, FV perform better for solutions with steep gradients or discontinuities, while DG can be much faster for rather smooth solutions.
+For the same number of discrete points, DG will generally be slower but often more accurate.
+
For further information on the choice of discretization methods and their parameters, see Spatial discretization methods.
SPATIAL_METHOD
Spatial discretization method. Optional, defaults to \(\texttt{FV}\)
CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Only the input fields for the chosen method need to be specified.
+
CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Each method has it’s own set of input fields.
While both methods approximate the same solution to the same underlying model, they may differ in terms of computational performance.
-Generally, FV is more performant for solutions with steep gradients or discontinuities, while DG excels for rather smooth solutions.
-We note that DG is only faster in the sense that less spatial discrete points are required to achieve the same accuracy as FV. For the same number of discrete points, DG will be slower, but more accurate.
-For further information on the choice of discretization methods and their parameters, see Spatial discretization methods.
+With our currently implemented variants of FV and DG, FV perform better for solutions with steep gradients or discontinuities, while DG can be much faster for rather smooth solutions.
+For the same number of discrete points, DG will generally be slower but often more accurate.
+
For further information on the choice of discretization methods and their parameters, see Spatial discretization methods.
SPATIAL_METHOD
Spatial discretization method. Optional, defaults to \(\texttt{FV}\)
CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Only the input fields for the chosen method need to be specified.
+
CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Each method has it’s own set of input fields.
While both methods approximate the same solution to the same underlying model, they may differ in terms of computational performance.
-Generally, FV is more performant for solutions with steep gradients or discontinuities, while DG excels for rather smooth solutions.
-We note that DG is only faster in the sense that less spatial discrete points are required to achieve the same accuracy as FV. For the same number of discrete points, DG will be slower, but more accurate.
-For further information on the choice of discretization methods and their parameters, see Spatial discretization methods.
+With our currently implemented variants of FV and DG, FV perform better for solutions with steep gradients or discontinuities, while DG can be much faster for rather smooth solutions.
+For the same number of discrete points, DG will generally be slower but often more accurate.
+
For further information on the choice of discretization methods and their parameters, see Spatial discretization methods.
SPATIAL_METHOD
Spatial discretization method. Optional, defaults to \(\texttt{FV}\)
No interaction between the components is considered when the model has multiple components.
One of the limitation of this isotherm is the first order Jacobian \(\left(\frac{dq^*}{dc_p}\right)\) tends to infinity as \(c_{p} \rightarrow 0\) for \(n>1\).
To address this issue an approximation of isotherm is considered near the origin.
-This approximation matches the isotherm in such a way that \(q=0\) at \(c_p=0\) and also matches the first derivative of the istotherm at \(c_p = \epsilon\), where \(\epsilon\) is a very small number, for example \(1e-14\).
+This approximation matches the isotherm in such a way that \(q=0\) at \(c_p=0\) and also matches the first derivative of the istotherm at \(c_p = \varepsilon\), where \(\varepsilon\) is a very small number, for example \(1e-14\).
The form of approximation and its derivative is given below for \(c_p < \varepsilon\) and \(n>1\):
This approximation can be used for any pore phase cocentration \(c_p < \epsilon\) given \(n>1\).
+
This approximation can be used for any pore phase cocentration \(c_p < \varepsilon\) given \(n>1\).
For the case, when \(n \le 1\) no special treament near the origin is required.
For more information on model parameters required to define in CADET file format, see Freundlich LDF.
The population balance model (PBM) is given by a particle-number continuity equation which describes the evolution of the number density \(n\) of the particles over time \(t\) and with respect to a so-called internal coordinate \(x\) and external coordinate \(z\).
+The internal coordinate can be chosen as any characteristic property of the particles such as the particle size or volume.
+The external coordinate can be a characteristic dimension of the reactor itself, including its axial length.
+
In CADET, we chose particle size and axial coordinate as the internal and external coodinate respectively.
+The PBM in CADET is implemented so that it can be used in any unit operation that supports reactions.
+Typical applications consider crystallization in a CSTR or, to model continuous processes, in a Dispersive Plug-Flow Reactor (DPFR), which is described by the LRM without solid phase.
+
In the following, we give a brief overview on the modelling equations, for more information on the PBM as implemented in CADET, please refer to [24].
+
+
+
+
Fig. 8 Nucleation, growth and growth rate dispersion in PBM. Note that dispersion is used to model (random) variance in growth speed, not the reduction of particle size, which is feasible for a convection dominated process.¶
We assume a well-mixed tank and choose the particle size \(x\in (x_c, \infty)\) as the internal coodinate, with \(x_c>0\) being the minimal particle size considered.
+The corresponding PBM is given as
where \(F_{in}, F_{out}\in \mathbb{R}^+\) are the volumetric inflow and outflow rates, \(V\in\mathbb{R}^+\) is the reactor volume,
+\(n(t, x)\colon [0, T_\text{end}] \times (x_c, \infty) \mapsto \mathbb{R}^+\) is the number density distribution,
+\(n_{in}\in\mathbb{R}^+\) is the number density distribution of the inlet feed, \(v_{G}\in\mathbb{R}^+\) is the particle growth rate,
+\(D_g\in\mathbb{R}^+\) is the growth dispersion rate.
+
The boundary conditions are given by the regularity boundary condition
where \(c(t)\colon [0, T_\text{end}] \mapsto \mathbb{R}^+\) is the solute concentration in the bulk phase, \(c_{in}\in\mathbb{R}^+\) is the inlet solute mass concentration, \(\rho > 0\) is the nuclei mass density and \(k_v > 0\) is the volumetric shape factor of the particles.
The PBM can also be formulated for a DPFR to model continuous processes.
+That is, we choose the axial position within a DPFR as the external coordinate \(z\in[0, L]\) and formulate the \(2D\) PBM
where \(n(t, x, z)\colon [0, T_\text{end}] \times (x_c, \infty) \times [0, L] \mapsto \mathbb{R}^+\) is the number density distribution,
+\(v_\text{ax}\in\mathbb{R}^+\) is the axial velocity and \(D_{ax}\in\mathbb{R}^+\) is the axial dispersion coefficient.
+
Boundary conditions for the internal coordinate are again given by Eq. 27 and Eq. 28.
+
For the external coordinate \(z\), Danckwerts boundary conditions are applied:
Which are in turn defined by the following constitutive equations.
+An empirical equation for primary nucleation is given by:
+
+\[\begin{aligned}
+ B_p=k_ps^u,
+\end{aligned}\]
+
where \(k_p\in\mathbb{R}^+\) is the primary nucleation rate constant and \(u\in\mathbb{R}^+\) is a constant.
+An empirical power-law expression is used for the secondary nucleation:
where \(k_b\in\mathbb{R}^+\) is the secondary nucleation rate constant, \(b\in\mathbb{R}^+\) and \(k\in\mathbb{R}^+\) are system-related parameters and \(M\in\mathbb{R}^+\) is the suspension density defined as
where \(k_g\in\mathbb{R}^+\) is the growth rate constant, \(\gamma\in\mathbb{R}^+\) quantifies the size dependence, and \(g, a, p\in\mathbb{R}^+\) are system-related constants.
+
For information on model parameters and how to specify the model interface, see Population balance model.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/chore/developer_guide/modelling/equations.html b/chore/developer_guide/modelling/equations.html
index ecd5dd2d6..441dd0633 100644
--- a/chore/developer_guide/modelling/equations.html
+++ b/chore/developer_guide/modelling/equations.html
@@ -49,7 +49,7 @@
The network of unit operations uses “connection”-variables \(c_{\text{con}}\) to connect the different unit operation ports with each other.
The inlet port variables \(c_{\text{in},n,k}\) of unit operation \(n\) are attached to \(c_{\text{con},n}\) via
-(22)¶\[\begin{aligned}
+(25)¶\[\begin{aligned}
c_{\text{in},n,k,i} &= c_{\text{con},n,k,i}, \qquad k = 1, \dots, N_{\text{port},\text{in},n},\quad i = 1, \dots, N_{\text{comp},n}.
\end{aligned}\]
While \(N_{\text{port},\text{in},n}\) denotes the number of inlet ports of unit operation \(n\), the number of outlet ports is given by \(N_{\text{port},\text{out},n}\).
The connection variables \(c_{\text{con},n,k,i}\) collect all inflows of component \(i\) into port \(k\) of unit operation \(n\):
where \(F_{m,\ell}\) denotes the volumetric flow rate from outlet port \(\ell\) of unit operation \(m\), \(S_{(n,k,i),(m,\ell,j)} \in \{0, 1\}\) is a connection matrix indicating whether component \(i\) at outlet port \(k\) of unit operation \(n\) is connected to component \(j\) at inlet port \(\ell\) of unit operation \(m\), and \(\hat{S}_{(n,k),(m,\ell)} \in \{0, 1\}\) is another connection matrix indicating whether outlet port \(k\) of unit operation \(n\) is connected to inlet port \(\ell\) of unit operation \(m\), that is
where \(t_s\) is the beginning of the time section that triggers the valve switch.
-
Note that the denominator in Eq. 23 must always be positive.
+
Note that the denominator in Eq. 26 must always be positive.
That is, the flow rate coefficients have to be chosen such that the flow into every connected inlet port is strictly positive at all times.
Each time step in the simulation requires the solution of a nonlinear system Eq. 24 (see Sec. Time stepping).
-The nonlinear problem is solved by a Newton iteration, which, in turn, requires the solution of a linear system that essentially consists of the Jacobians of the unit operations and some coupling matrices from Eqs. 22 and 23.
+
Each time step in the simulation requires the solution of a nonlinear system Eq. 29 (see Sec. Time stepping).
+The nonlinear problem is solved by a Newton iteration, which, in turn, requires the solution of a linear system that essentially consists of the Jacobians of the unit operations and some coupling matrices from Eqs. 25 and 26.
These linear systems are either solved in parallel or sequentially. The parallel method first solves each unit operation (in parallel) to compute the solution at its outlet.
Using these values, the inlets are adjusted and the unit operations are solved again.
This is iterated until the system is fully solved.
However, due to packing irregularity and inhomogeneous flow at the inlet (i.e., frits), this assumption may be a crude approximation.
This model can be improved by introducing a radial coordinate \(\rho \in [0, R]\), where \(R\) is the column radius, in the interstitial volume Eq. 1:
For simplicity, it is assumed that the parameters are piecewise constant, that is, the range \([0, R]\) is divided into disjoint zones in which all parameters are constant.
These zones are used for radial discretization and can be supplied to the simulator.
Continuous dependence of the parameters can be realized by piecewise constant approximation.
-
The Danckwerts boundary conditions at the column in- and outlet, Eq. 12 and 11, are modified to account for the radial coordinate:
+
The Danckwerts boundary conditions at the column in- and outlet, Eq. 3 and 2, are modified to account for the radial coordinate:
While the inner condition Eq.19 represents symmetry at the column center, the outer condition Eq. 20 is a no-flux condition.
-
Using the inlet boundary condition Eq. 17, each radial zone is equipped with its own inlet and outlet port.
+
While the inner condition Eq.22 represents symmetry at the column center, the outer condition Eq. 23 is a no-flux condition.
+
Using the inlet boundary condition Eq. 20, each radial zone is equipped with its own inlet and outlet port.
That is, this unit operation has as many inlet and outlet ports as it has radial zones (parameter NRAD in the discretization group).
This allows each radial zone to have its own inlet profile, which enables modeling of flow distribution in the frits by sending the feed through varying hold-up volumes before injecting it into a radial zone.
Here, \(c^\ell_i\colon \left[0, T_{\text{end}}\right] \times [0, L] \rightarrow \mathbb{R}^{\geq 0}\) denotes the concentration in the interstitial column volume, \(c^p_{j,i}\colon \left[0, T_{\text{end}}\right] \times [0, L] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}\) the liquid phase concentration in the beads, \(k_{f,j,i}\) the film diffusion coefficient, \(D_{\text{ax},i}\) the dispersion coefficient, \(u\) the interstitial velocity, \(d_j\) the volume fraction of particle type \(j\), and \(\beta_c = \varepsilon_c / (1 - \varepsilon_c)\) the column phase ratio, where \(\varepsilon_c\) is the column porosity (ratio of interstitial volume to total column volume).
+
Here, \(c^\ell_i\colon \left[0, T_{\text{end}}\right] \times [0, L] \rightarrow \mathbb{R}^{\geq 0}\) denotes the concentration in the interstitial column volume, \(c^p_{j,i}\colon \left[0, T_{\text{end}}\right] \times [0, L] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}\) the liquid phase concentration in the beads, \(k_{f,j,i}\geq 0\) the film diffusion coefficient, \(D_{\text{ax},i}\geq 0\) the dispersion coefficient, \(u\in\mathbb{R}\) the interstitial velocity, \(d_j > 0\) the volume fraction of particle type \(j\), and \(\frac{1}{\beta_c} = (1 - \varepsilon_c) / \varepsilon_c\) the column phase ratio, where \(\varepsilon_c\in (0,1]\) is the column porosity (ratio of interstitial volume to total column volume).
If reactions are considered, the term \(f_{\text{react},i}^\ell\left(c^\ell\right)\) represents the net change of concentration \(c_i\) due to reactions involving component \(i\).
Danckwerts boundary conditions [8] are applied to inlet and outlet of the column:
-(11)¶\[\begin{aligned}
+(2)¶\[\begin{aligned}
u c_{\text{in},i}(t) &= u c^\ell_i(t,0) - D_{\text{ax},i} \frac{\partial c^\ell_i}{\partial z}(t, 0) & \forall t > 0,
\end{aligned}\]
where \(c^s_{j,i,m_{j,i}}\colon \left[0, T_{\text{end}}\right] \times [0,L] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}\) denotes the solid phase concentration of the \(i\)th component’s \(m_{j,i}\)th bound state in the beads of \(j\)th type, \(D_{p,j,i}\) the effective diffusion coefficient in the beads, \(D_{s,j,i}\) the surface diffusion coefficient, \(F_{\text{acc},j,i} \in [0,1]\) the pore accessibility factor, and \(\varepsilon_{p,j}\) the particle porosity (ratio of pore volume to total bead volume).
+
where \(c^s_{j,i,m_{j,i}}\colon \left[0, T_{\text{end}}\right] \times [0,L] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}\) denotes the solid phase concentration of the \(i\)th component’s \(m_{j,i}\)th bound state in the beads of \(j\)th type, \(D_{p,j,i}>0\) the effective diffusion coefficient in the beads, \(D_{s,j,i}\geq 0\) the surface diffusion coefficient, \(F_{\text{acc},j,i}\geq 0 \in [0,1]\) the pore accessibility factor, and \(\varepsilon_{p,j}\in (0,1]\) the particle porosity (ratio of pore volume to total bead volume).
The inner bead radius \(r_{c,j} \in [0, r_{p,j})\) is assumed to be \(0\) by default, but can be positive in order to account for core-shell particles that have an impermeable core.
Reaction terms in liquid and solid phase are collected in \(f_{\text{react},j,i}^p( c_j^p, c_j^s)\) and \(f_{\text{react},j,i}^s(c_j^p, c_j^s)\), respectively.
The GRM is used with both quasi-stationary (Eq. 5) and dynamic (Eq. 6) binding models.
@@ -347,7 +349,7 @@
Branches
The radial flow GRM describes transport of solute molecules through the interstitial column volume by radial convective flow, band broadening caused by radial dispersion, mass transfer resistance through a stagnant film around the beads, pore (and surface) diffusion in the porous beads [5, 6, 7], and adsorption to the inner bead surfaces.
The main assumptions are:
-
The shells of the column are homogenous in terms of interstitial volume, fluid flow, and distribution of components.
+
The cylindrical shells of the column are homogenous in terms of interstitial volume, fluid flow, and distribution of components.
Thus, only one spatial coordinate in radial direction \(\rho\) is needed and axial transport is neglected in the column bulk volume.
The bead radii \(r_{p}\) are much smaller than the column radius \(\mathrm{P}-\mathrm{P}_c\), with \(\mathrm{P}\) and \(\mathrm{P}_c\) being the inner and outer column radius respectively, and the column length \(L\).
Therefore, the beads can be seen as continuously distributed inside the column (i.e., at each point there is interstitial and bead volume).
@@ -355,23 +357,23 @@
Branches
That is, the volumetric flow rate at the inner and outer column radius are the same.
Consider a hollow (double walled) column with inner column diameter \(\mathrm{P}_c>0\) and outer diameter \(\mathrm{P}>\mathrm{P}_c\), filled with spherical beads of (possibly) multiple types with radius \(r_{p,j} \ll L\) (see Fig. 2), where \(j\) is the particle type index. The mass balance in the interstitial column volume is described by
Here, \(c^\ell_i\colon \left[0, T_{\text{end}}\right] \times [\mathrm{P}_c, \mathrm{P}] \rightarrow \mathbb{R}^{\geq 0}\) denotes the concentration in the interstitial column volume, \(c^p_{j,i}\colon \left[0, T_{\text{end}}\right] \times [P_c, P] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}\) the liquid phase concentration in the beads, \(k_{f,j,i}\) the film diffusion coefficient, \(D_{\text{rad},i}\) the dispersion coefficient, \(u\) the interstitial velocity, \(d_j\) the volume fraction of particle type \(j\), and \(\beta_c = \varepsilon_c / (1 - \varepsilon_c)\) the column phase ratio, where \(\varepsilon_c\) is the column porosity (ratio of interstitial volume to total column volume).
+
Here, \(c^\ell_i\colon \left[0, T_{\text{end}}\right] \times [\mathrm{P}_c, \mathrm{P}] \rightarrow \mathbb{R}^{\geq 0}\) denotes the concentration in the interstitial column volume, \(c^p_{j,i}\colon \left[0, T_{\text{end}}\right] \times [P_c, P] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}\) the liquid phase concentration in the beads, \(k_{f,j,i}\geq 0\) the film diffusion coefficient, \(D_{\text{rad},i}\geq 0\) the dispersion coefficient, \(u>0\) the interstitial velocity, \(d_j>0\) the volume fraction of particle type \(j\), and \(\beta_c = \varepsilon_c / (1 - \varepsilon_c)\) the column phase ratio, where \(\varepsilon_c\in(0,1)\) is the column porosity (ratio of interstitial volume to total column volume).
If reactions are considered, the term \(f_{\text{react},i}^\ell\left(c^\ell\right)\) represents the net change of concentration \(c_i\) due to reactions involving component \(i\).
Danckwerts boundary conditions [8] are applied to inlet and outlet of the column:
Note that the outlet boundary condition Eq. 11 is also known as “do nothing” or natural outflow condition.
+
Note that the outlet boundary condition Eq. 11 is also known as “do nothing” or natural outflow condition.
The complementing mass transport and binding equations for the liquid and solid phases of the porous beads are described by the same equations as for the axial GRM.
Moreover, the pseudo unit operations Inlet, and Outlet act as sources and sinks for the system.
diff --git a/chore/developer_guide/modelling/unit_operations/inlet.html b/chore/developer_guide/modelling/unit_operations/inlet.html
index 88811f481..940a9cc9b 100644
--- a/chore/developer_guide/modelling/unit_operations/inlet.html
+++ b/chore/developer_guide/modelling/unit_operations/inlet.html
@@ -59,6 +59,7 @@
The lumped rate model with pores [3, 4] deviates from the general rate model (see Section General rate model (GRM)) by neglecting pore diffusion.
The particle phase \(c^p_j\) is still there, but no mass transfer happens except for binding and film diffusion.
Hence, the model equations are given by
The same model equations arise in describing other biological and technical processes outside of the field of plant sciences, where solutes are transported and exchanged between spatially separated compartments, for example liquid-liquid chromatography (LLC). Here, components in a mixture are separated based on their interactions with two immiscible phases of a biphasic solvent system [10]. The MCT model represents these phases by channels with respective transport and exchange properties. While the current implementation only covers linear driving forces for the exchange processes, the reaction module in CADET allows to add non-linear driving forces for the exchange processes and other chemical reactions in the channels.
The MCT model equations are given for all channels \(l \in \{1, \dots, N_k\}\) and components \(i \in \{1, \dots, N_c\}\) by
+
+
+ You're reading the documentation for a development version.
+ For the latest released version, please have a look at v5.0.0.
+
+
+
+
+
+
General CADET-Core:
+
+
Leweke, S.; von Lieres, E.: ChromatographyAnalysisandDesignToolkit(CADET)<https://doi.org/10.1016/j.compchemeng.2018.02.025>_, Computers and Chemical Engineering 113 (2018), 274?294.
+
von Lieres, E.; Andersson, J.: Afastandaccuratesolverforthegeneralratemodelofcolumnliquidchromatography<https://doi.org/10.1016/j.compchemeng.2010.03.008>_, Computers and Chemical Engineering 34,8 (2010), 1180?1191.
+
+
CADET-Core numerics:
+
+
Breuer, J. M.; Leweke, S.; Schm?lder, J.; Gassner, G.; von Lieres, E.: SpatialdiscontinuousGalerkinspectralelementmethodforafamilyofchromatographymodelsinCADET<https://doi.org/10.1016/j.compchemeng.2023.108340>_, Computers and Chemical Engineering 177 (2023), 108340.
+
Leweke, S.; von Lieres, E.: Fastarbitraryordermomentsandarbitraryprecisionsolutionofthegeneralratemodelofcolumnliquidchromatographywithlinearisotherm<http://dx.doi.org/10.1016/j.compchemeng.2015.09.009>_, Computers and Chemical Engineering 84 (2016), 350?362.
+
P?ttmann, A.; Schnittert, S.; Naumann, U.; von Lieres, E.: Fastandaccurateparametersensitivitiesforthegeneralratemodelofcolumnliquidchromatography<http://dx.doi.org/10.1016/j.compchemeng.2013.04.021>_, Computers and Chemical Engineering 56 (2013), 46?57.
+
+
Selected applications and use-cases of CADET-Core:
+
+
Heymann, W.; Glaser, J.; Schlegel, F.; Johnson, W.; Rolandi, P.; von Lieres, E.: Advancedscoresystemandautomatedsearchstrategiesforparameterestimationinmechanisticchromatographymodeling<https://doi.org/10.1016/j.chroma.2021.462693>_, Journal of Chromatography A 1661 (2022): 462693.
+
He, Q.-L.; Leweke, S.; von Lieres, E.: Efficientnumericalsimulationofsimulatedmovingbedchromatographywithasingle-columnsolver<http://doi.org/10.1016/j.compchemeng.2017.12.022>_, Computers and Chemical Engineering 111 (2018), 183?198.
This chapter gives an overview of the simulation process and the different steps involved.
-
CADET uses a backward-differentiation-formula (BDF) time discretization as implemented by the IDAS solver from SUNDIALS [24].
+
CADET uses a backward-differentiation-formula (BDF) time discretization as implemented by the IDAS solver from SUNDIALS [25].
Each time step requires the solution of a nonlinear algebraic system of equations is performed by a Newton method.
Since chromatographic systems can exhibit strong nonlinearity and stiff systems, the Jacobian of the equation system is always updated (i.e., an “exact” Newton method is used).
Time sections are used for various purposes, for example, for defining piecewise polynomials used as inlet profiles or external function, for changing operating conditions such as flow rates, or for changing the connectivity in a network of unit operations.
-A sequence of (one or more) time sections with smooth transitions is called a time slice (see Fig. 9).
+A sequence of (one or more) time sections with smooth transitions is called a time slice (see Fig. 10).
A transition from one section to the next can either be smooth or discontinuous.
On smooth transitions, the time integrator can just step over the section transition.
Contrary to smooth transitions, a discontinuous transition requires some extra work in resetting the time integrator and finding consistent initial conditions for the next time slice.
-
Fig. 9 Time sections, time slices, and transitions between them¶
+
Fig. 10 Time sections, time slices, and transitions between them¶
@@ -206,7 +207,7 @@
Branches
The IDAS time integrator adaptively changes the step size \({\Delta t_\tau = t_\tau-t_{\tau-1}}\) and order \(1 \le q_{\tau} \le 5\) in each time step and automatically determines the corresponding coefficients \(\alpha_{\tau,i}\).
This ansatz is inserted into the DAE and the resulting nonlinear algebraic equation system is solved for \(y_{\tau} = y\left( t_\tau \right)\) using a Newton method.
The BDF order \(q_{\tau}\) and size of the time step \(t_\tau\) are chosen such that the error bounds are satisfied with minimal work.
-Equation 24 is solved with a Newton iteration using very few iterations (MAX_NEWTON_ITER from Table Group /solver/time_integrator) since the starting point is assumed to be close to the solution as the time steps are small.
+Equation 29 is solved with a Newton iteration using very few iterations (MAX_NEWTON_ITER from Table Group /solver/time_integrator) since the starting point is assumed to be close to the solution as the time steps are small.
If the solution of the Newton iteration does not pass the convergence test, the step size \(t_\tau\) is reduced and the Newton iteration is tried again.
This may happen at most MAX_CONVTEST_FAIL times, otherwise time integration is aborted with failure.
Having a solution of the Newton iteration at hand, a local truncation error test is performed which controls the error of the BDF method.
-If this test fails, step size \(t_\tau\) and order \(q_{\tau}\) are adapted and the process restarts with solving the nonlinear system Eq. 24.
+If this test fails, step size \(t_\tau\) and order \(q_{\tau}\) are adapted and the process restarts with solving the nonlinear system Eq. 29.
The error test may be failed at most MAX_ERRTEST_FAIL times before time integration is aborted with failure.
Error bounds for the local truncation error test are specified by an absolute tolerance (ABSTOL) and a relative tolerance (RELTOL).
Note that the relative tolerance only works for non-zero values, whereas zero values are accounted for by the absolute tolerance.
@@ -255,15 +256,15 @@
Branches
&= \frac{\partial F}{\partial y}(t, y, \dot{y}, p) s + \frac{\partial F}{\partial \dot{y}}(t, y, \dot{y}, p) \dot{s} + \frac{\partial F}{\partial p}(t, y, \dot{y}, p).
\end{aligned}\end{split}\]
These linear DAEs depend on the solution \(y\), \(\dot{y}\) of the original DAE system.
-Consequently, the sensitivity systems are solved together with the original DAE system in a staggered approach [25].
-
After the nonlinear Eq. 24 has been successfully solved using Newton iteration (i.e., it has passed the convergence test), each sensitivity is solved using the same Newton iteration.
+Consequently, the sensitivity systems are solved together with the original DAE system in a staggered approach [26].
+
After the nonlinear Eq. 29 has been successfully solved using Newton iteration (i.e., it has passed the convergence test), each sensitivity is solved using the same Newton iteration.
If direct linear solvers were used, this iteration would convergence with a single iteration as there is no nonlinearity.
The Newton method for the sensitivities performs at most MAX_NEWTON_ITER_SENS (see Table Group /solver/time_integrator) iterations.
Assuming the convergence test has passed for each sensitivity, the local truncation error test is performed for the full set of variables (i.e., original system and sensitivities).
The sensitivities can be excluded from the local truncation error test by setting ERRORTEST_SENS appropriately.
Note that time integration step size is always affected by sensitivities due to possible convergence test failures.
While the Jacobians \(\partial F / \partial y\) and \(\partial F / \partial \dot{y}\) can be computed either analytically or via AD, the last term \(\partial F / \partial p\) is always computed by AD.
-In fact, the terms \(\partial F / \partial y\) and \(\partial F / \partial p\) can be computed by one AD-enabled evaluation of \(F\) using the vector mode with appropriate seed vectors [26].
+In fact, the terms \(\partial F / \partial y\) and \(\partial F / \partial p\) can be computed by one AD-enabled evaluation of \(F\) using the vector mode with appropriate seed vectors [27].
A parameter sensitivity is specified by identifying the involved parameters, which can be more than one (see below).
Parameters are identified by name and multiple indices, which may not all be used (see Tab. Group /input/sensitivity/param_XXX). Indices that are not used for identification (e.g., flow rate is independent of bound phase or component) are set to \(-1\). All other indices are zero-based.
Note that the sensitivity systems need to be consistently initialized, too.
diff --git a/chore/developer_guide/sitemap.xml b/chore/developer_guide/sitemap.xml
index 4538b8b50..0a3283052 100644
--- a/chore/developer_guide/sitemap.xml
+++ b/chore/developer_guide/sitemap.xml
@@ -1,2 +1,2 @@
-https://cadet.github.io/master/en/README.htmlhttps://cadet.github.io/master/en/developer_guide/build_options.htmlhttps://cadet.github.io/master/en/developer_guide/cadet_core_architecture.htmlhttps://cadet.github.io/master/en/developer_guide/cadet_python.htmlhttps://cadet.github.io/master/en/developer_guide/debugging.htmlhttps://cadet.github.io/master/en/developer_guide/index.htmlhttps://cadet.github.io/master/en/developer_guide/model_expansion.htmlhttps://cadet.github.io/master/en/developer_guide/testing.htmlhttps://cadet.github.io/master/en/examples/batch_chromatography.htmlhttps://cadet.github.io/master/en/examples/index.htmlhttps://cadet.github.io/master/en/examples/load_wash_elute.htmlhttps://cadet.github.io/master/en/examples/reaction_cstr.htmlhttps://cadet.github.io/master/en/examples/rtd.htmlhttps://cadet.github.io/master/en/getting_started/build_linux.htmlhttps://cadet.github.io/master/en/getting_started/build_osx.htmlhttps://cadet.github.io/master/en/getting_started/build_windows.htmlhttps://cadet.github.io/master/en/getting_started/index.htmlhttps://cadet.github.io/master/en/getting_started/installation.htmlhttps://cadet.github.io/master/en/getting_started/tutorials/breakthrough.htmlhttps://cadet.github.io/master/en/index.htmlhttps://cadet.github.io/master/en/interface/binding/bi_steric_mass_action.htmlhttps://cadet.github.io/master/en/interface/binding/extended_mobile_phase_modulator_langmuir.htmlhttps://cadet.github.io/master/en/interface/binding/freundlich_ldf.htmlhttps://cadet.github.io/master/en/interface/binding/generalized_ion_exchange.htmlhttps://cadet.github.io/master/en/interface/binding/hic_constant_water_activity.htmlhttps://cadet.github.io/master/en/interface/binding/hic_water_on_hydrophobic_surfaces.htmlhttps://cadet.github.io/master/en/interface/binding/index.htmlhttps://cadet.github.io/master/en/interface/binding/linear.htmlhttps://cadet.github.io/master/en/interface/binding/mobile_phase_modulator_langmuir.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_anti_langmuir.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_bi_langmuir.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_bi_langmuir_ldf.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_colloidal.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_langmuir.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_langmuir_ldf.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_langmuir_ldf_liquid_phase.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_spreading.htmlhttps://cadet.github.io/master/en/interface/binding/multi_state_steric_mass_action.htmlhttps://cadet.github.io/master/en/interface/binding/saska.htmlhttps://cadet.github.io/master/en/interface/binding/self_association.htmlhttps://cadet.github.io/master/en/interface/binding/simplified_multi_state_steric_mass_action.htmlhttps://cadet.github.io/master/en/interface/binding/steric_mass_action.htmlhttps://cadet.github.io/master/en/interface/consistent_initialization.htmlhttps://cadet.github.io/master/en/interface/flux_reconstruction.htmlhttps://cadet.github.io/master/en/interface/index.htmlhttps://cadet.github.io/master/en/interface/input_group.htmlhttps://cadet.github.io/master/en/interface/introduction.htmlhttps://cadet.github.io/master/en/interface/meta_group.htmlhttps://cadet.github.io/master/en/interface/output_group.htmlhttps://cadet.github.io/master/en/interface/parameter_dependencies.htmlhttps://cadet.github.io/master/en/interface/reaction/index.htmlhttps://cadet.github.io/master/en/interface/reaction/mass_action_law.htmlhttps://cadet.github.io/master/en/interface/reaction/michaelis_menten_kinetics.htmlhttps://cadet.github.io/master/en/interface/return_data.htmlhttps://cadet.github.io/master/en/interface/sensitivities.htmlhttps://cadet.github.io/master/en/interface/solver.htmlhttps://cadet.github.io/master/en/interface/spatial_discretization_methods.htmlhttps://cadet.github.io/master/en/interface/system.htmlhttps://cadet.github.io/master/en/interface/unit_operations/2d_general_rate_model.htmlhttps://cadet.github.io/master/en/interface/unit_operations/cstr.htmlhttps://cadet.github.io/master/en/interface/unit_operations/general_rate_model.htmlhttps://cadet.github.io/master/en/interface/unit_operations/index.htmlhttps://cadet.github.io/master/en/interface/unit_operations/inlet.htmlhttps://cadet.github.io/master/en/interface/unit_operations/lumped_rate_model_with_pores.htmlhttps://cadet.github.io/master/en/interface/unit_operations/lumped_rate_model_without_pores.htmlhttps://cadet.github.io/master/en/interface/unit_operations/multi_channel_transport_model.htmlhttps://cadet.github.io/master/en/interface/unit_operations/outlet.htmlhttps://cadet.github.io/master/en/interface/unit_operations/radial_flow_models.htmlhttps://cadet.github.io/master/en/license.htmlhttps://cadet.github.io/master/en/modelling/binding/bi_steric_mass_action.htmlhttps://cadet.github.io/master/en/modelling/binding/extended_mobile_phase_modulator_langmuir.htmlhttps://cadet.github.io/master/en/modelling/binding/freundlich_ldf.htmlhttps://cadet.github.io/master/en/modelling/binding/generalized_ion_exchange.htmlhttps://cadet.github.io/master/en/modelling/binding/hic_constant_water_activity.htmlhttps://cadet.github.io/master/en/modelling/binding/hic_water_on_hydrophobic_surfaces.htmlhttps://cadet.github.io/master/en/modelling/binding/index.htmlhttps://cadet.github.io/master/en/modelling/binding/linear.htmlhttps://cadet.github.io/master/en/modelling/binding/mobile_phase_modulator_langmuir.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_anti_langmuir.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_bi_langmuir.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_bi_langmuir_ldf.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_colloidal.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_langmuir.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_langmuir_ldf.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_langmuir_ldf_liquid_phase.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_spreading.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_state_steric_mass_action.htmlhttps://cadet.github.io/master/en/modelling/binding/saska.htmlhttps://cadet.github.io/master/en/modelling/binding/self_association.htmlhttps://cadet.github.io/master/en/modelling/binding/simplified_multi_state_steric_mass_action.htmlhttps://cadet.github.io/master/en/modelling/binding/steric_mass_action.htmlhttps://cadet.github.io/master/en/modelling/equations.htmlhttps://cadet.github.io/master/en/modelling/index.htmlhttps://cadet.github.io/master/en/modelling/networks.htmlhttps://cadet.github.io/master/en/modelling/reaction/index.htmlhttps://cadet.github.io/master/en/modelling/reaction/mass_action_law.htmlhttps://cadet.github.io/master/en/modelling/reaction/michaelis_menten_kinetics.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/2d_general_rate_model.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/cstr.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/general_rate_model.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/index.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/inlet.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/lumped_rate_model_with_pores.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/lumped_rate_model_without_pores.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/multi_channel_transport_model.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/outlet.htmlhttps://cadet.github.io/master/en/requirements.htmlhttps://cadet.github.io/master/en/simulation/index.htmlhttps://cadet.github.io/master/en/zbibliography.htmlhttps://cadet.github.io/master/en/genindex.htmlhttps://cadet.github.io/master/en/search.html
\ No newline at end of file
+https://cadet.github.io/master/en/README.htmlhttps://cadet.github.io/master/en/developer_guide/build_options.htmlhttps://cadet.github.io/master/en/developer_guide/cadet_core_architecture.htmlhttps://cadet.github.io/master/en/developer_guide/cadet_python.htmlhttps://cadet.github.io/master/en/developer_guide/debugging.htmlhttps://cadet.github.io/master/en/developer_guide/index.htmlhttps://cadet.github.io/master/en/developer_guide/model_expansion.htmlhttps://cadet.github.io/master/en/developer_guide/release_new_version.htmlhttps://cadet.github.io/master/en/developer_guide/testing.htmlhttps://cadet.github.io/master/en/examples/batch_chromatography.htmlhttps://cadet.github.io/master/en/examples/index.htmlhttps://cadet.github.io/master/en/examples/load_wash_elute.htmlhttps://cadet.github.io/master/en/examples/reaction_cstr.htmlhttps://cadet.github.io/master/en/examples/rtd.htmlhttps://cadet.github.io/master/en/getting_started/build_linux.htmlhttps://cadet.github.io/master/en/getting_started/build_osx.htmlhttps://cadet.github.io/master/en/getting_started/build_windows.htmlhttps://cadet.github.io/master/en/getting_started/index.htmlhttps://cadet.github.io/master/en/getting_started/installation.htmlhttps://cadet.github.io/master/en/getting_started/tutorials/breakthrough.htmlhttps://cadet.github.io/master/en/index.htmlhttps://cadet.github.io/master/en/interface/binding/bi_steric_mass_action.htmlhttps://cadet.github.io/master/en/interface/binding/extended_mobile_phase_modulator_langmuir.htmlhttps://cadet.github.io/master/en/interface/binding/freundlich_ldf.htmlhttps://cadet.github.io/master/en/interface/binding/generalized_ion_exchange.htmlhttps://cadet.github.io/master/en/interface/binding/hic_constant_water_activity.htmlhttps://cadet.github.io/master/en/interface/binding/hic_water_on_hydrophobic_surfaces.htmlhttps://cadet.github.io/master/en/interface/binding/index.htmlhttps://cadet.github.io/master/en/interface/binding/linear.htmlhttps://cadet.github.io/master/en/interface/binding/mobile_phase_modulator_langmuir.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_anti_langmuir.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_bi_langmuir.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_bi_langmuir_ldf.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_colloidal.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_langmuir.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_langmuir_ldf.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_langmuir_ldf_liquid_phase.htmlhttps://cadet.github.io/master/en/interface/binding/multi_component_spreading.htmlhttps://cadet.github.io/master/en/interface/binding/multi_state_steric_mass_action.htmlhttps://cadet.github.io/master/en/interface/binding/saska.htmlhttps://cadet.github.io/master/en/interface/binding/self_association.htmlhttps://cadet.github.io/master/en/interface/binding/simplified_multi_state_steric_mass_action.htmlhttps://cadet.github.io/master/en/interface/binding/steric_mass_action.htmlhttps://cadet.github.io/master/en/interface/consistent_initialization.htmlhttps://cadet.github.io/master/en/interface/flux_reconstruction.htmlhttps://cadet.github.io/master/en/interface/index.htmlhttps://cadet.github.io/master/en/interface/input_group.htmlhttps://cadet.github.io/master/en/interface/introduction.htmlhttps://cadet.github.io/master/en/interface/meta_group.htmlhttps://cadet.github.io/master/en/interface/output_group.htmlhttps://cadet.github.io/master/en/interface/parameter_dependencies.htmlhttps://cadet.github.io/master/en/interface/population_balance_model.htmlhttps://cadet.github.io/master/en/interface/reaction/index.htmlhttps://cadet.github.io/master/en/interface/reaction/mass_action_law.htmlhttps://cadet.github.io/master/en/interface/reaction/michaelis_menten_kinetics.htmlhttps://cadet.github.io/master/en/interface/return_data.htmlhttps://cadet.github.io/master/en/interface/sensitivities.htmlhttps://cadet.github.io/master/en/interface/solver.htmlhttps://cadet.github.io/master/en/interface/spatial_discretization_methods.htmlhttps://cadet.github.io/master/en/interface/system.htmlhttps://cadet.github.io/master/en/interface/unit_operations/2d_general_rate_model.htmlhttps://cadet.github.io/master/en/interface/unit_operations/cstr.htmlhttps://cadet.github.io/master/en/interface/unit_operations/general_rate_model.htmlhttps://cadet.github.io/master/en/interface/unit_operations/index.htmlhttps://cadet.github.io/master/en/interface/unit_operations/inlet.htmlhttps://cadet.github.io/master/en/interface/unit_operations/lumped_rate_model_with_pores.htmlhttps://cadet.github.io/master/en/interface/unit_operations/lumped_rate_model_without_pores.htmlhttps://cadet.github.io/master/en/interface/unit_operations/multi_channel_transport_model.htmlhttps://cadet.github.io/master/en/interface/unit_operations/outlet.htmlhttps://cadet.github.io/master/en/interface/unit_operations/radial_flow_models.htmlhttps://cadet.github.io/master/en/license.htmlhttps://cadet.github.io/master/en/modelling/binding/bi_steric_mass_action.htmlhttps://cadet.github.io/master/en/modelling/binding/extended_mobile_phase_modulator_langmuir.htmlhttps://cadet.github.io/master/en/modelling/binding/freundlich_ldf.htmlhttps://cadet.github.io/master/en/modelling/binding/generalized_ion_exchange.htmlhttps://cadet.github.io/master/en/modelling/binding/hic_constant_water_activity.htmlhttps://cadet.github.io/master/en/modelling/binding/hic_water_on_hydrophobic_surfaces.htmlhttps://cadet.github.io/master/en/modelling/binding/index.htmlhttps://cadet.github.io/master/en/modelling/binding/linear.htmlhttps://cadet.github.io/master/en/modelling/binding/mobile_phase_modulator_langmuir.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_anti_langmuir.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_bi_langmuir.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_bi_langmuir_ldf.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_colloidal.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_langmuir.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_langmuir_ldf.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_langmuir_ldf_liquid_phase.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_component_spreading.htmlhttps://cadet.github.io/master/en/modelling/binding/multi_state_steric_mass_action.htmlhttps://cadet.github.io/master/en/modelling/binding/saska.htmlhttps://cadet.github.io/master/en/modelling/binding/self_association.htmlhttps://cadet.github.io/master/en/modelling/binding/simplified_multi_state_steric_mass_action.htmlhttps://cadet.github.io/master/en/modelling/binding/steric_mass_action.htmlhttps://cadet.github.io/master/en/modelling/crystallization.htmlhttps://cadet.github.io/master/en/modelling/equations.htmlhttps://cadet.github.io/master/en/modelling/index.htmlhttps://cadet.github.io/master/en/modelling/networks.htmlhttps://cadet.github.io/master/en/modelling/reaction/index.htmlhttps://cadet.github.io/master/en/modelling/reaction/mass_action_law.htmlhttps://cadet.github.io/master/en/modelling/reaction/michaelis_menten_kinetics.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/2d_general_rate_model.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/cstr.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/general_rate_model.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/index.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/inlet.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/lumped_rate_model_with_pores.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/lumped_rate_model_without_pores.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/multi_channel_transport_model.htmlhttps://cadet.github.io/master/en/modelling/unit_operations/outlet.htmlhttps://cadet.github.io/master/en/publications.htmlhttps://cadet.github.io/master/en/requirements.htmlhttps://cadet.github.io/master/en/simulation/index.htmlhttps://cadet.github.io/master/en/zbibliography.htmlhttps://cadet.github.io/master/en/genindex.htmlhttps://cadet.github.io/master/en/search.html
\ No newline at end of file
diff --git a/chore/developer_guide/zbibliography.html b/chore/developer_guide/zbibliography.html
index 1eda58949..cbd1836ca 100644
--- a/chore/developer_guide/zbibliography.html
+++ b/chore/developer_guide/zbibliography.html
@@ -49,7 +49,7 @@
Wendi Zhang, Todd Przybycien, Johannes Schmölder, Samuel Leweke, and Eric von Lieres. Solving crystallization/precipitation population balance models in cadet, part i: nucleation growth and growth rate dispersion in batch and continuous modes on nonuniform grids. Computers & Chemical Engineering, pages 108612, 2024. doi:https://doi.org/10.1016/j.compchemeng.2024.108612.
+
+
+[25]
Alan C. Hindmarsh, Peter N. Brown, Keith E. Grant, Steven L. Lee, Radu Serban, Dan E. Shumaker, and Carol S. Woodward. SUNDIALS: Suite of nonlinear and differential/algebraic equation solvers. ACM Transactions on Mathematical Software, 31(3):363–396, September 2005. URL: http://portal.acm.org/citation.cfm?doid=1089014.1089020, doi:10.1145/1089014.1089020.
To build the documentation locally, in the doc folder, install sphinx and other dependencies by running
+
pipinstall-rrequirements.txt
+
+
+
+
Then, in the doc folder, run:
+
sphinx-build-bhtml.build
+
The output is in the build directory and can be opened with any browser.
+
To build the documentation for all releases and the master branch, run:
+
sphinx-multiversion././build/.
+
Any changes to the documentation will automatically be pushed to the github-pages repository (https://github.com/cadet/cadet.github.io) using github actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/_images/PBM_Part_I.png b/v5.0.1/_images/PBM_Part_I.png
new file mode 100644
index 000000000..7870c34ce
Binary files /dev/null and b/v5.0.1/_images/PBM_Part_I.png differ
diff --git a/v5.0.1/_images/architecture_libcadet_classes.png b/v5.0.1/_images/architecture_libcadet_classes.png
new file mode 100644
index 000000000..e2e79ae28
Binary files /dev/null and b/v5.0.1/_images/architecture_libcadet_classes.png differ
diff --git a/v5.0.1/_images/breakthrough_chromatogram.png b/v5.0.1/_images/breakthrough_chromatogram.png
new file mode 100644
index 000000000..26e932489
Binary files /dev/null and b/v5.0.1/_images/breakthrough_chromatogram.png differ
diff --git a/v5.0.1/_images/breakthrough_chromatogram1.png b/v5.0.1/_images/breakthrough_chromatogram1.png
new file mode 100644
index 000000000..b430fe39a
Binary files /dev/null and b/v5.0.1/_images/breakthrough_chromatogram1.png differ
diff --git a/v5.0.1/_images/breakthrough_system.png b/v5.0.1/_images/breakthrough_system.png
new file mode 100644
index 000000000..40142b021
Binary files /dev/null and b/v5.0.1/_images/breakthrough_system.png differ
diff --git a/v5.0.1/_images/breakthrough_system.svg b/v5.0.1/_images/breakthrough_system.svg
new file mode 100644
index 000000000..6dc4691d8
--- /dev/null
+++ b/v5.0.1/_images/breakthrough_system.svg
@@ -0,0 +1,3 @@
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/_images/cadet_architecture_overview.png b/v5.0.1/_images/cadet_architecture_overview.png
new file mode 100644
index 000000000..ca1778a83
Binary files /dev/null and b/v5.0.1/_images/cadet_architecture_overview.png differ
diff --git a/v5.0.1/_images/cadet_logo.png b/v5.0.1/_images/cadet_logo.png
new file mode 100644
index 000000000..f56f4fef3
Binary files /dev/null and b/v5.0.1/_images/cadet_logo.png differ
diff --git a/v5.0.1/_images/column_bead_model.png b/v5.0.1/_images/column_bead_model.png
new file mode 100644
index 000000000..cede3331b
Binary files /dev/null and b/v5.0.1/_images/column_bead_model.png differ
diff --git a/v5.0.1/_images/column_bulk_model.png b/v5.0.1/_images/column_bulk_model.png
new file mode 100644
index 000000000..46e4e9733
Binary files /dev/null and b/v5.0.1/_images/column_bulk_model.png differ
diff --git a/v5.0.1/_images/column_particle_geometries.png b/v5.0.1/_images/column_particle_geometries.png
new file mode 100644
index 000000000..5eb42a547
Binary files /dev/null and b/v5.0.1/_images/column_particle_geometries.png differ
diff --git a/v5.0.1/_images/file_format_input.png b/v5.0.1/_images/file_format_input.png
new file mode 100644
index 000000000..41e53f163
Binary files /dev/null and b/v5.0.1/_images/file_format_input.png differ
diff --git a/v5.0.1/_images/file_format_input_model_unit.png b/v5.0.1/_images/file_format_input_model_unit.png
new file mode 100644
index 000000000..0a3e2146e
Binary files /dev/null and b/v5.0.1/_images/file_format_input_model_unit.png differ
diff --git a/v5.0.1/_images/file_format_output.png b/v5.0.1/_images/file_format_output.png
new file mode 100644
index 000000000..de8bd0a6e
Binary files /dev/null and b/v5.0.1/_images/file_format_output.png differ
diff --git a/v5.0.1/_images/file_format_structure.png b/v5.0.1/_images/file_format_structure.png
new file mode 100644
index 000000000..453bc44dc
Binary files /dev/null and b/v5.0.1/_images/file_format_structure.png differ
diff --git a/v5.0.1/_images/mct_variable_areas.png b/v5.0.1/_images/mct_variable_areas.png
new file mode 100644
index 000000000..bea268c98
Binary files /dev/null and b/v5.0.1/_images/mct_variable_areas.png differ
diff --git a/v5.0.1/_images/multi_channel_transport_model_class.png b/v5.0.1/_images/multi_channel_transport_model_class.png
new file mode 100644
index 000000000..9e55c9f2c
Binary files /dev/null and b/v5.0.1/_images/multi_channel_transport_model_class.png differ
diff --git a/v5.0.1/_images/multiple_bound_states.png b/v5.0.1/_images/multiple_bound_states.png
new file mode 100644
index 000000000..f80378ebd
Binary files /dev/null and b/v5.0.1/_images/multiple_bound_states.png differ
diff --git a/v5.0.1/_images/sections.png b/v5.0.1/_images/sections.png
new file mode 100644
index 000000000..835ac448f
Binary files /dev/null and b/v5.0.1/_images/sections.png differ
diff --git a/v5.0.1/_images/time_integration.png b/v5.0.1/_images/time_integration.png
new file mode 100644
index 000000000..f2342e678
Binary files /dev/null and b/v5.0.1/_images/time_integration.png differ
diff --git a/v5.0.1/_sources/README.md.txt b/v5.0.1/_sources/README.md.txt
new file mode 100644
index 000000000..8a82e81ab
--- /dev/null
+++ b/v5.0.1/_sources/README.md.txt
@@ -0,0 +1,21 @@
+## CADET Documentation
+
+
+To build the documentation locally, in the `doc` folder, install sphinx and other dependencies by running
+
+```
+pip install -r requirements.txt
+
+```
+
+Then, in the `doc` folder, run:
+
+`sphinx-build -b html . build`
+
+The output is in the `build` directory and can be opened with any browser.
+
+To build the documentation for all releases and the master branch, run:
+
+`sphinx-multiversion ./ ./build/`.
+
+Any changes to the documentation will automatically be pushed to the github-pages repository (https://github.com/cadet/cadet.github.io) using github actions.
diff --git a/v5.0.1/_sources/developer_guide/build_options.rst.txt b/v5.0.1/_sources/developer_guide/build_options.rst.txt
new file mode 100644
index 000000000..efc70dd00
--- /dev/null
+++ b/v5.0.1/_sources/developer_guide/build_options.rst.txt
@@ -0,0 +1,58 @@
+.. _build_options:
+
+CADET build options
+===================
+
+For builds on MS Windows, the CMake command arguments are specified for every build configuration in the cmakeSettings.json.
+For builds on Linux and MacOs, the CMake command arguments must be specified from the command line.
+
+cmakeSettings.json
+------------------
+
+The cmakeSettings.json provides standard build configurations for a ``DEBUG`` build, a ``RELEASE`` build and a ``RELEASE_with_Debug_Info`` build.
+
+The ``DEBUG`` build compiles code suited for debugging, i.e. the code is compiled such that every line of code is individually executed.
+This way, it is possible to go through the code line by line and to set breakpoints in an IDE such as MS Visual Studio.
+Additionally, the ``DEBUG`` build will print additional information during the simulation, such as the current step size and time point of the simulation.
+
+The ``RELEASE`` build compiles optimized code and should be used to actually use CADET for simulations.
+
+The ``RELEASE_with_Debug_Info`` build compiles optimized code but some debug information will still be printed.
+
+The ``RELEASE_with_Tests`` and ``DEBUG_with_Test`` build options additionally build the ``testRunner``, which is required to run the integrated tests in ``CADET-Core``.
+
+Options
+-------
+
+The following build arguments can be set in the cmakeSettings.json or from the cmake command line:
+
+- ``DCMAKE_INSTALL_PREFIX``: location for the installed ``CADET-Core`` framework.
+- ``DENABLE_STATIC_LINK_LAPACK`` Prefer static over dynamic linking of LAPACK and BLAS into the ``CADET-Core`` framework. Static linking incorporates all necessary libraries into the final executable at compile time, while dynamic linking loads libraries at runtime. Static linking produces larger executables that are less dependent on changes in the operating system. Dynamic linking allows for dynamic updates of underlying libraries and smaller compiled software.
+- ``DENABLE_STATIC_LINK_DEPS``: Prefer static over dynamic linking of dependencies into the ``CADET-Core`` framework.
+- ``DENABLE_STATIC_LINK_CLI``: Prefers static over dynamic linking for CADET CLI.
+- ``DENABLE_TESTS``: Build the ``restRunner`` executable to evaluate the integrated tests in ``CADET-Core``.
+- ``DENABLE_ANALYTIC_JACOBIAN_CHECK``: Computes both the analytical and AD Jacobian and compares them for testing purpose.
+- ``DENABLE_THREADING``: Enables multi-threading capabilities. Parallelized code will be compiled, using the TBB library. Note that the non-parallelized code is faster compared to the parallelized code when only one thread is being used. The number of threads is specified in the filed ``N_THREADS``.
+- ``DBLA_VENDOR``: Vendor for the BLAS & LAPACK library. If unset, the system library will be used. By default on Windows we use the Intel OneApi library, specified with ``Intel10_64lp_seq``. If a parallelized build is generated, this should be set to ``Intel10_64lp``.
+- ``DENABLE_LOGGING``: Enables logging functionality.
+- ``DENABLE_BENCHMARK``: Activates benchmark mode for fine-grained timing.
+- ``DENABLE_PLATFORM_TIMER``: Utilizes a platform-dependent timer.
+- ``DENABLE_DEBUG_THREADING``: Activates multi-threading in debug builds.
+- ``DENABLE_2D_MODELS``: Builds 2D models such as the 2D general rate model and multichannel transport.
+- ``DENABLE_DG``: Constructs DG variants of models.
+- ``DENABLE_SUNDIALS_OPENMP``: Prefers the OpenMP vector implementation of SUNDIALS for large problems if available.
+- ``DENABLE_CADET_CLI``: Builds the CADET command line interface.
+- ``DENABLE_CADET_TOOLS``: Constructs CADET tools.
+- ``DENABLE_PACKAGED_SUNDIALS``: Uses packaged SUNDIALS code.
+- ``DENABLE_IPO``: Enables interprocedural optimization if the compiler supports it.
+- ``DCMAKE_INSTALL_RPATH_USE_LINK_PATH``: Adds paths to linker search and installed rpath.
+- ``DNUM_MAX_AD_DIRS``: Specifies the number of allowed AD directions (default value is 80). Increasing this value can decrease performance when AD is being used.
+
+The following build arguments are exclusive to builds on MS windows:
+
+- ``DVCPKG_TARGET_TRIPLET``: We use ``vcpkg`` to manage our dependencies. This triplet specifies which version of the dependencies should be installed. It takes the form of ``architecture-os-linking``, so ``x64-windows-static`` for our use cases.
+
+The following build arguments can only be used with the Clang or GCC compilers:
+
+- ``DENABLE_ASAN``: enables the address sanitizer.
+- ``DENABLE_UBSAN``: enables the undefined behaviour sanitizer.
diff --git a/v5.0.1/_sources/developer_guide/cadet_core_architecture.rst.txt b/v5.0.1/_sources/developer_guide/cadet_core_architecture.rst.txt
new file mode 100644
index 000000000..0c0674765
--- /dev/null
+++ b/v5.0.1/_sources/developer_guide/cadet_core_architecture.rst.txt
@@ -0,0 +1,113 @@
+.. _cadet_core_architecture:
+
+Software Architecture
+=====================
+
+This section gives a general overview of the object-oriented c++ implementation of CADET-Core and is based on the Software Architecture chapter 3.2 in Samuel Lewekes PhD thesis [1]_.
+
+The CADET-Core software is designed to be modular, extendable, maintainable and computationally efficient and robust.
+To promote these goals, CADET-Core is implemented in C++, a highly performant, object-oriented language that supports cross-platform compatibility.
+
+Features and Capabilities
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+CADET-Core
+
+- Builds on Windows, Linux and MacOs
+
+- Allows to easily add new frontends as the core simulator is implemented in the library ``libcadet``, which can be called from different frontends.
+ Currently, CADET-Core features the command line interface ``cadet-cli`` and CADET-Python, which includes a ``Cadet`` class that serves as a generic HDF5 frontend and calls the ``cadet-cli``.
+ The CADET-Process frontend is a separate software that wraps CADET-Python and supports additional pre- and post-processing functionality, as described in the `CADET-Process documentation `_.
+ The Matlab frontend was deprecated in `commit 4b34e0d5 `_ due to its maintenance overhead.
+
+- Can compute parameter sensitivities via a custom Algorithmic Differentiation (AD) implementation. The AD infrastructure allows for easy extension of new models to support parameter sensitivities, as described in the AD section of the :ref:`model_expansion` chapter.
+
+- Allows arbitrary systems of unit operations, including cycles.
+
+- Implements a method of lines approach to solve the model equations: Custom implementations of model equations and, if required, spatial discretizations, are complemented by the well-established and publicly available time integration software library `SUNDIALS `_.
+ Their IDAS solver implements a variable order (up to fifth order) BDF with adaptive time stepping and has proven to be stable and robust.
+ Additionally, IDAS supports the forward computation of parameter sensitivities, i.e. solves the forward sensitivity equation system as `described in their documentation `_.
+
+
+Implementation Details
+^^^^^^^^^^^^^^^^^^^^^^
+
+Classes and realationships
+
+.. _LibcadetClasses:
+.. figure:: _images/architecture_libcadet_classes.png
+
+
+ Selected relationships of classes in ``libcadet`` [1]_.
+
+.. [#] Samuel Lewekes PhD thesis, available at: https://publications.rwth-aachen.de/record/840314
+
+In the following, we briefly describe the purpose of some of the items in the figure above:
+
+Classes with capital letter ``I`` as prefix are abstract classes that define the interface for the derived classes.
+
+``ISimulator``
+Exported interface to the simulator.
+
+``Simulator``
+Implements time integration including parameter sensitivities.
+
+``IModelSystem``
+Defines basic functions that users of libcadet can use to modify a system of submodels (e.g., add submodels, access parameters).
+
+``ISimulatableModel``
+Defines functions that the time integration process needs to run.
+This includes, for example, evaluation of model equations, solution of linearized model equations, and consistent initialization.
+
+``ModelSystem``
+Implements the system of submodels.
+It also owns external functions that can be used to modify model parameters based on externally given data (e.g., pH profile).
+
+``IExternalFunction``
+Defines the functions for evaluating an externally given function.
+For example, an external function can be represented by a piecewise cubic polynomial.
+It could also interpolate between given data points or delegate the calls to a MATLAB function.
+Besides evaluating the function itself, certain derivatives have to be provided.
+
+``IUnitOperation``
+Corresponds to a black box submodel which meets the :ref:`UnitOperationAssumption`.
+Besides evaluation of model equations, solution of linearized model equations, and consistent initialization, it also handles ports and their volumetric flow rates.
+
+``GeneralRateModel``
+Implements the :ref:`general_rate_model_model`.
+It serves as an example for an IUnitOperation implementation in the diagram.
+Common functionality between submodels is moved into separate classes or functions (e.g., ``ConvectionDispersionOperator``).
+
+``ConvectionDispersionOperator``
+Implements the operator :math:`-u \frac{\partial c}{\partial z} + D_\text{ax} \frac{\partial^2 c}{\partial z^2}`, which is used in many transport models.
+It also converts the volumetric flow rate to the interstitial velocity :math:`u` using the cross section area of the column and the porosity.
+
+``IBindingModel``
+Defines functions for evaluating the binding rates :math:`f_\text{ads,j}\left(c^p_j, c^s_j\right)` (as used in, e.g., the :ref:`general_rate_model_model`), according to some :ref:`binding_models`. This interface fully encapsulates a binding model.
+If supported, binding model parameters may have a :ref:`dependence-on-external-function_bind`.
+
+``IDynamicReactionModel``
+Defines functions for evaluating the reaction rates :math:`f_\text{react,i}\left( c \right)` (as used in, e.g., the :ref:`general_rate_model_model`), according to some :ref:`reaction_models`.
+If supported, reaction model parameters may have a :ref:`dependence-on-external-function_react`.
+
+.. _UnitOperationAssumption:
+
+Unit Operation submodel assumption
+-----------------------------------
+
+- Each submodel has :math:`N_{c,n} \in \mathbb{N}` components, :math:`N_{in, n} \in \mathbb{N}` inlet ports and :math:`N_{out, n} \in \mathbb{N}` outlet ports.
+
+- The dynamics of each submodel n are described by a fully implicit equation (e.g., PDE, PDAE, DAE, ODER) of the form
+
+.. math::
+
+ \mathcal{F}_n \left(t, \mathbf{q}_{in,n}, \mathbf{q}_{out,n}, \mathbf{y}_{in,n}, \mathbf{y}_{n}, \frac{\partial \mathbf{y}_{n}}{\partial t} \right),
+
+where:
+ - :math:`t \in (0, T_\text{end})` denotes time,
+ - :math:`\mathbf{q}_{in,n}, \mathbf{q}_{out,n} \in \mathbb{R}^{N_{in, n}}` are the inlet port and outlet port volumetric flow rates, respectively,
+ - :math:`\mathbf{y}_{in,n} \in \mathbb{R}^{N_{in, n} N_c,n}` is the inlet concentration of all ports and components,
+ - :math:`\mathbf{y}_{n}` contains the state variables of the submodel, and :math:`\frac{\partial \mathbf{y}_{n}}{\partial t}` contains its time derivatives.
+
+- The outlet concentration :math:`\mathbf{c}_{out,n,j} \ \colon (0, T_\text{end}) \mapsto \mathbb{R}^{N_{c,n}}` of port :math:`j\in\{1,\dots , N_{out,n}\}` of submodel :math:`n` is a linear function of its state vector :math:`\mathbf{y}_n`.
+
diff --git a/v5.0.1/_sources/developer_guide/cadet_python.rst.txt b/v5.0.1/_sources/developer_guide/cadet_python.rst.txt
new file mode 100644
index 000000000..1da8c269b
--- /dev/null
+++ b/v5.0.1/_sources/developer_guide/cadet_python.rst.txt
@@ -0,0 +1,273 @@
+.. _cadet_python:
+
+CADET-Python Introduction
+=========================
+
+The CADET-Python API can be very useful for developers as it allows to create an arbitrary input configuration for CADET-Core.
+This is especially useful when new methods and models are added, which are not (yet) supported by the CADET-Process frontend.
+To demonstrate the use of CADET-Python, we set up a simulation in the following.
+
+Performing a forward simulation comprises several steps:
+ * Setting up the model including all parameters and discretization options
+ * Defining sections and switches
+ * Setting up the simulator and actually running the simulation
+ * Evaluating results (e.g., plotting)
+
+In this tutorial, we will build a simple forward simulation with a breakthrough of one component using the following system:
+
+.. figure:: _images/breakthrough_system.png
+
+For this purpose, we use :ref:`CADET-Python `, a file based frontend for CADET.
+CADET still must be downloaded (or built from source) as explained in the :ref:`installation guide `.
+The Python frontend almost exactly maps to the documented :ref:`CADET file format ` except that all dataset names are lowercase.
+This simplifies using the frontend.
+The package includes a ``Cadet`` class which serves as a generic HDF5 frontend.
+
+As an example, we consider setting the external porosity for the column model (``unit_001``).
+From :ref:`file format `, the path for this is ``/input/model/unit_001/COL_POROSITY``.
+In the Python frontend, this becomes:
+
+.. code-block:: Python3
+
+ sim = Cadet()
+ sim.root.input.model.unit_001.col_porosity = 0.33
+
+0. Preliminary Steps
+--------------------
+
+First, we need to import some libraries and specify the location of the ``cadet-cli`` executable (core simulator).
+It is located in the ``bin`` folder where CADET was installed.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 2-6
+
+
+To create the model and specify its parameters, we create an instance of the ``Cadet`` class.
+In the ``root`` attribute of this object, the parameter structure is defined as described in the :ref:`file format reference `.
+It is implemented as a ``Dict`` of the |addict package|_.
+This allows for creating arbitrary nested dictionaries using dot-notation.
+
+.. |addict package| replace:: ``addict`` package
+.. _addict package: https://github.com/mewwts/addict
+
+.. warning:: Note, that the ``Cadet`` class does not provide any sanity checks.
+ If parameters are misspelled or have the wrong dimensions, they are simply ignored.
+ This can cause problems later on, when the simulator is run.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 9
+
+
+1. Setting Up the Model
+-----------------------
+
+Although the order of the parameter specification does not matter, it is reasonable to first specify the number of unit operations before we select the models and define the parameters.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 12
+
+The available models are listed in the :ref:`unit operation chapter `.
+The units of the different parameters and quantities are given in the corresponding :ref:`file format ` of the respective unit operation.
+
+Inlet Model
+^^^^^^^^^^^
+
+In CADET, the ``INLET`` pseudo unit operation serves as a source for the system and is used to create arbitary concentration profiles as boundary conditions.
+First, we define an ``INLET`` as the first unit operation by adding the field ``unit_000`` in the ``/input/model/`` group.
+The concentration profile is described using a piecewise cubic polynomial (cubic spline in the continuous case) for each component, where the pieces are given by the time sections.
+Later, we will define the polynomials, when we look at time sections.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 15-17
+
+General Rate Model
+^^^^^^^^^^^^^^^^^^
+
+We now add a second unit operation, the column model.
+For the :ref:`general rate model model `, we set the ``unit_type`` parameter of the corresponding unit operation model to ``GENERAL_RATE_MODEL``.
+In this group, we set the parameters related to transport and column geometry.
+For a more detailed description of the parameters and their units, see the :ref:`corresponding file format `.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 20-34
+
+Note that film, particle, and surface diffusion are all component-specific, that is, they are vectors of length ``n_components``.
+
+Adsorption Model
+~~~~~~~~~~~~~~~~
+
+Every column model can be equipped with an adsorption model.
+The available models are listed in the :ref:`binding model chapter `.
+
+For the :ref:`Langmuir model `, we set the ``adsorption_model`` parameter of the corresponding unit operation model to ``MULTI_COMPONENT_LANGMUIR``.
+Then, we decide if we want to use the :ref:`rapid-equilibrium assumption ` in the binding model (``is_kinetic = False``), which is not the case here (dynamic binding).
+Finally, the parameters of the binding model have to be set for each component (they are vectors of length ``n_components``).
+They are described in the :ref:`corresponding file format specification `.
+In case of the Langmuir model, we have to specify the parameters ``kA``, ``kD``, and ``qMAX``.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 37-41
+
+Initial Conditions
+~~~~~~~~~~~~~~~~~~
+
+Next, we specify the initial conditions (concentration of the components in the mobile and stationary phases) for the column.
+These concentrations are entered as vectors, where each entry gives the concentration for the corresponding component.
+In this example, we start with an empty column.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 44-45
+
+Setting up the Discretization
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are several options for adapting the spatial discretization of the PDE model.
+However, the two most important ones are the number of grid cells in the column (axial direction) and the particles, which are also set in this example.
+We choose ``20`` axial cells in the column ``ncol`` and ``5`` radial cells in the particle ``npar``.
+
+.. warning:: These are rather low values to make the examples run faster, since they are only for educational purposes.
+ In practice, much higher values are expected (say 100-200 axial cells and 16-32 particle cells).
+ Note that the WENO scheme, which handles the advection, drastically reduces the required amount of cells compared to an upwind scheme.
+
+Moreover, we have to specify the number of bound states for each component.
+Finally, we set some other options for the discretization, which usually do not need to be changed.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 48-66
+
+Outlet Model
+^^^^^^^^^^^^
+
+The ``OUTLET`` is another pseudo unit operation that serves as sink for the system.
+
+.. note:: In this case, the outlet unit is actually not required. We could use the outlet concentration signal of the column model instead.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 69-70
+
+
+2. Setting up Time Sections and Connections
+-------------------------------------------
+
+Time Sections
+^^^^^^^^^^^^^
+
+:ref:`Time sections ` are used to specify changes of parameter values during the simulation.
+A section typically corresponds to an operating step (load, wash, elute etc.), but can also be used to indicate changes in connectivity, or even discontinuities of :ref:`model parameters `.
+
+In the ``/input/solver/sections/`` group, ``nsec`` denotes the number of sections.
+The start and end times of a section are given in the ``section_times`` vector.
+It should always start at ``0.0`` and contains ``nsec + 1`` values, that is, the ``i``\ th section goes from ``section_times[i]`` to ``section_times[i+1]``.
+
+The ``section_continuity`` indicates whether a transition from one section to the next is continuous in both the inlet and the parameters.
+It has ``nsec - 1`` number of values, since there is one transition less than there are sections.
+The continuity is used in CADET’s time integrator, which needs to decide whether to restart on entering a new section.
+If the transition is continuous, the time integrator can try to step over the transition without restarting, thus saving some computation time (since the restart is costly).
+If you are unsure about the continuity, just leave it at ``0``.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 73-75
+
+As mentioned earlier, we now define the ``INLET`` profile using a piecewise cubic polynomial.
+On each section :math:`[ t_i, t_{i+1} ]` a cubic polynomial :math:`p_i` is defined:
+
+.. math::
+
+ p_i( t ) = d * (t - t_i)^3 + c * (t - t_i)^2 + b * (t - t_i) + a,
+
+where the coefficients of the polynomial are ``const_coeff`` (a), ``lin_coeff`` (b), ``quad_coeff`` (c), and ``cube_coeff`` (d).
+Note that the constant coefficient ``const_coeff`` determines the starting concentration on each section.
+The stopping concentration is given by :math:`p_i( t_{i+1} )` or :math:`p_{i+1}( t_{i+1} )` in case of a continuous profile.
+
+In this example, which has only one section, we define its coefficients by adding the field ``sec_000`` to the inlet unit (``unit_000``).
+Since the column should be constantly fed with :math:`1.0 \cdot 10^{-3} mol / m^3`, we set ``const_coeff`` to ``[1.0e-3]`` and all other cofficients to ``[0.0]``.
+Note that for more components, a vector of coefficients needs to be specified.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 78-81
+
+System Connectivity
+^^^^^^^^^^^^^^^^^^^
+
+In order to specify the :ref:`connectivity of the network `, we have to provide a list of connections.
+CADET requires that we append all connections to a long vector (i.e., if each connection is a row in a matrix, CADET wants this matrix in row-major storage).
+Moreover, we have to specify the section in which the specified connectivity should be applied.
+
+The elements of a connection are (in order):
+
+ ``[UnitOpID from, UnitOpID to, Component from, Component to, Volumetric flow rate]``
+
+Usually, ``Component from`` and ``Component to`` can be set to ``-1``, which will connect all components from the origin and destination unit operations.
+
+.. note:: Since CADET version 4.1, the flow rates can also be defined with piecewise cubic polynomials.
+ Also, for the 2D General rate model inlet ports need to be speciefied.
+ For more information on the parameters, see the :ref:`file format specification `.
+
+In this case, we connect all components of ``unit_000`` to ``unit_001``, and from ``unit_001`` to ``unit_002``.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 84-88
+
+.. note:: Since the flow in the column models is incompressible, the total entering flow rate must equal the total outgoing flow rate.
+ This restriction does not apply to a :ref:`CSTR model `, because it has a variable volume.
+
+3. Setting Up the Simulator and Running the Simulation
+------------------------------------------------------
+
+Before we can start the simulation, we have to specify some settings for the simulator.
+
+First, we set some options for the solver and the time integrator.
+Usually, these only need to be adapted in special cases.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 91-104
+
+Of these options, the most interesting ones are ``time_integrator.abstol`` and ``time_integrator.reltol``, which control the errors during time integration, and ``nthreads``, which sets the number of CPU cores CADET is allowed to use.
+
+Second, we have to specify which results we want CADET to return.
+For this, we have to specify the ``/input/return/`` group.
+For more information, see the :ref:`file format specification `.
+
+.. note::Because ``return`` is a reserved keyword in Python, we cannot use dot-notation but have to use the ‘proper’ dictionary indexing syntax.
+
+In this example, we want to write the concentration profile of the inlet and outlet of each unit operation.
+In addition, we are interested in the concentration in the interstitial volume (bulk volume) of the column.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 106-115
+
+Finally, we have to set the time points at which we want to evaluate the solution.
+Note that the end time must not exceed the last section time specified in the model.
+If the time points are not set explicitly, the time integrator outputs the solution at arbitrary time points between ``0`` and ``section_times[-1]``.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 117-118
+
+The last remaining step is to actually run the simulation.
+For this, we have to specify a filename, save the configuration to ``H5``-format and call call the ``model``\ ’s ``run()`` function.
+We check if the simulation has completed successfully and load the results.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 121-131
+
+4. Plotting the Results
+-----------------------
+
+The data is stored in the ``/output/`` group of the ``Cadet`` object.
+The structure and format of the data is described in the :ref:`file format specification `.
+Finally, we plot the concentration signal at the outlet of the column.
+
+.. literalinclude:: examples/breakthrough.py
+ :lines: 134-141
+
+.. image:: _images/breakthrough_chromatogram.png
+
+
+Exercises
+---------
+
+- Add a second inlet section from ``10000`` to ``40000`` seconds in which no sample is fed into the column (rectangular pulse).
+- Increase the length of the column and the flow rate.
+- Increase the desorption coefficient ``MCL_KD``.
+- Add a second component.
+- Plot the concentration profile of the ``INLET`` unit operation
diff --git a/v5.0.1/_sources/developer_guide/debugging.rst.txt b/v5.0.1/_sources/developer_guide/debugging.rst.txt
new file mode 100644
index 000000000..c8cddb071
--- /dev/null
+++ b/v5.0.1/_sources/developer_guide/debugging.rst.txt
@@ -0,0 +1,15 @@
+.. _debugging:
+
+CADET-Core debugging
+====================
+
+We advice to use an IDE like MS Visual Studio to debug CADET-Core.
+
+If the debugger does not stop at a breakpoint even though it is set in the correct source file, this might be because a corresponding libcadet file was build and is being run. You can find these files under `build/src/libcadet`. Alternatively, you can set a breakpoint in an early stage, e.g. in the driver file and manually step through the code.
+
+To run a specific simulation with the Visual Studio debugguer, you can add the launch.vs.json file provided here to the .vs folder
+
+.. literalinclude:: launch.vs.json
+ :language: json
+
+To debug memory related issues, you can compile the code with the address sanitizer ASAN and the undefined behaviour sanitizer UBSAN by enabling the cmake arguments `DENABLE_ASAN` and `DENABLE_UBSAN`.
\ No newline at end of file
diff --git a/v5.0.1/_sources/developer_guide/index.rst.txt b/v5.0.1/_sources/developer_guide/index.rst.txt
new file mode 100644
index 000000000..57f98abba
--- /dev/null
+++ b/v5.0.1/_sources/developer_guide/index.rst.txt
@@ -0,0 +1,25 @@
+.. _developer_guide:
+
+Developer Guide
+===============
+
+This developer guide is intended to help expand and maintain CADET-Core and is written to serve developers with diverse backgrounds.
+
+If you find any gaps or have suggestions for improvement, your input is valuable in refining our documentation for better comprehension by all developers.
+Please feel free to open an `issue on GitHub `_ or, even better, write a draft and create a pull request.
+
+When planning to extend or contribute to CADET-Core, please adhere to our notation style and research software engineering (RSE) best practices.
+For detailed guidance, you can e.g. refer to the `RSE guidelines `_.
+Since some developers may be new to collaborative software development using Git and GitHub, we specifically recommend consulting the `Git RSE guide `_.
+
+
+.. toctree::
+ :maxdepth: 2
+
+ cadet_python
+ cadet_core_architecture
+ build_options
+ model_expansion
+ debugging
+ testing
+ release_new_version
diff --git a/v5.0.1/_sources/developer_guide/model_expansion.rst.txt b/v5.0.1/_sources/developer_guide/model_expansion.rst.txt
new file mode 100644
index 000000000..481c602a5
--- /dev/null
+++ b/v5.0.1/_sources/developer_guide/model_expansion.rst.txt
@@ -0,0 +1,123 @@
+.. _model_expansion:
+
+Model Expansion
+===============
+
+There are 7+ transport models and 20+ adsorption models implemented in CADET.
+Please make sure that the one you are interested in is not implemented.
+Additionally, some models can be mimicked by or are even equivalent to already implemented models when specific parameters are chosen, see e.g. the LRM use-case section for the :ref:`multi_channel_transport_model_model`.
+
+The implementation of a new model follows three main steps:
+1. Create a template binding/unit/reaction model from existing code
+2. Register the binding/unit/reaction model in the respective CADET binding/unit/reaction model factory and add it to cmake
+3. Implementation of model equations and Jacobian matrix
+4. Testing
+
+Binding Model
+^^^^^^^^^^^^^
+
+An extensive description on how to add a new binding model to CADET-Core is given in a `forum post `_, where such an extension is described using the example of a Langmuir binding.
+A more concise description is given in the following:
+
+1.
+Use the `binding model template `_ to create a new binding model file in the CADET binding model source directory
+
+``\src\libcadet\model\binding\YourModelNameBinding.cpp``
+
+and rename the model in the file (i.e. Template to YoureModelName).
+Note that the provided template binding model is an implementation of the multi-component Langmuir binding.
+
+2.
+Register the binding model by adding
+
+``void registerYourModelNameModel(std::unordered_map>& bindings);``
+
+to the ``src\libcadet\BindingModelFactory.cpp`` at the end of all the other registering functions such as ``void registerLinearModel``.
+Then add
+
+``model::binding::registerExampleModel(_bindingModels);``
+
+to the ``BindingModelFactory.cpp`` at the end of all the other registering functions such as ``model::binding::registerLinearModel(_bindingModels)``.
+The final step to register your model is to add your model to the ``\src\libcadet\CMakeLists.txt`` (again look for similar statements for the other binding models) by adding
+
+``${CMAKE_SOURCE_DIR} /src/libcadet/model/binding/ExampleBinding.cpp``
+
+Before continuing with the third step, you should rebuild CADET-Core to verify that the first two steps went well.
+
+3.
+The actual implementation of the new binding model follows two main steps: the configuration of the relevant mechanistic parameters and implementation of adsorption flux and Jacobian.
+To set up the configuration of isotherm parameters a macro (.json script) has been included in the code, which generates the relevant code section when the user defines the parameters in the scope of this script.
+To modify the script go to Line 30 in the provided file template and adjust the parameters to your needs, a more detailed description for that is provided in the `aforementioned forum post `_.
+
+Next, the adsorption flux equations need to be implemented int the corresponding function
+
+``int fluxImpl(double t, unsigned int secIdx, const ColumnPosition& colPos, StateType const* y, CpStateType const* yCp, ResidualType* res, LinearBufferAllocator workSpace) const``
+
+For an explanation of ``active`` types for the template arguments ``StateType``, ``ParamType``, ``ResidualType``, please refer to the Algorithmic Differentiation section.
+
+Finally, the Jacobian needs to be implemented in the function
+
+``void jacobianImpl()``
+
+We note that the Jacobian implementation is optional but highly recommended to speed up the simulation.
+If you have trouble with deriving the Jacobian or if you want to test you model first, modify the
+``implementsAnalyticJacobian()``
+function to return false.
+By doing so, CADET-Core defaults to computing the binding `Jacobian via Algorithmic differentiation (AD) `_.
+
+
+Unit Operation
+^^^^^^^^^^^^^^
+
+The easiest way to create a new unit operation in CADET-Core is to start from an existing unit operation (e.g. ``src/libcadet/StirredTankModel``, but optimally the most similar one) and make adjustments from there.
+The first, model independent steps are:
+
+1. Add ``NewModel.cpp`` and ``NewModel.hpp`` files in ``src\libcadet\model`` folder (copy and rename existing ones). Note that we'll call the new model "NewModel" from here on, so make sure to substitute this with the actual name of your model.
+2. Add ``${CMAKE_SOURCE_DIR}/src/libcadet/model/NewModel.cpp`` to the ``src/libcadet/CMakeLists.txt``
+3. (Optional) In the root/CMakeLists.txt file, you can add a build option to make building your new model optional. This enables building CADET versions with and without the new extension. This can be done, e.g., when additional dependencies are required or when build time should be reduced. See e.g. ``ENABLE_GRM_2D`` or ``ENABLE_DG``.
+4. Add new model to ModelBuilder (in ModelBuilderImpl.cpp, just like the other models are included):
+5. Rename everything to the new model
+ a. Change the ``identifier()`` function in the ``NewModel.hpp`` to return a new unique model name (here: "NewModel")
+ b. Adjust the ``registerNewModel()`` function in the ``NewModel.cpp`` accordingly
+ c. rename all functions, i.e. substitute the previous (copied) model name by your model name. Also do this for the header guards in the hpp file and the include in the cpp (essentially every occurrence of the old model name has to be changed).
+6. Try to build (and maybe even run) the new unit operation, which at this point is essentially still the same as the copied one, to make sure everything is set up correctly.
+
+You are now ready to implement your model in CADET-Core.
+Note that you will probably have to clean up a lot of things from the copied unit operation and that you also need to change the documentation comments to match your model and implementation.
+
+Most important functionality to be implemented:
+
+1. configure(): Model configuration parameters are read from the .h5 file and exceptions are thrown if parameters are missing or have the wrong size or format. Furthermore, if required, implicitly given parameters are determined and memory is allocated.
+2. configureModelDiscretization(): Similar to the function above but treats the numerical discretization part.
+3. residualImpl(): Implements the residual formulation (i.e. function :math:`F = 0`) of the equations. Triggers updates of the (possibly state dependent) system Jacobian.
+4. System Jacobian: Owned by the unit operation. Defined given by :math:`J := \frac{\partial F}{\partial y} + \alpha \frac{\partial F}{\partial \dot{y}}`, i.e. both the state and state derivative Jacobian need to be implemented.
+5. Linear solve: Solves the system :math:`J x = b` with given :math:`b`.
+6. Algorithmic differentiation (AD):
+ a. Parameter sensitivities: Use ``ParamType`` for all parameters and ``ResidualType`` for the residual.
+ b. Jacobian calculation via AD (can be used to verify the analytical implementation): Use ``StateType`` for the state and ``ResidualType`` for the residual. Additionally, you need to implement the following functions to enable the AD Jacobian: ``requiredADdirs()``, ``prepareADvectors``, ``extractJacobianFromAD()``, ``useAnalyticJacobian()``. For details please refer to `Pttmann et al. `_.
+
+Testing and Publication
+^^^^^^^^^^^^^^^^^^^^^^^
+Many extensions of CADET-Core result in both software and paper publications.
+Over the years we have established standard procedures to ensure good quality of the publication, including research data management and reproducability of the results.
+An important part of the publication procedure on the software side is the implementation of tests:
+Every model or method extension of CADET-Core has to be tested adequatly before it can be merged into the master branch.
+Even if your extension is not planned to become a contribution to the master branch, rigorous testing should still be implemented as it is essential to ensure confidence in your code.
+Please refer to the :ref:`testing` section for more technical information on the implementation of tests in CADET-Core.
+
+We highly recommend reading the reference tests subsection within the :ref:`testing` section before writing the paper, as the testing procedure that we describe strongly overlaps with the model/method validation part, which should be part of the publication.
+
+Algorithmic differentiation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+AD in CADET-Core can be used to compute parameter sensitivities and/or the Jacobian of the system.
+The custom AD implementation introduces an ``active`` type (see `AutoDiff.hpp `_), which is treated as a scalar but holds multiple double values.
+The first ``active`` entry holds the actual double value of the variable.
+The latter ``active`` entries hold the derivatives of that variable w.r.t different directions.
+Directions can either be the parameter(s) whose sensitivity we want to calculate or, if we compute the Jacobian via AD, an entry of the discrete state vector.
+
+To use AD for a new binding model, you only need to use the template types properly:
+Use ``ParamType`` and ``ResidualType`` for parameters and residual ``res`` to enable parameter sensitivities; that is, all parameters must be defined as actives in the binding model and used as ParamType in the residual function.
+Use ``StateType`` and ``ResidualType`` for the state ``y`` and residual ``res`` to enable the AD Jacobian.
+
+To use AD for a new unit operation, you can either apply dense AD or, in case of a model with many states or spatial resolution, you need to think of the shape of the Jacobian and apply sparse AD.
diff --git a/v5.0.1/_sources/developer_guide/release_new_version.rst.txt b/v5.0.1/_sources/developer_guide/release_new_version.rst.txt
new file mode 100644
index 000000000..051373f8d
--- /dev/null
+++ b/v5.0.1/_sources/developer_guide/release_new_version.rst.txt
@@ -0,0 +1,54 @@
+.. _release_new_version:
+
+CADET-Core version release
+==========================
+
+CADET-Core releases follow the semantic versioning system, which is documented `here `_.
+
+Release checklist
+-----------------
+
+- Run the release tests:
+
+ - The release tests contain extensive testing that is not included in our CI, such as EOC tests.
+ Running these tests might take a while and this should be done on the server.
+ - Some tests are implemented in CADET-Core, and can be run with the [ReleaseCI] flag.
+ - More tests are implemented in Python, the code can be found in `CADET-Verification `_
+ Compare the results with the previous run.
+ The release process can only be continued if the results are reasonable.
+
+- Run performance benchmarks:
+
+ - If numerical algorithms were refactored or if performance-critical infrastructure was changed, you should run performance benchmarks to compare the latest release with the planned new one.
+ To this end, you can refer to the performance benchmark templates in CADET-Reference, e.g. the `benchmark for the modified Newton method `_
+
+- Create a version bump commit, which will be the target commit for the release.
+ The bump commit contains:
+
+ - Update of the version number in the `version.txt` and in the zenodo.json
+ - Update of the authors list if needed: CONTRIBUTING.md and zenodo.json
+ - Update of the copyright (years)
+ - Update of the file format if needed
+
+- Create the release on github `here `_.
+
+ - Add the version number according to the semantic versioning system as the tag and set the master branch as target.
+ - Add release notes with these categories:
+
+ - Added: New features, enhancements, or functionalities introduced in this release.
+ - Fixed: Bug fixes and corrections made to resolve issues from previous versions.
+ - Changed: Modifications to existing features and breaking changes for major releases including changes in the interface.
+ - Updated: Improvements to documentation, minor tweaks, or other updates that don’t fit into the other categories.
+
+ - Attach the (zipped) source code.
+
+- Check success of zenodo archiving:
+
+ - Upon release, Zenodo automatically archives the release, generating a version-specific DOI (Digital Object Identifier) for it and storing a copy of the source code, along with any associated files.
+ The `concept DOI `_, which is also given in the repository README, does not change but represents the repository as a whole and always points to the latest version.
+
+Release of binaries on conda-forge
+----------------------------------
+
+To ensure CADET-Core is accessible to a broad community, it is available as a Python package on conda-forge.
+Other software, such as our Python interface, `CADET-Python`, and the frontend, `CADET-Process`, import this package.
diff --git a/v5.0.1/_sources/developer_guide/testing.rst.txt b/v5.0.1/_sources/developer_guide/testing.rst.txt
new file mode 100644
index 000000000..b0473a686
--- /dev/null
+++ b/v5.0.1/_sources/developer_guide/testing.rst.txt
@@ -0,0 +1,115 @@
+.. _testing:
+
+CADET-Core testing
+==================
+
+Run the tests
+-------------
+
+If you want to run tests in CADET-Core you need to ensure that in the `CMakeSettings.json` file:
+
+1. The ``cmakeCommandArgs`` contain:
+ 1. ``-DENABLE_TESTS=ON`` to enable building the test runner
+ 2. ``-DENABLE_STATIC_LINK_LAPACK=ON -DENABLE_STATIC_LINK_DEPS=ON`` to create statically linked dependencies
+2. The `variables` field contains:
+.. code-block:: json
+ {
+ "name": "HDF5_USE_STATIC_LIBRARIES",
+ "value": "1",
+ "type": "STRING"
+ },
+ {
+ "name": "BUILD_SHARED_LIBS",
+ "value": "0",
+ "type": "STRING"
+ }
+
+
+After building, you can find the testRunner.exe in ``CADET-root/build/test/Release`` or, when build in debug mode, in ``CADET-root/build/test/Debug``.
+
+To debug specific tests (with flag [testHere]) from the Visual Studio IDE, you can add the following configuration to the launch.vs.json file mentioned in the :ref:`debugging` section:
+
+.. code-block:: json
+ {
+ "type": "default",
+ "project": "CMakeLists.txt",
+ "projectTarget": "testRunner.exe (test/Debug/testRunner.exe)",
+ "name": "testRunner.exe (test/Debug/testRunner.exe)",
+ "args": [
+ "[testHere]"
+ ]
+ }
+
+Select the testRunner.exe in the startup item dropdown menu and you can start debugging tests with the specified flag.
+
+Adding tests for your model
+---------------------------
+
+Every model and numerical method implemented in CADET-Core has to be tested adequatly.
+Here, we distinguish between unit tests and numerical reference tests.
+
+Unit tests
+^^^^^^^^^^
+
+Unit tests are designed to verify the correctness of individual units or components of code in isolation.
+Unit tests in CADET-Core typically encompass tests for the Jacobian implementation and consistent initialization of the model, which can be adapted from corresponding existing tests.
+Testing the Jacobian typically involves comparing the analytical Jacobian to the AD Jacobian to verify that the residual implementation is consistent to the analytical Jacobian.
+To this end, it might be necessary to increase the maximum number of AD directions for your test case, which can be done via the cmake argument `NUM_MAX_AD_DIRS`, as described in the :ref:`build_options`.
+
+Numerical reference tests
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Every major feature of the model or numerical method should be tested in a separate test case, preferably recreating examples from literature, including your own publication on the corresponding CADET extension.
+This section provides a guide on creating reference tests, including convergence tables and research data management (RDM).
+We strongly emphasize that the procedure described here should be taken into consideration not just as part of the software testing but also for method/model validation, especially when a paper publication is planned.
+
+We utilize `CADET-Database `_ and `CADET-Verification `_ to ensure reproducibility of the tests.
+
+We recommend using this procedure not only for the tests but also for the publication to make good standards regarding RDM.
+
+The general procedure how to add a reference test is as follows:
+
+**1. Define your model setup in CADET-Database:**
+The easiest way to do this, is to clone the `CADET-Database `_, checkout the core_tests branch and store your model setup file as a json file in the cadet-config folder.
+You can create this json config file by translating the standard CADET h5 file to a json using python, see the utility/h5ToJson.py script for reference.
+Make sure to give your model setup a meaningful and unique name (follow the naming logic of other setups in that folder).
+Note that the return data should only specify the output required for the reference test, i.e. usually the outlet of a single unit.
+
+**2. Add a CADET-Verification script:**
+This python script reads the model setup from CADET-Database and generates all the reference data that will be used in your tests.
+This includes a specific low resolution reference solution as well as convergence (EOC) tables computed using a high precision solution.
+If analytical solutions are available for the considered model, you should use that as the high precision solution.
+Otherwise, you additionally need to generate a very high resolution numerical reference solution, preferably with an accuracy of at least :math:`\mathcal{L}_\text{inf} \approx 1e-8`.
+
+**3. Add numerical reference tests to CADET-Core:**
+These tests should read the model setups previously defined in CADET-Database and run them with the same numerical specification as used to compute the reference solutions computed by the CADET-Verification script.
+The resulta are compared to the reference solution generated by CADET-Verification.
+This type of tests ensures that the model is still functional and that the numerics for this model have not changed.
+Hence, every major feature of the model should be tested in a separete tests.
+This way, we make sure that ongoing CADET-Core development doesnt break the model and these tests should be included in the CI pipeline by adding the [CI] flag as described in the implementation procedure section.
+
+**4. Add EOC tests to CADET-Core (optional):**
+These tests should be part of the paper publication which introduces the new model implemented in CADET-Core and can also be included in the CADET-Core tests.
+Verifying the experimental order of convergence (EOC) is widely considered the most rigorous and best scientific practice in model and method validation, which is why we recommend including the EOC tables in your publication.
+The convergence tests should not be added to the standard CI but only be rerun on release, i.e. by adding the [releaseCI] flag.
+Details on how to compute EOC tables can be found elsewhere, please also refer to the already implemented EOC tests in CADET-Verification.
+
+Manufactured solution
+^^^^^^^^^^^^^^^^^^^^^
+If no analytical solution is available for your model, you can use a so-called "manufactured solution" to verify your implementation.
+A manufactured solution was implemented e.g. for the radial flow model, see test/testRadialKernel.cpp.
+
+Implementation procedure
+^^^^^^^^^^^^^^^^^^^^^^^^
+Create a new test file ``test\NewModelMethod.cpp``, an easy way to begin with is to copy one of the files that implements tests which are the closest to the ones that you are planning on, e.g. LumpedRateModelWithPores to test a new unit operation.
+Add your tests to the testrunner executable by adding ``NewModelMethod.cpp`` to the list in the command ``add_executable(testrunner`` within the ``test\CmakeList.txt`` file.
+Note that every test needs an unique name, which is specified for each test by ``TEST_CASE("My first test", "[FLAG1],[FLAG2]")``.
+Flags are used as options for the testrunner.exe and are specified within square brackets.
+Reuse existing flags and add new ones for your extension.
+The ``[CI]`` flag is used for tests that shall be rerun as part of our github continuous integration (CI) pipeline.
+
+Maintenance of the tests
+------------------------
+
+Some changes will break the tests without them being necessarily wrong. A change in the numerics for instance, will most likely break some tests.
+This can be fixed by carefully adapting the absolute and relative tolerances for the broken tests. These changes should not change the magnitude of the tolerances, except if this is within an acceptable and expected new tolerance).
diff --git a/v5.0.1/_sources/examples/batch_chromatography.rst.txt b/v5.0.1/_sources/examples/batch_chromatography.rst.txt
new file mode 100644
index 000000000..6f408bb3b
--- /dev/null
+++ b/v5.0.1/_sources/examples/batch_chromatography.rst.txt
@@ -0,0 +1,3 @@
+Batch chromatography
+====================
+
diff --git a/v5.0.1/_sources/examples/index.rst.txt b/v5.0.1/_sources/examples/index.rst.txt
new file mode 100644
index 000000000..6885aed41
--- /dev/null
+++ b/v5.0.1/_sources/examples/index.rst.txt
@@ -0,0 +1,12 @@
+.. _examples:
+
+Examples
+========
+
+.. toctree::
+ :maxdepth: 2
+
+ reaction_cstr
+ rtd
+ batch_chromatography
+ load_wash_elute
diff --git a/v5.0.1/_sources/examples/load_wash_elute.rst.txt b/v5.0.1/_sources/examples/load_wash_elute.rst.txt
new file mode 100644
index 000000000..d811f9944
--- /dev/null
+++ b/v5.0.1/_sources/examples/load_wash_elute.rst.txt
@@ -0,0 +1,3 @@
+Load Wash Elute
+===============
+
diff --git a/v5.0.1/_sources/examples/reaction_cstr.rst.txt b/v5.0.1/_sources/examples/reaction_cstr.rst.txt
new file mode 100644
index 000000000..31ff5a3ef
--- /dev/null
+++ b/v5.0.1/_sources/examples/reaction_cstr.rst.txt
@@ -0,0 +1,2 @@
+Chemical reactions
+==================
diff --git a/v5.0.1/_sources/examples/rtd.rst.txt b/v5.0.1/_sources/examples/rtd.rst.txt
new file mode 100644
index 000000000..591d27ffe
--- /dev/null
+++ b/v5.0.1/_sources/examples/rtd.rst.txt
@@ -0,0 +1,3 @@
+Residence time distributions
+============================
+
diff --git a/v5.0.1/_sources/getting_started/build_linux.rst.txt b/v5.0.1/_sources/getting_started/build_linux.rst.txt
new file mode 100644
index 000000000..1039b2f23
--- /dev/null
+++ b/v5.0.1/_sources/getting_started/build_linux.rst.txt
@@ -0,0 +1,7 @@
+.. _build_linux:
+
+Build for Linux
+===============
+
+.. include:: ../../BUILD-LINUX.md
+ :parser: myst_parser.sphinx_
diff --git a/v5.0.1/_sources/getting_started/build_osx.rst.txt b/v5.0.1/_sources/getting_started/build_osx.rst.txt
new file mode 100644
index 000000000..c8b01a522
--- /dev/null
+++ b/v5.0.1/_sources/getting_started/build_osx.rst.txt
@@ -0,0 +1,7 @@
+.. _build_osx:
+
+Build for OSX
+=============
+
+.. include:: ../../BUILD-OSX.md
+ :parser: myst_parser.sphinx_
diff --git a/v5.0.1/_sources/getting_started/build_windows.rst.txt b/v5.0.1/_sources/getting_started/build_windows.rst.txt
new file mode 100644
index 000000000..4f9061fec
--- /dev/null
+++ b/v5.0.1/_sources/getting_started/build_windows.rst.txt
@@ -0,0 +1,7 @@
+.. _build_windows:
+
+Build for MS Windows
+====================
+
+.. include:: ../../BUILD-WINDOWS.md
+ :parser: myst_parser.sphinx_
diff --git a/v5.0.1/_sources/getting_started/index.rst.txt b/v5.0.1/_sources/getting_started/index.rst.txt
new file mode 100644
index 000000000..d9a39fcaf
--- /dev/null
+++ b/v5.0.1/_sources/getting_started/index.rst.txt
@@ -0,0 +1,16 @@
+.. _getting_started:
+
+Getting started
+===============
+
+This section details the steps to install CADET, as pre-built binaries or building from scratch, and also provides the series of tutorials that will help in building complete model from scratch in CADET.
+
+.. toctree::
+ :maxdepth: 1
+
+ installation
+
+.. toctree::
+ :maxdepth: 1
+
+ tutorials/breakthrough
diff --git a/v5.0.1/_sources/getting_started/installation.rst.txt b/v5.0.1/_sources/getting_started/installation.rst.txt
new file mode 100644
index 000000000..3c05ffbb5
--- /dev/null
+++ b/v5.0.1/_sources/getting_started/installation.rst.txt
@@ -0,0 +1,56 @@
+.. _installation:
+
+Installation
+============
+
+A CADET installation consists of two parts: The CADET core simulator and a frontend.
+
+Install CADET core simulator
+----------------------------
+
+The core simulator can be compiled from source, or you can download pre-built binaries.
+If you want to extend or modify CADET (e.g., add a custom binding model), you will need to build CADET from source.
+
+Install pre-built binaries
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+CADET can be installed via `conda `_ from the ``conda-forge channel``.
+
+``conda install -c conda-forge cadet``
+
+Optionally, use `mamba `_ which uses a faster dependency solver than ``conda``.
+
+``mamba install -c conda-forge cadet``
+
+Install from source
+^^^^^^^^^^^^^^^^^^^
+
+- :ref:`build_linux`
+- :ref:`build_windows`
+- :ref:`build_osx`
+
+.. _cadet_process:
+
+Install a frontend
+------------------
+
+CADET provides a Python API, called ``CADET-Python``, which can be used to set the model input according to the Interface specifications section.
+Setting up the model using ``CADET-Python`` can become very tedious, especially for systems, and is outdated now that an actual frontend is available:
+
+We recommend using the ``CADET-Process`` frontend, which facilitates modeling processes using an object oriented model builder.
+This interface layer provides convenient access to all model parameters in the system.
+It automatically checks validity of the parameter values and sets reasonable default values where possible.
+
+Install CADET-Process
+^^^^^^^^^^^^^^^^^^^^
+
+To install ``CADET-Process``, open an `anaconda shell` or `mamba shell` and execute:
+
+.. code-block:: bash
+
+ pip install CADET-Process
+
+If you want to use ``CADET-Python``, open an `anaconda shell` or `mamba shell` and execute:
+
+.. code-block:: bash
+
+ pip install CADET-Python
\ No newline at end of file
diff --git a/v5.0.1/_sources/getting_started/tutorials/breakthrough.rst.txt b/v5.0.1/_sources/getting_started/tutorials/breakthrough.rst.txt
new file mode 100644
index 000000000..f0cabaf76
--- /dev/null
+++ b/v5.0.1/_sources/getting_started/tutorials/breakthrough.rst.txt
@@ -0,0 +1,139 @@
+CADET Introduction
+==================
+
+Performing a forward simulation comprises several steps:
+ * Setting up the model including all parameters
+ * Defining connectivity and dynamic events
+ * Setting up the simulator and actually running the simulation
+ * Evaluating results (e.g., plotting)
+
+In this tutorial, we will build a simple forward simulation with a breakthrough of one component using the following system:
+
+.. figure:: _images/breakthrough_system.svg
+
+For this purpose, we use `CADET-Process `_, an object oriented Python frontend for CADET.
+CADET still must be downloaded (or built from source) as explained in the :ref:`installation guide `.
+
+.. figure:: _images/cadet_architecture_overview.png
+
+ Relations between CADET-Core, CADET-Python, and CADET-Process.
+
+For more information on how to set up models using CADET-Python, a plain file based API for CADET, please refer to the :ref:`cadet_python`.
+
+1. Setting Up the Model
+-----------------------
+
+We first create a ``ComponentSystem``.
+The ``ComponentSystem`` ensures that all parts of the process have the same number of components.
+Moreover, components can be named which automatically adds legends to the plot methods.
+
+.. literalinclude:: ../../examples/breakthrough.py
+ :lines: 2-5
+
+
+Inlet Model
+^^^^^^^^^^^
+
+In CADET, the ``Inlet`` pseudo unit operation serves as a source for the system and is used to create arbitary concentration profiles as boundary conditions.
+The concentration profile is described using a piecewise cubic polynomial (cubic spline in the continuous case) for each component, where the pieces are given by the time sections.
+In this example we set a constant inlet concentration of 1 mM.
+
+.. literalinclude:: ../../examples/breakthrough.py
+ :lines: 9-13
+
+
+Column Model
+^^^^^^^^^^^^
+Adsorption Model
+~~~~~~~~~~~~~~~~
+
+Every unit operation model can be equipped with an adsorption model.
+The available models are listed in the :ref:`binding model chapter `.
+
+For the :ref:`Langmuir model `, we use the ``Langmuir`` class.
+Then, we decide if we want to use the :ref:`rapid-equilibrium assumption ` in the binding model (``binding_model.is_kinetic = False``), which is not the case here (dynamic binding).
+Finally, the parameters of the binding model have to be set for each component (they are vectors of length ``n_components``).
+All model parameters can be listed using the ``parameters`` attribute.
+In case of the Langmuir model, we have to specify the parameters ``adsorption_rate``, ``desorption_rate``, and ``capacity``.
+
+.. literalinclude:: ../../examples/breakthrough.py
+ :lines: 18-24
+
+General Rate Model
+~~~~~~~~~~~~~~~~~~
+
+We now add a second unit operation, the column model.
+For the :ref:`general rate model model `, we use the ``GeneralRateModel`` class.
+In this class, we set the parameters related to transport and column geometry.
+
+.. literalinclude:: ../../examples/breakthrough.py
+ :lines: 28-42
+
+Note that film, pore, and surface diffusion are all component-specific, that is, they are vectors of length ``n_components``.
+
+Initial Conditions
+~~~~~~~~~~~~~~~~~~
+
+Next, we specify the initial conditions (concentration of the components in the mobile and stationary phases) for the column.
+These concentrations are entered as vectors, where each entry gives the concentration for the corresponding component.
+In this example, we start with an empty column.
+
+.. literalinclude:: ../../examples/breakthrough.py
+ :lines: 45-47
+
+
+^^^^^^^^^^^^
+
+The ``OUTLET`` is another pseudo unit operation that serves as sink for the system.
+
+.. note:: In this case, the outlet unit is actually not required. We could use the outlet concentration signal of the column model instead.
+
+.. literalinclude:: ../../examples/breakthrough.py
+ :lines: 50-52
+
+
+System Connectivity
+^^^^^^^^^^^^^^^^^^^
+
+The connectivity of unit operations is defined in the ``FlowSheet`` class.
+This class provides a directed graph structure that allows for the simple definition of configurations for multiple columns or reactor-separator networks, even when they are cyclic.
+We add the previously defined units to the flow sheet and add connections between them.
+
+.. literalinclude:: ../../examples/breakthrough.py
+ :lines: 55-64
+
+.. note:: Since the flow in the column models is incompressible, the total entering flow rate must equal the total outgoing flow rate.
+ This restriction does not apply to a :ref:`CSTR model `, because it has a variable volume.
+
+
+Process properties
+^^^^^^^^^^^^^^^^^^^
+The ``Process`` class is used to define dynamic changes of model parameters or flow sheet connections.
+This includes the duration of a simulation (``cycle_time``).
+To instantiate a ``Process``, a ``FlowSheet`` needs to be passed as argument, as well as a string to name that process.
+
+.. literalinclude:: ../../examples/breakthrough.py
+ :lines: 67-70
+
+
+3. Setting Up the Simulator and Running the Simulation
+------------------------------------------------------
+
+To simulate a ``Process``, a simulator needs to be configured.
+The simulator translates the ``Process`` configuration into the API of the corresponding simulator.
+
+.. literalinclude:: ../../examples/breakthrough.py
+ :lines: 72-76
+
+4. Plotting the Results
+-----------------------
+
+The data is stored in the ``.solution`` group of the ``SimulationResults`` object.
+Finally, we plot the concentration signal at the outlet of the column.
+
+.. literalinclude:: ../../examples/breakthrough.py
+ :lines: 78
+
+.. image:: _images/breakthrough_chromatogram.png
+
+For further details on the front-end and more examples please refer to the `CADET-Process `_ documentation.
diff --git a/v5.0.1/_sources/index.rst.txt b/v5.0.1/_sources/index.rst.txt
new file mode 100644
index 000000000..d54b536ac
--- /dev/null
+++ b/v5.0.1/_sources/index.rst.txt
@@ -0,0 +1,128 @@
+.. _contents:
+
+.. image:: _static/cadet_logo.png
+
+|
+
+.. image:: https://img.shields.io/github/release/cadet/cadet-core.svg
+ :target: https://github.com/cadet/cadet-core/releases
+
+.. image:: https://github.com/cadet/cadet-core/actions/workflows/ci.yml/badge.svg?branch=master
+ :target: https://github.com/cadet/cadet-core/actions/workflows/ci.yml?query=branch%3Amaster
+
+.. image:: https://anaconda.org/conda-forge/cadet/badges/downloads.svg
+ :target: https://anaconda.org/conda-forge/cadet
+
+.. image:: https://zenodo.org/badge/DOI/10.5281/zenodo.8179015.svg
+ :target: https://doi.org/10.5281/zenodo.8179015
+
+.. image:: https://img.shields.io/badge/JuRSE_Code_Pick-Oct_2024-blue.svg
+ :target: https://www.fz-juelich.de/en/rse/community-initiatives/jurse-code-of-the-month/october-2024
+|
+
+CADET
+=====
+CADET is developed at the Institute of Bio- and Geosciences 1 (IBG-1) of Forschungszentrum Jülich (FZJ) under supervision of Dr. Eric von Lieres.
+The heart of the CADET software is a fast and accurate solver for a comprehensive model family.
+Typical applications include (but are by far not limited to) chromatography, filtration, crystallization, and fermentation.
+CADET can handle arbitrary sequences and networks of unit operations, including reactors, tanks, tubes, pumps, valves, detectors, etc.
+The resulting models are solved with state-of-the-art mathematical algorithms and scientific computing techniques.
+
+- **Forum:** https://forum.cadet-web.de
+- **Source:** https://github.com/cadet/cadet-core
+- **Demo:** http://cadet-web.de
+- **Newsletter:** https://cadet-web.de/newsletter/
+
+Features
+--------
+
+* Fast and accurate solution of strongly coupled partial differential algebraic equations (PDAE)
+* Computation of parameter sensitivities with algorithmic differentiation (AD)
+* Shared memory parallelization using Intel TBB
+* Python interface
+* Support of HDF5 and XML data formats
+* Flexible and extensible through modular design
+* Works on Windows, Linux, and Mac OS X
+
+
+Installation
+------------
+CADET can be installed via conda from the ``conda-forge`` channel.
+
+``conda install -c conda-forge cadet``
+
+This requires a working `conda installation `_.
+
+Optionally, use `mamba `_ which uses a faster dependency solver than ``conda``.
+
+``mamba install -c conda-forge cadet``
+
+For more information on how to install and build CADET, see :ref:`here `.
+
+Ongoing Development
+-------------------
+
+We do our best to provide you with a stable API.
+However, CADET is actively developed and breaking changes can sometimes be unavoidable.
+For non-developers, it is recommended to upgrade from release to release instead of always working with the most recent commit.
+
+
+Bugs
+----
+
+Please report any bugs that you find `here `_. Or, even better, fork the repository on `GitHub `_ and create a pull request (PR) with the fix.
+
+Donations
+---------
+
+`Donations `_ for helping to host, maintain, and further develop the CADET project are highly appreciated.
+
+
+Citing
+------
+
+The development of CADET has been a collaborative effort, with multiple dedicated individuals contributing their expertise to create a powerful and versatile open-source software tool.
+Countless hours of hard work have been invested to provide the scientific community with a valuable resource.
+As an open-source project, CADET relies on the support and recognition from users and researchers to thrive.
+Therefore, we kindly ask that any publications or projects leveraging the capabilities of CADET acknowledge its creators and their contributions by citing an adequate selection of our publications.
+
+**General:**
+
+- Leweke, S.; von Lieres, E.: `Chromatography Analysis and Design Toolkit (CADET) `_, Computers and Chemical Engineering **113** (2018), 274–294.
+
+- von Lieres, E.; Andersson, J.: `A fast and accurate solver for the general rate model of column liquid chromatography `_, Computers and Chemical Engineering **34,8** (2010), 1180–1191.
+
+**Numerics:**
+
+- Breuer, J. M.; Leweke, S.; Schmölder, J.; Gassner, G.; von Lieres, E.: `Spatial discontinuous Galerkin spectral element method for a family of chromatography models in CADET `_, Computers and Chemical Engineering **177** (2023), 108340.
+
+- Leweke, S.; von Lieres, E.: `Fast arbitrary order moments and arbitrary precision solution of the general rate model of column liquid chromatography with linear isotherm `_, Computers and Chemical Engineering **84** (2016), 350–362.
+
+- Püttmann, A.; Schnittert, S.; Naumann, U.; von Lieres, E.: `Fast and accurate parameter sensitivities for the general rate model of column liquid chromatography `_, Computers and Chemical Engineering **56** (2013), 46–57.
+
+Additionally, to ensure reproducibility of your work, we recommend citing the `zenodo doi `_ corresponding to the specific CADET release that you used.
+
+Selected applications that demonstrate the capabilities and use-cases of CADET are highlighted `here `_.
+
+Acknowledgments
+---------------
+
+Please refer to the `list of contributors `_ who helped building and funding this project.
+
+
+.. toctree::
+ :maxdepth: 3
+ :hidden:
+
+ getting_started/index
+ modelling/index
+ simulation/index
+ interface/index
+ developer_guide/index
+ .. examples/index
+ CADET-Match
+ license
+ zbibliography
+ Legal notice
+
+
diff --git a/v5.0.1/_sources/interface/binding/bi_steric_mass_action.rst.txt b/v5.0.1/_sources/interface/binding/bi_steric_mass_action.rst.txt
new file mode 100644
index 000000000..4ece990b1
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/bi_steric_mass_action.rst.txt
@@ -0,0 +1,89 @@
+.. _bi_steric_mass_action_config:
+
+Bi Steric Mass Action
+~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = BI_STERIC_MASS_ACTION**
+
+For information on model equations, refer to :ref:`bi_steric_mass_action_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =======================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =======================
+
+``BISMA_KA``
+ Adsorption rate constants in state-major ordering
+
+**Unit:** :math:`m_{MP}^{3}~m_{SP}^{-3}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NSTATES :math:`\cdot` NCOMP
+=================== ========================= =========================================
+
+``BISMA_KD``
+ Desorption rate constants in state-major ordering
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NSTATES :math:`\cdot` NCOMP
+=================== ========================= =========================================
+
+``BISMA_NU``
+ Characteristic charges :math:`\nu_{i,j}` of the :math:`i`\ th protein
+ with respect to the :math:`j`\ th binding site type in state-major
+ ordering
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NSTATES :math:`\cdot` NCOMP
+=================== ========================= =========================================
+
+``BISMA_SIGMA``
+ Steric factors :math:`\sigma_{i,j}` of the :math:`i`\ th protein with
+ respect to the :math:`j`\ th binding site type in state-major
+ ordering
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NSTATES :math:`\cdot` NCOMP
+=================== ========================= =========================================
+
+``BISMA_LAMBDA``
+ Stationary phase capacity (monovalent salt counterions) of the
+ different binding site types :math:`\lambda_j`
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= ===============================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NSTATES
+=================== ========================= ===============================
+
+``BISMA_REFC0``
+ Reference liquid phase concentration for each binding site type or
+ one value for all types (optional, defaults to :math:`1.0`)
+
+**Unit:** :math:`mol~m_{MP}^{-3}`
+
+=================== ========================= ===============================
+**Type:** double **Range:** :math:`\gt 0` **Length:** {1,NSTATES}
+=================== ========================= ===============================
+
+``BISMA_REFQ``
+ Reference solid phase concentration for each binding site type or one
+ value for all types (optional, defaults to :math:`1.0`)
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= ===============================
+**Type:** double **Range:** :math:`\gt 0` **Length:** {1,NSTATES}
+=================== ========================= ===============================
diff --git a/v5.0.1/_sources/interface/binding/extended_mobile_phase_modulator_langmuir.rst.txt b/v5.0.1/_sources/interface/binding/extended_mobile_phase_modulator_langmuir.rst.txt
new file mode 100644
index 000000000..eb2e1fa74
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/extended_mobile_phase_modulator_langmuir.rst.txt
@@ -0,0 +1,78 @@
+.. _extended_mobile_phase_modulator_langmuir_config:
+
+Extended Mobile Phase Modulator Langmuir
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = EXTENDED_MOBILE_PHASE_MODULATOR**
+
+For information on model equations, refer to :ref:`extended_mobile_phase_modulator_langmuir_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``EMPM_COMP_MODE``
+ Determines the mode of each component (:math:`0` denotes the modifier
+ component, :math:`1` is linear binding, :math:`2` is modified Langmuir
+ binding). At most one modifier component is allowed, that is, a
+ modifier is not required.
+
+ Note that this field has the same name for the externally dependent
+ variant of the model.
+
+=================== ============================ =========================================
+**Type:** int **Range:** :math:`\{0,1,2\}` **Length:** NCOMP
+=================== ============================ =========================================
+
+``EMPM_KA``
+ Adsorption rate constants
+
+**Unit:** :math:`m_{MP}^3~mol^{-1}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``EMPM_KD``
+ Desorption rate constants
+
+**Unit:** :math:`m_{MP}^{3\beta}~mol^{-\beta}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``EMPM_QMAX``
+ Maximum adsorption capacities
+
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``EMPM_BETA``
+ Parameters describing the ion-exchange characteristics (IEX)
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``EMPM_GAMMA``
+ Parameters describing the hydrophobicity (HIC)
+
+**Unit:** :math:`m_{MP}^{3} mol^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
diff --git a/v5.0.1/_sources/interface/binding/freundlich_ldf.rst.txt b/v5.0.1/_sources/interface/binding/freundlich_ldf.rst.txt
new file mode 100644
index 000000000..9e84bbae5
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/freundlich_ldf.rst.txt
@@ -0,0 +1,54 @@
+.. _freundlich_ldf_config:
+
+Freundlich LDF
+~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = FREUNDLICH_LDF**
+
+For information on model equations, refer to :ref:`freundlich_ldf_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= ==================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= ==================================
+
+``FLDF_KKIN``
+ Driving force coefficient for each component
+
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= ==================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1/NTOTALBND
+=================== ========================= ==================================
+
+
+``FLDF_KF``
+ Freundlich coefficient for each component
+
+**Unit:** :math:`m_{MP}^{3/n}~m_{SP}^{-3}~mol^{1-1/n}`
+
+=================== ========================= ==================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1/NTOTALBND
+=================== ========================= ==================================
+
+``FLDF_N``
+ Freundlich exponent for each component
+
+**Unit:** [-]
+
+=================== ========================= ==================================
+**Type:** double **Range:** :math:`> 0` **Length:** 1/NTOTALBND
+=================== ========================= ==================================
+
+
+
+
+
+
diff --git a/v5.0.1/_sources/interface/binding/generalized_ion_exchange.rst.txt b/v5.0.1/_sources/interface/binding/generalized_ion_exchange.rst.txt
new file mode 100644
index 000000000..9c6688562
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/generalized_ion_exchange.rst.txt
@@ -0,0 +1,181 @@
+.. _generalized_ion_exchange_config:
+
+Generalized Ion Exchange
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = GENERALIZED_ION_EXCHANGE**
+
+For information on model equations, refer to :ref:`generalized_ion_exchange_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``GIEX_KA``
+ Base value of adsorption rate constant
+
+**Unit:** :math:`m_{MP}^{3}~m_{SP}^{-3}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``GIEX_KA_LIN``
+ Coefficient of linear dependence of adsorption rate constant on
+ modifier component
+
+**Unit:** :math:`\text{[Mod]}^{-1}`
+
+=================== =========================
+**Type:** double **Length:** NCOMP
+=================== =========================
+
+``GIEX_KA_QUAD``
+ Coefficient of quadratic dependence of adsorption rate constant on
+ modifier component
+
+**Unit:** :math:`\text{[Mod]}^{-2}`
+
+=================== =========================
+**Type:** double **Length:** NCOMP
+=================== =========================
+
+``GIEX_KA_SALT``
+ Salt coefficient of adsorption rate constants; difference of
+ water-protein and salt-protein interactions
+
+=================== =========================
+**Type:** double **Length:** NCOMP
+=================== =========================
+
+``GIEX_KA_PROT``
+ Protein coefficient of adsorption rate constants; difference of
+ water-protein and protein-protein interactions
+
+**Unit:** :math:`m_{MP}^{3} mol^{-1}`
+
+=================== =========================
+**Type:** double **Length:** NCOMP
+=================== =========================
+
+``GIEX_KD``
+ Base value of desorption rate constant
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``GIEX_KD_LIN``
+ Coefficient of linear dependence of desorption rate constant on
+ modifier component
+
+**Unit:** :math:`\text{[Mod]}^{-1}`
+
+=================== =========================
+**Type:** double **Length:** NCOMP
+=================== =========================
+
+``GIEX_KD_QUAD``
+ Coefficient of quadratic dependence of desorption rate constant on
+ modifier component
+
+**Unit:** :math:`\text{[Mod]}^{-2}`
+
+=================== =========================
+**Type:** double **Length:** NCOMP
+=================== =========================
+
+``GIEX_KD_SALT``
+ Salt coefficient of desorption rate constants; difference of
+ water-protein and salt-protein interactions
+
+=================== =========================
+**Type:** double **Length:** NCOMP
+=================== =========================
+
+``GIEX_KD_PROT``
+ Protein coefficient of desorption rate constants; difference of
+ water-protein and protein-protein interactions
+
+**Unit:** :math:`m_{MP}^{3} mol^{-1}`
+
+=================== =========================
+**Type:** double **Length:** NCOMP
+=================== =========================
+
+``GIEX_NU``
+ Base value for characteristic charges of the protein; The number of
+ sites :math:`\nu` that the protein interacts with on the resin
+ surface
+
+=================== =========================
+**Type:** double **Length:** NCOMP
+=================== =========================
+
+``GIEX_NU_LIN``
+ Coefficient of linear dependence of characteristic charge on modifier
+ component
+
+**Unit:** :math:`\text{[Mod]}^{-1}`
+
+=================== =========================
+**Type:** double **Length:** NCOMP
+=================== =========================
+
+``GIEX_NU_QUAD``
+ Coefficient of quadratic dependence of characteristic charge on
+ modifier component
+
+**Unit:** :math:`\text{[Mod]}^{-2}`
+
+=================== =========================
+**Type:** double **Length:** NCOMP
+=================== =========================
+
+``GIEX_SIGMA``
+ Steric factors of the protein; The number of sites :math:`\sigma` on
+ the surface that are shielded by the protein and prevented from
+ exchange with the salt counterions in solution
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``GIEX_LAMBDA``
+ Stationary phase capacity (monovalent salt counterions); The total
+ number of binding sites available on the resin surface
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
+``GIEX_REFC0``
+ Reference liquid phase concentration (optional, defaults to
+ :math:`1.0`)
+
+**Unit:** :math:`mol~m_{MP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** 1
+=================== ========================= =========================================
+
+``GIEX_REFQ``
+ Reference solid phase concentration (optional, defaults to
+ :math:`1.0`)
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** 1
+=================== ========================= =========================================
diff --git a/v5.0.1/_sources/interface/binding/hic_constant_water_activity.rst.txt b/v5.0.1/_sources/interface/binding/hic_constant_water_activity.rst.txt
new file mode 100644
index 000000000..753f4ff87
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/hic_constant_water_activity.rst.txt
@@ -0,0 +1,80 @@
+.. _hic_constant_water_activity_config:
+
+HIC Constant Water Activity
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = HIC_CONSTANT_WATER_ACTIVITY**
+
+For information on model equations, refer to :ref:`hic_constant_water_activity_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =======================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =======================
+
+``HICCWA_KA``
+ Adsorption rate constant
+
+**Unit:** :math:`m_{MP}^{3}~m_{SP}^{-3}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``HICCWA_KD``
+ Desorption rate constant
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``HICCWA_NU``
+ Number of ligands per ligand-protein interaction
+
+**Unit: [-]**
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+
+``HICCWA_QMAX``
+ Maximum binding capacity
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+
+``HICCWA_BETA0``
+ Parameters describing the number of highly ordered water molecules
+ that stabilize the hydrophobic surfaces at infinitely diluted
+ salt concentration
+
+**Unit: [-]**
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
+``HICCWA_BETA1``
+ Parameters describing the change in the number of highly ordered
+ water molecules that stabilize the hydrophobic surfaces with
+ respect to changes in the salt concentration
+
+**Unit:** :math:`m_{MP}^{3}~mol^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
diff --git a/v5.0.1/_sources/interface/binding/hic_water_on_hydrophobic_surfaces.rst.txt b/v5.0.1/_sources/interface/binding/hic_water_on_hydrophobic_surfaces.rst.txt
new file mode 100644
index 000000000..31ff02484
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/hic_water_on_hydrophobic_surfaces.rst.txt
@@ -0,0 +1,80 @@
+.. _hic_water_on_hydrophobic_surfaces_config:
+
+HIC Water on Hydrophobic Surfaces
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = HIC_WATER_ON_HYDROPHOBIC_SURFACES**
+
+For information on model equations, refer to :ref:`hic_water_on_hydrophobic_surfaces_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =======================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =======================
+
+``HICWHS_KA``
+ Adsorption rate constant
+
+**Unit:** :math:`m_{MP}^{3}~m_{SP}^{-3}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``HICWHS_KD``
+ Desorption rate constant
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``HICWHS_NU``
+ Number of ligands per ligand-protein interaction
+
+**Unit: [-]**
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+
+``HICWHS_QMAX``
+ Maximum binding capacity
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+
+``HICWHS_BETA0``
+ Parameters describing the number of highly ordered water molecules
+ that stabilize the hydrophobic surfaces at infinitely diluted
+ salt concentration
+
+**Unit: [-]**
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
+``HICWHS_BETA1``
+ Parameters describing the change in the number of highly ordered
+ water molecules that stabilize the hydrophobic surfaces with
+ respect to changes in the salt concentration
+
+**Unit:** :math:`m_{MP}^{3}~mol^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
diff --git a/v5.0.1/_sources/interface/binding/index.rst.txt b/v5.0.1/_sources/interface/binding/index.rst.txt
new file mode 100644
index 000000000..a4e6e2c74
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/index.rst.txt
@@ -0,0 +1,74 @@
+.. _FFAdsorption:
+
+Binding models
+==============
+
+Externally dependent binding models
+-----------------------------------
+
+Some binding models have a variant that can use external sources as specified in :ref:`/input/model/external/` (also see Section :ref:`dependence-on-external-function_bind` for more information, and Section :ref:`binding_model_feature` on which binding models support this feature).
+For the sake of brevity, only the standard variant of those binding models is specified below.
+In order to obtain the format for the externally dependent variant, first replace the binding model name ``XXX`` by ``EXT_XXX``.
+Each parameter :math:`p` (except for reference concentrations ``XXX_REFC0`` and ``XXX_REFQ``) depends on a (possibly distinct) external source in a polynomial way:
+
+.. math::
+
+ \begin{aligned}
+ p(T) &= p_{\texttt{TTT}} T^3 + p_{\texttt{TT}} T^2 + p_{\texttt{T}} T + p.
+ \end{aligned}
+
+Thus, a parameter ``XXX_YYY`` of the standard binding model variant is replaced by the four parameters ``EXT_XXX_YYY``, ``EXT_XXX_YYY_T``, ``EXT_XXX_YYY_TT``, and ``EXT_XXX_YYY_TTT``.
+Since each parameter can depend on a different external source, the dataset ``EXTFUN`` (not listed in the standard variants below) should contain a vector of 0-based integer indices of the external source of each parameter.
+The ordering of the parameters in ``EXTFUN`` is given by the ordering in the standard variant.
+However, if only one index is passed in ``EXTFUN``, this external source is used for all parameters.
+
+Note that parameter sensitivities with respect to column radius, column length, particle core radius, and particle radius may be wrong when using externally dependent binding models.
+This is caused by not taking into account the derivative of the external profile with respect to column position.
+
+
+Non-binding components
+----------------------
+
+For binding models that do not support multiple bound states, many parameters can vary per component and their length is taken as ``NCOMP``.
+However, these models still support non-binding components.
+In this case, the entries in their parameters that correspond to non-binding components are simply ignored.
+
+
+.. _multiple-particle-types_binding:
+
+Multiple particle types
+-----------------------
+
+The group that contains the parameters of a binding model in unit operation with index ``XXX`` reads ``/input/model/unit_XXX/adsorption``.
+This is valid for models with a single particle type.
+If a model has multiple particle types, it may have a different binding model in each type.
+The parameters are then placed in the group ``/input/model/unit_XXX/adsorption_YYY`` instead, where ``YYY`` denotes the index of the particle type.
+
+Note that, in any case, ``/input/model/unit_XXX/adsorption_000`` contains the parameters of the first (and possibly sole) particle type.
+This group also takes precedence over a possibly existing ``/input/model/unit_XXX/adsorption`` group.
+
+.. toctree::
+ :maxdepth: 2
+
+ linear
+ multi_component_langmuir
+ multi_component_langmuir_ldf
+ multi_component_langmuir_ldf_liquid_phase
+ mobile_phase_modulator_langmuir
+ extended_mobile_phase_modulator_langmuir
+ multi_component_bi_langmuir
+ multi_component_bi_langmuir_ldf
+ multi_component_anti_langmuir
+ multi_component_spreading
+ steric_mass_action
+ multi_state_steric_mass_action
+ simplified_multi_state_steric_mass_action
+ bi_steric_mass_action
+ generalized_ion_exchange
+ saska
+ self_association
+ freundlich_ldf
+ hic_water_on_hydrophobic_surfaces
+ hic_constant_water_activity
+ multi_component_colloidal
+
diff --git a/v5.0.1/_sources/interface/binding/linear.rst.txt b/v5.0.1/_sources/interface/binding/linear.rst.txt
new file mode 100644
index 000000000..30d80cc86
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/linear.rst.txt
@@ -0,0 +1,44 @@
+.. _linear_config:
+
+Linear
+~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = LINEAR**
+
+For information on model equations, refer to :ref:`linear_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``LIN_KA``
+ Adsorption rate constants for each component
+
+
+**Unit:** :math:`m_{MP}^3~m_{SP}^{-3}~s^{-1}`
+
+=================== ========================= ==================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1/NTOTALBND
+=================== ========================= ==================================
+
+
+``LIN_KD``
+ Desorption rate constants for each component
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= ==================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1/NTOTALBND
+=================== ========================= ==================================
+
+
+
+
+
diff --git a/v5.0.1/_sources/interface/binding/mobile_phase_modulator_langmuir.rst.txt b/v5.0.1/_sources/interface/binding/mobile_phase_modulator_langmuir.rst.txt
new file mode 100644
index 000000000..a93c7c8e1
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/mobile_phase_modulator_langmuir.rst.txt
@@ -0,0 +1,65 @@
+.. _mobile_phase_modulator_langmuir_config:
+
+Mobile Phase Modulator Langmuir
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = MOBILE_PHASE_MODULATOR**
+
+For information on model equations, refer to :ref:`mobile_phase_modulator_langmuir_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``MPM_KA``
+ Adsorption rate constants
+
+**Unit:** :math:`m_{MP}^3~mol^{-1}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``MPM_KD``
+ Desorption rate constants
+
+**Unit:** :math:`m_{MP}^{3\beta}~mol^{-\beta}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``MPM_QMAX``
+ Maximum adsorption capacities
+
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``MPM_BETA``
+ Parameters describing the ion-exchange characteristics (IEX)
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``MPM_GAMMA``
+ Parameters describing the hydrophobicity (HIC)
+
+**Unit:** :math:`m_{MP}^{3} mol^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
diff --git a/v5.0.1/_sources/interface/binding/multi_component_anti_langmuir.rst.txt b/v5.0.1/_sources/interface/binding/multi_component_anti_langmuir.rst.txt
new file mode 100644
index 000000000..1263b71da
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/multi_component_anti_langmuir.rst.txt
@@ -0,0 +1,55 @@
+.. _multi_component_anti_langmuir_config:
+
+Multi Component Anti-Langmuir
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = MULTI_COMPONENT_ANTILANGMUIR**
+
+For information on model equations, refer to :ref:`multi_component_anti_langmuir_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``MCAL_KA``
+ Adsorption rate constants
+
+**Unit:** :math:`m_{MP}^3~mol^{-1}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``MCAL_KD``
+ Desorption rate constants
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= ==================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= ==================================
+
+``MCAL_QMAX``
+ Maximum adsorption capacities
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= ==================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** NCOMP
+=================== ========================= ==================================
+
+``MCAL_ANTILANGMUIR``
+ Anti-Langmuir coefficients (optional)
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= ==================================
+**Type:** double **Range:** {-1,1} **Length:** NCOMP
+=================== ========================= ==================================
diff --git a/v5.0.1/_sources/interface/binding/multi_component_bi_langmuir.rst.txt b/v5.0.1/_sources/interface/binding/multi_component_bi_langmuir.rst.txt
new file mode 100644
index 000000000..5a6a1bcbb
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/multi_component_bi_langmuir.rst.txt
@@ -0,0 +1,47 @@
+.. _multi_component_bi_langmuir_config:
+
+Multi Component Bi-Langmuir
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = MULTI_COMPONENT_BILANGMUIR**
+
+For information on model equations, refer to :ref:`multi_component_bi_langmuir_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``MCBL_KA``
+ Adsorption rate constants in state-major ordering (see :ref:`ordering_multi_dimensional_data`)
+
+**Unit:** :math:`m_{MP}^3~mol^{-1}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NSTATES :math:`\cdot` NCOMP
+=================== ========================= =========================================
+
+``MCBL_KD``
+ Desorption rate constants in state-major ordering
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NSTATES :math:`\cdot` NCOMP
+=================== ========================= =========================================
+
+``MCBL_QMAX``
+ Maximum adsorption capacities in state-major ordering
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NSTATES :math:`\cdot` NCOMP
+=================== ========================= =========================================
+
diff --git a/v5.0.1/_sources/interface/binding/multi_component_bi_langmuir_ldf.rst.txt b/v5.0.1/_sources/interface/binding/multi_component_bi_langmuir_ldf.rst.txt
new file mode 100644
index 000000000..325b76136
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/multi_component_bi_langmuir_ldf.rst.txt
@@ -0,0 +1,46 @@
+.. _multi_component_bi_langmuir_ldf_config:
+
+Multi Component Bi-Langmuir LDF
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = MULTI_COMPONENT_BILANGMUIR_LDF**
+
+For information on model equations, refer to :ref:`multi_component_bi_langmuir_ldf_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``MCBLLDF_KEQ``
+ Equillibrium loading constants in state-major ordering (see :ref:`ordering_multi_dimensional_data`)
+
+**Unit:** :math:`m_{MP}^3~mol^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP :math:`\cdot` NSTATES
+=================== ========================= =========================================
+
+``MCBLLDF_KKIN``
+ Linear driving force coefficients in state-major ordering
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP :math:`\cdot` NSTATES
+=================== ========================= =========================================
+
+``MCBLLDF_QMAX``
+ Maximum adsorption capacities in state-major ordering
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** NCOMP :math:`\cdot` NSTATES
+=================== ========================= =========================================
diff --git a/v5.0.1/_sources/interface/binding/multi_component_colloidal.rst.txt b/v5.0.1/_sources/interface/binding/multi_component_colloidal.rst.txt
new file mode 100644
index 000000000..9f1c353af
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/multi_component_colloidal.rst.txt
@@ -0,0 +1,163 @@
+.. _multi_component_colloidal_config:
+
+Multi Component Colloidal
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = MULTI_COMPONENT_COLLOIDAL**
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``COL_PHI``
+ Phase ratio :math:`\Phi`
+
+**Unit:** :math:`m^{2} m_{s}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
+``COL_KAPPA_EXP``
+ Screening term exponent factor :math:`\kappa_{ef}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
+``COL_KAPPA_FACT``
+ Screening term factor :math:`\kappa_{f}`
+
+**Unit:** :math:`m \cdot mM^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
+``COL_KAPPA_CONST``
+ Screening term constant :math:`\kappa_{c}`
+
+**Unit:** :math:`m`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
+``COL_CORDNUM``
+ Coordination number :math:`n`
+
+=================== ========================= =========================================
+**Type:** int **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
+``COL_LOGKEQ_PH_EXP``
+ Protein-resin interaction :math:`K_{e,i}` equilibrium: Constant exponent :math:`k_{e,i}` for pH
+ If pH is not considered, this value will be not be used but must still be specified, i.e. can be any number.
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``COL_LOGKEQ_SALT_POWEXP``
+ Protein-resin interaction :math:`K_{e,i}` equilibrium: Constant pre-factor :math:`k_{a,i}` for salt power
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``COL_LOGKEQ_SALT_POWFAC``
+ Protein-resin interaction :math:`K_{e,i}` equilibrium: Constant exponent :math:`k_{b,i}` for salt power
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``COL_LOGKEQ_SALT_EXPFAC``
+ Protein-resin interaction :math:`K_{e,i}` equilibrium: Constant pre-factor :math:`k_{c,i}` for e-function with salt power
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``COL_LOGKEQ_SALT_EXPARGMULT``
+ Protein-resin interaction :math:`K_{e,i}` equilibrium: Constant power factor :math:`k_{d,i}` for salt in e-function
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``COL_BPP_PH_EXP``
+ Protein-protein interaction :math:`b_{pp,i}`: Constant power term :math:`b_{e,i}` for pH.
+ If pH is not considered, this value will be not be used but must still be specified, i.e. can be any number.
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``COL_BPP_SALT_POWFACT``
+ Protein-protein interaction :math:`b_{pp,i}`: Constant power pre-factor :math:`b_{a,i}` for salt
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``COL_BPP_SALT_POWEX``
+ Protein-protein interaction :math:`b_{pp,i}`: Constant power :math:`b_{b,i}` for salt
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``COL_BPP_SALT_EXPFACT``
+ Protein-protein interaction :math:`b_{pp,i}`: Constant pre-factor :math:`b_{c,i}` e-function with salt power
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``COL_BPP_SALT_EXPARGMULT``
+ Protein-protein interaction :math:`b_{pp,i}`: Constant power factor :math:`b_{d,i}` for salt in e-function
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``COL_PROTEIN_RADIUS``
+ Protein radius :math:`r_i`
+
+**Unit:** :math:`m`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``COL_KKIN``
+ Adsorption rate constants :math:`K_\text{kin}` in state-major ordering
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``COL_LINEAR_THRESHOLD``
+ Threshold concentration :math:`c_\epsilon` for switching to linear approximation
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`> 0` **Length:** 1
+=================== ========================= =========================================
+
+``COL_USE_PH``
+ Selects if pH is included in the model or not: 1 = yes, 0 = no.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1
+=================== ========================= =========================================
+
diff --git a/v5.0.1/_sources/interface/binding/multi_component_langmuir.rst.txt b/v5.0.1/_sources/interface/binding/multi_component_langmuir.rst.txt
new file mode 100644
index 000000000..174846c21
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/multi_component_langmuir.rst.txt
@@ -0,0 +1,46 @@
+.. _multi_component_langmuir_config:
+
+Multi Component Langmuir
+========================
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = MULTI_COMPONENT_LANGMUIR**
+
+For information on model equations, refer to :ref:`multi_component_langmuir_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``MCL_KA``
+ Adsorption rate constants
+
+**Unit:** :math:`m_{MP}^3~mol^{-1}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``MCL_KD``
+ Desorption rate constants
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= ==================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= ==================================
+
+``MCL_QMAX``
+ Maximum adsorption capacities
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= ==================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** NCOMP
+=================== ========================= ==================================
diff --git a/v5.0.1/_sources/interface/binding/multi_component_langmuir_ldf.rst.txt b/v5.0.1/_sources/interface/binding/multi_component_langmuir_ldf.rst.txt
new file mode 100644
index 000000000..f703731be
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/multi_component_langmuir_ldf.rst.txt
@@ -0,0 +1,46 @@
+.. _multi_component_langmuir_ldf_config:
+
+Multi Component Langmuir LDF
+============================
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = MULTI_COMPONENT_LANGMUIR_LDF**
+
+For information on model equations, refer to :ref:`multi_component_langmuir_ldf_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``MCLLDF_KEQ``
+ Equillibrium loading constants
+
+**Unit:** :math:`m_{MP}^3~mol^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``MCLLDF_KKIN``
+ Linear driving force coefficients
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= ==================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= ==================================
+
+``MCLLDF_QMAX``
+ Maximum adsorption capacities
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= ==================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** NCOMP
+=================== ========================= ==================================
diff --git a/v5.0.1/_sources/interface/binding/multi_component_langmuir_ldf_liquid_phase.rst.txt b/v5.0.1/_sources/interface/binding/multi_component_langmuir_ldf_liquid_phase.rst.txt
new file mode 100644
index 000000000..1bf25bbb8
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/multi_component_langmuir_ldf_liquid_phase.rst.txt
@@ -0,0 +1,46 @@
+.. _multi_component_langmuir_ldf_liquid_phase_config:
+
+Multi Component Langmuir LDF Liquid Phase
+==========================================
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = MULTI_COMPONENT_LANGMUIR_LDF_LIQUID_PHASE**
+
+For information on model equations, refer to :ref:`multi_component_langmuir_ldf_liquid_phase_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``MCLLDFC_KEQ``
+ Equillibrium loading constants
+
+**Unit:** :math:`m_{MP}^3~mol^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``MCLLDFC_KKIN``
+ Linear driving force coefficients
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= ==================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= ==================================
+
+``MCLLDFC_QMAX``
+ Maximum adsorption capacities
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= ==================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** NCOMP
+=================== ========================= ==================================
diff --git a/v5.0.1/_sources/interface/binding/multi_component_spreading.rst.txt b/v5.0.1/_sources/interface/binding/multi_component_spreading.rst.txt
new file mode 100644
index 000000000..203bcbc19
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/multi_component_spreading.rst.txt
@@ -0,0 +1,64 @@
+.. _multi_component_spreading_config:
+
+Multi Component Spreading
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = MULTI_COMPONENT_SPREADING**
+
+For information on model equations, refer to :ref:`multi_component_spreading_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``MCSPR_KA``
+ Adsorption rate constants in state-major ordering
+
+**Unit:** :math:`m_{MP}^3~mol^{-1}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``MCSPR_KD``
+ Desorption rate constants in state-major ordering
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``MCSPR_QMAX``
+ Maximum adsorption capacities in state-major ordering
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``MCSPR_K12``
+ Exchange rates from the first to the second bound state
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``MCSPR_K21``
+ Exchange rates from the second to the first bound state
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
diff --git a/v5.0.1/_sources/interface/binding/multi_state_steric_mass_action.rst.txt b/v5.0.1/_sources/interface/binding/multi_state_steric_mass_action.rst.txt
new file mode 100644
index 000000000..ecc587179
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/multi_state_steric_mass_action.rst.txt
@@ -0,0 +1,95 @@
+.. _multi_state_steric_mass_action_config:
+
+Multi-State Steric Mass Action
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = MULTISTATE_STERIC_MASS_ACTION**
+
+For information on model equations, refer to :ref:`multi_state_steric_mass_action_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``MSSMA_KA``
+ Adsorption rate constants of the components to the different bound
+ states in component-major ordering
+
+**Unit:** :math:`m_{MP}^3~m_{SP}^{-3}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``MSSMA_KD``
+ Desorption rate constants of the components in the different bound
+ states in component-major ordering
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``MSSMA_NU``
+ Characteristic charges of the components in the different bound
+ states in component-major ordering
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``MSSMA_SIGMA``
+ Steric factors of the components in the different bound states in
+ component-major ordering
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``MSSMA_RATES``
+ Conversion rates between different bound states in
+ component-row-major ordering
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= ===================================================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** :math:`\sum_{i=0}^{\text{NCOMP}-1} \text{NBND}_{i}^{2}`
+=================== ========================= ===================================================================
+
+``MSSMA_LAMBDA``
+ Stationary phase capacity (monovalent salt counterions); The total
+ number of binding sites available on the resin surface
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
+``MSSMA_REFC0``
+ Reference liquid phase concentration (optional, defaults to
+ :math:`1.0`)
+
+**Unit:** :math:`mol~m_{MP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** 1
+=================== ========================= =========================================
+
+``MSSMA_REFQ``
+ Reference solid phase concentration (optional, defaults to
+ :math:`1.0`)
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** 1
+=================== ========================= =========================================
diff --git a/v5.0.1/_sources/interface/binding/saska.rst.txt b/v5.0.1/_sources/interface/binding/saska.rst.txt
new file mode 100644
index 000000000..cd4da6899
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/saska.rst.txt
@@ -0,0 +1,42 @@
+.. _saska_config:
+
+Saska
+~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = SASKA**
+
+For information on model equations, refer to :ref:`saska_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+
+``SASKA_H``
+ Henry coefficient
+
+**Unit:** :math:`m_{MP}^3~m_{SP}^{-3}~s^{-1}`
+
+=================== ================================= =========================================
+**Type:** double **Range:** :math:`\mathbb {R}` **Length:** NCOMP
+=================== ================================= =========================================
+
+
+``SASKA_K``
+ Quadratic factors
+
+**Unit:** :math:`m_{MP}^6~m_{SP}^{-3}~s^{-1}`
+
+=================== ================================ =========================================
+**Type:** double **Range:** :math:`\mathbb {R}` **Length:** :math:`\text{NCOMP}^2`
+=================== ================================ =========================================
+
+
+
diff --git a/v5.0.1/_sources/interface/binding/self_association.rst.txt b/v5.0.1/_sources/interface/binding/self_association.rst.txt
new file mode 100644
index 000000000..febe7773b
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/self_association.rst.txt
@@ -0,0 +1,93 @@
+.. _self_association_config:
+
+Self Association
+~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = SELF_ASSOCIATION**
+
+For information on model equations, refer to :ref:`self_association_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``SAI_KA1``
+ Adsorption rate constants
+
+**Unit:** :math:`m_{MP}^3~m_{SP}^{-3}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SAI_KA2``
+ Adsorption rate constants
+
+**Unit:** :math:`m_{MP}^6~m_{SP}^{-3}~mol^{-1}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SAI_KD``
+ Desorption rate constants
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SAI_NU``
+ Characteristic charges :math:`\nu` of the protein
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SAI_SIGMA``
+ Steric factors :math:`\sigma` of the protein
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SAI_LAMBDA``
+ Stationary phase capacity (monovalent salt counterions); The total
+ number of binding sites available on the resin surface
+
+**Unit:** :math:`mol m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
+
+``SAI_REFC0``
+ Reference liquid phase concentration (optional, defaults to
+ :math:`1.0`)
+
+**Unit:** :math:`mol m_{MP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** 1
+=================== ========================= =========================================
+
+
+``SAI_REFQ``
+ Reference solid phase concentration (optional, defaults to
+ :math:`1.0`)
+
+**Unit:** :math:`mol m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** 1
+=================== ========================= =========================================
+
diff --git a/v5.0.1/_sources/interface/binding/simplified_multi_state_steric_mass_action.rst.txt b/v5.0.1/_sources/interface/binding/simplified_multi_state_steric_mass_action.rst.txt
new file mode 100644
index 000000000..c682369ea
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/simplified_multi_state_steric_mass_action.rst.txt
@@ -0,0 +1,178 @@
+.. _simplified_multi_state_steric_mass_action_config:
+
+Simplified Multi-State Steric Mass Action
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = SIMPLIFIED_MULTISTATE_STERIC_MASS_ACTION**
+
+For information on model equations, refer to :ref:`simplified_multi_state_steric_mass_action_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``SMSSMA_LAMBDA``
+ Stationary phase capacity (monovalent salt counterions); The total
+ number of binding sites available on the resin surface
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
+``SMSSMA_KA``
+ Adsorption rate constants of the components to the different bound
+ states in component-major ordering
+
+**Unit:** :math:`m_{MP}^{3}~m_{SP}^{-3}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``SMSSMA_KD``
+ Desorption rate constants of the components to the different bound
+ states in component-major ordering
+
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NTOTALBND
+=================== ========================= =========================================
+
+``SMSSMA_NU_MIN``
+ Characteristic charges of the components in the first (weakest) bound
+ state
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SMSSMA_NU_MAX``
+ Characteristic charges of the components in the last (strongest)
+ bound state
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SMSSMA_NU_QUAD``
+ Quadratic modifiers of the characteristic charges of the different
+ components depending on the index of the bound state
+
+=================== ============================== =========================================
+**Type:** double **Range:** :math:`\mathbb{R}` **Length:** NCOMP
+=================== ============================== =========================================
+
+``SMSSMA_SIGMA_MIN``
+ Steric factors of the components in the first (weakest) bound state
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SMSSMA_SIGMA_MAX``
+ Steric factors of the components in the last (strongest) bound state
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SMSSMA_SIGMA_QUAD``
+ Quadratic modifiers of steric factors of the different components
+ depending on the index of the bound state
+
+=================== ============================== =========================================
+**Type:** double **Range:** :math:`\mathbb{R}` **Length:** NCOMP
+=================== ============================== =========================================
+
+``SMSSMA_KWS``
+ Exchange rates from a weakly bound state to the next stronger bound
+ state
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SMSSMA_KWS_LIN``
+ Linear exchange rate coefficients from a weakly bound state to the
+ next stronger bound state
+
+**Unit:** :math:`s^{-1}`
+
+=================== ============================== =========================================
+**Type:** double **Range:** :math:`\mathbb{R}` **Length:** NCOMP
+=================== ============================== =========================================
+
+``SMSSMA_KWS_QUAD``
+ Quadratic exchange rate coefficients from a weakly bound state to the
+ next stronger bound state
+
+**Unit:** :math:`s^{-1}`
+
+=================== ============================== =========================================
+**Type:** double **Range:** :math:`\mathbb{R}` **Length:** NCOMP
+=================== ============================== =========================================
+
+``SMSSMA_KSW``
+ Exchange rates from a strongly bound state to the next weaker bound
+ state
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SMSSMA_KSW_LIN``
+ Linear exchange rate coefficients from a strongly bound state to the
+ next weaker bound state
+
+**Unit:** :math:`s^{-1}`
+
+=================== ============================== =========================================
+**Type:** double **Range:** :math:`\mathbb{R}` **Length:** NCOMP
+=================== ============================== =========================================
+
+``SMSSMA_KSW_QUAD``
+ Quadratic exchange rate coefficients from a strongly bound state to
+ the next weaker bound state
+
+**Unit:** :math:`s^{-1}`
+
+=================== ============================== =========================================
+**Type:** double **Range:** :math:`\mathbb{R}` **Length:** NCOMP
+=================== ============================== =========================================
+
+``SMSSMA_REFC0``
+ Reference liquid phase concentration (optional, defaults to
+ :math:`1.0`)
+
+**Unit:** :math:`mol~m_{MP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** 1
+=================== ========================= =========================================
+
+``SMSSMA_REFQ``
+ Reference solid phase concentration (optional, defaults to
+ :math:`1.0`)
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** 1
+=================== ========================= =========================================
diff --git a/v5.0.1/_sources/interface/binding/steric_mass_action.rst.txt b/v5.0.1/_sources/interface/binding/steric_mass_action.rst.txt
new file mode 100644
index 000000000..ed48c44fa
--- /dev/null
+++ b/v5.0.1/_sources/interface/binding/steric_mass_action.rst.txt
@@ -0,0 +1,87 @@
+.. _steric_mass_action_config:
+
+Steric Mass Action
+~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = STERIC_MASS_ACTION**
+
+For information on model equations, refer to :ref:`steric_mass_action_model`.
+
+
+``IS_KINETIC``
+ Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+ quasi-stationary. If a single value is given, the mode is set for all
+ bound states. Otherwise, the adsorption mode is set for each bound
+ state separately.
+
+=================== ========================= =========================================
+**Type:** int **Range:** {0,1} **Length:** 1/NTOTALBND
+=================== ========================= =========================================
+
+``SMA_KA``
+ Adsorption rate constants
+
+**Unit:** :math:`m_{MP}^3~m_{SP}^{-3}~s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SMA_KD``
+ Desorption rate constants
+
+
+**Unit:** :math:`s^{-1}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SMA_NU``
+ Characteristic charges of the protein; The number of sites
+ :math:`\nu` that the protein interacts with on the resin surface
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SMA_SIGMA``
+ Steric factors of the protein; The number of sites :math:`\sigma` on
+ the surface that are shielded by the protein and prevented from
+ exchange with the salt counterions in solution
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** NCOMP
+=================== ========================= =========================================
+
+``SMA_LAMBDA``
+ Stationary phase capacity (monovalent salt counterions); The total
+ number of binding sites available on the resin surface
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\ge 0` **Length:** 1
+=================== ========================= =========================================
+
+``SMA_REFC0``
+ Reference liquid phase concentration (optional, defaults to
+ :math:`1.0`)
+
+
+**Unit:** :math:`mol~m_{MP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** 1
+=================== ========================= =========================================
+
+``SMA_REFQ``
+ Reference solid phase concentration (optional, defaults to
+ :math:`1.0`)
+
+
+**Unit:** :math:`mol~m_{SP}^{-3}`
+
+=================== ========================= =========================================
+**Type:** double **Range:** :math:`\gt 0` **Length:** 1
+=================== ========================= =========================================
diff --git a/v5.0.1/_sources/interface/consistent_initialization.rst.txt b/v5.0.1/_sources/interface/consistent_initialization.rst.txt
new file mode 100644
index 000000000..6635338f4
--- /dev/null
+++ b/v5.0.1/_sources/interface/consistent_initialization.rst.txt
@@ -0,0 +1,39 @@
+.. _non_consistency_solver_parameters:
+
+Nonlinear solver for consistent initialization
+===============================================
+
+Group /input/model/unit_XXX/discretization/consistency_solver - Nonlinear consistency solver paramters
+------------------------------------------------------------------------------------------------------
+
+``SOLVER_NAME``
+
+Name of the solver. Available solvers are ``LEVMAR``, ``ATRN_RES``, ``ATRN_ERR``, and ``COMPOSITE``.
+
+ ================== =======================
+ **Type:** string **Length:** :math:`1`
+ ================== =======================
+
+``INIT_DAMPING``
+
+Initial damping factor (default is :math:`0.01`)
+
+ ================ ============================= ==================================
+ **Type:** double **Range:** :math:`\ge 0` **Length:** :math:`1`
+ ================ ============================= ==================================
+
+``MIN_DAMPING``
+
+Minimal damping factor (default is :math:`0.0001`; ignored by ``LEVMAR``)
+
+ ================ ============================= ==================================
+ **Type:** double **Range:** :math:`\ge 0` **Length:** :math:`1`
+ ================ ============================= ==================================
+
+``SUBSOLVERS``
+
+Vector with names of solvers for the composite solver (only required for composite solver). See ``SOLVER_NAME`` for available solvers.
+
+ ================== ==========================
+ **Type:** string **Length:** :math:`\gt 1`
+ ================== ==========================
diff --git a/v5.0.1/_sources/interface/flux_reconstruction.rst.txt b/v5.0.1/_sources/interface/flux_reconstruction.rst.txt
new file mode 100644
index 000000000..d9dddd68d
--- /dev/null
+++ b/v5.0.1/_sources/interface/flux_reconstruction.rst.txt
@@ -0,0 +1,53 @@
+.. _flux_reconstruction_methods:
+
+Flux reconstruction methods
+===========================
+
+Group /input/model/unit_XXX/discretization/reconstruction = WENO
+-----------------------------------------------------------------
+
+``BOUNDARY_MODEL``
+
+ Boundary model type:
+ 0. Lower WENO order (stable)
+ 1. Zero weights (unstable for small :math:`D_{\mathrm{ax}}`)
+ 2. Zero weights for :math:`p \neq 0` (less stable)
+
+ ============= ============================== =============
+ **Type:** int **Range:** :math:`\{0, 1, 2\}` **Length:** 1
+ ============= ============================== =============
+
+``WENO_EPS``
+
+ WENO :math:`\varepsilon`
+
+ ================ ================================== =============
+ **Type:** double **Range:** :math:`\mathbb{R}^{>0}` **Length:** 1
+ ================ ================================== =============
+
+``WENO_ORDER``
+
+ WENO order, also called WENO :math:`k`:
+
+ 1. Standard upwind scheme (order 1)
+ 2. WENO 2 (order 3)
+ 3. WENO 3 (order 5)
+
+ ============= ============================== =============
+ **Type:** int **Range:** :math:`\{1, 2, 3\}` **Length:** 1
+ ============= ============================== =============
+
+
+Group /input/model/unit_XXX/discretization/reconstruction = KOREN
+-----------------------------------------------------------------
+
+The Koren scheme implemented in CADET intrinsically uses a van Leer flux limiter. It can reach a maximum order of 2 depending on the smoothness of the solution. The
+BOUNDARY_MODEL is intrinsically set to 0 (stable).
+
+``KOREN_EPS``
+
+ Set :math:`\varepsilon` in the van Leer flux limiter
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\qe 0\` **Length:** 1
+ ================ ========================= =============
\ No newline at end of file
diff --git a/v5.0.1/_sources/interface/index.rst.txt b/v5.0.1/_sources/interface/index.rst.txt
new file mode 100644
index 000000000..5ef57e6fb
--- /dev/null
+++ b/v5.0.1/_sources/interface/index.rst.txt
@@ -0,0 +1,28 @@
+.. _file_format:
+
+Interface specifications
+========================
+
+The CADET framework is designed to work on a file format structured into groups and datasets.
+This concept may be implemented by different file formats.
+At the moment, CADET natively supports HDF5 and XML as file formats.
+The choice is not limited to those two formats but can be extended as needed.
+In this section the general layout and structure of the file format is described.
+
+.. topic:: File format versions
+
+ The file format may change and evolve over time as new features are added to the simulator.
+ This manual describes the most recent file format version that is also set as default value in ``/meta/FILE_FORMAT`` (see Tab. :ref:`FFMeta`).
+ The simulator assumes that the input file uses the most recent format version and does not update old files to the current standard.
+
+
+.. toctree::
+ :maxdepth: 3
+
+ introduction
+ input_group
+ output_group
+ meta_group
+
+
+
diff --git a/v5.0.1/_sources/interface/input_group.rst.txt b/v5.0.1/_sources/interface/input_group.rst.txt
new file mode 100644
index 000000000..e23e52457
--- /dev/null
+++ b/v5.0.1/_sources/interface/input_group.rst.txt
@@ -0,0 +1,21 @@
+.. _FFInput:
+
+Input Group
+===========
+
+.. toctree::
+ :maxdepth: 3
+
+ system
+ unit_operations/index
+ binding/index
+ population_balance_model
+ reaction/index
+ flux_reconstruction
+ consistent_initialization
+ return_data
+ sensitivities
+ solver
+ parameter_dependencies
+ spatial_discretization_methods
+
diff --git a/v5.0.1/_sources/interface/introduction.rst.txt b/v5.0.1/_sources/interface/introduction.rst.txt
new file mode 100644
index 000000000..48de6a113
--- /dev/null
+++ b/v5.0.1/_sources/interface/introduction.rst.txt
@@ -0,0 +1,143 @@
+.. _FFIntroduction:
+
+Introduction
+============
+
+Global structure
+----------------
+
+The global structure (see :numref:`FFRootFig`) is divided into three parts: ``input``, ``output``, and ``meta``.
+Every valid CADET file needs an ``input`` group (see :numref:`FFInputFig`) which contains all relevant information for simulating a model.
+It does not need an ``output`` (see :numref:`FFOutputFig`) or ``meta`` (see :numref:`FFRootFig`) group, since those are created when results are written.
+Whereas the ``output`` group is solely used as output and holds the results of the simulation, the ``meta`` group is used for input and output.
+Details such as file format version and simulator version are read from and written to the ``meta`` group.
+
+If not explicitly stated otherwise, all datasets are mandatory.
+By convention all group names are lowercase, whereas all dataset names are uppercase.
+Note that this is just a description of the file format and not a detailed explanation of the meaning of the parameters.
+For the latter, please refer to the corresponding sections in the previous chapter.
+
+.. _FFRootFig:
+.. figure:: file_format_structure.png
+
+ Structure of the groups in the root group of the file format
+
+.. _FFInputFig:
+.. figure:: file_format_input.png
+
+ High-level structure of the groups in the input part of the file format
+
+.. _FFModelUnitOpColumnFig:
+.. figure:: file_format_input_model_unit.png
+
+ Structure of the groups in a column unit operation (/input/model group)
+
+.. _FFOutputFig:
+.. figure:: file_format_output.png
+
+ Structure of the groups in the output part of the file format
+
+Notation and identifiers
+------------------------
+
+Reference volumes are denoted by subscripts:
+
+- :math:`m_{IV}^{3}` Interstitial volume
+- :math:`m_{MP}^{3}` Bead mobile phase volume
+- :math:`m_{SP}^{3}` Bead solid phase volume
+
+Common notation and identifiers that are used in the subsequent description are listed in
+:numref:`table_notation_identifiers`.
+
+.. _table_notation_identifiers:
+.. list-table:: Common notation and identifiers used in the file format description
+ :widths: 30 70
+ :header-rows: 1
+
+ * - Identifier
+ - Meaning
+ * - NCOMP
+ - Number of components of a unit operation
+ * - NTOTALCOMP
+ - Total number of components in the system (sum of all unit operation components)
+ * - NPARTYPE
+ - Number of particles types of a unit operation
+ * - NBOUND\ :sub:`i` \
+ - Number of bound states of component i of the current particle type
+ * - NTOTALBOUND
+ - Total number of bound states of the current particle type (sum of all bound states of all components)
+ * - NSTATES
+ - Maximum of the number of bound states for each component of a particle type
+ * - NREACT
+ - Number of reactions (in bulk volume or in the current particle type)
+ * - NDOF
+ - Total number of degrees of freedom of the current unit operation model or system of unit operations
+ * - NSEC
+ - Number of time integration sections
+ * - PARAM_VALUE
+ - Value of a generic unspecified parameter
+
+.. _ordering_multi_dimensional_data:
+
+Ordering of multi dimensional data
+----------------------------------
+
+Some model parameters, especially in certain binding models, require multi dimensional data.
+Since CADET only reads one dimensional arrays, the layout of the data has to be specified (i.e., the way how the data is linearized in memory).
+The term “*xyz*-major” means that the index corresponding to *xyz* changes the slowest.
+
+For instance, suppose a model with :math:`2` components and :math:`3` bound states has a “state-major” dataset.
+Then, the requested matrix is stored in memory such that all components are listed for each bound state (i.e., the bound state index changes the slowest and the component index the fastest):
+
+::
+
+ comp0bnd0, comp1bnd0, comp0bnd1, comp1bnd1, comp0bnd2, comp1bnd2
+
+
+This linear array can also be represented as a :math:`3 \times 2` matrix in “row-major” storage format:
+
+::
+
+ comp0bnd0, comp1bnd0
+ comp0bnd1, comp1bnd1
+ comp0bnd2, comp1bnd2
+
+
+.. _section_dependent_parameters:
+
+Section dependent model parameters
+----------------------------------
+
+Some model parameters (see :numref:`section_dependent_datasets`) can be assigned different values for each section.
+For example, the velocity a column is operated with could differ in the load, wash, and elution phases.
+Section dependency is recognized by specifying the appropriate number of values for the parameters (see *Length* column in the following tables).
+If a parameter depends on both the component and the section, the ordering is section-major.
+
+For instance, the *Length* field of the parameter ``VELOCITY`` reads :math:`1 / NSEC` which means that it is not recognized as section dependent if only :math:`1` value (scalar) is passed. However, if ``NSEC`` many values (vector) are present, it will be treated as section dependent.
+
+Note that all components of component dependent datasets have to be section dependent (e.g., you cannot have a section dependency on component :math:`2` only while the other components are not section dependent).
+
+.. _section_dependent_datasets:
+.. list-table:: Section dependent datasets in the 1D unit operation models (``/input/model/unit_XXX group``)
+ :widths: 40 30 30
+ :header-rows: 1
+
+ * - Dataset
+ - Component dependent
+ - Section dependent
+ * - COL_DISPERSION
+ - ✓
+ - ✓
+ * - FILM_DIFFUSION
+ - ✓
+ - ✓
+ * - PAR_DIFFUSION
+ - ✓
+ - ✓
+ * - PAR_SURDIFFUSION
+ - ✓
+ - ✓
+ * - VELOCITY
+ -
+ - ✓
+
diff --git a/v5.0.1/_sources/interface/meta_group.rst.txt b/v5.0.1/_sources/interface/meta_group.rst.txt
new file mode 100644
index 000000000..0aba45435
--- /dev/null
+++ b/v5.0.1/_sources/interface/meta_group.rst.txt
@@ -0,0 +1,46 @@
+.. _FFMeta:
+
+Meta Group
+==========
+
+``FILE_FORMAT``
+
+ Version of the file format (defaults to 040000 = 4.0.0 if omitted) with two digits per part (Major.Minor.Patch)
+
+ ================ =========================
+ **In/out:** In **Type:** int
+ ================ =========================
+
+``CADET_VERSION``
+
+ Version of the executed :math:`\texttt{CADET}` simulator
+
+ ================ =========================
+ **In/out:** Out **Type:** string
+ ================ =========================
+
+``CADET_COMMIT``
+
+ Git commit SHA1 from which the :math:`\texttt{CADET}` simulator was built
+
+ ================ =========================
+ **In/out:** Out **Type:** string
+ ================ =========================
+
+``CADET_BRANCH``
+
+ Git branch from which the :math:`\texttt{CADET}` simulator was built
+
+ ================ =========================
+ **In/out:** Out **Type:** string
+ ================ =========================
+
+``TIME_SIM``
+
+ Time that the time integration took (excluding any preparations and postprocessing)
+
+ **Unit:** :math:`\mathrm{s}`
+
+ ================ =========================
+ **In/out:** Out **Type:** double
+ ================ =========================
diff --git a/v5.0.1/_sources/interface/output_group.rst.txt b/v5.0.1/_sources/interface/output_group.rst.txt
new file mode 100644
index 000000000..9ba4ca6eb
--- /dev/null
+++ b/v5.0.1/_sources/interface/output_group.rst.txt
@@ -0,0 +1,578 @@
+.. _FFOutput:
+
+Output Group
+===============
+
+Group /output
+-------------
+
+``LAST_STATE_Y``
+
+ Full state vector at the last time point of the time integrator if :math:`\texttt{WRITE_SOLUTION_LAST}` in :math:`\texttt{/input/return}` is enabled
+
+ **Type:** double
+
+``LAST_STATE_YDOT``
+
+ Full time derivative state vector at the last time point of the time integrator if :math:`\texttt{WRITE_SOLUTION_LAST}` in :math:`\texttt{/input/return}` is enabled
+
+ **Type:** double
+
+``LAST_STATE_SENSY_XXX``
+
+ Full state vector of the ``XXX`` th sensitivity system at the last time point of the time integrator if :math:`\texttt{WRITE_SENS_LAST}` in :math:`\texttt{/input/return}` is enabled
+
+ **Type:** double
+
+``LAST_STATE_SENSYDOT_XXX``
+
+ Full time derivative state vector of the ``XXX`` th sensitivity system at the last time point of the time integrator if :math:`\texttt{WRITE_SENS_LAST}` in :math:`\texttt{/input/return}` is enabled
+
+ **Type:** double
+
+Group /output/solution
+----------------------
+
+``SOLUTION_TIMES``
+
+ Time points at which the solution is written if :math:`\texttt{WRITE_SOLUTION_TIMES}` in :math:`\texttt{/input/return}` is enabled
+
+ **Unit:** :math:`\mathrm{s}`
+
+ **Type:** double
+
+
+Group /output/solution/unit_XXX
+-------------------------------
+
+``SOLUTION_BULK``
+
+ Interstitial solution as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ **Type:** double
+
+``SOLUTION_PARTICLE``
+
+ Mobile phase solution inside the particles as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if just one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}`
+
+ **Type:** double
+
+``SOLUTION_PARTICLE_PARTYPE_XXX``
+
+ Mobile phase solution inside the particles of type ``XXX`` as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if more than one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}`
+
+ **Type:** double
+
+``SOLUTION_SOLID``
+
+ Solid phase solution inside the particles as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if just one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{SP}}^{-3}`
+
+ **Type:** double
+
+``SOLUTION_SOLID_PARTYPE_XXX``
+
+ Solid phase solution inside the particles of type ``XXX`` as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if more than one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{SP}}^{-3}`
+
+ **Type:** double
+
+``SOLUTION_FLUX``
+
+ Flux solution as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}^{-2}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLUTION_VOLUME``
+
+ Volume solution
+
+ **Unit:** :math:`\mathrm{m}^{3}`
+
+ **Type:** double
+
+``SOLUTION_OUTLET``
+
+ Tensor of solutions at the unit operation outlet with components as columns in time-port-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are both disabled. If the unit operation only has a single port, the port-dimension is removed if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ **Type:** double
+
+``SOLUTION_INLET``
+
+ Tensor of solutions at the unit operation inlet with components as columns in time-port-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are both disabled. If the unit operation only has a single port, the port-dimension is removed if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ **Type:** double
+
+``SOLUTION_OUTLET_COMP_XXX``
+
+ Component ``XXX`` of the solution at all outlet ports of the unit operation as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is enabled and :math:`\texttt{SPLIT_PORTS_DATA}` is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ **Type:** double
+
+``SOLUTION_INLET_COMP_XXX``
+
+ Component ``XXX`` of the solution at all inlet ports of the unit operation inlet as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is enabled and :math:`\texttt{SPLIT_PORTS_DATA}` is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ **Type:** double
+
+``SOLUTION_OUTLET_PORT_XXX``
+
+ All components at outlet port ``XXX`` of the solution of the unit operation as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is disabled and :math:`\texttt{SPLIT_PORTS_DATA}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ **Type:** double
+
+``SOLUTION_INLET_PORT_XXX``
+
+ All components at inlet port ``XXX`` of the solution of the unit operation inlet as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is disabled and :math:`\texttt{SPLIT_PORTS_DATA}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ **Type:** double
+
+``SOLUTION_OUTLET_PORT_XXX_COMP_YYY``
+
+ Component ``YYY`` at outlet port ``XXX`` of the solution of the unit operation. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are enabled, and the unit operation has multiple outlet ports. If the unit operation only has a single port, the field is created if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ **Type:** double
+
+``SOLUTION_INLET_PORT_XXX_COMP_YYY``
+
+ Component ``YYY`` at inlet port ``XXX`` of the solution of the unit operation. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are enabled, and the unit operation has multiple inlet ports. If the unit operation only has a single port, the field is created if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ **Type:** double
+
+``SOLDOT_BULK``
+
+ Interstitial solution time derivative as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLDOT_PARTICLE``
+
+ Mobile phase solution time derivative inside the particles as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if just one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLDOT_PARTICLE_PARTYPE_XXX``
+
+ Mobile phase solution time derivative inside the particles of type ``XXX`` as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if more than one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLDOT_SOLID``
+
+ Solid phase solution time derivative inside the particles as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if just one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLDOT_SOLID_PARTYPE_XXX``
+
+ Solid phase solution time derivative inside the particles of type ``XXX`` as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if more than one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{SP}}^{-3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLDOT_FLUX``
+
+ Flux solution time derivative as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}^{-2}\,\mathrm{s}^{-2}`
+
+ **Type:** double
+
+``SOLDOT_VOLUME``
+
+ Volume solution time derivative
+
+ **Unit:** :math:`\mathrm{m}^{3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLDOT_OUTLET``
+
+ Tensor of solution time derivatives at the unit operation outlet with components as columns in time-port-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are both disabled. If the unit operation only has a single port, the port-dimension is removed if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLDOT_INLET``
+
+ Tensor of solution time derivatives at the unit operation inlet with components as columns in time-port-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are both disabled. If the unit operation only has a single port, the port-dimension is removed if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLDOT_OUTLET_COMP_XXX``
+
+ Component ``XXX`` of the solution time derivative at all outlet ports of the unit operation as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is enabled and :math:`\texttt{SPLIT_PORTS_DATA}` is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLDOT_INLET_COMP_XXX``
+
+ Component ``XXX`` of the solution time derivative at all inlet ports of the unit operation inlet as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is enabled and :math:`\texttt{SPLIT_PORTS_DATA}` is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLDOT_OUTLET_PORT_XXX``
+
+ All components at outlet port ``XXX`` of the solution time derivative of the unit operation as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is disabled and :math:`\texttt{SPLIT_PORTS_DATA}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLDOT_INLET_PORT_XXX``
+
+ All components at inlet port ``XXX`` of the solution time derivative of the unit operation inlet as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is disabled and :math:`\texttt{SPLIT_PORTS_DATA}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLDOT_OUTLET_PORT_XXX_COMP_YYY``
+
+ Component ``YYY`` at outlet port ``XXX`` of the solution time derivative of the unit operation. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are enabled, and the unit operation has multiple outlet ports. If the unit operation only has a single port, the field is created if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``SOLDOT_INLET_PORT_XXX_COMP_YYY``
+
+ Component ``YYY`` at inlet port ``XXX`` of the solution time derivative of the unit operation. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are enabled, and the unit operation has multiple inlet ports. If the unit operation only has a single port, the field is created if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}`
+
+ **Type:** double
+
+``LAST_STATE_Y``
+
+ State vector of this unit at the last time point of the time integrator if :math:`\texttt{WRITE_SOLUTION_LAST_UNIT}` in :math:`\texttt{/input/return/unit_XXX}` is enabled.
+ Note that the vector includes the dedicated inlet DOFs at the beginning (length: :math:`\texttt{NCOMP} \cdot \texttt{NPORT}`).
+
+ **Type:** double
+
+``LAST_STATE_YDOT``
+
+ Time derivative state vector of this unit at the last time point of the time integrator if :math:`\texttt{WRITE_SOLUTION_LAST_UNIT}` in :math:`\texttt{/input/return/unit_XXX}` is enabled.
+ Note that the vector includes the dedicated inlet DOFs at the beginning (length: :math:`\texttt{NCOMP} \cdot \texttt{NPORT}`).
+
+ **Type:** double
+
+
+Group /output/sensitivity/param_XXX/unit_YYY
+--------------------------------------------
+
+``SENS_BULK``
+
+ Interstitial sensitivity as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_PARTICLE``
+
+ Mobile phase sensitivity inside the particles as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if just one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_PARTICLE_PARTYPE_XXX``
+
+ Mobile phase sensitivity inside the particles of type ``XXX`` as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if more than one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_SOLID``
+
+ Solid phase sensitivity inside the particles as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if just one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_SOLID_PARTYPE_XXX``
+
+ Solid phase sensitivity inside the particles of type ``XXX`` as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if more than one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{SP}}^{-3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_FLUX``
+
+ Flux sensitivity as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}^{-2}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_VOLUME``
+
+ Volume sensitivity
+
+ **Unit:** :math:`\mathrm{m}^{3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_OUTLET``
+
+ Tensor of sensitivities at the unit operation outlet with components as columns in time-port-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are both disabled. If the unit operation only has a single port, the port-dimension is removed if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_INLET``
+
+ Tensor of sensitivities at the unit operation inlet with components as columns in time-port-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are both disabled. If the unit operation only has a single port, the port-dimension is removed if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_OUTLET_COMP_XXX``
+
+ Component ``XXX`` of the sensitivity at all outlet ports of the unit operation as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is enabled and :math:`\texttt{SPLIT_PORTS_DATA}` is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_INLET_COMP_XXX``
+
+ Component ``XXX`` of the sensitivity at all inlet ports of the unit operation inlet as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is enabled and :math:`\texttt{SPLIT_PORTS_DATA}` is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_OUTLET_PORT_XXX``
+
+ All components at outlet port ``XXX`` of the sensitivity of the unit operation as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is disabled and :math:`\texttt{SPLIT_PORTS_DATA}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_INLET_PORT_XXX``
+
+ All components at inlet port ``XXX`` of the sensitivity of the unit operation inlet as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is disabled and :math:`\texttt{SPLIT_PORTS_DATA}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_OUTLET_PORT_XXX_COMP_YYY``
+
+ Component ``YYY`` at outlet port ``XXX`` of the sensitivity of the unit operation. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are enabled, and the unit operation has multiple outlet ports. If the unit operation only has a single port, the field is created if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENS_INLET_PORT_XXX_COMP_YYY``
+
+ Component ``YYY`` at inlet port ``XXX`` of the sensitivity of the unit operation. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are enabled, and the unit operation has multiple inlet ports. If the unit operation only has a single port, the field is created if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_BULK``
+
+ Interstitial sensitivity time derivative as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_PARTICLE``
+
+ Mobile phase sensitivity time derivative inside the particles as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if just one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_PARTICLE_PARTYPE_XXX``
+
+ Mobile phase sensitivity time derivative inside the particles of type ``XXX`` as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if more than one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_SOLID``
+
+ Solid phase sensitivity time derivative inside the particles as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if just one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_SOLID_PARTYPE_XXX``
+
+ Solid phase sensitivity time derivative inside the particles of type ``XXX`` as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage. Only present if more than one particle type is defined.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{SP}}^{-3}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_FLUX``
+
+ Flux sensitivity time derivative as :math:`n_{\text{Time}} \times \texttt{UNITOPORDERING}` tensor in row-major storage
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}^{-2}\,\mathrm{s}^{-2}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_VOLUME``
+
+ Volume sensitivity time derivative
+
+ **Unit:** :math:`^{3}\,\mathrm{s}\mathrm{m}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_OUTLET``
+
+ Tensor of sensitivity time derivatives at the unit operation outlet with components as columns in time-port-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are both disabled. If the unit operation only has a single port, the port-dimension is removed if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_INLET``
+
+ Tensor of sensitivity time derivatives at the unit operation inlet with components as columns in time-port-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are both disabled. If the unit operation only has a single port, the port-dimension is removed if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_OUTLET_COMP_XXX``
+
+ Component ``XXX`` of the sensitivity time derivative at all outlet ports of the unit operation as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is enabled and :math:`\texttt{SPLIT_PORTS_DATA}` is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_INLET_COMP_XXX``
+
+ Component ``XXX`` of the sensitivity time derivative at all inlet ports of the unit operation inlet as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is enabled and :math:`\texttt{SPLIT_PORTS_DATA}` is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is disabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_OUTLET_PORT_XXX``
+
+ All components at outlet port ``XXX`` of the sensitivity time derivative of the unit operation as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is disabled and :math:`\texttt{SPLIT_PORTS_DATA}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_INLET_PORT_XXX``
+
+ All components at inlet port ``XXX`` of the sensitivity time derivative of the unit operation inlet as matrix in time-major storage. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` is disabled and :math:`\texttt{SPLIT_PORTS_DATA}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_OUTLET_PORT_XXX_COMP_YYY``
+
+ Component ``YYY`` at outlet port ``XXX`` of the sensitivity time derivative of the unit operation. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are enabled, and the unit operation has multiple outlet ports. If the unit operation only has a single port, the field is created if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+``SENSDOT_INLET_PORT_XXX_COMP_YYY``
+
+ Component ``YYY`` at inlet port ``XXX`` of the sensitivity time derivative of the unit operation. Only present if :math:`\texttt{SPLIT_COMPONENTS_DATA}` and :math:`\texttt{SPLIT_PORTS_DATA}` are enabled, and the unit operation has multiple inlet ports. If the unit operation only has a single port, the field is created if :math:`\texttt{SINGLE_AS_MULTI_PORT}` is enabled.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}\,[\mathrm{Param}]^{-1}`
+
+ **Type:** double
+
+
+/output/coordinates/unit_XXX
+------------------------------
+
+``AXIAL_COORDINATES``
+
+ Axial coordinates of the bulk discretization nodes
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ =================================
+ **Type:** double **Length:** :math:`\texttt{NCOL}`
+ ================ =================================
+
+``RADIAL_COORDINATES``
+
+ Radial coordinates of the bulk discretization nodes (only for 2D unit operations)
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ =================================
+ **Type:** double **Length:** :math:`\texttt{NRAD}`
+ ================ =================================
+
+``PARTICLE_COORDINATES_XXX``
+
+ Coordinates of the particle discretization nodes in particles of type ``XXX``
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ =================================
+ **Type:** double **Length:** :math:`\texttt{NPAR}`
+ ================ =================================
diff --git a/v5.0.1/_sources/interface/parameter_dependencies.rst.txt b/v5.0.1/_sources/interface/parameter_dependencies.rst.txt
new file mode 100644
index 000000000..862801ff4
--- /dev/null
+++ b/v5.0.1/_sources/interface/parameter_dependencies.rst.txt
@@ -0,0 +1,180 @@
+.. _parameter_dependencies:
+
+Parameter Dependencies
+======================
+
+Some parameters depend on other parameters (parameter-parameter dependency) or the solution variables (parameter-state dependency).
+Parameter dependencies are defined in the unit operation scope.
+
+Parameter-Parameter Dependencies
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Group /input/model/unit_XXX
+---------------------------
+
+``COL_DISPERSION_DEP``
+
+ Parameter dependence of column dispersion on the interstitial velocity. Available for the LRM, LRMP and GRM units (with FV discretization only at the moment)
+
+ ================ ===================================== =============
+ **Type:** string **Range:** :math:`\texttt{POWER_LAW}` **Length:** 1
+ ================ ===================================== =============
+
+``FILM_DIFFUSION_DEP``
+
+ Parameter dependence of film diffusion on the interstitial velocity. Available for the LRMP unit (with FV discretization only at the moment)
+
+ ================ ===================================== =============
+ **Type:** string **Range:** :math:`\texttt{POWER_LAW}` **Length:** 1
+ ================ ===================================== =============
+
+
+**Correlations**
+""""""""""""""""
+
+Different types of parameter correlations are can be applied.
+The following correlations can be used for all parameter-parameter dependencies, but we specify the required input fields only for ``COL_DISPERSION_DEP``, for the sake of conciseness.
+
+**Power Law**
+
+.. math::
+
+ \begin{aligned}
+ p_{dep} &= p_{dep} \cdot b \ |p_{on}^x|
+ \end{aligned}
+
+Here, :math:`p_{dep}` is the dependent parameter and :math:`p_{on}` is the parameter it depends on.
+
+``COL_DISPERSION_DEP_BASE``
+
+ Base :math:`b` of the power law parameter dependence. Optional, defaults to :math:`1.0`
+
+ ================ ============================= =============
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** 1
+ ================ ============================= =============
+
+``COL_DISPERSION_DEP_EXPONENT``
+
+ Exponent :math:`x` of the power law parameter dependence
+
+ ================ ============================= =============
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** 1
+ ================ ============================= =============
+
+``COL_DISPERSION_DEP_ABS``
+
+ Specifies whether or not the absolute value should be computed. Optional, defaults to :math:`1`
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+
+Parameter-State Dependencies
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Currently, the dependence of surface diffusion on the particle liquid salt component is the only available parameter-state dependence.
+
+Group /input/model/unit_XXX
+---------------------------
+
+``PAR_SURFDIFFUSION_DEP``
+
+ Parameter dependence of :math:`\texttt{PAR_SURFDIFFUSION}` on the particle liquid salt component (i.e. component with index 0). Valid dependencies are:
+
+ - :math:`\texttt{NONE}` Original parameter is used unmodified.
+ - :math:`\texttt{LIQUID_SALT_EXPONENTIAL}` Original parameter is modified by exponential law of liquid phase salt concentration.
+ - :math:`\texttt{LIQUID_SALT_POWER}` Original parameter is modified by power law of liquid phase salt concentration.
+ - :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}` Original parameter is modified by colloidal binding affinity based on liquid phase salt concentration.
+
+ Optional: If left out, no parameter dependence is assumed and the original surface diffusion coefficients are used unmodified.
+
+ ================ =========================================
+ **Type:** string **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ =========================================
+
+``PAR_SURFDIFFUSION_EXPFACTOR``
+
+ Factor :math:`\texttt{p1}` in exponential law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} exp \left(p_{2, i, m} c_{0}^{p} \right)`, where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient.
+ Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_EXPONENTIAL}`.
+
+ ================ ========================= ===================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NBOUND}`
+ ================ ========================= ===================================
+
+ ``PAR_SURFDIFFUSION_EXPFACTOR``
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
+ :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
+ Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
+ ================ ============================= ===================================
+
+``PAR_SURFDIFFUSION_EXPARGMULT``
+
+ Factor :math:`\texttt{p2}` in exponential law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} exp \left(p_{2, i, m} c_{0}^{p} \right)`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient. Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_EXPONENTIAL}`.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
+ ================ ============================= ===================================
+
+``PAR_SURFDIFFUSION_POWFACTOR``
+
+ Factor :math:`\texttt{p1}` in power law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} \left( c_{0}^{p} \right)^{p_{2, i, m}}`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient. Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_POWER}`.
+
+ ================ ========================= ===================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NBOUND}`
+ ================ ========================= ===================================
+
+``PAR_SURFDIFFUSION_POWEXP``
+
+ Fjactor :math:`\texttt{p2}` in power law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} \left( c_{0}^{p} \right)^{p_{2, i, m}}`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient. Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_POWER}`.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
+ ================ ============================= ===================================
+
+``PAR_SURFDIFFUSION_LOGKEQFACTOR``
+
+ Factor :math:`\texttt{p1}` in colloidal affinity law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
+ :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
+ Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
+ ================ ============================= ===================================
+
+``PAR_SURFDIFFUSION_LOGKEQEXP``
+
+ Factor :math:`\texttt{p2}` in colloidal affinity law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
+ :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
+ Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
+ ================ ============================= ===================================
+
+``PAR_SURFDIFFUSION_LOGKEQCONST``
+
+ Factor :math:`\texttt{p3}` in colloidal affinity law particle surface diffusion relation
+ :math:`D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]`
+ where :math:`\tilde{D}_{s, i, m}` is the original surface diffusion coefficient and
+ :math:`k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}`.
+ Only required if :math:`\texttt{PAR_SURFDIFFUSION_DEP}` is :math:`\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}`.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NBOUND}`
+ ================ ============================= ===================================
diff --git a/v5.0.1/_sources/interface/population_balance_model.rst.txt b/v5.0.1/_sources/interface/population_balance_model.rst.txt
new file mode 100644
index 000000000..38babada4
--- /dev/null
+++ b/v5.0.1/_sources/interface/population_balance_model.rst.txt
@@ -0,0 +1,161 @@
+.. _pbm_config:
+
+Population balance model
+========================
+
+The PBM in CADET is implemented as part of the reaction module and can thus be used in any unit operation that includes reactions.
+Typical applications consider crystallization in a :ref:`cstr_config` or, to model continuous processes, in a Dispersive Plug-Flow Reactor (DPFR), which is modelled by a :ref:`lumped_rate_model_without_pores_config`.
+
+The particle size domain (internal coordinate) is discretized by the FV method, giving us a finite set of particle sizes under consideration :math:`\{x_1, \dots, x_{N_x}\}`.
+Every particle size considered is treated as an individual component of the unit operation and the field ``NCOMP`` of that unit operation in which the crystallization happens, must be specified accordingly as :math:`N_x + 2`.
+The two additional components account for the solute :math:`c` and solubility :math:`c_\text{eq}`.
+*That is, by setting the ``NCOMP`` field, you specify the number of FV cells for the internal coordinate.*
+
+Note that the first component must be solute :math:`c` and the last component must be the solubility :math:`c_\text{eq}`.
+
+Example code to configure the PBM can be found in `CADET-Verification `_ .
+
+Group /input/model/unit_XXX
+---------------------------
+
+``NCOMP``
+
+ Number of components, which is given by two plus the number discrete particle sizes, which is given by the number of FV cells discretizing the internal coordinate
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 3` **Length:** 1
+ ============= ========================= =============
+
+``REACTION_MODEL``
+
+ The crystallization code is implemented as a reaction module, which is why crystallization needs to be specified here
+
+ ================ ======================================== =============
+ **Type:** String **Range:** :math:`\{ CRYSTALLIZATION \}` **Length:** 1
+ ================ ======================================== =============
+
+Group /input/model/unit_XXX/reaction_bulk - REACTION_MODEL = CRYSTALLIZATION - UNIT_TYPE = CSTR
+-----------------------------------------------------------------------------------------------
+
+*The following parameters need to be specified under Group /input/model/unit_XXX/reaction/reaction_bulk/ for CSTR units, and Group /input/model/unit_XXX/reaction/reaction/ for transport units like the LRM.*
+
+``CRY_BINS``
+
+ Coordinates of the cell faces, e.g. equidistant or logarithmic discretization of the internal coordinate :math:`x \in [x_c, x_\text{end}]`, including the end points.
+
+ ================ ========================= =====================================
+ **Type:** double **Range:** :math:`\geq 1` **Length:** :math:`\mathrm{N_x} + 1`
+ ================ ========================= =====================================
+
+``CRY_NUCLEI_MASS_DENSITY``
+
+ Nulcei mass density
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_VOL_SHAPE_FACTOR``
+
+ Volumetric shape factor of the particles
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_PRIMARY_NUCLEATION_RATE``
+
+ Primary nucleation rate constant :math:`k_p`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_SECONDARY_NUCLEATION_RATE``
+
+ Secondary nucleation rate :math:`k_b`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_GROWTH_RATE_CONSTANT``
+
+ Growth rate constant :math:`k_g`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_GROWTH_CONSTANT``
+
+ Growth constant :math:`\gamma`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_A``
+
+ Defines constant :math:`a` used to determine the growth rate
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_G``
+
+ Defines constant :math:`g` used to determine the growth rate
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_P``
+
+ Defines constant :math:`p` used to determine the growth rate
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_GROWTH_DISPERSION_RATE``
+
+ Growth dispersion rate :math:`D_g`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_U``
+
+ Defines constant :math:`u` used to determine the primary nucleation
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_B``
+
+ Defines constant :math:`b` used to determine the secondary nucleation
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_K``
+
+ Defines constant :math:`k` used to determine the secondary nucleation
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CRY_GROWTH_SCHEME_ORDER``
+
+ Defines the growth flux FV reconstruction scheme. It can only be :math:`1`: upwind scheme; :math:`2`: HR Koren scheme; :math:`3`: WENO23 scheme; :math:`4`: WENO35 scheme.
+ We recommend using the HR Koren scheme, which showed to be the most performant in our benchmarks.
+
+ ============= ================================ =============
+ **Type:** int **Range:** :math:`[1, \dots, 4]` **Length:** 1
+ ============= ================================ =============
diff --git a/v5.0.1/_sources/interface/reaction/index.rst.txt b/v5.0.1/_sources/interface/reaction/index.rst.txt
new file mode 100644
index 000000000..5e00dd6d7
--- /dev/null
+++ b/v5.0.1/_sources/interface/reaction/index.rst.txt
@@ -0,0 +1,46 @@
+.. _FFReaction:
+
+Reaction models
+===============
+
+.. toctree::
+ :maxdepth: 2
+
+ mass_action_law
+ michaelis_menten_kinetics
+
+Externally dependent reaction models
+------------------------------------
+
+Some reaction models have a variant that can use external sources as specified :ref:`/input/model/external/` (also see Section:ref:`dependence-on-external-function_react`).
+For the sake of brevity, only the standard variant of those reaction models is specified below.
+In order to obtain the format for the externally dependent variant, first replace the reaction model name ``XXX`` by ``EXT_XXX``.
+Each parameter :math:`p` (except for stoichiometric and exponent matrices) depends on a (possibly distinct) external source in a polynomial way:
+
+.. math::
+
+ \begin{aligned}
+ p(T) &= p_{\texttt{TTT}} T^3 + p_{\texttt{TT}} T^2 + p_{\texttt{T}} T + p.
+ \end{aligned}
+
+Thus, a parameter ``XXX_YYY`` of the standard reaction model variant is replaced by the four parameters ``EXT_XXX_YYY``, ``EXT_XXX_YYY_T``, ``EXT_XXX_YYY_TT``, and ``EXT_XXX_YYY_TTT``.
+Since each parameter can depend on a different external source, the dataset ``EXTFUN`` (not listed in the standard variants below) should contain a vector of 0-based integer indices of the external source of each parameter.
+The ordering of the parameters in ``EXTFUN`` is given by the ordering in the standard variant.
+However, if only one index is passed in ``EXTFUN``, this external source is used for all parameters.
+
+Note that parameter sensitivities with respect to column radius, column length, particle core radius, and particle radius may be wrong when using externally dependent reaction models.
+This is caused by not taking into account the derivative of the external profile with respect to column position.
+
+
+.. _multiple-particle-types_reactions:
+
+Multiple particle types
+-----------------------
+
+The group that contains the parameters of a reaction model in unit operation with index ``XXX`` reads ``/input/model/unit_XXX/reaction_particle``.
+This is valid for models with a single particle type.
+If a model has multiple particle types, it may have a different reaction model in each type.
+The parameters are then placed in the group ``/input/model/unit_XXX/reaction_particle_YYY`` instead, where ``YYY`` denotes the index of the particle type.
+
+Note that, in any case, ``/input/model/unit_XXX/reaction_particle_000`` contains the parameters of the first (and possibly sole) particle type.
+This group also takes precedence over a possibly existing ``/input/model/unit_XXX/adsorption_particle`` group.
diff --git a/v5.0.1/_sources/interface/reaction/mass_action_law.rst.txt b/v5.0.1/_sources/interface/reaction/mass_action_law.rst.txt
new file mode 100644
index 000000000..26c20b89f
--- /dev/null
+++ b/v5.0.1/_sources/interface/reaction/mass_action_law.rst.txt
@@ -0,0 +1,158 @@
+.. _mass_action_law_config:
+
+Mass Action Law
+~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/reaction - REACTION_MODEL = MASS_ACTION_LAW**
+
+``MAL_KFWD_BULK``
+
+ Forward rate constants for bulk volume reactions (available for external functions)
+
+ ================ ========================= ===================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NREACT}`
+ ================ ========================= ===================================
+
+``MAL_KBWD_BULK``
+
+ Backward rate constants for bulk volume reactions (available for external functions)
+
+ ================ ========================= ===================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NREACT}`
+ ================ ========================= ===================================
+
+``MAL_KFWD_LIQUID``
+
+ Forward rate constants for particle liquid phase reactions (available for external functions)
+
+ ================ ========================= ===================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NREACT}`
+ ================ ========================= ===================================
+
+``MAL_KBWD_LIQUID``
+
+ Backward rate constants for particle liquid phase reactions (available for external functions)
+
+ ================ ========================= ===================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NREACT}`
+ ================ ========================= ===================================
+
+``MAL_KFWD_SOLID``
+
+ Forward rate constants for particle solid phase reactions (available for external functions)
+
+ ================ ========================= ===================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NREACT}`
+ ================ ========================= ===================================
+
+``MAL_KBWD_SOLID``
+
+ Backward rate constants for particle solid phase reactions (available for external functions)
+
+ ================ ========================= ===================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NREACT}`
+ ================ ========================= ===================================
+
+``MAL_STOICHIOMETRY_BULK``
+
+ Stoichiometric matrix of bulk volume reactions as :math:`\texttt{NCOMP} \times \texttt{NREACT}` matrix in row-major storage
+
+ ================ ========================================================
+ **Type:** double **Length:** :math:`\texttt{NCOMP} \cdot \texttt{NREACT}`
+ ================ ========================================================
+
+``MAL_EXPONENTS_BULK_FWD``
+
+ Forward exponent matrix of bulk volume reactions as :math:`\texttt{NCOMP} \times \texttt{NREACT}` matrix in row-major storage (optional, calculated from :math:`\texttt{MAL_STOICHIOMETRY_BULK}` by default)
+
+ ================ ========================================================
+ **Type:** double **Length:** :math:`\texttt{NCOMP} \cdot \texttt{NREACT}`
+ ================ ========================================================
+
+``MAL_EXPONENTS_BULK_BWD``
+
+ Backward exponent matrix of bulk volume reactions as :math:`\texttt{NCOMP} \times \texttt{NREACT}` matrix in row-major storage (optional, calculated from :math:`\texttt{MAL_STOICHIOMETRY_BULK}` by default)
+
+ ================ ========================================================
+ **Type:** double **Length:** :math:`\texttt{NCOMP} \cdot \texttt{NREACT}`
+ ================ ========================================================
+
+``MAL_STOICHIOMETRY_LIQUID``
+
+ Stoichiometric matrix of particle liquid phase reactions as :math:`\texttt{NCOMP} \times \texttt{NREACT}` matrix in row-major storage
+
+ ================ ========================================================
+ **Type:** double **Length:** :math:`\texttt{NCOMP} \cdot \texttt{NREACT}`
+ ================ ========================================================
+
+``MAL_EXPONENTS_LIQUID_FWD``
+
+ Forward exponent matrix of particle liquid phase reactions as :math:`\texttt{NCOMP} \times \texttt{NREACT}` matrix in row-major storage (optional, calculated from :math:`\texttt{MAL_STOICHIOMETRY_LIQUID}` by default)
+
+ ================ ========================================================
+ **Type:** double **Length:** :math:`\texttt{NCOMP} \cdot \texttt{NREACT}`
+ ================ ========================================================
+
+``MAL_EXPONENTS_LIQUID_BWD``
+
+ Backward exponent matrix of particle liquid phase reactions as :math:`\texttt{NCOMP} \times \texttt{NREACT}` matrix in row-major storage (optional, calculated from :math:`\texttt{MAL_STOICHIOMETRY_LIQUID}` by default)
+
+ ================ ========================================================
+ **Type:** double **Length:** :math:`\texttt{NCOMP} \cdot \texttt{NREACT}`
+ ================ ========================================================
+
+``MAL_EXPONENTS_LIQUID_FWD_MODSOLID``
+
+ Forward solid phase modifier exponent matrix of particle liquid phase reactions as :math:`\texttt{NTOTALBND} \times \texttt{NREACT}` matrix in row-major storage (optional, defaults to all 0)
+
+ ================ ============================================================
+ **Type:** double **Length:** :math:`\texttt{NTOTALBND} \cdot \texttt{NREACT}`
+ ================ ============================================================
+
+``MAL_EXPONENTS_LIQUID_BWD_MODSOLID``
+
+ Backward solid phase modifier exponent matrix of particle liquid phase reactions as :math:`\texttt{NTOTALBND} \times \texttt{NREACT}` matrix in row-major storage (optional, defaults to all 0)
+
+ ================ ============================================================
+ **Type:** double **Length:** :math:`\texttt{NTOTALBND} \cdot \texttt{NREACT}`
+ ================ ============================================================
+
+``MAL_STOICHIOMETRY_SOLID``
+
+ Stoichiometric matrix of particle solid phase reactions as :math:`\texttt{NTOTALBND} \times \texttt{NREACT}` matrix in row-major storage
+
+ ================ ============================================================
+ **Type:** double **Length:** :math:`\texttt{NTOTALBND} \cdot \texttt{NREACT}`
+ ================ ============================================================
+
+``MAL_EXPONENTS_SOLID_FWD``
+
+ Forward exponent matrix of particle solid phase reactions as :math:`\texttt{NTOTALBND} \times \texttt{NREACT}` matrix in row-major storage (optional, calculated from :math:`\texttt{MAL_STOICHIOMETRY_SOLID}` by default)
+
+ ================ ============================================================
+ **Type:** double **Length:** :math:`\texttt{NTOTALBND} \cdot \texttt{NREACT}`
+ ================ ============================================================
+
+``MAL_EXPONENTS_SOLID_BWD``
+
+ Backward exponent matrix of particle solid phase reactions as :math:`\texttt{NTOTALBND} \times \texttt{NREACT}` matrix in row-major storage (optional, calculated from :math:`\texttt{MAL_STOICHIOMETRY_SOLID}` by default)
+
+ ================ ============================================================
+ **Type:** double **Length:** :math:`\texttt{NTOTALBND} \cdot \texttt{NREACT}`
+ ================ ============================================================
+
+``MAL_EXPONENTS_SOLID_FWD_MODLIQUID``
+
+ Forward liquid phase modifier exponent matrix of particle solid phase reactions as :math:`\texttt{NCOMP} \times \texttt{NREACT}` matrix in row-major storage (optional, defaults to all 0)
+
+ ================ ========================================================
+ **Type:** double **Length:** :math:`\texttt{NCOMP} \cdot \texttt{NREACT}`
+ ================ ========================================================
+
+``MAL_EXPONENTS_SOLID_BWD_MODLIQUID``
+
+ Backward liquid phase modifier exponent matrix of particle solid phase reactions as :math:`\texttt{NCOMP} \times \texttt{NREACT}` matrix in row-major storage (optional, defaults to all 0)
+
+ ================ ========================================================
+ **Type:** double **Length:** :math:`\texttt{NCOMP} \cdot \texttt{NREACT}`
+ ================ ========================================================
diff --git a/v5.0.1/_sources/interface/reaction/michaelis_menten_kinetics.rst.txt b/v5.0.1/_sources/interface/reaction/michaelis_menten_kinetics.rst.txt
new file mode 100644
index 000000000..76884ea2e
--- /dev/null
+++ b/v5.0.1/_sources/interface/reaction/michaelis_menten_kinetics.rst.txt
@@ -0,0 +1,41 @@
+.. _michaelis_menten_kinetics_config:
+
+Michaelis Menten kinetics
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Group /input/model/unit_XXX/reaction - REACTION_MODEL = MICHAELIS_MENTEN**
+
+``MM_STOICHIOMETRY_BULK``
+
+ Stochiometric matrix :math:`S`.
+ The substrate component :math:`c_S` is identified by the index of the first negative entry in the stoichiometry of the corresponding reaction.
+ Input as reaction index major.
+
+ ================ ============================= ========================================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NREACT} \cdot \texttt{NCOMP}`
+ ================ ============================= ========================================================
+
+``MM_VMAX``
+
+ Limiting rate :math:`\mu_{\mathrm{max},j}` at saturation.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NREACT}`
+ ================ ============================= ===================================
+
+``MM_KMM``
+
+ Michaelis constant :math:`k_{\mathrm{MM},j}`.
+
+ ================ ============================= ===================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NREACT}`
+ ================ ============================= ===================================
+
+``MM_KI``
+
+ Inhibition constant :math:`k_{\mathrm{I},j,i}` w.r.t component :math:`i` and reaction :math:`j`. If :math:`k_{\mathrm{I},j,i} <= 0`, the component does not inhibit the reaction.
+ Input as reaction index major.
+
+ ================ ============================= ========================================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NREACT} \cdot \texttt{NCOMP}`
+ ================ ============================= ========================================================
\ No newline at end of file
diff --git a/v5.0.1/_sources/interface/return_data.rst.txt b/v5.0.1/_sources/interface/return_data.rst.txt
new file mode 100644
index 000000000..7562ea8ef
--- /dev/null
+++ b/v5.0.1/_sources/interface/return_data.rst.txt
@@ -0,0 +1,308 @@
+.. _return:
+
+Return data
+===========
+
+Group /input/return
+-------------------
+
+``WRITE_SOLUTION_TIMES``
+
+ Write times at which a solution was produced (optional, defaults to 1)
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLUTION_LAST``
+
+ Write full solution state vector at last time point, including the state derivative vector (optional, defaults to 0)
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENS_LAST``
+
+ Write full sensitivity state vectors at last time point, including the state derivative vector (optional, defaults to 0)
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``SPLIT_COMPONENTS_DATA``
+
+ Determines whether a joint dataset (matrix or tensor) for all components is created or if each component is put in a separate dataset (:math:`\texttt{XXX_COMP_000}`, :math:`\texttt{XXX_COMP_001}`, etc.) (optional, defaults to 1)
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``SPLIT_PORTS_DATA``
+
+ Determines whether a joint dataset (matrix or tensor) for all inlet/outlet ports is created or if each port is put in a separate dataset (:math:`\texttt{XXX_PORT_000}`, :math:`\texttt{XXX_PORT_001}`, etc.) (optional, defaults to 1)
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``SINGLE_AS_MULTI_PORT``
+
+ Determines whether single port unit operations are treated as multi port unit operations in the output naming scheme (i.e., :math:`\texttt{_PORT_XYZ_}` is added to the name) (optional, defaults to 0)
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+
+Group /input/return/unit_XXX
+----------------------------
+
+``WRITE_COORDINATES``
+
+ Write coordinates of discretization nodes
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLUTION_INLET``
+
+ Write solutions at unit operation inlet :math:`c^l_i(t,0)`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLUTION_OUTLET``
+
+ Write solutions at unit operation outlet (chromatograms) :math:`c^l_i(t,L)`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLUTION_BULK``
+
+ Write solutions of the bulk volume :math:`c^l_i`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLUTION_PARTICLE``
+
+ Write solutions of the particle mobile phase :math:`c^p_{j,i}`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLUTION_SOLID``
+
+ Write solutions of the solid phase :math:`c^s_{j,i,m_{j,i}}`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLUTION_FLUX``
+
+ Write solutions of the bead fluxes :math:`j_{f,i}`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLUTION_VOLUME``
+
+ Write solutions of the volume V
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLDOT_INLET``
+
+ Write solution time derivatives at unit operation inlet :math:`\partial c^l_i(t,0) / \partial t`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLDOT_OUTLET``
+
+ Write solution time derivatives at unit operation outlet (chromatograms) :math:`\partial c^l_i(t,L) / \partial t`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLDOT_BULK``
+
+ Write solution time derivatives of the bulk volume :math:`\partial c^l_i / \partial t`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLDOT_PARTICLE``
+
+ Write solution time derivatives of the particle mobile phase :math:`\partial c^p_{j,i} / \partial t`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLDOT_SOLID``
+
+ Write solution time derivatives of the solid phase :math:`\partial c^s_{j,i,m_{j,i}} / \partial t`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLDOT_FLUX``
+
+ Write solution time derivatives of the bead fluxes :math:`\partial j_{f,i} / \partial t`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLDOT_VOLUME``
+
+ Write solution time derivatives of the volume :math:`\partial V / \partial t`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENS_INLET``
+
+ Write sensitivities at unit operation inlet :math:`\partial c^l_i(t,0) / \partial p`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENS_OUTLET``
+
+ Write sensitivities at unit operation outlet (chromatograms) :math:`\partial c^l_i(t,L) / \partial p`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENS_BULK``
+
+ Write sensitivities of the bulk volume :math:`\partial c^l_i / \partial p`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENS_PARTICLE``
+
+ Write sensitivities of the particle mobile phase :math:`\partial c^p_{j,i} / \partial p`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENS_SOLID``
+
+ Write sensitivities of the solid phase :math:`\partial c^s_{j,i,m_{j,i}} / \partial p`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENS_FLUX``
+
+ Write sensitivities of the bead fluxes :math:`\partial j_{f,i} / \partial p`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENS_VOLUME``
+
+ Write sensitivities of the volume :math:`\partial V / \partial p`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENSDOT_INLET``
+
+ Write sensitivity time derivatives at unit operation inlet :math:`\partial^2 c^l_i(t,0) / (\partial p, \partial t)`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENSDOT_OUTLET``
+
+ Write sensitivity time derivatives at unit operation outlet (chromatograms) :math:`\partial^2 c^l_i(t,L) / (\partial p, \partial t)`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENSDOT_BULK``
+
+ Write sensitivity time derivatives of the bulk volume :math:`\partial^2 c^l_i / (\partial p, \partial t)`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENSDOT_PARTICLE``
+
+ Write sensitivity time derivatives of the particle mobile phase :math:`\partial^2 c^p_{j,i} / (\partial p, \partial t)`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENSDOT_SOLID``
+
+ Write sensitivity time derivatives of the solid phase :math:`\partial^2 c^s_{j,i,m_{j,i}} / (\partial p, \partial t)`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENSDOT_FLUX``
+
+ Write sensitivity time derivatives of the bead fluxes :math:`\partial^2 j_{f,i} / (\partial p, \partial t)`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENSDOT_VOLUME``
+
+ Write sensitivity time derivatives of the volume :math:`\partial^2 V / (\partial p, \partial t)`
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SOLUTION_LAST_UNIT``
+
+ Write solution state vector of this unit at last time point, including the state derivative vector (optional, defaults to 0)
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
+``WRITE_SENS_LAST_UNIT``
+
+ Write sensitivity state vector of this unit at last time point, including the state derivative vector (optional, defaults to 0)
+
+ ============= ==========================
+ **Type:** int **Range:** :math:`\{0,1\}`
+ ============= ==========================
+
diff --git a/v5.0.1/_sources/interface/sensitivities.rst.txt b/v5.0.1/_sources/interface/sensitivities.rst.txt
new file mode 100644
index 000000000..e179ae8b9
--- /dev/null
+++ b/v5.0.1/_sources/interface/sensitivities.rst.txt
@@ -0,0 +1,102 @@
+.. _sensitivity:
+
+Parameter Sensitivities
+=======================
+
+.. _FFSensitivity:
+
+Group /input/sensitivity
+------------------------
+
+``NSENS``
+
+ Number of sensitivities to be computed
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 0` **Length:** 1
+ ============= ========================= =============
+
+``SENS_METHOD``
+
+ Method used for computation of sensitivities (algorithmic differentiation)
+
+ ================ =============================== =============
+ **Type:** string **Range:** :math:`\texttt{ad1}` **Length:** 1
+ ================ =============================== =============
+
+.. _FFSensitivityParam:
+
+Group /input/sensitivity/param_XXX
+----------------------------------
+
+``SENS_UNIT``
+
+ Unit operation index
+
+ ============= ========================= ==========================
+ **Type:** int **Range:** :math:`\geq 0` **Length:** :math:`\geq 1`
+ ============= ========================= ==========================
+
+``SENS_NAME``
+
+ Name of the parameter (Note that ``PAR_RADIUS`` and ``PAR_CORE_RADIUS`` sensitivities are only available for Finite Volume discretization)
+
+ ================ ===========================
+ **Type:** string **Length:** :math:`\geq 1`
+ ================ ===========================
+
+``SENS_COMP``
+
+ Component index (:math:`-1` if parameter is independent of components)
+
+ ============= ========================== ============================
+ **Type:** int **Range:** :math:`\geq -1` **Length:** :math:`\geq 1`
+ ============= ========================== ============================
+
+``SENS_PARTYPE``
+
+ Particle type index (:math:`-1` if parameter is independent of particle types)
+
+ ============= ========================== ===========================
+ **Type:** int **Range:** :math:`\geq -1` **Length:** :math:`\geq 1`
+ ============= ========================== ===========================
+
+``SENS_REACTION``
+
+ Reaction index (:math:`-1` if parameter is independent of reactions)
+
+ ============= ========================== ===========================
+ **Type:** int **Range:** :math:`\geq -1` **Length:** :math:`\geq 1`
+ ============= ========================== ===========================
+
+``SENS_BOUNDPHASE``
+
+ Bound phase index (:math:`-1` if parameter is independent of bound phases)
+
+ ============= ========================== ==========================
+ **Type:** int **Range:** :math:`\geq -1` **Length:** :math:`\geq 1`
+ ============= ========================== ==========================
+
+``SENS_SECTION``
+
+ Section index (:math:`-1` if parameter is independent of sections)
+
+ ============= ========================== ==========================
+ **Type:** int **Range:** :math:`\geq -1` **Length:** :math:`\geq 1`
+ ============= ========================== ==========================
+
+``SENS_ABSTOL``
+
+ Absolute tolerance used in the computation of the sensitivities (optional). Rule of thumb: :math:`\texttt{ABSTOL} / \texttt{PARAM_VALUE}`
+
+ ================ =========================== ==========================
+ **Type:** double **Range:** :math:`\geq 0.0` **Length:** :math:`\geq 1`
+ ================ =========================== ==========================
+
+``SENS_FACTOR``
+
+ Linear factor of the combined sensitivity (optional, taken as :math:`1.0` if left out)
+
+ ================ ============================= ==========================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\geq 1`
+ ================ ============================= ==========================
diff --git a/v5.0.1/_sources/interface/solver.rst.txt b/v5.0.1/_sources/interface/solver.rst.txt
new file mode 100644
index 000000000..d700f50cb
--- /dev/null
+++ b/v5.0.1/_sources/interface/solver.rst.txt
@@ -0,0 +1,204 @@
+.. _solver:
+
+Solver Configuration
+====================
+
+Group /input/solver
+-------------------
+
+``NTHREADS``
+
+ Number of used threads
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``USER_SOLUTION_TIMES``
+
+ Vector with timepoints at which the solution is evaluated
+
+ **Unit:** :math:`\mathrm{s}`
+
+ ================ ========================= =====================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** Arbitrary
+ ================ ========================= =====================
+
+``CONSISTENT_INIT_MODE``
+
+ Consistent initialization mode (optional, defaults to :math:`1`). Valid values are:
+
+ 0. None
+ 1. Full
+ 2. Once, full
+ 3. Lean
+ 4. Once, lean
+ 5. Full once, then lean
+ 6. None once, then full
+ 7. None once, then lean
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{ 0, \dots, 7\}` **Length:** 1
+ ============= =================================== =============
+
+``CONSISTENT_INIT_MODE_SENS``
+
+ Consistent initialization mode for parameter sensitivities (optional, defaults to :math:`1`). Valid values are:
+
+ 0. None
+ 1. Full
+ 2. Once, full
+ 3. Lean
+ 4. Once, lean
+ 5. Full once, then lean
+ 6. None once, then full
+ 7. None once, then lean
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{ 0, \dots, 7\}` **Length:** 1
+ ============= =================================== =============
+
+.. _FFSolverTime:
+
+Group /solver/time_integrator
+-----------------------------
+
+``USE_MODIFIED_NEWTON``
+
+ Specifies whether modified or full Newton method should be used (optional, defaults to :math:`0`)
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``ABSTOL``
+
+ Absolute tolerance in the solution of the original system
+
+ ================ ====================== =============
+ **Type:** double **Range:** :math:`> 0` **Length:** 1
+ ================ ====================== =============
+
+``RELTOL``
+
+ Relative tolerance in the solution of the original system
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``ALGTOL``
+
+ Tolerance in the solution of the nonlinear consistency equations
+
+ ================ ====================== =============
+ **Type:** double **Range:** :math:`> 0` **Length:** 1
+ ================ ====================== =============
+
+``RELTOL_SENS``
+
+ Relative tolerance in the solution of the sensitivity systems
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``INIT_STEP_SIZE``
+
+ Initial time integrator step size for each section or one value for all sections (0.0: IDAS default value), see IDAS guide 4.5, p.\ 36f.
+
+ **Unit:** :math:`\mathrm{s}`
+
+ ================ ========================= =====================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`1 / \texttt{NSEC}`
+ ================ ========================= =====================================
+
+``MAX_STEPS``
+
+ Maximum number of timesteps taken by IDAS (0: IDAS default = 500), see IDAS guide Sec.~4.5
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 0` **Length:** 1
+ ============= ========================= =============
+
+``MAX_STEP_SIZE``
+
+ Maximum size of timesteps taken by IDAS (optional, defaults to unlimited 0.0), see IDAS guide Sec.~4.5
+
+ **Unit:** :math:`\mathrm{s}`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``ERRORTEST_SENS``
+
+ Determines whether (forward) sensitivities take part in local error test (optional, defaults to 1)
+
+ ============= ========================== =============
+ **Type:** int **Range:** :math:`\{0,1\}` **Length:** 1
+ ============= ========================== =============
+
+``MAX_NEWTON_ITER``
+
+ Maximum number of Newton iterations in time step (optional, defaults to 4 (IDAS default))
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 0` **Length:** 1
+ ============= ========================= =============
+
+``MAX_ERRTEST_FAIL``
+
+ Maximum number of local error test failures in time step (optional, defaults to 10 (IDAS default))
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 0` **Length:** 1
+ ============= ========================= =============
+
+``MAX_CONVTEST_FAIL``
+
+ Maximum number of Newton convergence test failures (optional, defaults to 10 (IDAS default))
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 0` **Length:** 1
+ ============= ========================= =============
+
+``MAX_NEWTON_ITER_SENS``
+
+ Maximum number of Newton iterations in forward sensitivity time step (optional, defaults to 4 (IDAS default))
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 0` **Length:** 1
+ ============= ========================= =============
+
+.. _FFSolverSections:
+
+Group /solver/sections
+----------------------
+
+``NSEC``
+
+ Number of sections
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``SECTION_TIMES``
+
+ Simulation times at which the model changes or behaves discontinously; including start and end times
+
+ **Unit:** :math:`\mathrm{s}`
+
+ ================ ========================= ===================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NSEC}+1`
+ ================ ========================= ===================================
+
+``SECTION_CONTINUITY``
+
+ Continuity indicator for each section transition: 0 (discontinuous) or 1 (continuous).
+
+ ============= ========================== ===================================
+ **Type:** int **Range:** :math:`\{0,1\}` **Length:** :math:`\texttt{NSEC}-1`
+ ============= ========================== ===================================
+
diff --git a/v5.0.1/_sources/interface/spatial_discretization_methods.rst.txt b/v5.0.1/_sources/interface/spatial_discretization_methods.rst.txt
new file mode 100644
index 000000000..d0b9e8be4
--- /dev/null
+++ b/v5.0.1/_sources/interface/spatial_discretization_methods.rst.txt
@@ -0,0 +1,124 @@
+.. _spatial_discretization_methods:
+
+Spatial discretization methods
+==============================
+
+Group /input/model/unit_XXX/discretization/SPATIAL_METHOD - Details on the methods
+----------------------------------------------------------------------------------
+
+CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG).
+While both methods approximate the same solution to the underlying models, they may differ in terms of computational performance.
+Generally, FV can perform better for small problem sizes and solutions with steep gradients, while DG excels for large problem sizes and smooth solutions.
+
+In the following, we give a brief introduction to the numerical theory w.r.t. the computational performance of the methods.
+Based on that theory and our experience, we give advice on which method to use in which scenario, how to identify the computationally best performing method, and how to specify discretization parameters.
+For a comprehensive description of the FV and DG variants that are implemented in CADET, we refer to our publications on `CADET-FV `_ and `CADET-DG `_.
+
+Discrete system size
+--------------------
+
+FV and DG discretize the continuous spatial domain of the partial differential algebraic equations (PDAE) into a finite set of discrete points.
+Then, a system of (semi-discrete) equations is formulated on those points, resulting in a system of ordinary differential algebraic equations (ODAE).
+The system size and number of unknowns, are also referred to as degrees of freedom (DoF), is given by the number of (spatial) discrete points (times the number of components for multi-component systems).
+
+The numerical solution becomes more accurate with more discrete points used, but the compute time required to solve the equations also increases.
+That is, we trade compute time for approximation accuracy.
+
+For the FV method, the number of axial discrete points in the column is specified by the number of volume cells ``NCOL``.
+For the DG method, the number of axial discrete points in the column is specified by the number of polynomial interpolation nodes (= ``POLYDEG`` + 1) times the number of DG elements ``NELEM``.
+The GRM additionally comprises a transport equation along the radial coordinate of the particles which is also spatially discretized and the particle discrete points are correspondingly given by ``NPAR`` for FV and for DG via ``PAR_POLYDEG`` and ``PAR_NELEM``.
+
+Order of convergence
+--------------------
+
+The computational performance of a numerical method depends on its theoretical order of convergence.
+The order of convergence refers to the rate at which the numerical approximation approaches the exact solution under refinement of the spatial grid.
+Consequently, higher order methods often require less spatial discrete points to compute an approximation of the desired accuracy and can thus be computationally more efficient.
+
+The theoretical order of convergence for the CADET-FV method is globally limited to 2.
+It is locally (except column boundaries) limited to 3, with an improved order of up to 5 for smooth solutions, and can be varied by specifying the parameters described in the :ref:`flux_reconstruction_methods` section.
+For the CADET-DG method, the theoretical order of convergence is :math:`N_d + 1` with :math:`N_d` denoting the polynomial degree, and can thus be user-defined by specifying the field ``POLYDEG`` (and ``PAR_POLYDEG`` for the particles in the GRM).
+
+The theoretical order of convergence is an asymptotic property, i.e. holds for infinite refinements, but can be numerivcally observed for finite refinements as well.
+Having the exact solution, we can compute an experimental order of convergence (EOC) via the formula
+
+.. math::
+ :label: ModelColumn
+
+ \begin{aligned}
+ EOC_k = \frac{log(\varepsilon_{k+1} / \varepsilon_{k}) }{log(n_{k} / n_{k+1})},
+ \end{aligned}
+
+with :math:`\varepsilon_{k}` and :math:`n_{k}` denoting some error norm and the degrees of freedom of the $k$th approximation.
+The EOC approaches the theoretical order of convergence for :math:`k \rightarrow \infty` but is typically lower for underresolved problems.
+High-order methods typically do typically not exhibit their theoretical order on very coarse grids.
+That is, increasing the number of discrete points from, e.g., 2 to 4 does often not improve the solution according to the theoretical order of convergence but by a much smaller EOC.
+
+For smooth solutions, we typically observe an EOC of around 2.5 for the default CADET-FV method and around :math:`N_d` for the CADET-DG method.
+To our experience, DG with :math:`N_d>6` does usually not realize an EOC of :math:`>6` for approximation errors within engineering tolerances, i.e. higher rates are achieved only for excessively small error tolerances that are not relevant for most applications.
+We thus recommend to choose :math:`3 \leq N_d \leq 5` for the DG method.
+
+One could still think that the higher the order of the method, the better the performance, but that is unfortunately not generally true, as the numerical solver performance can strongly depend on the smoothness of the approximated solution.
+
+Smooth solutions
+----------------
+
+The smoothness of a function indicates the absence of sudden changes, reflected in the continuity and differentiability of the function and its derivatives.
+In numerical simulation, smoothness indicators are often based on derivatives or moments of the solution.
+That is, the occurrence of strong gradients and high frequencies are used to identify non-smooth parts of the solution.
+Godunov's order barrier theorem shows why the concept of smoothness plays a crucial role in the deployment of numerical methods.
+It states that linear high-order methods that are monotonous are at most first-order accurate.
+Linear higher-order (:math:`\gt 1`) methods thus suffer from artificial oscillations at non-smooth parts of the solution, specifically at discontinuities and strong gradients.
+Some higher-order methods, such as the FV variants implemented in CADET, contain a non-linear mechanism to suppress these oscillations.
+The non-linear WENO mechanism employed in CADET-FV can be fine-tuned via the parameters specified in the :ref:`flux_reconstruction_methods` section.
+Unfortunately, non-linear higher-order methods (here :math:`\geq 3`) are either not applicable (e.g., undefined boundary treatment) or have other shortcomings, such as parameters whose optimal values can be highly proplem-specific.
+
+The DG variant that is implemented in CADET is a linear high-order method (arbitrary order) and can thus exhibit oscillatory behaviour at strong gradients, which increases the approximation error and results in a smaller EOC for lower resolutions.
+Since strong gradients are local phenomena which can be captured by employing more discrete points, DG performs better again for higher spatial resolutions.
+This, however, might happen after the engineering error tolerance is by far surpassed.
+Hence, CADET-FV as a stabilized lower-order method can perform better, depending on the smoothness of the approximated solution.
+The DG method reduces its oscillatory behaviour by adding artificial numerical dispersion at element interfaces.
+Thus, the use of a lower polynomial degree and more elements is recommended for non-smooth solutions.
+
+In Chromatography, mathematical discontinuities never happen, as there are always some dispersive effects in reality.
+Chromatography models, however, allow for discontinuities if dispersion parameters are set to zero.
+Moreover, steep and self-sharpening concentration fronts might appear due to competitive adsorption.
+Examples that can cause self-sharpening concentration fronts are often associated with competitive Langmuir type isotherms for components with differently strong binding properties.
+Nonetheless, many chromatography settings yield rather smooth concentration profiles, for which DG is the better choice in terms of computational performance.
+
+Recommendations on the choice of spatial discretization methods
+---------------------------------------------------------------
+
+We recommend the FV method for
+
+- Small problem sizes, e.g., low spatial resolution with the LRM
+- Problems with strong gradients, e.g., no or low dispersion and binding model parameters that create sharp fronts
+- Binding models that mathematically require positive values or exhibit strange behaviour with negative concentration values
+
+We recommend the DG method for
+
+- Large problem sizes, e.g., high spatial resolutions and more complex models (i.e. the LRMP and specifically the GRM)
+- Smooth problems, i.e., sufficient band broadening
+
+Recommendations on DG discretization parameters
+-----------------------------------------------
+
+- Employ an axial polynomial degree between 3 and 5
+- Select a lower axial polynomial degree for approximating functions that tend to be less smooth and employ more elements instead. Converse choice for smooth problems
+- Adjust the DG particle polynomial degree to control approximation accuracy; leave the number of elements at one. Make exceptions if very steep gradients occur inside the particles or when specific regions of the particle domain are more interesting (the spatial resolution of certain regions can be refined by a user-defined spacing of multiple elements)
+- The field ``EXACT_INTEGRATION`` specifies the DG polynomial integration method. The default value of $0$ (collocation DG) is expected to be slightly more performant in most settings
+
+Refinement strategy
+-------------------
+
+A common problem in numerical simulation is that the number of discrete points required to yield an accurate approximation within a specific tolerance is unknown.
+We thus recommend determining the approximation error via comparison with a refined reference approximation.
+Both the theoretical order of convergence and the EOC can be used to estimate the required number of discrete points.
+An EOC that is significantly lower than the theoretical order indicates that the problem is numerically underresolved.
+
+Note on DG solution vector
+--------------------------
+
+Any liquid or solid concentration within the column or particles is reported on the discrete points that are employed by the method.
+That is, DG yields a piece-wise polynomial approximation on Lagrange-Gauss-Lobatto nodes.
+If the solution is desired on a different grid, element-wise polynomial interpolation should be applied, and element interface values must be averaged.
diff --git a/v5.0.1/_sources/interface/system.rst.txt b/v5.0.1/_sources/interface/system.rst.txt
new file mode 100644
index 000000000..1b855b12b
--- /dev/null
+++ b/v5.0.1/_sources/interface/system.rst.txt
@@ -0,0 +1,268 @@
+.. _FFModelSystem:
+
+System of unit operations
+=========================
+
+Group /input/model
+------------------
+
+``NUNITS``
+
+ Number of unit operations in the system
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``INIT_STATE_Y``
+
+ Initial full state vector (optional, unit operation specific initial data is ignored)
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``INIT_STATE_YDOT``
+
+ Initial full time derivative state vector (optional, unit operation specific initial data is ignored)
+
+ ================ ==================================
+ **Type:** double **Length:** :math:`\texttt{NDOF}`
+ ================ ==================================
+
+``INIT_STATE_SENSY_XXX``
+
+ Initial full time derivative state vector of the :math:`\texttt{XXX}` th sensitivity system (optional, can currently not be specified on unit operation level)
+
+ ================ ==================================
+ **Type:** double **Length:** :math:`\texttt{NDOF}`
+ ================ ==================================
+
+``INIT_STATE_SENSYDOT_XXX``
+
+ Initial full state vector of the :math:`\texttt{XXX}` th sensitivity system (optional, can currently not be specified on unit operation level)
+
+ ================ ==================================
+ **Type:** double **Length:** :math:`\texttt{NDOF}`
+ ================ ==================================
+
+.. _FFModelSystemConnections:
+
+Group /input/model/connections
+------------------------------
+
+``NSWITCHES``
+
+ Number of valve switches
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``CONNECTIONS_INCLUDE_PORTS``
+
+ Determines whether the :math:`\texttt{CONNECTIONS}` table includes ports (:math:`1`) or not (:math:`0`). Optional, defaults to 0 unless a unit operation model with multiple ports is present.
+
+ ============= ============================ =============
+ **Type:** int **Range:** :math:`\{ 0,1 \}` **Length:** 1
+ ============= ============================ =============
+
+``CONNECTIONS_INCLUDE_DYNAMIC_FLOW``
+
+ Determines whether the :math:`\texttt{CONNECTIONS}` table includes linear, quadratic, and cubic flow rate coefficients (1) or not (0). Optional, defaults to 0.
+
+ ============= ============================ =============
+ **Type:** int **Range:** :math:`\{ 0,1 \}` **Length:** 1
+ ============= ============================ =============
+
+
+.. _FFModelConnectionSwitch:
+
+Group /input/model/connections/switch_XXX
+-----------------------------------------
+
+``SECTION``
+
+ Index of the section that activates this connection set
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 0` **Length:** 1
+ ============= ========================= =============
+
+``CONNECTIONS``
+
+ Matrix with list of connections in row-major storage. Columns are *UnitOpID from*, *UnitOpID to*, *Port from*, *Port to*, *Component from*, *Component to*, *volumetric flow rate*, *linear flow rate coefficient*, *quadratic flow rate coefficient*, *cubic flow rate coefficient*.
+ If both port indices are :math:`-1`, all ports are connected.
+ If both component indices are :math:`-1`, all components are connected.
+
+ The flow rate is a cubic function of time,
+
+ .. math::
+ Q = Q_0 + Q_1(t - t_s) + Q_2(t-t_s)^2 + Q_3(t-t_s)^3,
+
+ where :math:`t_s` is the beginning of the section that activates the switch (i.e., :math:`\texttt{SECTION_TIMES}` at index :math:`\texttt{SECTION}`).
+
+ The port indices are left out if :math:`\texttt{CONNECTIONS_INCLUDE_PORTS}` is set to :math:`0` and no unit operation with multiple ports is present in the system. If a unit operation with multiple ports is present, :math:`\texttt{CONNECTIONS_INCLUDE_PORTS}` is ignored and port indices are mandatory.
+
+ The last three flow rate coefficients are left out if :math:`\texttt{CONNECTIONS_INCLUDE_DYNAMIC_FLOW}` is set to :math:`0`.
+ Contrary to the constant coefficient, which has the parameter name :math:`\texttt{CONNECTION}`, the other coefficients are named :math:`\texttt{CONNECTION_LIN}`, :math:`\texttt{CONNECTION_QUAD}`, and :math:`\texttt{CONNECTION_CUB}`, respectively.
+
+ For addressing the flow rates as a parameter senstivity, the mapping is as follows:
+
+ - :math:`\texttt{SENS_UNIT}` Unused, always set to :math:`-1`
+ - :math:`\texttt{SENS_BOUNDPHASE}` *UnitOpID from*
+ - :math:`\texttt{SENS_REACTION}` *UnitOpID to*
+ - :math:`\texttt{SENS_COMP}` *Port from*
+ - :math:`\texttt{SENS_PARTYPE}` *Port to*
+ - :math:`\texttt{SENS_SECTION}` :math:`\texttt{SECTION}` that activates the valve switch
+
+ ================ ========================== ============================================================
+ **Type:** double **Range:** :math:`\geq -1` **Length:** :math:`\{5,7,8,10\} \cdot \texttt{NCONNECTIONS}`
+ ================ ========================== ============================================================
+
+.. _FFModelExternalSourceLinInterp:
+
+Group /input/model/external/source_XXX - EXTFUN_TYPE = LINEAR_INTERP_DATA
+-------------------------------------------------------------------------
+
+``VELOCITY``
+
+ Velocity of the external profile in positive column axial direction.
+ The velocity is normalized to a column with length 1, hence the unit :math:`\mathrm{s}^{-1}`.
+
+ **Unit:** :math:`\mathrm{s}^{-1}`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``DATA``
+
+ Function values :math:`T` at the data points
+
+ **Unit:** :math:`[\mathrm{Ext}]`
+
+ ================ ============================= =====================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** Arbitrary
+ ================ ============================= =====================
+
+``TIME``
+ Time of the data points
+
+ **Unit:** :math:`\mathrm{s}`
+
+ ================ =========================== =========================================
+ **Type:** double **Range:** :math:`\geq 0.0` **Length:** Same as :math:`\texttt{DATA}`
+ ================ =========================== =========================================
+
+
+.. _FFModelExternalSourcePieceCubicPoly:
+
+Group /input/model/external/source_XXX - EXTFUN_TYPE = PIECEWISE_CUBIC_POLY
+---------------------------------------------------------------------------
+
+``VELOCITY``
+
+ Velocity of the external profile in positive column axial direction.
+ The velocity is normalized to a column with length 1, hence the unit :math:`\mathrm{s}^{-1}`.
+
+ **Unit:** :math:`\mathrm{s}^{-1}`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``CONST_COEFF``
+
+ Constant coefficients of piecewise cubic polynomial
+
+ **Unit:** :math:`[\mathrm{Ext}]`
+
+ ================ ============================= =====================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** Arbitrary
+ ================ ============================= =====================
+
+``LIN_COEFF``
+
+ Linear coefficients of piecewise cubic polynomial
+
+ **Unit:** :math:`[\mathrm{Ext}]\,\mathrm{s}^{-1}`
+
+ ================ ============================= ================================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** Same as :math:`\texttt{CONST_COEFF}`
+ ================ ============================= ================================================
+
+``QUAD_COEFF``
+
+ Quadratic coefficients of piecewise cubic polynomial
+
+ **Unit:** :math:`[\mathrm{Ext}]\,\mathrm{s}^{-2}`
+
+ ================ ============================= ================================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** Same as :math:`\texttt{CONST_COEFF}`
+ ================ ============================= ================================================
+
+``CUBE_COEFF``
+
+ Cubic coefficients of piecewise cubic polynomial
+
+ **Unit:** :math:`[\mathrm{Ext}]\,\mathrm{s}^{-3}`
+
+ ================ ============================= ================================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** Same as :math:`\texttt{CONST_COEFF}`
+ ================ ============================= ================================================
+
+``SECTION_TIMES``
+
+ Simulation times at which a new piece begins (breaks of the piecewise polynomial)
+
+ **Unit:** :math:`\mathrm{s}`
+
+ ================ =========================== ==========================================
+ **Type:** double **Range:** :math:`\geq 0.0` **Length:** :math:`\texttt{CONST_COEFF}+1`
+ ================ =========================== ==========================================
+
+.. _FFModelSolver:
+
+Group /input/model/solver
+-------------------------
+
+``GS_TYPE``
+
+ Type of Gram-Schmidt orthogonalization, see IDAS guide Section~4.5.7.3, p.~41f. A value of :math:`0` enables classical Gram-Schmidt, a value of 1 uses modified Gram-Schmidt.
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``MAX_KRYLOV``
+
+ Defines the size of the Krylov subspace in the iterative linear GMRES solver (0: :math:`\texttt{MAX_KRYLOV} = \texttt{NDOF}`)
+
+ ============= ============================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, \texttt{NDOF}\}` **Length:** 1
+ ============= ============================================== =============
+
+``MAX_RESTARTS``
+
+ Maximum number of restarts in the GMRES algorithm. If lack of memory is not an issue, better use a larger Krylov space than restarts.
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 0` **Length:** 1
+ ============= ========================= =============
+
+``SCHUR_SAFETY``
+
+ Schur safety factor; Influences the tradeoff between linear iterations and nonlinear error control; see IDAS guide Section~2.1 and 5.
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``LINEAR_SOLUTION_MODE``
+
+ Determines whether the system of models is solved in parallel (1) or sequentially (2). A sequential solution is only possible for systems without cyclic connections. The setting can be chosen automatically (0) based on a heuristic (less than 25 unit operations and acyclic network selects sequential mode). Optional, defaults to automatic (0).
+
+ ============= ============================== =============
+ **Type:** int **Range:** :math:`\{ 0,1,2 \}` **Length:** 1
+ ============= ============================== =============
diff --git a/v5.0.1/_sources/interface/unit_operations/2d_general_rate_model.rst.txt b/v5.0.1/_sources/interface/unit_operations/2d_general_rate_model.rst.txt
new file mode 100644
index 000000000..43fa62af0
--- /dev/null
+++ b/v5.0.1/_sources/interface/unit_operations/2d_general_rate_model.rst.txt
@@ -0,0 +1,515 @@
+.. _2d_general_rate_model_config:
+
+Two dimensional general rate model
+==================================
+
+Group /input/model/unit_XXX - UNIT_TYPE = GENERAL_RATE_MODEL_2D
+---------------------------------------------------------------
+
+For information on model equations, refer to :ref:`2d_general_rate_model_model`.
+
+
+``UNIT_TYPE``
+
+ Specifies the type of unit operation model
+
+ ================ ================================================= =============
+ **Type:** string **Range:** :math:`\texttt{GENERAL_RATE_MODEL_2D}` **Length:** 1
+ ================ ================================================= =============
+
+``NCOMP``
+
+ Number of chemical components in the chromatographic medium
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``ADSORPTION_MODEL``
+
+ Specifies the type of binding model of each particle type (or of all particle types if length is 1)
+
+ ================ ========================================== ==========================================
+ **Type:** string **Range:** See Section :ref:`FFAdsorption` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ ========================================== ==========================================
+
+``ADSORPTION_MODEL_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{ADSORPTION_MODEL}`. If set to 0, each particle type has a different binding model and the length of :math:`\texttt{ADSORPTION_MODEL}` is :math:`\texttt{NPARTYPE}`. If set to 1, all particle types share the same binding model and the length of :math:`\texttt{ADSORPTION_MODEL}` is 1. This field is optional and inferred from the length of :math:`\texttt{ADSORPTION_MODEL}` if left out.
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``NBOUND``
+
+ Number of bound states for each component in each particle type in type-major ordering
+
+ ============= ========================= ==========================================================================
+ **Type:** int **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NCOMP} / \texttt{NPARTYPE} \cdot \texttt{NCOMP}`
+ ============= ========================= ==========================================================================
+
+``REACTION_MODEL_BULK``
+
+ Specifies the type of reaction model of the bulk volume. The model is configured in the subgroup :math:`\texttt{reaction_bulk}`.
+
+ ================ ======================================== =============
+ **Type:** string **Range:** See Section :ref:`FFReaction` **Length:** 1
+ ================ ======================================== =============
+
+``REACTION_MODEL_PARTICLES``
+
+ Specifies the type of reaction model of each particle type (or of all particle types if length is 1). The model is configured in the subgroup :math:`\texttt{reaction_particle}`, or :math:`\texttt{reaction_particle_XXX}` in case of disabled multiplexing.
+
+ ================ ======================================== ==========================================
+ **Type:** string **Range:** See Section :ref:`FFReaction` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ ======================================== ==========================================
+
+``REACTION_MODEL_PARTICLES_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{REACTION_MODEL_PARTICLES}`. If set to 0, each particle type has a different reaction model and the length of :math:`\texttt{REACTION_MODEL_PARTICLES}` is :math:`\texttt{NPARTYPE}`. If set to 1, all particle types share the same reaction model and the length of :math:`\texttt{REACTION_MODEL_PARTICLES}` is 1. This field is optional and inferred from the length of :math:`\texttt{REACTION_MODEL_PARTICLES}` if left out.
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``INIT_C``
+
+ Initial concentrations for each component in all radial zones the bulk mobile phase (length :math:`\texttt{NCOMP}`), or for each component in each radial zone (length :math:`\texttt{NCOMP} \cdot \texttt{NRAD}`, ordering radial-major)
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ ================ ========================= =========================================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NCOMP} / \texttt{NCOMP} \cdot \texttt{NRAD}`
+ ================ ========================= =========================================================================
+
+``INIT_CP``
+
+ Initial concentrations for each component in the bead liquid phase (optional, :math:`\texttt{INIT_C}` is used if left out). The length of this field can be :math:`\texttt{NCOMP}` (same values for each radial zone and particle type), :math:`\texttt{NPARTYPE} \cdot \texttt{NCOMP}` (same values for each radial zone), :math:`\texttt{RAD} \cdot \texttt{NCOMP}` (same values for each particle type), or :math:`\texttt{NRAD} \cdot \texttt{NPARTYPE} \cdot \texttt{NCOMP}`. The ordering is radial-type-major. Values for each particle type can only be given when :math:`\texttt{ADSORPTION_MODEL_MULTIPLEX}` is 0. In the radial-inhomogeneous case, the :math:`\texttt{SENS_REACTION}` field is used for indexing the radial zone when specifying parameter sensitivities.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}`
+
+ ================ =========================
+ **Type:** double **Range:** :math:`\geq 0`
+ ================ =========================
+
+``INIT_Q``
+
+ Initial concentrations for each bound state of each component in the bead solid phase. If :math:`\texttt{ADSORPTION_MODEL_MULTIPLEX}` is 0, values for each particle type are required in type-component-major ordering (length is :math:`\texttt{NTOTALBND}`). If :math:`\texttt{ADSORPTION_MODEL_MULTIPLEX}` is 1, values for one particle type are required in component-major ordering (length is :math:`\sum_{i = 0}^{\texttt{NCOMP} - 1} \texttt{NBND}_i`). Alternatively, values for each radial zone can be supplied. If :math:`\texttt{ADSORPTION_MODEL_MULTIPLEX}` is 0, values for each radial zone and each particle type are required in radial-type-component-major ordering (length is :math:`\texttt{NRAD} \cdot \texttt{NTOTALBND}`). If :math:`\texttt{ADSORPTION_MODEL_MULTIPLEX}` is 1, values for each radial zone and all particle types are required in radial-component-major ordering (length is :math:`\texttt{NRAD} \cdot \sum_{i = 0}^{\texttt{NCOMP} - 1} \texttt{NBND}_i`). In the radial-inhomogeneous case, the :math:`\texttt{SENS_REACTION}` field is used for indexing the radial zone when specifying parameter sensitivities.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{SP}}^{-3}`
+
+ ================ =========================
+ **Type:** double **Range:** :math:`\geq 0`
+ ================ =========================
+
+``INIT_STATE``
+
+ Full state vector for initialization (optional, :math:`\texttt{INIT_C}`, :math:`\texttt{INIT_CP}`, and :math:`\texttt{INIT_Q}` will be ignored; if length is :math:`2\texttt{NDOF}`, then the second half is used for time derivatives)
+
+ **Unit:** :math:`various`
+
+ ================ ============================= ==================================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NDOF} / 2\texttt{NDOF}`
+ ================ ============================= ==================================================
+
+``COL_DISPERSION``
+
+ Axial dispersion coefficient. In case of a spatially inhomogeneous setting, the :math:`\texttt{SENS_PARTYPE}` field is used for indexing the radial zone when specifying parameter sensitivities.
+
+ **Unit:** :math:`\mathrm{m}_{\mathrm{IV}}^{2}\,\mathrm{s}^{-1}`
+
+ ================ ========================= =========================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{COL_DISPERSION_MULTIPLEX}`
+ ================ ========================= =========================================================
+
+``COL_DISPERSION_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{COL_DISPERSION}`. Determines whether :math:`\texttt{COL_DISPERSION}` is treated as component-, radial-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{COL_DISPERSION}`. Valid modes are:
+
+ 0. Component-independent, radial-independent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is 1
+ 1. Component-independent, radial-dependent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NRAD}`
+ 2. Component-dependent, radial-independent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP}`
+ 3. Component-dependent, radial-dependent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NRAD}`; ordering is radial-major
+ 4. Component-independent, radial-independent, section-dependent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NSEC}`
+ 5. Component-independent, radial-dependent, section-dependent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NRAD} \cdot \texttt{NSEC}`; ordering is section-major
+ 6. Component-dependent, radial-independent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+ 7. Component-dependent, radial-dependent, section-dependent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NRAD} \cdot \texttt{NSEC}`; ordering is section-radial-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 7 \}` **Length:** 1
+ ============= =================================== =============
+
+``COL_DISPERSION_RADIAL``
+
+ Radial dispersion coefficient. In case of a spatially inhomogeneous setting, the :math:`\texttt{SENS_PARTYPE}` field is used for indexing the radial zone when specifying parameter sensitivities.
+
+ **Unit:** :math:`\mathrm{m}_{\mathrm{IV}}^{2}\,\mathrm{s}^{-1}`
+
+ ================ ========================= ================================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{COL_DISPERSION_RADIAL_MULTIPLEX}`
+ ================ ========================= ================================================================
+
+``COL_DISPERSION_RADIAL_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{COL_DISPERSION_RADIAL}`. Determines whether :math:`\texttt{COL_DISPERSION_RADIAL}` is treated as component-, radial-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{COL_DISPERSION_RADIAL}`. Valid modes are:
+
+ 0. Component-independent, radial-independent, section-independent; length of :math:`\texttt{COL_DISPERSION_RADIAL}` is 1
+ 1. Component-independent, radial-dependent, section-independent; length of :math:`\texttt{COL_DISPERSION_RADIAL}` is :math:`\texttt{NRAD}`
+ 2. Component-dependent, radial-independent, section-independent; length of :math:`\texttt{COL_DISPERSION_RADIAL}` is :math:`\texttt{NCOMP}`
+ 3. Component-dependent, radial-dependent, section-independent; length of :math:`\texttt{COL_DISPERSION_RADIAL}` is :math:`\texttt{NCOMP} \cdot \texttt{NRAD}`; ordering is radial-major
+ 4. Component-independent, radial-independent, section-dependent; length of :math:`\texttt{COL_DISPERSION_RADIAL}` is :math:`\texttt{NSEC}`
+ 5. Component-independent, radial-dependent, section-dependent; length of :math:`\texttt{COL_DISPERSION_RADIAL}` is :math:`\texttt{NRAD} \cdot \texttt{NSEC}`; ordering is section-major
+ 6. Component-dependent, radial-independent, section-independent; length of :math:`\texttt{COL_DISPERSION_RADIAL}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+ 7. Component-dependent, radial-dependent, section-dependent; length of :math:`\texttt{COL_DISPERSION_RADIAL}` is :math:`\texttt{NCOMP} \cdot \texttt{NRAD} \cdot \texttt{NSEC}`; ordering is section-radial-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 7 \}` **Length:** 1
+ ============= =================================== =============
+
+``COL_LENGTH``
+
+ Column length
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ ====================== =============
+ **Type:** double **Range:** :math:`> 0` **Length:** 1
+ ================ ====================== =============
+
+``COL_RADIUS``
+
+ Column radius. This parameter is optional if ``CROSS_SECTION_AREA`` is provided.
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ ====================== =============
+ **Type:** double **Range:** :math:`> 0` **Length:** 1
+ ================ ====================== =============
+
+``CROSS_SECTION_AREA``
+
+ Cross section area of the column. This parameter is optional and will be ignored if `COL_RADIUS` is provided.
+
+ **Unit:** :math:`\mathrm{m}^{2}`
+
+ ================ ===================== =============
+ **Type:** double **Range:** :math:`>0` **Length:** 1
+ ================ ===================== =============
+
+``COL_POROSITY``
+
+ Column porosity, either constant (length is 1) or for each radial zone (length is :math:`\texttt{NRAD}`). In case of a spatially inhomogeneous setting, the :math:`\texttt{SENS_PARTYPE}` field is used for indexing the radial zone when specifying parameter sensitivities.
+
+ ================ ======================== =====================================
+ **Type:** double **Range:** :math:`(0,1]` **Length:** :math:`1 / \texttt{NRAD}`
+ ================ ======================== =====================================
+
+``FILM_DIFFUSION``
+
+ Film diffusion coefficients for each component of each particle type
+
+ **Unit:** :math:`\mathrm{m}\,\mathrm{s}^{-1}`
+
+ ================ ========================= =======================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{FILM_DIFFUSION_MULTIPLEX}`
+ ================ ========================= =======================================================
+
+``FILM_DIFFUSION_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{FILM_DIFFUSION}`. Determines whether :math:`\texttt{FILM_DIFFUSION}` is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{FILM_DIFFUSION}`. Valid modes are:
+
+ 0. Component-dependent, type-independent, section-independent; length of :math:`\texttt{FILM_DIFFUSION}` is :math:`\texttt{NCOMP}`
+ 1. Component-dependent, type-independent, section-dependent; length of :math:`\texttt{FILM_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+ 2. Component-dependent, type-dependent, section-independent; length of :math:`\texttt{FILM_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE}`; ordering is type-major
+ 3. Component-dependent, type-dependent, section-dependent; length of :math:`\texttt{FILM_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}`; ordering is section-type-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``PAR_POROSITY``
+
+ Particle porosity of all particle types or for each particle type
+
+ ================ ======================== =========================================
+ **Type:** double **Range:** :math:`(0,1]` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ ======================== =========================================
+
+``PAR_RADIUS``
+
+ Particle radius of all particle types or for each particle type
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ ===================== =========================================
+ **Type:** double **Range:** :math:`>0` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ ===================== =========================================
+
+``PAR_CORERADIUS``
+
+ Particle core radius of all particle types or for each particle type (optional, defaults to :math:`0~m`)
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ =========================================== =========================================
+ **Type:** double **Range:** :math:`[0, \texttt{PAR_RADIUS})` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ =========================================== =========================================
+
+``PORE_ACCESSIBILITY``
+
+ Pore accessibility factor of each component in each particle type (optional, defaults to 1).
+ Note: Should not be used in combination with any binding model!
+
+ ================ ========================= =============================================================
+ **Type:** double **Range:** :math:`(0, 1]` **Length:** see :math:`\texttt{PORE_ACCESSIBILITY_MULTIPLEX}`
+ ================ ========================= =============================================================
+
+``PORE_ACCESSIBILITY_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{PORE_ACCESSIBILITY}`. Determines whether :math:`\texttt{PORE_ACCESSIBILITY}` is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{PORE_ACCESSIBILITY}`. Valid modes are:
+
+ 0. Component-dependent, type-independent, section-independent; length of :math:`\texttt{PORE_ACCESSIBILITY}` is :math:`\texttt{NCOMP}`
+ 1. Component-dependent, type-independent, section-dependent; length of :math:`\texttt{PORE_ACCESSIBILITY}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+ 2. Component-dependent, type-dependent, section-independent; length of :math:`\texttt{PORE_ACCESSIBILITY}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE}`; ordering is type-major
+ 3. Component-dependent, type-dependent, section-dependent; length of :math:`\texttt{PORE_ACCESSIBILITY}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}`; ordering is section-type-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``PAR_DIFFUSION``
+
+ Effective particle diffusion coefficients of each component in each particle type
+
+ **Unit:** :math:`\mathrm{m}_{\mathrm{MP}}^{2}\,\mathrm{s}^{-1}`
+
+ ================ ====================== ========================================================
+ **Type:** double **Range:** :math:`> 0` **Length:** see :math:`\texttt{PAR_DIFFUSION_MULTIPLEX}`
+ ================ ====================== ========================================================
+
+``PAR_DIFFUSION_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{PAR_DIFFUSION}`. Determines whether :math:`\texttt{PAR_DIFFUSION}` is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{PAR_DIFFUSION}`. Valid modes are:
+
+ 0. Component-dependent, type-independent, section-independent; length of :math:`\texttt{PAR_DIFFUSION}` is :math:`\texttt{NCOMP}`
+ 1. Component-dependent, type-independent, section-dependent; length of :math:`\texttt{PAR_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+ 2. Component-dependent, type-dependent, section-independent; length of :math:`\texttt{PAR_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE}`; ordering is type-major
+ 3. Component-dependent, type-dependent, section-dependent; length of :math:`\texttt{PAR_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}`; ordering is section-type-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``PAR_SURFDIFFUSION``
+
+ Particle surface diffusion coefficients of each bound state of each component in each particle type (optional, defaults to all :math:`0~m_{SP}^2 s^{-1}`)
+
+ **Unit:** :math:`\mathrm{m}_{\mathrm{SP}}^{2}\,\mathrm{s}^{-1}`
+
+ ================ ========================= ============================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{PAR_SURFDIFFUSION_MULTIPLEX}`
+ ================ ========================= ============================================================
+
+``PAR_SURFDIFFUSION_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{PAR_SURFDIFFUSION}`. Determines whether :math:`\texttt{PAR_SURFDIFFUSION}` is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{PAR_SURFDIFFUSION}`. Valid modes are:
+
+ 0. Component-dependent, type-independent, section-independent; length of :math:`\texttt{PAR_SURFDIFFUSION}` is :math:`\texttt{NBND}`; ordering is component-major
+ 1. Component-dependent, type-independent, section-dependent; length of :math:`\texttt{PAR_SURFDIFFUSION}` is :math:`\texttt{NBND} \cdot \texttt{NSEC}`; ordering is section-component-major
+ 2. Component-dependent, type-dependent, section-independent; length of :math:`\texttt{PAR_SURFDIFFUSION}` is :math:`\texttt{NTOTALBND}`; ordering is type-component-major
+ 3. Component-dependent, type-dependent, section-dependent; length of :math:`\texttt{PAR_SURFDIFFUSION}` is :math:`\texttt{NTOTALBND} \cdot \texttt{NSEC}`; ordering is section-type-component-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``VELOCITY``
+
+ Indicates flow direction in each radial zone (forward if value is positive, backward if value is negative), see Section :ref:`MUOPGRMflow2D`). In case of a spatially inhomogeneous setting, the :math:`\texttt{SENS_PARTYPE}` field is used for indexing the radial cell when specifying parameter sensitivities.
+
+ ================ ============================= ===================================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** see :math:`\texttt{VELOCITY_MULTIPLEX}`
+ ================ ============================= ===================================================
+
+``VELOCITY_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{VELOCITY}`. Determines whether :math:`\texttt{VELOCITY}` is treated as radial- and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{VELOCITY}`. Valid modes are:
+
+ 0. Radial-independent, section-independent; length of :math:`\texttt{VELOCITY}` is 1
+ 1. Radial-dependent, section-independent; length of :math:`\texttt{VELOCITY}` is :math:`\texttt{NRAD}`
+ 2. Section-dependent; length of :math:`\texttt{VELOCITY}` is :math:`\texttt{NSEC}`
+ 3. Radial-dependent, section-dependent; length of :math:`\texttt{VELOCITY}` is :math:`\texttt{NRAD} \cdot \texttt{NSEC}`; ordering is section-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``NPARTYPE``
+
+ Number of particle types. Optional, inferred from the length of :math:`\texttt{NPAR}` or :math:`\texttt{NBOUND}` if left out.
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``PAR_GEOM``
+
+ Specifies the particle geometry for all or each particle type. Valid values are :math:`\texttt{SPHERE}`, :math:`\texttt{CYLINDER}`, :math:`\texttt{SLAB}`. Optional, defaults to :math:`\texttt{SPHERE}`.
+
+ ================ =================================================
+ **Type:** string **Length:** :math:`1` / :math:`\texttt{NPARTYPE}`
+ ================ =================================================
+
+``PAR_TYPE_VOLFRAC``
+
+ Volume fractions of the particle types. The volume fractions can be set homogeneous or individually along both axes. For each cell, the volume fractions have to sum to 1. In case of a spatially inhomogeneous setting, the :math:`\texttt{SENS_SECTION}` field is used for indexing the axial cell and the :math:`\texttt{SENS_REACTION}` field is used for indexing the radial cell when specifying parameter sensitivities. This field is optional in case of only one particle type.
+
+ ================ ======================== ===========================================================
+ **Type:** double **Range:** :math:`[0,1]` **Length:** see :math:`\texttt{PAR_TYPE_VOLFRAC_MULTIPLEX}`
+ ================ ======================== ===========================================================
+
+``PAR_TYPE_VOLFRAC_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{PAR_TYPE_VOLFRAC}`. Determines whether :math:`\texttt{PAR_TYPE_VOLFRAC}` is treated as radial- and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{PAR_TYPE_VOLFRAC}`. Valid modes are:
+
+ 0. Radial-independent, axial-independent; length of :math:`\texttt{PAR_TYPE_VOLFRAC}` is :math:`\texttt{NPARTYPE}`
+ 1. Radial-dependent, axial-independent; length of :math:`\texttt{PAR_TYPE_VOLFRAC}` is :math:`\texttt{NRAD} \cdot \texttt{NPARTYPE}`; ordering is radial-major
+ 2. Axial-dependent; length of :math:`\texttt{PAR_TYPE_VOLFRAC}` is :math:`\texttt{NCOL} \cdot \texttt{NPARTYPE}`; ordering is axial-major
+ 3. Radial-dependent, axial-dependent; length of :math:`\texttt{PAR_TYPE_VOLFRAC}` is :math:`\texttt{NCOL} \cdot \texttt{NRAD} \cdot \texttt{NPARTYPE}`; ordering is axial-radial-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+
+Group /input/model/unit_XXX/discretization - UNIT_TYPE - GENERAL_RATE_MODEL_2D
+------------------------------------------------------------------------------
+
+``NCOL``
+
+ Number of axial column discretization cells
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``NRAD``
+
+ Number of radial column discretization cells
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``NPAR``
+
+ Number of particle (radial) discretization cells for each particle type
+
+ ============= ========================= =========================================
+ **Type:** int **Range:** :math:`\geq 1` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ============= ========================= =========================================
+
+``RADIAL_DISC_TYPE``
+
+ Specifies the radial discretization scheme. Valid values are :math:`\texttt{EQUIDISTANT}`, :math:`\texttt{EQUIVOLUME}`, and :math:`\texttt{USER_DEFINED}`.
+
+ ================ =============
+ **Type:** string **Length:** 1
+ ================ =============
+
+``RADIAL_COMPARTMENTS``
+
+ Coordinates for the radial compartment boundaries (ignored if :math:`\texttt{RADIAL_DISC_TYPE} \neq \texttt{USER_DEFINED}`). The coordinates are absolute and have to include the endpoints 0 and :math:`\texttt{COLUMN_RADIUS}`. The values are expected in ascending order (i.e., 0 is the first and :math:`\texttt{COLUMN_RADIUS}` the last value in the array).
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ ============================================= ====================================
+ **Type:** double **Range:** :math:`[0,\texttt{COLUMN_RADIUS}]` **Length:** :math:`\texttt{NRAD} + 1`
+ ================ ============================================= ====================================
+
+``PAR_DISC_TYPE``
+
+ Specifies the discretization scheme inside the particles for all or each particle type. Valid values are :math:`\texttt{EQUIDISTANT_PAR}`, :math:`\texttt{EQUIVOLUME_PAR}`, and :math:`\texttt{USER_DEFINED_PAR}`.
+
+ ================ =========================================
+ **Type:** string **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ =========================================
+
+``PAR_DISC_VECTOR``
+
+ Node coordinates for the cell boundaries (ignored if :math:`\texttt{PAR_DISC_TYPE} \neq \texttt{USER_DEFINED_PAR}`). The coordinates are relative and have to include the endpoints 0 and 1. They are later linearly mapped to the true radial range :math:`[r_{c,j}, r_{p,j}]`. The coordinates for each particle type are appended to one long vector in type-major ordering.
+
+ ================ ======================== ===============================================
+ **Type:** double **Range:** :math:`[0,1]` **Length:** :math:`sum_i (\texttt{NPAR}_i + 1)`
+ ================ ======================== ===============================================
+
+``PAR_BOUNDARY_ORDER``
+
+ Order of accuracy of outer particle boundary condition. Optional, defaults to 2.
+
+ ============= ============================ =============
+ **Type:** int **Range:** :math:`\{ 1,2 \}` **Length:** 1
+ ============= ============================ =============
+
+``USE_ANALYTIC_JACOBIAN``
+
+ Determines whether analytically computed Jacobian matrix (faster) is used (value is 1) instead of Jacobians generated by algorithmic differentiation (slower, value is 0)
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``LINEAR_SOLVER_BULK``
+
+ Linear solver used for the sparse column bulk block. This field is optional, the best available method is selected (i.e., sparse direct solver if possible). Valid values are:
+
+ - :math:`\texttt{DENSE}` Converts the sparse matrix into a banded matrix and uses regular LAPACK. Slow and memory intensive, but always available.
+ - :math:`\texttt{UMFPACK}` Uses the UMFPACK sparse direct solver (LU decomposition) from SuiteSparse. Fast, but has to be enabled when compiling and requires UMFPACK library.
+ - :math:`\texttt{SUPERLU}` Uses the SuperLU sparse direct solver (LU decomposition). Fast, but has to be enabled when compiling and requires SuperLU library.
+
+ ================ ======================================================================= =============
+ **Type:** string **Range:** :math:`\{\texttt{DENSE},\texttt{UMFPACK},\texttt{SUPERLU}\}` **Length:** 1
+ ================ ======================================================================= =============
+
+``RECONSTRUCTION``
+
+ Type of reconstruction method for fluxes
+
+ ================ ================================ =============
+ **Type:** string **Range:** :math:`\texttt{WENO}` **Length:** 1
+ ================ ================================ =============
+
+``GS_TYPE``
+
+ Type of Gram-Schmidt orthogonalization, see IDAS guide Section~4.5.7.3, p.~41f. A value of 0 enables classical Gram-Schmidt, a value of 1 uses modified Gram-Schmidt.
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``MAX_KRYLOV``
+
+ Defines the size of the Krylov subspace in the iterative linear GMRES solver (0: :math:`\texttt{MAX_KRYLOV} = \texttt{NCOL} \cdot \texttt{NRAD} \cdot \texttt{NCOMP} \cdot \texttt{NPARTYPE}`)
+
+ ============= ================================================================================================================ =============
+ **Type:** int **Range:** :math:`\{0, \dots, \texttt{NCOL} \cdot \texttt{NRAD} \cdot \texttt{NCOMP} \cdot \texttt{NPARTYPE} \}` **Length:** 1
+ ============= ================================================================================================================ =============
+
+``MAX_RESTARTS``
+
+ Maximum number of restarts in the GMRES algorithm. If lack of memory is not an issue, better use a larger Krylov space than restarts.
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 0` **Length:** 1
+ ============= ========================= =============
+
+``SCHUR_SAFETY``
+
+ Schur safety factor; Influences the tradeoff between linear iterations and nonlinear error control; see IDAS guide Section~2.1 and 5.
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+For further discretization parameters, see also :ref:`flux_restruction_methods`, and :ref:`non_consistency_solver_parameters`.
diff --git a/v5.0.1/_sources/interface/unit_operations/cstr.rst.txt b/v5.0.1/_sources/interface/unit_operations/cstr.rst.txt
new file mode 100644
index 000000000..88385885b
--- /dev/null
+++ b/v5.0.1/_sources/interface/unit_operations/cstr.rst.txt
@@ -0,0 +1,142 @@
+.. _cstr_config:
+
+Continuous stirred tank reactor model
+=====================================
+
+Group /input/model/unit_XXX - UNIT_TYPE = CSTR
+----------------------------------------------
+
+
+For information on model equations, refer to :ref:`cstr_model`.
+
+``UNIT_TYPE``
+
+ Specifies the type of unit operation model
+
+ ================ ================================ =============
+ **Type:** string **Range:** :math:`\texttt{CSTR}` **Length:** 1
+ ================ ================================ =============
+
+``NCOMP``
+
+ Number of chemical components in the chromatographic medium
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``USE_ANALYTIC_JACOBIAN``
+
+ Determines whether analytically computed Jacobian matrix (faster) is used (value is 1) instead of Jacobians generated by algorithmic differentiation (slower, value is 0)
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``ADSORPTION_MODEL``
+
+ Specifies the type of binding model of each particle type
+
+ ================ ========================================== =====================================
+ **Type:** string **Range:** See Section :ref:`FFAdsorption` **Length:** :math:`\texttt{NPARTYPE}`
+ ================ ========================================== =====================================
+
+``NBOUND``
+
+ Number of bound states for each component in each particle type in type-major ordering (optional, defaults to all 0)
+
+ ============= ========================= ===========================================================
+ **Type:** int **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NPARTYPE} \cdot \texttt{NCOMP}`
+ ============= ========================= ===========================================================
+
+``REACTION_MODEL``
+
+ Specifies the type of reaction model of the bulk volume. The model is configured in the subgroup :math:`\texttt{reaction_bulk}`.
+
+ ================ ======================================== =============
+ **Type:** string **Range:** See Section :ref:`FFReaction` **Length:** 1
+ ================ ======================================== =============
+
+``REACTION_MODEL_PARTICLES``
+
+ Specifies the type of reaction model of each particle type (or of all particle types if length is 1). The model is configured in the subgroup :math:`\texttt{reaction_particle}`, or :math:`\texttt{reaction_particle_XXX}` in case of disabled multiplexing.
+
+ ================ ======================================== =========================================
+ **Type:** string **Range:** See Section :ref:`FFReaction` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ ======================================== =========================================
+
+``REACTION_MODEL_PARTICLES_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{REACTION_MODEL_PARTICLES}`. If set to 0, each particle type has a different reaction model and the length of :math:`\texttt{REACTION_MODEL_PARTICLES}` is :math:`\texttt{NPARTYPE}`. If set to 1, all particle types share the same reaction model and the length of :math:`\texttt{REACTION_MODEL_PARTICLES}` is 1. This field is optional and inferred from the length of :math:`\texttt{REACTION_MODEL_PARTICLES}` if left out.
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``INIT_C``
+
+ Initial concentrations for each component in the mobile phase
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ ================ ========================= ==================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NCOMP}`
+ ================ ========================= ==================================
+
+``INIT_LIQUID_VOLUME``
+
+ Initial liquid volume
+
+ **Unit:** :math:`\mathrm{m}^{3}`
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``INIT_Q``
+
+ Initial concentrations for each bound state of each component in the bead solid phase of each particle type in type-component-major ordering. This field is optional and defaults to all 0.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{SP}}^{-3}`
+
+ ================ ========================= =======================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NTOTALBND}`
+ ================ ========================= =======================================
+
+``INIT_STATE``
+
+ Full state vector for initialization (optional, :math:`\texttt{INIT_C}`, :math:`\texttt{INIT_Q}`, and :math:`\texttt{INIT_VOLUME}` will be ignored; if length is :math:`2\texttt{NDOF}`, then the second half is used for time derivatives)
+
+ **Unit:** :math:`various`
+
+ ================ ============================= ====================================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NDOF} / 2\texttt{NDOF}`
+ ================ ============================= ====================================================
+
+``CONST_SOLID_VOLUME``
+
+ Volume of solid phase
+
+ **Unit:** :math:`\mathrm{m}^{3}` (defaults to 0)
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``FLOWRATE_FILTER``
+
+ Flow rate of pure liquid without components (optional, defaults to :math:`\mathrm{m}^{3}\,\mathrm{s}^{-1}`)
+
+ **Unit:** :math:`\mathrm{m}^{3}\,\mathrm{s}^{-1}`
+
+ ================ ========================= ======================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`1 / \texttt{NSEC}`
+ ================ ========================= ======================================
+
+``PAR_TYPE_VOLFRAC``
+
+ Volume fractions of the particle types, have to sum to 1
+
+ ================ ======================== =====================================
+ **Type:** double **Range:** :math:`[0,1]` **Length:** :math:`\texttt{NPARTYPE}`
+ ================ ======================== =====================================
diff --git a/v5.0.1/_sources/interface/unit_operations/general_rate_model.rst.txt b/v5.0.1/_sources/interface/unit_operations/general_rate_model.rst.txt
new file mode 100644
index 000000000..996dc42f0
--- /dev/null
+++ b/v5.0.1/_sources/interface/unit_operations/general_rate_model.rst.txt
@@ -0,0 +1,497 @@
+.. _general_rate_model_config:
+
+General Rate Model
+==================
+
+Group /input/model/unit_XXX - UNIT_TYPE - GENERAL_RATE_MODEL
+------------------------------------------------------------
+
+For information on model equations, refer to :ref:`general_rate_model_model`.
+
+
+``UNIT_TYPE``
+
+ Specifies the type of unit operation model
+
+ ================ ============================================== =============
+ **Type:** string **Range:** :math:`\texttt{GENERAL_RATE_MODEL}` **Length:** 1
+ ================ ============================================== =============
+
+``NCOMP``
+
+ Number of chemical components in the chromatographic medium
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``ADSORPTION_MODEL``
+
+ Specifies the type of binding model of each particle type (or of all particle types if length is :math:`1`)
+
+ ================ ============================== =========================================
+ **Type:** string **Range:** :ref:`FFAdsorption` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ ============================== =========================================
+
+``ADSORPTION_MODEL_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{ADSORPTION_MODEL}`. If set to :math:`0`, each particle type has a different binding model and the length of :math:`\texttt{ADSORPTION_MODEL}` is :math:`\texttt{NPARTYPE}`. If set to :math:`1`, all particle types share the same binding model and the length of :math:`\texttt{ADSORPTION_MODEL}` is :math:`1`. This field is optional and inferred from the length of :math:`\texttt{ADSORPTION_MODEL}` if left out.
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``NBOUND``
+
+ Number of bound states for each component in each particle type in type-major ordering
+
+ ============= ========================= ===================================================================================
+ **Type:** int **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NCOMP}` / :math:`\texttt{NPARTYPE} \cdot \texttt{NCOMP}`
+ ============= ========================= ===================================================================================
+
+``REACTION_MODEL_BULK``
+
+ Specifies the type of reaction model of the bulk volume. The model is configured in the subgroup :math:`\texttt{reaction_bulk}`.
+
+ ================ ======================================== =============
+ **Type:** string **Range:** See Section :ref:`FFReaction` **Length:** 1
+ ================ ======================================== =============
+
+``REACTION_MODEL_PARTICLES``
+
+ Specifies the type of reaction model of each particle type (or of all particle types if length is :math:`1`). The model is configured in the subgroup :math:`\texttt{reaction_particle}`, or :math:`\texttt{reaction_particle_XXX}` in case of disabled multiplexing.
+
+ ================ ======================================== =========================================
+ **Type:** string **Range:** See Section :ref:`FFReaction` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ ======================================== =========================================
+
+``REACTION_MODEL_PARTICLES_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{REACTION_MODEL_PARTICLES}`. If set to :math:`0`, each particle type has a different reaction model and the length of :math:`\texttt{REACTION_MODEL_PARTICLES}` is :math:`\texttt{NPARTYPE}`. If set to :math:`1`, all particle types share the same reaction model and the length of :math:`\texttt{REACTION_MODEL_PARTICLES}` is :math:`1`. This field is optional and inferred from the length of :math:`\texttt{REACTION_MODEL_PARTICLES}` if left out.
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``INIT_C``
+
+ Initial concentrations for each component in the bulk mobile phase
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ ================ ========================= ==================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NCOMP}`
+ ================ ========================= ==================================
+
+``INIT_CP``
+
+ Initial concentrations for each component in the bead liquid phase (optional, :math:`\texttt{INIT_C}` is used if left out). The length of this field can be :math:`\texttt{NCOMP}` (same values for each particle type) or :math:`\texttt{NPARTYPE} \cdot \texttt{NCOMP}` Values for each particle type can only be given when :math:`\texttt{ADSORPTION_MODEL_MULTIPLEX}` is :math:`0`. The ordering is type-major.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}`
+
+ ================ ========================= ===========================================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NCOMP} / \texttt{NPARTYPE} \cdot \texttt{NCOMP}`
+ ================ ========================= ===========================================================================
+
+``INIT_Q``
+
+ Initial concentrations for each bound state of each component in the bead solid phase. If :math:`\texttt{ADSORPTION_MODEL_MULTIPLEX}` is :math:`0`, values for each particle type are required in type-component-major ordering (length is :math:`\texttt{NTOTALBND}`). If :math:`\texttt{ADSORPTION_MODEL_MULTIPLEX}` is :math:`1`, values for one particle type are required in component-major ordering (length is :math:`\sum_{i = 0}^{\texttt{NCOMP} - 1} \texttt{NBND}_i`).
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{SP}}^{-3}`
+
+ ================ =========================
+ **Type:** double **Range:** :math:`\geq 0`
+ ================ =========================
+
+``INIT_STATE``
+
+ Full state vector for initialization (optional, :math:`\texttt{INIT_C}`, :math:`\texttt{INIT_CP}`, and :math:`\texttt{INIT_Q}` will be ignored; if length is :math:`2\texttt{NDOF}`, then the second half is used for time derivatives)
+
+ **Unit:** :math:`various`
+
+ ================ ============================= ==================================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NDOF} / 2\texttt{NDOF}`
+ ================ ============================= ==================================================
+
+``COL_DISPERSION``
+
+ Axial dispersion coefficient
+
+ **Unit:** :math:`\mathrm{m}_{\mathrm{IV}}^{2}\,\mathrm{s}^{-1}`
+
+ ================ ========================= =========================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{COL_DISPERSION_MULTIPLEX}`
+ ================ ========================= =========================================================
+
+``COL_DISPERSION_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{COL_DISPERSION}`. Determines whether :math:`\texttt{COL_DISPERSION}` is treated as component- and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{COL_DISPERSION}`. Valid modes are:
+
+ 0. Component-independent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`1`
+ 1. Component-dependent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP}`
+ 2. Component-independent, section-dependent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NSEC}`
+ 3. Component-dependent, section-dependent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``COL_LENGTH``
+
+ Column length
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ ====================== =============
+ **Type:** double **Range:** :math:`> 0` **Length:** 1
+ ================ ====================== =============
+
+``COL_POROSITY``
+
+ Column porosity
+
+ ================ ======================== =============
+ **Type:** double **Range:** :math:`(0,1]` **Length:** 1
+ ================ ======================== =============
+
+``FILM_DIFFUSION``
+
+ Film diffusion coefficients for each component of each particle type
+
+ **Unit:** :math:`\mathrm{m}\,\mathrm{s}^{-1}`
+
+ ================ ========================= =========================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{FILM_DIFFUSION_MULTIPLEX}`
+ ================ ========================= =========================================================
+
+``FILM_DIFFUSION_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{FILM_DIFFUSION}`. Determines whether :math:`\texttt{FILM_DIFFUSION}` is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{FILM_DIFFUSION}`. Valid modes are:
+
+ 0. Component-dependent, type-independent, section-independent; length of :math:`\texttt{FILM_DIFFUSION}` is :math:`\texttt{NCOMP}`
+ 1. Component-dependent, type-independent, section-dependent; length of :math:`\texttt{FILM_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+ 2. Component-dependent, type-dependent, section-independent; length of :math:`\texttt{FILM_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE}`; ordering is type-major
+ 3. Component-dependent, type-dependent, section-dependent; length of :math:`\texttt{FILM_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}`; ordering is section-type-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``PAR_POROSITY``
+
+ Particle porosity of all particle types or for each particle type
+
+ ================ ======================== =========================================
+ **Type:** double **Range:** :math:`(0,1]` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ ======================== =========================================
+
+``PAR_RADIUS``
+
+ Particle radius of all particle types or for each particle type
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ ===================== =========================================
+ **Type:** double **Range:** :math:`>0` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ ===================== =========================================
+
+``PAR_CORERADIUS``
+
+ Particle core radius of all particle types or for each particle type (optional, defaults to :math:`\mathrm{m}`)
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ =========================================== =========================================
+ **Type:** double **Range:** :math:`[0, \texttt{PAR_RADIUS})` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ =========================================== =========================================
+
+``PORE_ACCESSIBILITY``
+
+ Pore accessibility factor of each component in each particle type (optional, defaults to :math:`1`).
+ Note: Should not be used in combination with any binding model!
+
+ ================ ========================= =============================================================
+ **Type:** double **Range:** :math:`(0, 1]` **Length:** see :math:`\texttt{PORE_ACCESSIBILITY_MULTIPLEX}`
+ ================ ========================= =============================================================
+
+``PORE_ACCESSIBILITY_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{PORE_ACCESSIBILITY}`. Determines whether :math:`\texttt{PORE_ACCESSIBILITY}` is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{PORE_ACCESSIBILITY}`. Valid modes are:
+ 0. Component-dependent, type-independent, section-independent; length of :math:`\texttt{PORE_ACCESSIBILITY}` is :math:`\texttt{NCOMP}`
+ 1. Component-dependent, type-independent, section-dependent; length of :math:`\texttt{PORE_ACCESSIBILITY}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+ 2. Component-dependent, type-dependent, section-independent; length of :math:`\texttt{PORE_ACCESSIBILITY}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE}`; ordering is type-major
+ 3. Component-dependent, type-dependent, section-dependent; length of :math:`\texttt{PORE_ACCESSIBILITY}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}`; ordering is section-type-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``PAR_DIFFUSION``
+
+ Effective particle diffusion coefficients of each component in each particle type
+
+ **Unit:** :math:`\mathrm{m}_{\mathrm{MP}}^{2}\,\mathrm{s}^{-1}`
+
+ ================ ====================== ========================================================
+ **Type:** double **Range:** :math:`> 0` **Length:** see :math:`\texttt{PAR_DIFFUSION_MULTIPLEX}`
+ ================ ====================== ========================================================
+
+``PAR_DIFFUSION_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{PAR_DIFFUSION}`. Determines whether :math:`\texttt{PAR_DIFFUSION}` is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{PAR_DIFFUSION}`. Valid modes are:
+
+ 0. Component-dependent, type-independent, section-independent; length of :math:`\texttt{PAR_DIFFUSION}` is :math:`\texttt{NCOMP}`
+ 1. Component-dependent, type-independent, section-dependent; length of :math:`\texttt{PAR_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+ 2. Component-dependent, type-dependent, section-independent; length of :math:`\texttt{PAR_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE}`; ordering is type-major
+ 3. Component-dependent, type-dependent, section-dependent; length of :math:`\texttt{PAR_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}`; ordering is section-type-major
+
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``PAR_SURFDIFFUSION``
+
+ Particle surface diffusion coefficients of each bound state of each component in each particle type (optional, defaults to all 0 :math:`\mathrm{m}_{\mathrm{SP}}^{2}\,\mathrm{s}^{-1}`)
+
+ **Unit:** :math:`\mathrm{m}_{\mathrm{SP}}^{2}\,\mathrm{s}^{-1}`
+
+ ================ ========================= ============================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{PAR_SURFDIFFUSION_MULTIPLEX}`
+ ================ ========================= ============================================================
+
+``PAR_SURFDIFFUSION_MULTIPLEX``
+ Multiplexing mode of :math:`\texttt{PAR_SURFDIFFUSION}`. Determines whether :math:`\texttt{PAR_SURFDIFFUSION}` is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{PAR_SURFDIFFUSION}`. Valid modes are:
+
+ 0. Component-dependent, type-independent, section-independent; length of :math:`\texttt{PAR_SURFDIFFUSION}` is :math:`\texttt{NBND}`; ordering is component-major
+ 1. Component-dependent, type-independent, section-dependent; length of :math:`\texttt{PAR_SURFDIFFUSION}` is :math:`\texttt{NBND} \cdot \texttt{NSEC}`; ordering is section-component-major
+ 2. Component-dependent, type-dependent, section-independent; length of :math:`\texttt{PAR_SURFDIFFUSION}` is :math:`\texttt{NTOTALBND}`; ordering is type-component-major
+ 3. Component-dependent, type-dependent, section-dependent; length of :math:`\texttt{PAR_SURFDIFFUSION}` is :math:`\texttt{NTOTALBND} \cdot \texttt{NSEC}`; ordering is section-type-component-major
+
+``PAR_SURFDIFFUSION_MULTIPLEX``
+ ============= ==================================== =============
+ **Type:** int **Range:** :math:`\{ 0, \dots, 3 \}` **Length:** 1
+ ============= ==================================== =============
+
+``PAR_SURFDIFFUSION_DEP``
+
+ Parameter dependence of :math:`\texttt{PAR_SURFDIFFUSION}`, please refer to :ref:`parameter_dependencies`, section parameter-state dependencies, for more information.
+
+``VELOCITY``
+
+ Interstitial velocity of the mobile phase (optional if :math:`\texttt{CROSS_SECTION_AREA}` is present, see Section :ref:`MUOPGRMflow`)
+ **Unit:** :math:`\mathrm{m}\,\mathrm{s}^{-1}`
+
+ ================ ============================= =======================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`1 / \texttt{NSEC}`
+ ================ ============================= =======================================
+
+``CROSS_SECTION_AREA``
+
+ Cross section area of the column (optional if :math:`\texttt{VELOCITY}` is present, see Section :ref:`MUOPGRMflow`)
+ **Unit:** :math:`\mathrm{m}^{2}`
+
+ ================ ===================== =============
+ **Type:** double **Range:** :math:`>0` **Length:** 1
+ ================ ===================== =============
+
+``NPARTYPE``
+
+ Number of particle types. Optional, inferred from the length of :math:`\texttt{NPAR}` or :math:`\texttt{NBOUND}` if left out.
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``PAR_GEOM``
+
+ Specifies the particle geometry for all or each particle type. Valid values are :math:`\texttt{SPHERE}`, :math:`\texttt{CYLINDER}`, :math:`\texttt{SLAB}`. Optional, defaults to :math:`\texttt{SPHERE}`.
+
+ ================ =================================================
+ **Type:** string **Length:** :math:`1` / :math:`\texttt{NPARTYPE}`
+ ================ =================================================
+
+``PAR_TYPE_VOLFRAC``
+
+ Volume fractions of the particle types. The volume fractions can be set for all axial cells together or for each individual axial cell. For each cell, the volume fractions have to sum to :math:`1`. In case of a spatially inhomogeneous setting, the data is expected in cell-major ordering and the :math:`\texttt{SENS_SECTION}` field is used for indexing the axial cell when specifying parameter sensitivities. This field is optional in case of only one particle type.
+
+ ================ ======================== =============================================================================
+ **Type:** double **Range:** :math:`[0,1]` **Length:** :math:`\texttt{NPARTYPE} / \texttt{NCOL} \cdot \texttt{NPARTYPE}`
+ ================ ======================== =============================================================================
+
+
+Group /input/model/unit_XXX/discretization - UNIT_TYPE - GENERAL_RATE_MODEL
+----------------------------------------------------------------------------------------
+
+``USE_ANALYTIC_JACOBIAN``
+
+ Determines whether analytically computed Jacobian matrix (faster) is used (value is 1) instead of Jacobians generated by algorithmic differentiation (slower, value is 0)
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``PAR_DISC_TYPE``
+
+ Specifies the discretization scheme inside the particles for all or each particle type. Valid values are :math:`\texttt{EQUIDISTANT_PAR}`, :math:`\texttt{EQUIVOLUME_PAR}`, and :math:`\texttt{USER_DEFINED_PAR}`.
+
+ ================ =================================================
+ **Type:** string **Length:** :math:`1` / :math:`\texttt{NPARTYPE}`
+ ================ =================================================
+
+``PAR_DISC_VECTOR``
+
+ Node coordinates for the cell boundaries (ignored if :math:`\texttt{PAR_DISC_TYPE} \neq \texttt{USER_DEFINED_PAR}`). The coordinates are relative and have to include the endpoints :math:`0` and :math:`1`. They are later linearly mapped to the true radial range :math:`[r_{c,j}, r_{p,j}]`. The coordinates for each particle type are appended to one long vector in type-major ordering.
+
+ ================ ======================== ================================================
+ **Type:** double **Range:** :math:`[0,1]` **Length:** :math:`\sum_i (\texttt{NPAR}_i + 1)`
+ ================ ======================== ================================================
+
+Spatial discretization - Numerical Methods
+------------------------------------------
+
+CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Each method has it's own set of input fields.
+While both methods approximate the same solution to the same underlying model, they may differ in terms of computational performance.
+With our currently implemented variants of FV and DG, FV perform better for solutions with steep gradients or discontinuities, while DG can be much faster for rather smooth solutions.
+For the same number of discrete points, DG will generally be slower but often more accurate.
+
+For further information on the choice of discretization methods and their parameters, see :ref:`spatial_discretization_methods`.
+
+``SPATIAL_METHOD``
+
+ Spatial discretization method. Optional, defaults to :math:`\texttt{FV}`
+
+ ================ =============================================== =============
+ **Type:** string **Range:** :math:`\{\texttt{FV}, \texttt{DG}\}` **Length:** 1
+ ================ =============================================== =============
+
+Finite Volumes (Default)
+------------------------
+
+``NCOL``
+
+ Number of axial column discretization points
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``NPAR``
+
+ Number of particle (radial) discretization points for each particle type
+
+ ============= ========================= =================================================
+ **Type:** int **Range:** :math:`\geq 1` **Length:** :math:`1` / :math:`\texttt{NPARTYPE}`
+ ============= ========================= =================================================
+
+``PAR_BOUNDARY_ORDER``
+
+ Order of accuracy of outer particle boundary condition. Optional, defaults to :math:`2`.
+
+ ============= ============================ =============
+ **Type:** int **Range:** :math:`\{ 1,2 \}` **Length:** 1
+ ============= ============================ =============
+
+``RECONSTRUCTION``
+
+ Type of reconstruction method for fluxes
+
+ ================ ================================ =============
+ **Type:** string **Range:** :math:`\texttt{WENO}` **Length:** 1
+ ================ ================================ =============
+
+``GS_TYPE``
+
+ Type of Gram-Schmidt orthogonalization, see IDAS guide Section 4.5.7.3, p. 41f. A value of :math:`0` enables classical Gram-Schmidt, a value of 1 uses modified Gram-Schmidt.
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``MAX_KRYLOV``
+
+ Defines the size of the Krylov subspace in the iterative linear GMRES solver (0: :math:`\texttt{MAX_KRYLOV} = \texttt{NCOL} \cdot \texttt{NCOMP} \cdot \texttt{NPARTYPE}`)
+
+ ============= ============================================================================================ =============
+ **Type:** int **Range:** :math:`\{0, \dots, \texttt{NCOL} \cdot \texttt{NCOMP} \cdot \texttt{NPARTYPE} \}` **Length:** 1
+ ============= ============================================================================================ =============
+
+``MAX_RESTARTS``
+
+ Maximum number of restarts in the GMRES algorithm. If lack of memory is not an issue, better use a larger Krylov space than restarts.
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 0` **Length:** 1
+ ============= ========================= =============
+
+``SCHUR_SAFETY``
+
+ Schur safety factor; Influences the tradeoff between linear iterations and nonlinear error control; see IDAS guide Section~2.1 and 5.
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+``FIX_ZERO_SURFACE_DIFFUSION``
+
+ Determines whether the surface diffusion parameters :math:`\texttt{PAR_SURFDIFFUSION}` are fixed if the parameters are zero. If the parameters are fixed to zero (:math:`\texttt{FIX_ZERO_SURFACE_DIFFUSION} = 1`, :math:`\texttt{PAR_SURFDIFFUSION} = 0`), the parameters must not become non-zero during this or subsequent simulation runs. The internal data structures are optimized for a more efficient simulation. This field is optional and defaults to :math:`0` (optimization disabled in favor of flexibility).
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+For further discretization parameters, see also :ref:`flux_reconstruction_methods` (FV specific)), and :ref:`non_consistency_solver_parameters`.
+
+Discontinuous Galerkin
+----------------------
+
+``POLYDEG``
+
+ DG polynomial degree. Optional, defaults to 4 and :math:`N_d \in \{3, 4, 5\}` is recommended. The total number of axial discrete points is given by (``POLYDEG`` + 1 ) * ``NELEM``
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``NELEM``
+
+ Number of axial column discretization DG cells\elements. The total number of axial discrete points is given by (``POLYDEG`` + 1 ) * ``NELEM``
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``NCOL``
+
+ Number of axial discrete points. Optional and ignored if ``NELEM`` is defined. Otherwise, used to calculate ``NELEM`` = :math:`\lfloor` ``NCOL`` / (``POLYDEG`` + 1 ) :math:`\rfloor`
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``EXACT_INTEGRATION``
+
+ Specifies the DG integration variant. Optional, defaults to 0
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``PAR_POLYDEG``
+
+ DG particle (radial) polynomial degree. Optional, defaults to 3. The total number of particle (radial) discrete points is given by (``PARPOLYDEG`` + 1 ) * ``PAR_NELEM``.
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``PAR_NELEM``
+
+ Number of particle (radial) discretization DG elements for each particle type. For the particle discretization, it is usually most performant to fix ``PAR_NELEM`` = 1 and to increase the polynomial degree for more accuracy.
+
+ ============= ========================= =================================================
+ **Type:** int **Range:** :math:`\geq 1` **Length:** :math:`1` / :math:`\texttt{NPARTYPE}`
+ ============= ========================= =================================================
+
+ When using the DG method for the GRM, we recommend specifying ``USE_MODIFIED_NEWTON = 1`` in :ref:`FFSolverTime`, i.e. to use the modified Newton method to solve the linear system within the time integrator.
+ For further discretization parameters, see also :ref:`non_consistency_solver_parameters`.
diff --git a/v5.0.1/_sources/interface/unit_operations/index.rst.txt b/v5.0.1/_sources/interface/unit_operations/index.rst.txt
new file mode 100644
index 000000000..078802e29
--- /dev/null
+++ b/v5.0.1/_sources/interface/unit_operations/index.rst.txt
@@ -0,0 +1,19 @@
+.. _unit_operation_config:
+
+Unit Operations
+===============
+
+.. toctree::
+ :maxdepth: 2
+
+ inlet
+ outlet
+ general_rate_model
+ lumped_rate_model_with_pores
+ lumped_rate_model_without_pores
+ 2d_general_rate_model
+ cstr
+ radial_flow_models
+ multi_channel_transport_model
+ population_balance_model
+
diff --git a/v5.0.1/_sources/interface/unit_operations/inlet.rst.txt b/v5.0.1/_sources/interface/unit_operations/inlet.rst.txt
new file mode 100644
index 000000000..fba0fc476
--- /dev/null
+++ b/v5.0.1/_sources/interface/unit_operations/inlet.rst.txt
@@ -0,0 +1,79 @@
+.. _inlet_config:
+
+Inlet
+=====
+
+Group /input/model/unit_XXX - UNIT-TYPE = INLET
+-----------------------------------------------
+
+For information on model equations, refer to :ref:`inlet_model`.
+
+
+``UNIT_TYPE``
+
+ Specifies the type of unit operation model
+
+ ================ ================================= =============
+ **Type:** string **Range:** :math:`\texttt{INLET}` **Length:** 1
+ ================ ================================= =============
+
+``NCOMP``
+
+ Number of chemical components in the chromatographic medium
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``INLET_TYPE``
+
+ Specifies the type of inlet profile
+
+ ================ ================================================ =============
+ **Type:** string **Range:** :math:`\texttt{PIECEWISE_CUBIC_POLY}` **Length:** 1
+ ================ ================================================ =============
+
+Group /input/model/unit_XXX/sec_XXX
+-----------------------------------
+
+``CONST_COEFF``
+
+ Constant coefficients for inlet concentrations
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ ================ ============================= ==================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NCOMP}`
+ ================ ============================= ==================================
+
+``LIN_COEFF``
+
+ Linear coefficients for inlet concentrations
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-1}`
+
+ ================ ============================= ==================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NCOMP}`
+ ================ ============================= ==================================
+
+``QUAD_COEFF``
+
+ Quadratic coefficients for inlet concentrations
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-2}`
+
+ ================ ============================= ==================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NCOMP}`
+ ================ ============================= ==================================
+
+``CUBE_COEFF``
+
+ Cubic coefficients for inlet concentrations
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}\,\mathrm{s}^{-3}`
+
+ ================ ============================= ==================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NCOMP}`
+ ================ ============================= ==================================
+
+
diff --git a/v5.0.1/_sources/interface/unit_operations/lumped_rate_model_with_pores.rst.txt b/v5.0.1/_sources/interface/unit_operations/lumped_rate_model_with_pores.rst.txt
new file mode 100644
index 000000000..8ac99c96f
--- /dev/null
+++ b/v5.0.1/_sources/interface/unit_operations/lumped_rate_model_with_pores.rst.txt
@@ -0,0 +1,357 @@
+.. _lumped_rate_model_with_pores_config:
+
+Lumped rate model with pores
+============================
+
+Group /input/model/unit_XXX - UNIT_TYPE = LUMPED_RATE_MODEL_WITH_PORES
+----------------------------------------------------------------------
+
+For information on model equations, refer to :ref:`lumped_rate_model_with_pores_model`.
+
+
+``UNIT_TYPE``
+ Specifies the type of unit operation model
+
+ ================ ======================================================== =============
+ **Type:** string **Range:** :math:`\texttt{LUMPED_RATE_MODEL_WITH_PORES}` **Length:** 1
+ ================ ======================================================== =============
+
+``NCOMP``
+ Number of chemical components in the chromatographic medium
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``ADSORPTION_MODEL``
+ Specifies the type of binding model of each particle type (or of all particle types if length is :math:`1`)
+
+ ================ ========================================== =========================================
+ **Type:** string **Range:** See Section :ref:`FFAdsorption` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ ========================================== =========================================
+
+``ADSORPTION_MODEL_MULTIPLEX``
+ Multiplexing mode of :math:`\texttt{ADSORPTION_MODEL}`. If set to :math:`0`, each particle type has a different binding model and the length of :math:`\texttt{ADSORPTION_MODEL}` is :math:`\texttt{NPARTYPE}`. If set to :math:`1`, all particle types share the same binding model and the length of :math:`\texttt{ADSORPTION_MODEL}` is :math:`1`. This field is optional and inferred from the length of :math:`\texttt{ADSORPTION_MODEL}` if left out.
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``NBOUND``
+
+ Number of bound states for each component in each particle type in type-major ordering
+
+ ============= ========================= ===========================================================================
+ **Type:** int **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NCOMP} / \texttt{NPARTYPE} \cdot \texttt{NCOMP}`
+ ============= ========================= ===========================================================================
+
+``REACTION_MODEL_BULK``
+ Specifies the type of reaction model of the bulk volume. The model is configured in the subgroup :math:`\texttt{reaction_bulk}`.
+
+ ================ ================================ =============
+ **Type:** string **Range:** See :ref:`FFReaction` **Length:** 1
+ ================ ================================ =============
+
+``REACTION_MODEL_PARTICLES``
+ Specifies the type of reaction model of each particle type (or of all particle types if length is :math:`1`). The model is configured in the subgroup :math:`\texttt{reaction_particle}`, or :math:`\texttt{reaction_particle_XXX}` in case of disabled multiplexing.
+
+ ================ ======================================== ===================================
+ **Type:** string **Range:** See Section :ref:`FFReaction` **Length:** :math:`1` / :math:`\texttt{NPARTYPE}`
+ ================ ======================================== ===================================
+
+``REACTION_MODEL_PARTICLES_MULTIPLEX``
+ Multiplexing mode of :math:`\texttt{REACTION_MODEL_PARTICLES}`. If set to :math:`0`, each particle type has a different reaction model and the length of :math:`\texttt{REACTION_MODEL_PARTICLES}` is :math:`\texttt{NPARTYPE}`. If set to :math:`1`, all particle types share the same reaction model and the length of :math:`\texttt{REACTION_MODEL_PARTICLES}` is :math:`1`. This field is optional and inferred from the length of :math:`\texttt{REACTION_MODEL_PARTICLES}` if left out.
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``INIT_C``
+ Initial concentrations for each component in the bulk mobile phase
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ ================ ========================= ==================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NCOMP}`
+ ================ ========================= ==================================
+
+``INIT_CP``
+ Initial concentrations for each component in the bead liquid phase (optional, :math:`\texttt{INIT_C}` is used if left out). The length of this field can be :math:`\texttt{NCOMP}` (same values for each particle type) or :math:`\texttt{NPARTYPE} \cdot \texttt{NCOMP}` Values for each particle type can only be given when :math:`\texttt{ADSORPTION_MODEL_MULTIPLEX}` is :math:`0`. The ordering is type-major.
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{MP}}^{-3}`
+
+ ================ ========================= ===========================================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NCOMP} / \texttt{NPARTYPE} \cdot \texttt{NCOMP}`
+ ================ ========================= ===========================================================================
+
+``INIT_Q``
+ Initial concentrations for each bound state of each component in the bead solid phase. If :math:`\texttt{ADSORPTION_MODEL_MULTIPLEX}` is :math:`0`, values for each particle type are required in type-component-major ordering (length is :math:`\texttt{NTOTALBND}`). If :math:`\texttt{ADSORPTION_MODEL_MULTIPLEX}` is :math:`1`, values for one particle type are required in component-major ordering (length is :math:`\sum_{i = 0}^{\texttt{NCOMP} - 1} \texttt{NBND}_i`).
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{SP}}^{-3}`
+
+ ================ =========================
+ **Type:** double **Range:** :math:`\geq 0`
+ ================ =========================
+
+``INIT_STATE``
+ Full state vector for initialization (optional, :math:`\texttt{INIT_C}`, :math:`\texttt{INIT_CP}`, and :math:`\texttt{INIT_Q}` will be ignored; if length is :math:`2\texttt{NDOF}`, then the second half is used for time derivatives)
+
+ **Unit:** :math:`various`
+
+ ================ ============================= ==================================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NDOF} / 2\texttt{NDOF}`
+ ================ ============================= ==================================================
+
+``COL_DISPERSION``
+ Axial dispersion coefficient
+
+ **Unit:** :math:`\mathrm{m}_{\mathrm{IV}}^{2}\,\mathrm{s}^{-1}`
+
+ ================ ========================= =========================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{COL_DISPERSION_MULTIPLEX}`
+ ================ ========================= =========================================================
+
+``COL_DISPERSION_MULTIPLEX``
+ Multiplexing mode of :math:`\texttt{COL_DISPERSION}`. Determines whether :math:`\texttt{COL_DISPERSION}` is treated as component- and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{COL_DISPERSION}`. Valid modes are:
+
+ 0. Component-independent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`1`
+ 1. Component-dependent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP}`
+ 2. Component-independent, section-dependent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NSEC}`
+ 3. Component-dependent, section-dependent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``COL_LENGTH``
+ Column length
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ ====================== =============
+ **Type:** double **Range:** :math:`> 0` **Length:** 1
+ ================ ====================== =============
+
+``COL_POROSITY``
+
+ Column porosity
+
+ ================ ======================== =============
+ **Type:** double **Range:** :math:`(0,1]` **Length:** 1
+ ================ ======================== =============
+
+``FILM_DIFFUSION``
+
+ Film diffusion coefficients for each component of each particle type
+
+ **Unit:** :math:`\mathrm{m}\,\mathrm{s}^{-1}`
+
+ ================ ========================= =========================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{FILM_DIFFUSION_MULTIPLEX}`
+ ================ ========================= =========================================================
+
+``FILM_DIFFUSION_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{FILM_DIFFUSION}`. Determines whether :math:`\texttt{FILM_DIFFUSION}` is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{FILM_DIFFUSION}`. Valid modes are:
+
+ 0. Component-dependent, type-independent, section-independent; length of :math:`\texttt{FILM_DIFFUSION}` is :math:`\texttt{NCOMP}`
+ 1. Component-dependent, type-independent, section-dependent; length of :math:`\texttt{FILM_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+ 2. Component-dependent, type-dependent, section-independent; length of :math:`\texttt{FILM_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE}`; ordering is type-major
+ 3. Component-dependent, type-dependent, section-dependent; length of :math:`\texttt{FILM_DIFFUSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}`; ordering is section-type-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``PAR_POROSITY``
+
+ Particle porosity of all particle types or for each particle type
+
+ ================ ======================== =========================================
+ **Type:** double **Range:** :math:`(0,1]` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ ======================== =========================================
+
+``PAR_RADIUS``
+
+ Particle radius of all particle types or for each particle type
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ ===================== =========================================
+ **Type:** double **Range:** :math:`>0` **Length:** :math:`1 / \texttt{NPARTYPE}`
+ ================ ===================== =========================================
+
+``PORE_ACCESSIBILITY``
+
+ Pore accessibility factor of each component in each particle type (optional, defaults to :math:`1`).
+ Note: Should not be used in combination with any binding model!
+
+
+ ================ ========================= =============================================================
+ **Type:** double **Range:** :math:`(0, 1]` **Length:** see :math:`\texttt{PORE_ACCESSIBILITY_MULTIPLEX}`
+ ================ ========================= =============================================================
+
+``PORE_ACCESSIBILITY_MULTIPLEX``
+ Multiplexing mode of :math:`\texttt{PORE_ACCESSIBILITY}`. Determines whether :math:`\texttt{PORE_ACCESSIBILITY}` is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{PORE_ACCESSIBILITY}`. Valid modes are:
+
+ 0. Component-dependent, type-independent, section-independent; length of :math:`\texttt{PORE_ACCESSIBILITY}` is :math:`\texttt{NCOMP}`
+ 1. Component-dependent, type-independent, section-dependent; length of :math:`\texttt{PORE_ACCESSIBILITY}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+ 2. Component-dependent, type-dependent, section-independent; length of :math:`\texttt{PORE_ACCESSIBILITY}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE}`; ordering is type-major
+ 3. Component-dependent, type-dependent, section-dependent; length of :math:`\texttt{PORE_ACCESSIBILITY}` is :math:`\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}`; ordering is section-type-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``VELOCITY``
+ Interstitial velocity of the mobile phase (optional if :math:`\texttt{CROSS_SECTION_AREA}` is present, see Section :ref:`MUOPGRMflow`)
+
+ **Unit:** :math:`\mathrm{m}\,\mathrm{s}^{-1}`
+
+ ================ ============================= =====================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`1 / \texttt{NSEC}`
+ ================ ============================= =====================================
+
+``CROSS_SECTION_AREA``
+
+ Cross section area of the column (optional if :math:`\texttt{VELOCITY}` is present, see Section :ref:`MUOPGRMflow`)
+
+ **Unit:** :math:`\mathrm{m}^{2}`
+
+ ================ ===================== =============
+ **Type:** double **Range:** :math:`>0` **Length:** 1
+ ================ ===================== =============
+
+``NPARTYPE``
+
+ Number of particle types. Optional, inferred from the length of :math:`\texttt{NBOUND}` if left out.
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``PAR_GEOM``
+
+ Specifies the particle geometry for all or each particle type. Valid values are :math:`\texttt{SPHERE}`, :math:`\texttt{CYLINDER}`, :math:`\texttt{SLAB}`. Optional, defaults to :math:`\texttt{SPHERE}`.
+
+ ================ =================================================
+ **Type:** string **Length:** :math:`1` / :math:`\texttt{NPARTYPE}`
+ ================ =================================================
+
+``PAR_TYPE_VOLFRAC``
+
+ Volume fractions of the particle types. The volume fractions can be set for all axial cells together or for each individual axial cell. For each cell, the volume fractions have to sum to :math:`1`. In case of a spatially inhomogeneous setting, the data is expected in cell-major ordering and the :math:`\texttt{SENS_SECTION}` field is used for indexing the axial cell when specifying parameter sensitivities. This field is optional in case of only one particle type.
+
+ ================ ======================== =====================================================================================
+ **Type:** double **Range:** :math:`[0,1]` **Length:** :math:`\texttt{NPARTYPE}` / :math:`\texttt{NCOL} \cdot \texttt{NPARTYPE}`
+ ================ ======================== =====================================================================================
+
+Spatial discretization - Numerical Methods
+------------------------------------------
+
+CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Each method has it's own set of input fields.
+While both methods approximate the same solution to the same underlying model, they may differ in terms of computational performance.
+With our currently implemented variants of FV and DG, FV perform better for solutions with steep gradients or discontinuities, while DG can be much faster for rather smooth solutions.
+For the same number of discrete points, DG will generally be slower but often more accurate.
+
+For further information on the choice of discretization methods and their parameters, see :ref:`spatial_discretization_methods`.
+
+``SPATIAL_METHOD``
+
+ Spatial discretization method. Optional, defaults to :math:`\texttt{FV}`
+
+ ================ =============================================== =============
+ **Type:** string **Range:** :math:`\{\texttt{FV}, \texttt{DG}\}` **Length:** 1
+ ================ =============================================== =============
+
+Finite Volumes (Default)
+------------------------
+
+``NCOL``
+
+ Number of axial column discretization points
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``RECONSTRUCTION``
+
+ Type of reconstruction method for fluxes
+
+ ================ ================================ =============
+ **Type:** string **Range:** :math:`\texttt{WENO}` **Length:** 1
+ ================ ================================ =============
+
+``GS_TYPE``
+
+ Type of Gram-Schmidt orthogonalization, see IDAS guide Section~4.5.7.3, p.~41f. A value of :math:`0` enables classical Gram-Schmidt, a value of 1 uses modified Gram-Schmidt.
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``MAX_KRYLOV``
+
+ Defines the size of the Krylov subspace in the iterative linear GMRES solver (0: :math:`\texttt{MAX_KRYLOV} = \texttt{NCOL} \cdot \texttt{NCOMP} \cdot \texttt{NPARTYPE}`)
+
+ ============= ============================================================================================ =============
+ **Type:** int **Range:** :math:`\{0, \dots, \texttt{NCOL} \cdot \texttt{NCOMP} \cdot \texttt{NPARTYPE} \}` **Length:** 1
+ ============= ============================================================================================ =============
+
+``MAX_RESTARTS``
+
+ Maximum number of restarts in the GMRES algorithm. If lack of memory is not an issue, better use a larger Krylov space than restarts.
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 0` **Length:** 1
+ ============= ========================= =============
+
+``SCHUR_SAFETY``
+
+ Schur safety factor; Influences the tradeoff between linear iterations and nonlinear error control; see IDAS guide Section~2.1 and 5.
+
+ ================ ========================= =============
+ **Type:** double **Range:** :math:`\geq 0` **Length:** 1
+ ================ ========================= =============
+
+For further discretization parameters, see also :ref:`flux_reconstruction_methods` (FV specific)), and :ref:`non_consistency_solver_parameters`.
+
+
+Discontinuous Galerkin
+----------------------
+
+``POLYDEG``
+
+ DG polynomial degree. Optional, defaults to 4 and :math:`N_d \in \{3, 4, 5\}` is recommended. The total number of axial discrete points is given by (``POLYDEG`` + 1 ) * ``NELEM``
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``NELEM``
+
+ Number of axial column discretization DG cells\elements. The total number of axial discrete points is given by (``POLYDEG`` + 1 ) * ``NELEM``
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``NCOL``
+
+ Number of axial discrete points. Optional and ignored if ``NELEM`` is defined. Otherwise, used to calculate ``NELEM`` = :math:`\lfloor` ``NCOL`` / (``POLYDEG`` + 1 ) :math:`\rfloor`
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``EXACT_INTEGRATION``
+
+ Specifies the DG integration variant. Optional, defaults to 0
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+ When using the DG method for the LRMP, we recommend specifying ``USE_MODIFIED_NEWTON = 1`` in :ref:`FFSolverTime`, i.e. to use the modified Newton method to solve the linear system within the time integrator.
+ For further discretization parameters, see also :ref:`non_consistency_solver_parameters`.
diff --git a/v5.0.1/_sources/interface/unit_operations/lumped_rate_model_without_pores.rst.txt b/v5.0.1/_sources/interface/unit_operations/lumped_rate_model_without_pores.rst.txt
new file mode 100644
index 000000000..e32c9b33d
--- /dev/null
+++ b/v5.0.1/_sources/interface/unit_operations/lumped_rate_model_without_pores.rst.txt
@@ -0,0 +1,230 @@
+.. _lumped_rate_model_without_pores_config:
+
+Lumped Rate Model Without Pores
+===============================
+
+Group /input/model/unit_XXX - UNIT_TYPE = LUMPED_RATE_MODEL_WITHOUT_PORES
+-------------------------------------------------------------------------
+
+For information on model equations, refer to :ref:`lumped_rate_model_without_pores_model`.
+
+
+``UNIT_TYPE``
+
+ Specifies the type of unit operation model
+
+ ================ =========================================================== =============
+ **Type:** string **Range:** :math:`\texttt{LUMPED_RATE_MODEL_WITHOUT_PORES}` **Length:** 1
+ ================ =========================================================== =============
+
+``NCOMP``
+
+ Number of chemical components in the chromatographic medium
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``ADSORPTION_MODEL``
+
+ Specifies the type of binding model
+
+ ================ ========================================== =============
+ **Type:** string **Range:** See Section :ref:`FFAdsorption` **Length:** 1
+ ================ ========================================== =============
+
+``NBOUND``
+
+ Number of bound states for each component
+
+ ============= ========================= ==================================
+ **Type:** int **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NCOMP}`
+ ============= ========================= ==================================
+
+``REACTION_MODEL``
+
+ Specifies the type of reaction model of the combined bulk and particle volume. The model is configured in the subgroup :math:`\texttt{reaction}`.
+
+ ================ ======================================== =============
+ **Type:** string **Range:** See Section :ref:`FFReaction` **Length:** 1
+ ================ ======================================== =============
+
+``INIT_C``
+
+ Initial concentrations for each component in the bulk mobile phase
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{IV}}^{-3}`
+
+ ================ ========================= ===================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NCOMP}`
+ ================ ========================= ===================================
+
+``INIT_Q``
+
+ Initial concentrations for each bound state of each component in the bead solid phase in component-major ordering
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}_{\mathrm{SP}}^{-3}`
+
+ ================ ========================= =======================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NTOTALBND}`
+ ================ ========================= =======================================
+
+``INIT_STATE``
+
+ Full state vector for initialization (optional, :math:`\texttt{INIT_C}` and :math:`\texttt{INIT_Q}` will be ignored; if length is :math:`2\texttt{NDOF}`, then the second half is used for time derivatives)
+
+ **Unit:** :math:`various`
+
+ ================ ============================= ===================================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NDOF} / 2\texttt{NDOF}`
+ ================ ============================= ===================================================
+
+``COL_DISPERSION``
+
+ Axial dispersion coefficient
+
+ **Unit:** :math:`\mathrm{m}_{\mathrm{IV}}^{2}\,\mathrm{s}^{-1}`
+
+ ================ ========================= =========================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{COL_DISPERSION_MULTIPLEX}`
+ ================ ========================= =========================================================
+
+``COL_DISPERSION_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{COL_DISPERSION}`. Determines whether :math:`\texttt{COL_DISPERSION}` is treated as component- and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{COL_DISPERSION}`. Valid modes are:
+
+ 0. Component-independent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`1`
+ 1. Component-dependent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP}`
+ 2. Component-independent, section-dependent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NSEC}`
+ 3. Component-dependent, section-dependent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``COL_LENGTH``
+
+ Column length
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ ====================== =============
+ **Type:** double **Range:** :math:`> 0` **Length:** 1
+ ================ ====================== =============
+
+``TOTAL_POROSITY``
+
+ Total porosity
+
+ ================ ======================== =============
+ **Type:** double **Range:** :math:`[0,1]` **Length:** 1
+ ================ ======================== =============
+
+``VELOCITY``
+
+ Interstitial velocity of the mobile phase (optional if :math:`\texttt{CROSS_SECTION_AREA}` is present, see Section :ref:`MUOPGRMflow`)
+
+ **Unit:** :math:`\mathrm{m}\,\mathrm{s}^{-1}`
+
+ ================ ============================= ======================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`1 / \texttt{NSEC}`
+ ================ ============================= ======================================
+
+``CROSS_SECTION_AREA``
+
+ Cross section area of the column (optional if :math:`\texttt{VELOCITY}` is present, see Section :ref:`MUOPGRMflow`)
+
+ **Unit:** :math:`\mathrm{m}^{2}`
+
+ ================ ===================== =============
+ **Type:** double **Range:** :math:`>0` **Length:** 1
+ ================ ===================== =============
+
+
+Group /input/model/unit_XXX/discretization - UNIT_TYPE = LUMPED_RATE_MODEL_WITHOUT_PORES
+----------------------------------------------------------------------------------------
+
+``USE_ANALYTIC_JACOBIAN``
+
+ Determines whether analytically computed Jacobian matrix (faster) is used (value is 1) instead of Jacobians generated by algorithmic differentiation (slower, value is 0)
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+Spatial discretization - Numerical Methods
+------------------------------------------
+
+CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Each method has it's own set of input fields.
+While both methods approximate the same solution to the same underlying model, they may differ in terms of computational performance.
+With our currently implemented variants of FV and DG, FV perform better for solutions with steep gradients or discontinuities, while DG can be much faster for rather smooth solutions.
+For the same number of discrete points, DG will generally be slower but often more accurate.
+
+For further information on the choice of discretization methods and their parameters, see :ref:`spatial_discretization_methods`.
+
+``SPATIAL_METHOD``
+
+ Spatial discretization method. Optional, defaults to :math:`\texttt{FV}`
+
+ ================ =============================================== =============
+ **Type:** string **Range:** :math:`\{\texttt{FV}, \texttt{DG}\}` **Length:** 1
+ ================ =============================================== =============
+
+Finite Volumes (Default)
+------------------------
+
+``NCOL``
+
+ Number of axial column discretization points
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``RECONSTRUCTION``
+
+ Type of reconstruction method for fluxes only (only needs to be specified for FV)
+
+ ================ ================================ =============
+ **Type:** string **Range:** :math:`\texttt{WENO}` **Length:** 1
+ ================ ================================ =============
+
+For further discretization parameters, see also :ref:`flux_reconstruction_methods` (FV specific)), and :ref:`non_consistency_solver_parameters`.
+
+
+Discontinuous Galerkin
+----------------------
+
+``POLYDEG``
+
+ DG polynomial degree. Optional, defaults to 4 and :math:`N_d \in \{3, 4, 5\}` is recommended. The total number of axial discrete points is given by (``POLYDEG`` + 1 ) * ``NELEM``
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``NELEM``
+
+ Number of axial column discretization DG cells\elements. The total number of axial discrete points is given by (``POLYDEG`` + 1 ) * ``NELEM``
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``NCOL``
+
+ Number of axial discrete points. Optional and ignored if ``NELEM`` is defined. Otherwise, used to calculate ``NELEM`` = :math:`\lfloor` ``NCOL`` / (``POLYDEG`` + 1 ) :math:`\rfloor`
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``EXACT_INTEGRATION``
+
+ Specifies the DG integration variant. Optional, defaults to 0
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+ For further discretization parameters, see also :ref:`non_consistency_solver_parameters`.
diff --git a/v5.0.1/_sources/interface/unit_operations/multi_channel_transport_model.rst.txt b/v5.0.1/_sources/interface/unit_operations/multi_channel_transport_model.rst.txt
new file mode 100644
index 000000000..3df6a7e73
--- /dev/null
+++ b/v5.0.1/_sources/interface/unit_operations/multi_channel_transport_model.rst.txt
@@ -0,0 +1,204 @@
+.. _multi_channel_transport_model_config:
+
+Multichannel Transport model (MCT model)
+========================================
+
+Group /input/model/unit_XXX - UNIT_TYPE = MULTI_CHANNEL_TRANSPORT
+-----------------------------------------------------------------
+
+For information on model equations, refer to :ref:`multi_channel_transport_model_model`.
+
+``UNIT_TYPE``
+
+ Specifies the type of unit operation model
+
+ ================ =================================================== =============
+ **Type:** string **Range:** :math:`\texttt{MULTI_CHANNEL_TRANSPORT}` **Length:** 1
+ ================ =================================================== =============
+
+``NCOMP``
+
+ Number of chemical components in the chromatographic medium
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``REACTION_MODEL_BULK``
+
+ Specifies the type of reaction model of the bulk volume. The model is configured in the subgroup :math:`\texttt{reaction_bulk}`.
+
+ ================ ======================================== =============
+ **Type:** string **Range:** See Section :ref:`FFReaction` **Length:** 1
+ ================ ======================================== =============
+
+``INIT_C``
+
+ Initial concentrations for each component in all channels of the bulk mobile phase (length :math:`\texttt{NCOMP}`), or for each component in each channel (length :math:`\texttt{NCOMP} \cdot \texttt{NCHANNEL}`, ordering channel-major)
+
+ **Unit:** :math:`\mathrm{mol}\,\mathrm{m}^{-3}`
+
+ ================ ========================= =========================================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** :math:`\texttt{NCOMP} / \texttt{NCOMP} \cdot \texttt{NCHANNEL}`
+ ================ ========================= =========================================================================
+
+``INIT_STATE``
+
+ Full state vector for initialization (optional, :math:`\texttt{INIT_C}` will be ignored; if length is :math:`2\texttt{NDOF}`, then the second half is used for time derivatives)
+
+ **Unit:** :math:`various`
+
+ ================ ============================= ==================================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`\texttt{NDOF} / 2\texttt{NDOF}`
+ ================ ============================= ==================================================
+
+``COL_DISPERSION``
+
+ Axial dispersion coefficient. In case of a spatially inhomogeneous setting, the :math:`\texttt{SENS_PARTYPE}` field is used for indexing the channel when specifying parameter sensitivities.
+
+ **Unit:** :math:`\mathrm{m}^{2}\,\mathrm{s}^{-1}`
+
+ ================ ========================= =========================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{COL_DISPERSION_MULTIPLEX}`
+ ================ ========================= =========================================================
+
+``COL_DISPERSION_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{COL_DISPERSION}`. Determines whether :math:`\texttt{COL_DISPERSION}` is treated as component-, channel-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{COL_DISPERSION}`. Valid modes are:
+
+ 1. Component-independent, channel-independent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is 1
+ 2. Component-independent, channel-dependent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCHANNEL}`
+ 3. Component-dependent, channel-independent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP}`
+ 4. Component-dependent, channel-dependent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NCHANNEL}`; ordering is channel-major
+ 5. Component-independent, channel-independent, section-dependent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NSEC}`
+ 6. Component-independent, channel-dependent, section-dependent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCHANNEL} \cdot \texttt{NSEC}`; ordering is section-major
+ 7. Component-dependent, channel-independent, section-independent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NSEC}`; ordering is section-major
+ 8. Component-dependent, channel-dependent, section-dependent; length of :math:`\texttt{COL_DISPERSION}` is :math:`\texttt{NCOMP} \cdot \texttt{NCHANNEL} \cdot \texttt{NSEC}`; ordering is section-channel-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 7 \}` **Length:** 1
+ ============= =================================== =============
+
+``COL_LENGTH``
+
+ Column length
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ ====================== =============
+ **Type:** double **Range:** :math:`> 0` **Length:** 1
+ ================ ====================== =============
+
+``VELOCITY``
+
+ Velocity
+
+ **Unit:** :math:`\mathrm{m}\,\mathrm{s}^{-1}`
+
+ Indicates flow direction in each channel (forward if value is positive, backward if value is negative), see Section :ref:`MUOPGRMflow2D`). In case of a spatially inhomogeneous setting, the :math:`\texttt{SENS_PARTYPE}` field is used for indexing the channel when specifying parameter sensitivities.
+
+ ================ ============================= ===================================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** see :math:`\texttt{VELOCITY_MULTIPLEX}`
+ ================ ============================= ===================================================
+
+``VELOCITY_MULTIPLEX``
+
+ Multiplexing mode of :math:`\texttt{VELOCITY}`. Determines whether :math:`\texttt{VELOCITY}` is treated as channel- and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of :math:`\texttt{VELOCITY}`. Valid modes are:
+
+ 1. Channel-independent, section-independent; length of :math:`\texttt{VELOCITY}` is 1
+ 2. Channel-dependent, section-independent; length of :math:`\texttt{VELOCITY}` is :math:`\texttt{NCHANNEL}`
+ 3. Section-dependent; length of :math:`\texttt{VELOCITY}` is :math:`\texttt{NSEC}`
+ 4. Channel-dependent, section-dependent; length of :math:`\texttt{VELOCITY}` is :math:`\texttt{NCHANNEL} \cdot \texttt{NSEC}`; ordering is section-major
+
+ ============= =================================== =============
+ **Type:** int **Range:** :math:`\{0, \dots, 3 \}` **Length:** 1
+ ============= =================================== =============
+
+``EXCHANGE_MATRIX``
+
+ Exchange matrix
+
+ **Unit:** :math:`\mathrm{s}^{-1}`
+
+ Ordered list containing all exchange rates :math:`e^k_{ij}` for component :math:`k` from compartment :math:`i` to :math:`j` based on the exchange matrix :math:`E^k`. The vector ordering is source channel - destination channel - component (i.e. i-j-k) major.
+
+ .. math::
+
+ E^k=\begin{bmatrix}
+ 0 & e^k_{12} & \dots & e^k_{1N} \\
+ e^k_{21} & \ddots & & \vdots\\
+ \vdots & & \ddots & e^k_{(N-1)N}\\
+ e^k_{N1} & \dots & e^k_{N(N-1)} & 0
+ \end{bmatrix}
+
+ For addressing the exchange rates as a parameter senstivity, the mapping is as follows:
+
+ - :math:`\texttt{SENS_BOUNDPHASE}` *Channel from*
+ - :math:`\texttt{SENS_PARTYPE}` *Channel to*
+
+ ================ ======================== ===============================================
+ **Type:** double **Range:** :math:`[0,1]` **Length:** :math:`\texttt{NCHANNEL}*\texttt{NCHANNEL}*\texttt{NCOMP}`
+ ================ ======================== ===============================================
+
+``NCHANNEL``
+
+ Number of channels :math:`ij`
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+
+``CHANNEL_CROSS_SECTION_AREAS``
+
+ Cross section areas
+
+ **Unit:** :math:`\mathrm{m}^{2}`
+
+ Defines the cross section area of each channel
+
+ ================ ====================== ======================================
+ **Type:** double **Range:** :math:`> 0` **Length:** :math:`\texttt{NCHANNEL}`
+ ================ ====================== ======================================
+
+
+Group /input/model/unit_XXX/discretization - UNIT_TYPE = MULTI_CHANNEL_TRANSPORT
+--------------------------------------------------------------------------------
+
+``USE_ANALYTIC_JACOBIAN``
+
+ Determines whether analytically computed Jacobian matrix (faster) is used (value is 1) instead of Jacobians generated by algorithmic differentiation (slower, value is 0)
+
+ ============= =========================== =============
+ **Type:** int **Range:** :math:`\{0, 1\}` **Length:** 1
+ ============= =========================== =============
+
+``NCOL``
+
+ Number of axial column discretization cells
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+``LINEAR_SOLVER_BULK``
+
+ Linear solver used for the sparse column bulk block. This field is optional, the best available method is selected (i.e., sparse direct solver if possible). Valid values are:
+
+ - :math:`\texttt{DENSE}` Converts the sparse matrix into a banded matrix and uses regular LAPACK. Slow and memory intensive, but always available.
+ - :math:`\texttt{UMFPACK}` Uses the UMFPACK sparse direct solver (LU decomposition) from SuiteSparse. Fast, but has to be enabled when compiling and requires UMFPACK library.
+ - :math:`\texttt{SUPERLU}` Uses the SuperLU sparse direct solver (LU decomposition). Fast, but has to be enabled when compiling and requires SuperLU library.
+
+ ================ ======================================================================= =============
+ **Type:** string **Range:** :math:`\{\texttt{DENSE},\texttt{UMFPACK},\texttt{SUPERLU}\}` **Length:** 1
+ ================ ======================================================================= =============
+
+``RECONSTRUCTION``
+
+ Type of reconstruction method for FV fluxes
+
+ ================ ================================ =============
+ **Type:** string **Range:** :math:`\texttt{WENO}` **Length:** 1
+ ================ ================================ =============
+
+For further discretization parameters, see also :ref:`flux_restruction_methods` (FV specific)), and :ref:`non_consistency_solver_parameters`.
diff --git a/v5.0.1/_sources/interface/unit_operations/outlet.rst.txt b/v5.0.1/_sources/interface/unit_operations/outlet.rst.txt
new file mode 100644
index 000000000..323da8bb6
--- /dev/null
+++ b/v5.0.1/_sources/interface/unit_operations/outlet.rst.txt
@@ -0,0 +1,30 @@
+.. _outlet_config:
+
+Outlet
+======
+
+Group /input/model/unit_XXX - UNIT-TYPE = OUTLET
+------------------------------------------------
+
+For information on model equations, refer to :ref:`outlet_model`.
+
+
+``UNIT_TYPE``
+
+ Specifies the type of unit operation model
+
+
+ ================ ================================== =============
+ **Type:** string **Range:** :math:`\texttt{OUTLET}` **Length:** 1
+ ================ ================================== =============
+
+``NCOMP``
+
+ Number of chemical components in the chromatographic medium
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+
+
diff --git a/v5.0.1/_sources/interface/unit_operations/radial_flow_models.rst.txt b/v5.0.1/_sources/interface/unit_operations/radial_flow_models.rst.txt
new file mode 100644
index 000000000..9fdac5fc9
--- /dev/null
+++ b/v5.0.1/_sources/interface/unit_operations/radial_flow_models.rst.txt
@@ -0,0 +1,109 @@
+.. _radial_flow_models_config:
+
+Radial Flow Models
+==================
+
+Radial flow models are available for the LRM, LRMP and GRM.
+The configurations specified here complement the description for the respective model, i.e. please additionally refer to :ref:`lumped_rate_model_without_pores_config` or :ref:`lumped_rate_model_with_pores_config` or :ref:`general_rate_model_config`, respectively.
+If input variables are described in both files, then only the description provided here applies for radial flow models.
+
+The unit type input must be specified with the prefix :math:`\texttt{RADIAL_}` followed by the respective transport model name.
+In this document, we specify the unit type as the radial GRM, but the LRM and LRMP are also available and the changes to input variables are the same for all three models.
+
+Group /input/model/unit_XXX - UNIT_TYPE - RADIAL_GENERAL_RATE_MODEL
+-------------------------------------------------------------------
+
+For information on model equations, refer to :ref:`lumped_rate_model_without_pores_model` or :ref:`lumped_rate_model_with_pores_model` or :ref:`general_rate_model_model`, respectively.
+
+
+``UNIT_TYPE``
+
+ Specifies the type of unit operation model
+
+ ================ ===================================================== =============
+ **Type:** string **Range:** :math:`\texttt{RADIAL_GENERAL_RATE_MODEL}` **Length:** 1
+ ================ ===================================================== =============
+
+``COL_DISPERSION``
+
+ Radial dispersion coefficient
+
+ **Unit:** :math:`\mathrm{m}_{\mathrm{IV}}^{2}\,\mathrm{s}^{-1}`
+
+ ================ ========================= =========================================================
+ **Type:** double **Range:** :math:`\geq 0` **Length:** see :math:`\texttt{COL_DISPERSION_MULTIPLEX}`
+ ================ ========================= =========================================================
+
+ In addition to the multiplex specification (e.g. component dependency, see :ref:`general_rate_model_model`), the dispersion coefficient for radial flow model usually depends on other parameters.
+ Parameter dependencies are described here :ref:`parameter_dependencies`.
+
+
+``COL_RADIUS_INNER``
+
+ Inner column radius
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ ====================== =============
+ **Type:** double **Range:** :math:`> 0` **Length:** 1
+ ================ ====================== =============
+
+``COL_RADIUS_OUTER``
+
+ Outer column radius
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ ====================== =============
+ **Type:** double **Range:** :math:`> 0` **Length:** 1
+ ================ ====================== =============
+
+``CROSS_SECTION_AREA``
+
+ Is not explicitly specified. Both the inner and outer cross section areas are implicitly given by the volumetric flow rates and either the velocity coefficient or column length
+
+``COL_LENGTH``
+
+ Column length/height (optional if :math:`\texttt{VELOCITY_COEFF}` is present, see Section :ref:`MUOPGRMflow`)
+
+ **Unit:** :math:`\mathrm{m}`
+
+ ================ ====================== =============
+ **Type:** double **Range:** :math:`> 0` **Length:** 1
+ ================ ====================== =============
+
+``VELOCITY_COEFF``
+
+ Interstitial velocity coefficient of the mobile phase (optional :math:`\texttt{COL_LENGTH}` is present, see Section :ref:`MUOPGRMflow`).
+ This input replaces the ``VELOCITY`` field, which is used for axial flow models. The distinction is made to emphasize that radial flow models do not incorporate a global velocity but a variable velocity field that depends on the spatial position, for details see Section :ref:`MUOPGRMradialFlow`.
+
+ **Unit:** :math:`\mathrm{m}\,\mathrm{s}^{-1}`
+
+ ================ ============================= =======================================
+ **Type:** double **Range:** :math:`\mathbb{R}` **Length:** :math:`1 / \texttt{NSEC}`
+ ================ ============================= =======================================
+
+
+Group /input/model/unit_XXX/discretization - UNIT_TYPE - RADIAL_GENERAL_RATE_MODEL
+----------------------------------------------------------------------------------------
+
+``NCOL``
+
+ Number of radial column discretization points
+
+ ============= ========================= =============
+ **Type:** int **Range:** :math:`\geq 1` **Length:** 1
+ ============= ========================= =============
+
+Currently, there is only a first order FV spatial discretization available. Higher order spatial discretizations are planned for the future.
+Accordingly, the following specifications can be left out for radial flow models.
+
+``RECONSTRUCTION``
+
+ Type of reconstruction method for fluxes
+
+ ================ ================================ =============
+ **Type:** string **Range:** :math:`\texttt{NONE}` **Length:** 1
+ ================ ================================ =============
+
+Parameters specified under :ref:`flux_restruction_methods` can also be ignored.
diff --git a/v5.0.1/_sources/license.rst.txt b/v5.0.1/_sources/license.rst.txt
new file mode 100644
index 000000000..5eb36d425
--- /dev/null
+++ b/v5.0.1/_sources/license.rst.txt
@@ -0,0 +1,559 @@
+License
+=======
+CADET is released under the GNU GPL v3
+
+::
+
+ GNU GENERAL PUBLIC LICENSE
+ Version 3, 29 June 2007
+ Copyright (C) 2007 Free Software Foundation, Inc.
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+ Preamble
+ The GNU General Public License is a free, copyleft license for
+ software and other kinds of works.
+ The licenses for most software and other practical works are designed
+ to take away your freedom to share and change the works. By contrast,
+ the GNU General Public License is intended to guarantee your freedom to
+ share and change all versions of a program--to make sure it remains free
+ software for all its users. We, the Free Software Foundation, use the
+ GNU General Public License for most of our software; it applies also to
+ any other work released this way by its authors. You can apply it to
+ your programs, too.
+ When we speak of free software, we are referring to freedom, not
+ price. Our General Public Licenses are designed to make sure that you
+ have the freedom to distribute copies of free software (and charge for
+ them if you wish), that you receive source code or can get it if you
+ want it, that you can change the software or use pieces of it in new
+ free programs, and that you know you can do these things.
+ To protect your rights, we need to prevent others from denying you
+ these rights or asking you to surrender the rights. Therefore, you have
+ certain responsibilities if you distribute copies of the software, or if
+ you modify it: responsibilities to respect the freedom of others.
+ For example, if you distribute copies of such a program, whether
+ gratis or for a fee, you must pass on to the recipients the same
+ freedoms that you received. You must make sure that they, too, receive
+ or can get the source code. And you must show them these terms so they
+ know their rights.
+ Developers that use the GNU GPL protect your rights with two steps:
+ (1) assert copyright on the software, and (2) offer you this License
+ giving you legal permission to copy, distribute and/or modify it.
+ For the developers' and authors' protection, the GPL clearly explains
+ that there is no warranty for this free software. For both users' and
+ authors' sake, the GPL requires that modified versions be marked as
+ changed, so that their problems will not be attributed erroneously to
+ authors of previous versions.
+ Some devices are designed to deny users access to install or run
+ modified versions of the software inside them, although the manufacturer
+ can do so. This is fundamentally incompatible with the aim of
+ protecting users' freedom to change the software. The systematic
+ pattern of such abuse occurs in the area of products for individuals to
+ use, which is precisely where it is most unacceptable. Therefore, we
+ have designed this version of the GPL to prohibit the practice for those
+ products. If such problems arise substantially in other domains, we
+ stand ready to extend this provision to those domains in future versions
+ of the GPL, as needed to protect the freedom of users.
+ Finally, every program is threatened constantly by software patents.
+ States should not allow patents to restrict development and use of
+ software on general-purpose computers, but in those that do, we wish to
+ avoid the special danger that patents applied to a free program could
+ make it effectively proprietary. To prevent this, the GPL assures that
+ patents cannot be used to render the program non-free.
+ The precise terms and conditions for copying, distribution and
+ modification follow.
+ TERMS AND CONDITIONS
+ 0. Definitions.
+ "This License" refers to version 3 of the GNU General Public License.
+ "Copyright" also means copyright-like laws that apply to other kinds of
+ works, such as semiconductor masks.
+ "The Program" refers to any copyrightable work licensed under this
+ License. Each licensee is addressed as "you". "Licensees" and
+ "recipients" may be individuals or organizations.
+ To "modify" a work means to copy from or adapt all or part of the work
+ in a fashion requiring copyright permission, other than the making of an
+ exact copy. The resulting work is called a "modified version" of the
+ earlier work or a work "based on" the earlier work.
+ A "covered work" means either the unmodified Program or a work based
+ on the Program.
+ To "propagate" a work means to do anything with it that, without
+ permission, would make you directly or secondarily liable for
+ infringement under applicable copyright law, except executing it on a
+ computer or modifying a private copy. Propagation includes copying,
+ distribution (with or without modification), making available to the
+ public, and in some countries other activities as well.
+ To "convey" a work means any kind of propagation that enables other
+ parties to make or receive copies. Mere interaction with a user through
+ a computer network, with no transfer of a copy, is not conveying.
+ An interactive user interface displays "Appropriate Legal Notices"
+ to the extent that it includes a convenient and prominently visible
+ feature that (1) displays an appropriate copyright notice, and (2)
+ tells the user that there is no warranty for the work (except to the
+ extent that warranties are provided), that licensees may convey the
+ work under this License, and how to view a copy of this License. If
+ the interface presents a list of user commands or options, such as a
+ menu, a prominent item in the list meets this criterion.
+ 1. Source Code.
+ The "source code" for a work means the preferred form of the work
+ for making modifications to it. "Object code" means any non-source
+ form of a work.
+ A "Standard Interface" means an interface that either is an official
+ standard defined by a recognized standards body, or, in the case of
+ interfaces specified for a particular programming language, one that
+ is widely used among developers working in that language.
+ The "System Libraries" of an executable work include anything, other
+ than the work as a whole, that (a) is included in the normal form of
+ packaging a Major Component, but which is not part of that Major
+ Component, and (b) serves only to enable use of the work with that
+ Major Component, or to implement a Standard Interface for which an
+ implementation is available to the public in source code form. A
+ "Major Component", in this context, means a major essential component
+ (kernel, window system, and so on) of the specific operating system
+ (if any) on which the executable work runs, or a compiler used to
+ produce the work, or an object code interpreter used to run it.
+ The "Corresponding Source" for a work in object code form means all
+ the source code needed to generate, install, and (for an executable
+ work) run the object code and to modify the work, including scripts to
+ control those activities. However, it does not include the work's
+ System Libraries, or general-purpose tools or generally available free
+ programs which are used unmodified in performing those activities but
+ which are not part of the work. For example, Corresponding Source
+ includes interface definition files associated with source files for
+ the work, and the source code for shared libraries and dynamically
+ linked subprograms that the work is specifically designed to require,
+ such as by intimate data communication or control flow between those
+ subprograms and other parts of the work.
+ The Corresponding Source need not include anything that users
+ can regenerate automatically from other parts of the Corresponding
+ Source.
+ The Corresponding Source for a work in source code form is that
+ same work.
+ 2. Basic Permissions.
+ All rights granted under this License are granted for the term of
+ copyright on the Program, and are irrevocable provided the stated
+ conditions are met. This License explicitly affirms your unlimited
+ permission to run the unmodified Program. The output from running a
+ covered work is covered by this License only if the output, given its
+ content, constitutes a covered work. This License acknowledges your
+ rights of fair use or other equivalent, as provided by copyright law.
+ You may make, run and propagate covered works that you do not
+ convey, without conditions so long as your license otherwise remains
+ in force. You may convey covered works to others for the sole purpose
+ of having them make modifications exclusively for you, or provide you
+ with facilities for running those works, provided that you comply with
+ the terms of this License in conveying all material for which you do
+ not control copyright. Those thus making or running the covered works
+ for you must do so exclusively on your behalf, under your direction
+ and control, on terms that prohibit them from making any copies of
+ your copyrighted material outside their relationship with you.
+ Conveying under any other circumstances is permitted solely under
+ the conditions stated below. Sublicensing is not allowed; section 10
+ makes it unnecessary.
+ 3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+ No covered work shall be deemed part of an effective technological
+ measure under any applicable law fulfilling obligations under article
+ 11 of the WIPO copyright treaty adopted on 20 December 1996, or
+ similar laws prohibiting or restricting circumvention of such
+ measures.
+ When you convey a covered work, you waive any legal power to forbid
+ circumvention of technological measures to the extent such circumvention
+ is effected by exercising rights under this License with respect to
+ the covered work, and you disclaim any intention to limit operation or
+ modification of the work as a means of enforcing, against the work's
+ users, your or third parties' legal rights to forbid circumvention of
+ technological measures.
+ 4. Conveying Verbatim Copies.
+ You may convey verbatim copies of the Program's source code as you
+ receive it, in any medium, provided that you conspicuously and
+ appropriately publish on each copy an appropriate copyright notice;
+ keep intact all notices stating that this License and any
+ non-permissive terms added in accord with section 7 apply to the code;
+ keep intact all notices of the absence of any warranty; and give all
+ recipients a copy of this License along with the Program.
+ You may charge any price or no price for each copy that you convey,
+ and you may offer support or warranty protection for a fee.
+ 5. Conveying Modified Source Versions.
+ You may convey a work based on the Program, or the modifications to
+ produce it from the Program, in the form of source code under the
+ terms of section 4, provided that you also meet all of these conditions:
+ a) The work must carry prominent notices stating that you modified
+ it, and giving a relevant date.
+ b) The work must carry prominent notices stating that it is
+ released under this License and any conditions added under section
+ 7. This requirement modifies the requirement in section 4 to
+ "keep intact all notices".
+ c) You must license the entire work, as a whole, under this
+ License to anyone who comes into possession of a copy. This
+ License will therefore apply, along with any applicable section 7
+ additional terms, to the whole of the work, and all its parts,
+ regardless of how they are packaged. This License gives no
+ permission to license the work in any other way, but it does not
+ invalidate such permission if you have separately received it.
+ d) If the work has interactive user interfaces, each must display
+ Appropriate Legal Notices; however, if the Program has interactive
+ interfaces that do not display Appropriate Legal Notices, your
+ work need not make them do so.
+ A compilation of a covered work with other separate and independent
+ works, which are not by their nature extensions of the covered work,
+ and which are not combined with it such as to form a larger program,
+ in or on a volume of a storage or distribution medium, is called an
+ "aggregate" if the compilation and its resulting copyright are not
+ used to limit the access or legal rights of the compilation's users
+ beyond what the individual works permit. Inclusion of a covered work
+ in an aggregate does not cause this License to apply to the other
+ parts of the aggregate.
+ 6. Conveying Non-Source Forms.
+ You may convey a covered work in object code form under the terms
+ of sections 4 and 5, provided that you also convey the
+ machine-readable Corresponding Source under the terms of this License,
+ in one of these ways:
+ a) Convey the object code in, or embodied in, a physical product
+ (including a physical distribution medium), accompanied by the
+ Corresponding Source fixed on a durable physical medium
+ customarily used for software interchange.
+ b) Convey the object code in, or embodied in, a physical product
+ (including a physical distribution medium), accompanied by a
+ written offer, valid for at least three years and valid for as
+ long as you offer spare parts or customer support for that product
+ model, to give anyone who possesses the object code either (1) a
+ copy of the Corresponding Source for all the software in the
+ product that is covered by this License, on a durable physical
+ medium customarily used for software interchange, for a price no
+ more than your reasonable cost of physically performing this
+ conveying of source, or (2) access to copy the
+ Corresponding Source from a network server at no charge.
+ c) Convey individual copies of the object code with a copy of the
+ written offer to provide the Corresponding Source. This
+ alternative is allowed only occasionally and noncommercially, and
+ only if you received the object code with such an offer, in accord
+ with subsection 6b.
+ d) Convey the object code by offering access from a designated
+ place (gratis or for a charge), and offer equivalent access to the
+ Corresponding Source in the same way through the same place at no
+ further charge. You need not require recipients to copy the
+ Corresponding Source along with the object code. If the place to
+ copy the object code is a network server, the Corresponding Source
+ may be on a different server (operated by you or a third party)
+ that supports equivalent copying facilities, provided you maintain
+ clear directions next to the object code saying where to find the
+ Corresponding Source. Regardless of what server hosts the
+ Corresponding Source, you remain obligated to ensure that it is
+ available for as long as needed to satisfy these requirements.
+ e) Convey the object code using peer-to-peer transmission, provided
+ you inform other peers where the object code and Corresponding
+ Source of the work are being offered to the general public at no
+ charge under subsection 6d.
+ A separable portion of the object code, whose source code is excluded
+ from the Corresponding Source as a System Library, need not be
+ included in conveying the object code work.
+ A "User Product" is either (1) a "consumer product", which means any
+ tangible personal property which is normally used for personal, family,
+ or household purposes, or (2) anything designed or sold for incorporation
+ into a dwelling. In determining whether a product is a consumer product,
+ doubtful cases shall be resolved in favor of coverage. For a particular
+ product received by a particular user, "normally used" refers to a
+ typical or common use of that class of product, regardless of the status
+ of the particular user or of the way in which the particular user
+ actually uses, or expects or is expected to use, the product. A product
+ is a consumer product regardless of whether the product has substantial
+ commercial, industrial or non-consumer uses, unless such uses represent
+ the only significant mode of use of the product.
+ "Installation Information" for a User Product means any methods,
+ procedures, authorization keys, or other information required to install
+ and execute modified versions of a covered work in that User Product from
+ a modified version of its Corresponding Source. The information must
+ suffice to ensure that the continued functioning of the modified object
+ code is in no case prevented or interfered with solely because
+ modification has been made.
+ If you convey an object code work under this section in, or with, or
+ specifically for use in, a User Product, and the conveying occurs as
+ part of a transaction in which the right of possession and use of the
+ User Product is transferred to the recipient in perpetuity or for a
+ fixed term (regardless of how the transaction is characterized), the
+ Corresponding Source conveyed under this section must be accompanied
+ by the Installation Information. But this requirement does not apply
+ if neither you nor any third party retains the ability to install
+ modified object code on the User Product (for example, the work has
+ been installed in ROM).
+ The requirement to provide Installation Information does not include a
+ requirement to continue to provide support service, warranty, or updates
+ for a work that has been modified or installed by the recipient, or for
+ the User Product in which it has been modified or installed. Access to a
+ network may be denied when the modification itself materially and
+ adversely affects the operation of the network or violates the rules and
+ protocols for communication across the network.
+ Corresponding Source conveyed, and Installation Information provided,
+ in accord with this section must be in a format that is publicly
+ documented (and with an implementation available to the public in
+ source code form), and must require no special password or key for
+ unpacking, reading or copying.
+ 7. Additional Terms.
+ "Additional permissions" are terms that supplement the terms of this
+ License by making exceptions from one or more of its conditions.
+ Additional permissions that are applicable to the entire Program shall
+ be treated as though they were included in this License, to the extent
+ that they are valid under applicable law. If additional permissions
+ apply only to part of the Program, that part may be used separately
+ under those permissions, but the entire Program remains governed by
+ this License without regard to the additional permissions.
+ When you convey a copy of a covered work, you may at your option
+ remove any additional permissions from that copy, or from any part of
+ it. (Additional permissions may be written to require their own
+ removal in certain cases when you modify the work.) You may place
+ additional permissions on material, added by you to a covered work,
+ for which you have or can give appropriate copyright permission.
+ Notwithstanding any other provision of this License, for material you
+ add to a covered work, you may (if authorized by the copyright holders of
+ that material) supplement the terms of this License with terms:
+ a) Disclaiming warranty or limiting liability differently from the
+ terms of sections 15 and 16 of this License; or
+ b) Requiring preservation of specified reasonable legal notices or
+ author attributions in that material or in the Appropriate Legal
+ Notices displayed by works containing it; or
+ c) Prohibiting misrepresentation of the origin of that material, or
+ requiring that modified versions of such material be marked in
+ reasonable ways as different from the original version; or
+ d) Limiting the use for publicity purposes of names of licensors or
+ authors of the material; or
+ e) Declining to grant rights under trademark law for use of some
+ trade names, trademarks, or service marks; or
+ f) Requiring indemnification of licensors and authors of that
+ material by anyone who conveys the material (or modified versions of
+ it) with contractual assumptions of liability to the recipient, for
+ any liability that these contractual assumptions directly impose on
+ those licensors and authors.
+ All other non-permissive additional terms are considered "further
+ restrictions" within the meaning of section 10. If the Program as you
+ received it, or any part of it, contains a notice stating that it is
+ governed by this License along with a term that is a further
+ restriction, you may remove that term. If a license document contains
+ a further restriction but permits relicensing or conveying under this
+ License, you may add to a covered work material governed by the terms
+ of that license document, provided that the further restriction does
+ not survive such relicensing or conveying.
+ If you add terms to a covered work in accord with this section, you
+ must place, in the relevant source files, a statement of the
+ additional terms that apply to those files, or a notice indicating
+ where to find the applicable terms.
+ Additional terms, permissive or non-permissive, may be stated in the
+ form of a separately written license, or stated as exceptions;
+ the above requirements apply either way.
+ 8. Termination.
+ You may not propagate or modify a covered work except as expressly
+ provided under this License. Any attempt otherwise to propagate or
+ modify it is void, and will automatically terminate your rights under
+ this License (including any patent licenses granted under the third
+ paragraph of section 11).
+ However, if you cease all violation of this License, then your
+ license from a particular copyright holder is reinstated (a)
+ provisionally, unless and until the copyright holder explicitly and
+ finally terminates your license, and (b) permanently, if the copyright
+ holder fails to notify you of the violation by some reasonable means
+ prior to 60 days after the cessation.
+ Moreover, your license from a particular copyright holder is
+ reinstated permanently if the copyright holder notifies you of the
+ violation by some reasonable means, this is the first time you have
+ received notice of violation of this License (for any work) from that
+ copyright holder, and you cure the violation prior to 30 days after
+ your receipt of the notice.
+ Termination of your rights under this section does not terminate the
+ licenses of parties who have received copies or rights from you under
+ this License. If your rights have been terminated and not permanently
+ reinstated, you do not qualify to receive new licenses for the same
+ material under section 10.
+ 9. Acceptance Not Required for Having Copies.
+ You are not required to accept this License in order to receive or
+ run a copy of the Program. Ancillary propagation of a covered work
+ occurring solely as a consequence of using peer-to-peer transmission
+ to receive a copy likewise does not require acceptance. However,
+ nothing other than this License grants you permission to propagate or
+ modify any covered work. These actions infringe copyright if you do
+ not accept this License. Therefore, by modifying or propagating a
+ covered work, you indicate your acceptance of this License to do so.
+ 10. Automatic Licensing of Downstream Recipients.
+ Each time you convey a covered work, the recipient automatically
+ receives a license from the original licensors, to run, modify and
+ propagate that work, subject to this License. You are not responsible
+ for enforcing compliance by third parties with this License.
+ An "entity transaction" is a transaction transferring control of an
+ organization, or substantially all assets of one, or subdividing an
+ organization, or merging organizations. If propagation of a covered
+ work results from an entity transaction, each party to that
+ transaction who receives a copy of the work also receives whatever
+ licenses to the work the party's predecessor in interest had or could
+ give under the previous paragraph, plus a right to possession of the
+ Corresponding Source of the work from the predecessor in interest, if
+ the predecessor has it or can get it with reasonable efforts.
+ You may not impose any further restrictions on the exercise of the
+ rights granted or affirmed under this License. For example, you may
+ not impose a license fee, royalty, or other charge for exercise of
+ rights granted under this License, and you may not initiate litigation
+ (including a cross-claim or counterclaim in a lawsuit) alleging that
+ any patent claim is infringed by making, using, selling, offering for
+ sale, or importing the Program or any portion of it.
+ 11. Patents.
+ A "contributor" is a copyright holder who authorizes use under this
+ License of the Program or a work on which the Program is based. The
+ work thus licensed is called the contributor's "contributor version".
+ A contributor's "essential patent claims" are all patent claims
+ owned or controlled by the contributor, whether already acquired or
+ hereafter acquired, that would be infringed by some manner, permitted
+ by this License, of making, using, or selling its contributor version,
+ but do not include claims that would be infringed only as a
+ consequence of further modification of the contributor version. For
+ purposes of this definition, "control" includes the right to grant
+ patent sublicenses in a manner consistent with the requirements of
+ this License.
+ Each contributor grants you a non-exclusive, worldwide, royalty-free
+ patent license under the contributor's essential patent claims, to
+ make, use, sell, offer for sale, import and otherwise run, modify and
+ propagate the contents of its contributor version.
+ In the following three paragraphs, a "patent license" is any express
+ agreement or commitment, however denominated, not to enforce a patent
+ (such as an express permission to practice a patent or covenant not to
+ sue for patent infringement). To "grant" such a patent license to a
+ party means to make such an agreement or commitment not to enforce a
+ patent against the party.
+ If you convey a covered work, knowingly relying on a patent license,
+ and the Corresponding Source of the work is not available for anyone
+ to copy, free of charge and under the terms of this License, through a
+ publicly available network server or other readily accessible means,
+ then you must either (1) cause the Corresponding Source to be so
+ available, or (2) arrange to deprive yourself of the benefit of the
+ patent license for this particular work, or (3) arrange, in a manner
+ consistent with the requirements of this License, to extend the patent
+ license to downstream recipients. "Knowingly relying" means you have
+ actual knowledge that, but for the patent license, your conveying the
+ covered work in a country, or your recipient's use of the covered work
+ in a country, would infringe one or more identifiable patents in that
+ country that you have reason to believe are valid.
+ If, pursuant to or in connection with a single transaction or
+ arrangement, you convey, or propagate by procuring conveyance of, a
+ covered work, and grant a patent license to some of the parties
+ receiving the covered work authorizing them to use, propagate, modify
+ or convey a specific copy of the covered work, then the patent license
+ you grant is automatically extended to all recipients of the covered
+ work and works based on it.
+ A patent license is "discriminatory" if it does not include within
+ the scope of its coverage, prohibits the exercise of, or is
+ conditioned on the non-exercise of one or more of the rights that are
+ specifically granted under this License. You may not convey a covered
+ work if you are a party to an arrangement with a third party that is
+ in the business of distributing software, under which you make payment
+ to the third party based on the extent of your activity of conveying
+ the work, and under which the third party grants, to any of the
+ parties who would receive the covered work from you, a discriminatory
+ patent license (a) in connection with copies of the covered work
+ conveyed by you (or copies made from those copies), or (b) primarily
+ for and in connection with specific products or compilations that
+ contain the covered work, unless you entered into that arrangement,
+ or that patent license was granted, prior to 28 March 2007.
+ Nothing in this License shall be construed as excluding or limiting
+ any implied license or other defenses to infringement that may
+ otherwise be available to you under applicable patent law.
+ 12. No Surrender of Others' Freedom.
+ If conditions are imposed on you (whether by court order, agreement or
+ otherwise) that contradict the conditions of this License, they do not
+ excuse you from the conditions of this License. If you cannot convey a
+ covered work so as to satisfy simultaneously your obligations under this
+ License and any other pertinent obligations, then as a consequence you may
+ not convey it at all. For example, if you agree to terms that obligate you
+ to collect a royalty for further conveying from those to whom you convey
+ the Program, the only way you could satisfy both those terms and this
+ License would be to refrain entirely from conveying the Program.
+ 13. Use with the GNU Affero General Public License.
+ Notwithstanding any other provision of this License, you have
+ permission to link or combine any covered work with a work licensed
+ under version 3 of the GNU Affero General Public License into a single
+ combined work, and to convey the resulting work. The terms of this
+ License will continue to apply to the part which is the covered work,
+ but the special requirements of the GNU Affero General Public License,
+ section 13, concerning interaction through a network will apply to the
+ combination as such.
+ 14. Revised Versions of this License.
+ The Free Software Foundation may publish revised and/or new versions of
+ the GNU General Public License from time to time. Such new versions will
+ be similar in spirit to the present version, but may differ in detail to
+ address new problems or concerns.
+ Each version is given a distinguishing version number. If the
+ Program specifies that a certain numbered version of the GNU General
+ Public License "or any later version" applies to it, you have the
+ option of following the terms and conditions either of that numbered
+ version or of any later version published by the Free Software
+ Foundation. If the Program does not specify a version number of the
+ GNU General Public License, you may choose any version ever published
+ by the Free Software Foundation.
+ If the Program specifies that a proxy can decide which future
+ versions of the GNU General Public License can be used, that proxy's
+ public statement of acceptance of a version permanently authorizes you
+ to choose that version for the Program.
+ Later license versions may give you additional or different
+ permissions. However, no additional obligations are imposed on any
+ author or copyright holder as a result of your choosing to follow a
+ later version.
+ 15. Disclaimer of Warranty.
+ THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+ APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+ HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+ OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+ THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+ IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+ 16. Limitation of Liability.
+ IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+ WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+ THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+ GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+ USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+ DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+ PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+ EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+ SUCH DAMAGES.
+ 17. Interpretation of Sections 15 and 16.
+ If the disclaimer of warranty and limitation of liability provided
+ above cannot be given local legal effect according to their terms,
+ reviewing courts shall apply local law that most closely approximates
+ an absolute waiver of all civil liability in connection with the
+ Program, unless a warranty or assumption of liability accompanies a
+ copy of the Program in return for a fee.
+ END OF TERMS AND CONDITIONS
+ How to Apply These Terms to Your New Programs
+ If you develop a new program, and you want it to be of the greatest
+ possible use to the public, the best way to achieve this is to make it
+ free software which everyone can redistribute and change under these terms.
+ To do so, attach the following notices to the program. It is safest
+ to attach them to the start of each source file to most effectively
+ state the exclusion of warranty; and each file should have at least
+ the "copyright" line and a pointer to where the full notice is found.
+
+ Copyright (C)
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see .
+ Also add information on how to contact you by electronic and paper mail.
+ If the program does terminal interaction, make it output a short
+ notice like this when it starts in an interactive mode:
+ Copyright (C)
+ This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+ This is free software, and you are welcome to redistribute it
+ under certain conditions; type `show c' for details.
+ The hypothetical commands `show w' and `show c' should show the appropriate
+ parts of the General Public License. Of course, your program's commands
+ might be different; for a GUI interface, you would use an "about box".
+ You should also get your employer (if you work as a programmer) or school,
+ if any, to sign a "copyright disclaimer" for the program, if necessary.
+ For more information on this, and how to apply and follow the GNU GPL, see
+ .
+ The GNU General Public License does not permit incorporating your program
+ into proprietary programs. If your program is a subroutine library, you
+ may consider it more useful to permit linking proprietary applications with
+ the library. If this is what you want to do, use the GNU Lesser General
+ Public License instead of this License. But first, please read
+ .
diff --git a/v5.0.1/_sources/modelling/binding/bi_steric_mass_action.rst.txt b/v5.0.1/_sources/modelling/binding/bi_steric_mass_action.rst.txt
new file mode 100644
index 000000000..936177170
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/bi_steric_mass_action.rst.txt
@@ -0,0 +1,41 @@
+.. _bi_steric_mass_action_model:
+
+Bi Steric Mass Action
+~~~~~~~~~~~~~~~~~~~~~
+
+Similar to the Bi-Langmuir model (see Section :ref:`multi_component_bi_langmuir_model`), the Bi-SMA model adds :math:`M - 1` *additional* types of binding sites :math:`q_{i,j}` (:math:`0 \leq j \leq M - 1`) to the SMA model (see Section :ref:`steric_mass_action_model`) without allowing an exchange between the different sites :math:`q_{i,j}` and :math:`q_{i,k}` (:math:`k \neq j`).
+Therefore, there are no competitivity effects between the two types of binding sites and they have independent capacities.
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_{i,j}}{\mathrm{d} t} &= k_{a,i,j} c_{p,i} \left(\frac{\bar{q}_{0,j}}{q_{\text{ref},j}} \right)^{\nu_{i,j}} - k_{d,i,j}\: q_{i,j}\: \left(\frac{c_{p,0}}{c_{\text{ref},j}}\right)^{\nu_{i,j}} & i = 1, \dots, N_{\text{comp}} - 1, \quad j = 0, \dots, M - 1,
+ \end{aligned}
+
+where :math:`c_{p,0}` and :math:`q_{0,j}` (:math:`0 \leq j \leq M - 1`) denote the salt concentrations in the liquid and solid phases of the beads respectively.
+The number of available salt ions :math:`\bar{q}_{0,j}` for each binding site type :math:`0 \leq j \leq M - 1` is given by
+
+.. math::
+
+ \begin{aligned}
+ \bar{q}_{0,j} &= \Lambda_j - \sum_{k=1}^{N_{\text{comp}} - 1} \left( \nu_{k,j} + \sigma_{k,j} \right) q_{k,j}.
+ \end{aligned}
+
+Electro-neutrality conditions compensating for the missing equations for :math:`\frac{\mathrm{d} q_{0,j}}{\mathrm{d}t}` are required:
+
+.. math::
+
+ \begin{aligned}
+ q_{0,j} &= \Lambda_j - \sum_{k=1}^{N_{\text{comp}} - 1} \nu_{k,j} q_{k,j} & j = 0, \dots, M - 1.
+ \end{aligned}
+
+Note that all binding components must have exactly the same number of binding site types :math:`M \geq 1`.
+
+The reference concentrations :math:`c_{\text{ref},j}` and :math:`q_{\text{ref},j}` can be specified for each binding site type :math:`0 \leq j \leq M - 1`.
+The concept of reference concentrations is explained in the respective paragraph in Section :ref:`reference_concentrations`.
+
+Originally, the Bi-SMA model is limited to two different binding site types.
+Here, the model has been extended to arbitrary many binding site types.
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`bi_steric_mass_action_config`.
diff --git a/v5.0.1/_sources/modelling/binding/extended_mobile_phase_modulator_langmuir.rst.txt b/v5.0.1/_sources/modelling/binding/extended_mobile_phase_modulator_langmuir.rst.txt
new file mode 100644
index 000000000..06b5d24b1
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/extended_mobile_phase_modulator_langmuir.rst.txt
@@ -0,0 +1,34 @@
+.. _extended_mobile_phase_modulator_langmuir_model:
+
+Extended Mobile Phase Modulator Langmuir
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This model is an extension of the mobile phase modulator Langmuir model (see Section :ref:`multi_component_langmuir_model`), which allows linear binding of some selected components.
+A modifier component :math:`c_{p,\mathrm{mod}}` is selected and the remaining components are divided into the index sets :math:`\mathcal{I}_{\mathrm{lin}}` and :math:`\mathcal{I}_{\mathrm{lang}}`.
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} &= k_{a,i} e^{\gamma_i c_{p,\mathrm{mod}}} c_{p,i}\: q_{\text{max},i} \left( 1 - \sum_{j=1}^{N_{\text{comp}} - 1} \frac{q_j}{q_{\text{max},j}} \right) - k_{d,i} \: c_{p,\mathrm{mod}}^{\beta_i} \: q_i && i \in \mathcal{I}_{\mathrm{lang}}, \\
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} &= k_{a,i} c_{p,i} - k_{d,i} \: q_i && i \in \mathcal{I}_{\mathrm{lin}}.
+ \end{aligned}
+
+The modifier component is considered to be inert, therefore either
+
+.. math::
+
+ \frac{\mathrm{d} q_{\mathrm{mod}}}{\mathrm{d} t} = 0
+
+is used if the modifier component has a bound state, or it can be used without a bound state.
+
+The model can also be used without a modifier component.
+In this case, the equations are given by
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} &= k_{a,i} c_{p,i}\: q_{\text{max},i} \left( 1 - \sum_{j=1}^{N_{\text{comp}} - 1} \frac{q_j}{q_{\text{max},j}} \right) - k_{d,i} \: q_i && i \in \mathcal{I}_{\mathrm{lang}}, \\
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} &= k_{a,i} c_{p,i} - k_{d,i} \: q_i && i \in \mathcal{I}_{\mathrm{lin}}.
+ \end{aligned}
+
+For more information on model parameters required to define in CADET file format, see :ref:`extended_mobile_phase_modulator_langmuir_config`.
diff --git a/v5.0.1/_sources/modelling/binding/freundlich_ldf.rst.txt b/v5.0.1/_sources/modelling/binding/freundlich_ldf.rst.txt
new file mode 100644
index 000000000..b5a24a07d
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/freundlich_ldf.rst.txt
@@ -0,0 +1,44 @@
+.. _freundlich_ldf_model:
+
+Freundlich LDF
+~~~~~~~~~~~~~~~
+
+The Freundlich isotherm model is an empirical model that considers changes in the equilibrium constant of the binding process due to the heterogeneity of the surface and the variation of the interaction strength :cite:`Benedikt2019,Singh2016`.
+This variant of the model is based on the linear driving force approximation (see section :ref:`ldf_model`) and is given as
+
+.. math::
+ \begin{aligned}
+ q^*_i= k_{F,i}c_{p,i}^{\frac{1}{n_{i}}} && i = 0, \dots, N_{\text{comp}} - 1.
+ \end{aligned}
+
+No interaction between the components is considered when the model has multiple components.
+One of the limitation of this isotherm is the first order Jacobian :math:`\left(\frac{dq^*}{dc_p}\right)` tends to infinity as :math:`c_{p} \rightarrow 0` for :math:`n>1`.
+To address this issue an approximation of isotherm is considered near the origin.
+This approximation matches the isotherm in such a way that :math:`q=0` at :math:`c_p=0` and also matches the first derivative of the istotherm at :math:`c_p = \varepsilon`, where :math:`\varepsilon` is a very small number, for example :math:`1e-14`.
+The form of approximation and its derivative is given below for :math:`c_p < \varepsilon` and :math:`n>1`:
+
+.. math::
+
+ \begin{aligned}
+ q^* = \alpha_0+\alpha_1 c+\alpha_2 c_p^2
+ \end{aligned}
+
+ \begin{aligned}
+ \frac{dq^*}{dc_p} = \alpha_1+ 2 \alpha_2 c_p
+ \end{aligned}
+
+where :math:`\alpha_0=0` and :math:`\alpha_1` and :math:`\alpha_2` are determined from :math:`\alpha_1 \varepsilon+\alpha_2 \varepsilon^2 = k_f \varepsilon^{1/n}` and :math:`\alpha_1 + 2 \alpha_2 \varepsilon = \frac{1}{n}k_f \varepsilon^{\frac{1-n}{n}}`.
+
+.. math::
+ \begin{aligned}
+ \alpha_1 = \frac{2 n-1}{n}k_f \varepsilon^{\frac{1-n}{n}}
+ \end{aligned}
+.. math::
+ \begin{aligned}
+ \alpha_2 = \frac{1-n}{n}k_f \varepsilon^{\frac{1-2 n}{n}}
+ \end{aligned}
+
+This approximation can be used for any pore phase cocentration :math:`c_p < \varepsilon` given :math:`n>1`.
+For the case, when :math:`n \le 1` no special treament near the origin is required.
+For more information on model parameters required to define in CADET file format, see :ref:`freundlich_ldf_config`.
+
diff --git a/v5.0.1/_sources/modelling/binding/generalized_ion_exchange.rst.txt b/v5.0.1/_sources/modelling/binding/generalized_ion_exchange.rst.txt
new file mode 100644
index 000000000..df14e22f8
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/generalized_ion_exchange.rst.txt
@@ -0,0 +1,39 @@
+.. _generalized_ion_exchange_model:
+
+Generalized Ion Exchange
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The generalized ion exchange model is based on the steric mass action model :cite:`Huuk2017,Mollerup2008`.
+In addition to the first component :math:`c_{p,0}`, which represents salt, the second component :math:`c_{p,1}` represents another non-binding modifier (e.g., pH).
+In comparison to the SMA model, the characteristic charge :math:`\nu` and the adsorption and desorption rate constants are modified:
+
+.. math::
+
+ \begin{aligned}
+ q_0 &= \Lambda - \sum_{j=2}^{N_{\text{comp}} - 1} \nu_j(c_{p,1}) q_j \\
+ \frac{\partial q_i}{\partial t} &= k_{a,i}(c_{p,0},c_{p,1}) \: c_{p,i} \: \left( \frac{\bar{q}_0 }{q_{\text{ref}}} \right)^{\nu_i(c_{p,1})} - k_{d,i}(c_{p,0},c_{p,1}) \: q_i \: \left( \frac{c_{p,0}}{c_{\text{ref}}} \right)^{\nu_i(c_{p,1})} & &i = 2, \dots, N_{\text{comp}} - 1,
+ \end{aligned}
+
+where
+
+.. math::
+
+ \begin{aligned}
+ \bar{q}_0 &= \Lambda - \sum_{j=2}^{N_{\text{comp}} - 1} \left( \nu_j(c_{p,1}) + \sigma_j \right) q_j = q_0 - \sum_{j=2}^{N_{\text{comp}} - 1} \sigma_j q_j
+ \end{aligned}
+
+The dependence of the parameters on :math:`c_{p,0}` and :math:`c_{p,1}` is given for :math:`i = 2, \dots, N_{\text{comp}} - 1` by
+
+.. math::
+
+ \begin{aligned}
+ \nu_i(c_{p,1}) &= \nu_{i,\mathrm{base}} + c_{p,1} \nu_{i,\mathrm{lin}} + c_{p,1}^2 \nu_{i,\mathrm{quad}} \\
+ k_{a,i}\left(c_{p,0}, c_{p,1}\right) &= k_{a,i,\mathrm{base}} \exp\left(k_{a,i,\mathrm{lin}} c_{p,1} + k_{a,i,\mathrm{quad}} c_{p,1}^2 + k_{a,i,\mathrm{salt}} \frac{c_{p,0}}{c_{\text{ref}}} + k_{a,i,\mathrm{prot}} c_{p,i}\right) \\
+ k_{d,i}\left(c_{p,0}, c_{p,1}\right) &= k_{d,i,\mathrm{base}} \exp\left(k_{d,i,\mathrm{lin}} c_{p,1} + k_{d,i,\mathrm{quad}} c_{p,1}^2 + k_{d,i,\mathrm{salt}} \frac{c_{p,0}}{c_{\text{ref}}} + k_{d,i,\mathrm{prot}} c_{p,i}\right)
+ \end{aligned}
+
+
+The concept of reference concentrations (:math:`c_{\text{ref}}` and :math:`q_{\text{ref}}`) is explained in the respective paragraph in Section :ref:`reference_concentrations`.
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`generalized_ion_exchange_config`.
diff --git a/v5.0.1/_sources/modelling/binding/hic_constant_water_activity.rst.txt b/v5.0.1/_sources/modelling/binding/hic_constant_water_activity.rst.txt
new file mode 100644
index 000000000..b1dc8fa73
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/hic_constant_water_activity.rst.txt
@@ -0,0 +1,18 @@
+.. _hic_constant_water_activity_model:
+
+HIC Constant Water Activity
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This model implemments the HIC isotherm assuming a constant water activity as described by Jäpel and Buyel :cite:`Jaepel2022`.
+
+.. math::
+ \begin{align}
+ \beta &= \beta_0 e^{c_{p,0}\beta_1} \\
+ \frac{\mathrm{d}q_i}{\mathrm{d}t} &= k_{a,i} c_{p,i} \left( 1 - \sum_j \frac{q_j}{q_{max,j}} \right)^{\nu_i} - k_{d,i} q_i 0.1^{\nu_i \beta}
+ \end{align}
+
+- Component :math:`c_0` is assumed to be salt without a bound state.
+- Multiple bound states are not supported.
+- Components without bound state (i.e., salt and non-binding components) are supported.
+
+For more information on model parameters required to define in CADET file format, see :ref:`hic_constant_water_activity_config`.
+
diff --git a/v5.0.1/_sources/modelling/binding/hic_water_on_hydrophobic_surfaces.rst.txt b/v5.0.1/_sources/modelling/binding/hic_water_on_hydrophobic_surfaces.rst.txt
new file mode 100644
index 000000000..f14deff60
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/hic_water_on_hydrophobic_surfaces.rst.txt
@@ -0,0 +1,20 @@
+.. _hic_water_on_hydrophobic_surfaces_model:
+
+HIC Water on Hydrophobic Surfaces
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This model implements a slightly modified version of the HIC isotherm by Wang et al. based on their 2016 paper :cite:`Wang2016`.
+A naive multicomponent version was added that reduces to the original formulation if only 1 binding species is present.
+
+.. math::
+
+ \begin{align}
+ \beta &= \beta_0 e^{c_{p,0}\beta_1} \\
+ \frac{\mathrm{d}q_i}{\mathrm{d}t} &= k_{a,i} c_{p,i} \left( 1 - \sum_j \frac{q_j}{q_{max,j}} \right)^{\nu_i} - k_{d,i} q_i \left(\sum_j q_j \right)^{\nu_i \beta}
+ \end{align}
+
+- Component :math:`c_0` is assumed to be salt without a bound state.
+- Multiple bound states are not supported.
+- Components without bound state (i.e., salt and non-binding components) are supported.
+
+For more information on model parameters required to define in CADET file format, see :ref:`hic_water_on_hydrophobic_surfaces_config`.
diff --git a/v5.0.1/_sources/modelling/binding/index.rst.txt b/v5.0.1/_sources/modelling/binding/index.rst.txt
new file mode 100644
index 000000000..98211587f
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/index.rst.txt
@@ -0,0 +1,282 @@
+.. _binding_models:
+
+Binding models
+==============
+
+The following binding models are presented in dynamic binding mode.
+By replacing all occurrences of :math:`\mathrm{d}q / \mathrm{d}t` with :math:`0`, quasi-stationary (rapid-equlibrium) binding mode is achieved.
+In quasi-stationary binding, it is assumed that ad- and desorption take place on a much faster time scale than the other transport processes such that bead liquid phase :math:`c_{p,i}` (or bulk liquid phase :math:`c_i` for certain unit operation models) are always in equilibrium with the solid phase :math:`q_i`.
+
+Equilibrium constants
+---------------------
+
+For the quasi-stationary binding mode, adsorption and desorption rate are no longer separate entities.
+Instead, the quotient :math:`k_{\text{eq}} = k_a / k_d` of adsorption and desorption coefficient is the relevant parameter as shown for the linear binding model (see Section :ref:`linear_model`):
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} &= k_{a,i} c_{p,i} - k_{d,i} q_i \qquad \Rightarrow 0 = k_{a,i} c_{p,i} - k_{d,i} q_i \qquad \Leftrightarrow q_i = \frac{k_{a,i}}{k_{d,i}} c_{p,i} = k_{\text{eq},i} c_{p,i}.
+ \end{aligned}
+
+The equilibrium constant :math:`k_{\text{eq},i}` is used in CADET by setting :math:`k_{d,i} = 1` and :math:`k_{a,i} = k_{\text{eq},i}`.
+
+Note that adsorption rate :math:`k_{a,i}` and desorption rate :math:`k_{d,i}` are linearly correlated in both binding modes due to the form of the equilibrium constant :math:`k_{\text{eq}}`:
+
+.. math::
+
+ \begin{aligned}
+ k_{a,i} = k_{\text{eq}} k_{d,i}.
+ \end{aligned}
+
+This correlation can potentially degrade performance of some optimization algorithms.
+While in quasi-stationary binding mode this is prevented by using the technique above, a dynamic binding model has to be reparameterized in order to decouple parameters:
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} &= k_{a,i} c_{p,i} - k_{d,i} q_i = k_{d,i} \left[ k_{\text{eq},i} c_{p,i} - q_i \right] = k_{a,i} \left[ c_{p,i} - \frac{1}{k_{\text{eq},i}} q_i \right].
+ \end{aligned}
+
+This can be achieved by a (nonlinear) parameter transform
+
+.. math::
+
+ \begin{aligned}
+ F\left( k_{\text{eq},i}, k_{d,i} \right) = \begin{pmatrix} k_{\text{eq},i} k_{d,i} \\ k_{d,i} \end{pmatrix} \text{ with Jacobian } J_F\left( k_{\text{eq},i}, k_{d,i} \right) = \begin{pmatrix} k_{d,i} & k_{\text{eq},i} \\ 0 & 1 \end{pmatrix}.
+ \end{aligned}
+
+
+.. _ldf_model:
+
+Linear Driving Force (LDF)
+---------------------------
+Some authors use the linear driving force (LDF) approximation instead of the native kinetic form of an isotherm.
+All three approaches are equivalent in rapid equilibrium (``IS_KINETIC = 0``) but not equivalent when binding kinetics are considered (``IS_KINETIC = 1``).
+
+1. In the native approach, :math:`\frac{dq}{dt}` is an explicit funtion of :math:`c` and :math:`q`. For example :math:`\frac{dq}{dt}=k_a c (q_m - q)-k_d q` in the Langmuir model.
+
+2. A linear driving force approximation is based on the equilibrium concentration :math:`q^*` for given :math:`c`.
+For example :math:`q^*= \frac{q_m k_{eq} c}{1 + k_{eq} c}` in the Langmuir model.
+Here, :math:`\frac{dq}{dt}` is proportional to the actual difference from equilibrium, i.e. :math:`\frac{dq}{dt} = k_{kin}(q^*-q)`.
+Note that, the sign of :math:`\frac{dq}{dt}` causes the resulting flux to act towards the equilibrium.
+In CADET, this approach is denoted by ``LDF``, for example in ``MULTI_COMPONENT_LANGMUIR_LDF``.
+
+3. An alterniative linear driving force approximation is based on the equilibrium concentration :math:`c^*` for given :math:`q`.
+For example :math:`c^*=\frac{q}{k_{eq} \left(q_{m}-q\right)}` in the Langmuir model.
+Here, :math:`\frac{dq}{dt}` is proportional to the actual difference from equilibrium concentrations, i.e. :math:`\frac{dq}{dt} = k_{kin}(c-c^*)`.
+Note that, the sign of :math:`\frac{dq}{dt}` causes the resulting flux to act towards the equilibrium.
+In CADET, this approach is denoted by ``LDF_LIQUID_PHASE``, for example in ``MULTI_COMPONENT_LANGMUIR_LDF_LIQUID_PHASE``.
+
+In both LDF examples, the original rate constants :math:`k_a` and :math:`k_d` are replaced by the equilibrium contant :math:`k_{eq}=\frac{k_a}{k_d}`.
+The linear driving force approximations are based on a new kinetic constant, :math:`k_{kin}`.
+
+Note that some isotherms, such as the Freundlich model, don't have a native representation in the above sense.
+LDF versions are availabe for some but not all binding models implemented in CADET.
+
+.. _reference_concentrations:
+
+Reference concentrations
+------------------------
+
+Some binding models use reference concentrations :math:`c_{\text{ref}}` and :math:`q_{\text{ref}}` of the mobile phase modulator (e.g., salt) in the particle liquid and solid phase, respectively.
+The reference values are mainly used for normalizing adsorption and desorption rates, but also for other parameters that appear with those concentrations.
+They amount to a simple parameter transformation that is exemplified at one equation of the steric mass action binding model
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} = k_{a,i} c_{p,i}\bar{q}_0^{\nu_i} - k_{d,i} q_i c_{p,0}^{\nu_i},
+ \end{aligned}
+
+where :math:`c_{p,0}` denotes the mobile phase salt concentration and
+
+.. math::
+
+ \begin{aligned}
+ \bar{q}_0 = \Lambda - \sum_{j=1}^{N_{\text{comp}} - 1} \left( \nu_j + \sigma_j \right) q_j
+ \end{aligned}
+
+is the number of available binding sites which is related to the number of bound salt ions.
+Using the parameter transformation
+
+.. math::
+
+ \begin{aligned}
+ k_{a,i} &= \tilde{k}_{a,i} q_{\text{ref}}^{-\nu_i}, \\
+ k_{d,i} &= \tilde{k}_{d,i} c_{\text{ref}}^{-\nu_i},
+ \end{aligned}
+
+we obtain the modified model equation
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} = \tilde{k}_{a,i} c_{p,i} \left(\frac{\bar{q}_0}{q_{\text{ref}}}\right)^{\nu_i} - \tilde{k}_{d,i} q_i \left(\frac{c_{p,0}}{c_{\text{ref}}}\right)^{\nu_i}.
+ \end{aligned}
+
+This transformation serves as a (partial) nondimensionalization of the adsorption and desorption rates and, by properly choosing the reference concentrations :math:`c_{\text{ref}}` and :math:`q_{\text{ref}}`, may improve the optimizer performance.
+
+Recommended choices for :math:`c_{\text{ref}}` are the average or maximum inlet concentration of the mobile phase modifier :math:`c_0`, and for :math:`q_{\text{ref}}` the ionic capacity :math:`\Lambda`.
+Note that setting the reference concentrations to :math:`1.0` each results in the original binding model.
+
+
+.. _dependence-on-external-function_bind:
+
+Dependence on external function
+-------------------------------
+
+A binding model may depend on an external function or profile :math:`T\colon \left[ 0, T_{\text{end}}\right] \times [0, L] \to \mathbb{R}`, where :math:`L` denotes the physical length of the unit operation, or :math:`T\colon \left[0, T_{\text{end}}\right] \to \mathbb{R}` if the unit operation model has no axial length.
+By using an external profile, it is possible to account for effects that are not directly modeled in CADET (e.g., temperature).
+The dependence of each parameter is modeled by a polynomial of third degree. For example, the adsorption rate :math:`k_a` is really given by
+
+.. math::
+
+ \begin{aligned}
+ k_a(T) &= k_{a,3} T^3 + k_{a,2} T^2 + k_{a,1} T + k_{a,0}.
+ \end{aligned}
+
+While :math:`k_{a,0}` is set by the original parameter ``XXX_KA`` of the file format (``XXX`` being a placeholder for the binding model), the parameters :math:`k_{a,3}`, :math:`k_{a,2}`, and :math:`k_{a,1}` are given by ``XXX_KA_TTT``, ``XXX_KA_TT``, and ``XXX_KA_T``, respectively.
+The identifier of the externally dependent binding model is constructed from the original identifier by prepending ``EXT_`` (e.g., ``MULTI_COMPONENT_LANGMUIR`` is changed into ``EXT_MULTI_COMPONENT_LANGMUIR``).
+This pattern applies to all parameters and supporting binding models (see :numref:`MBFeatureMatrix`).
+Note that the parameter units have to be adapted to the unit of the external profile by dividing with an appropriate power.
+
+Each parameter of the externally dependent binding model can depend on a different external source.
+The 0-based indices of the external source for each parameter is given in the dataset ``EXTFUN``.
+By assigning only one index to ``EXTFUN``, all parameters use the same source.
+The ordering of the parameters in ``EXTFUN`` is given by the ordering in the file format specification in Section :ref:`FFAdsorption`.
+
+
+.. _binding_model_feature:
+
+Binding model feature matrix
+----------------------------
+
+A short comparison of the most prominent binding model features is given in :numref:`MBFeatureMatrix`.
+The implemented binding models can be divided into two main classes: Single-state and multi-state binding.
+While single-state models only have one bound state per component (or less), multi-state models provide multiple (possibly different) bound states for each component, which may correspond to different binding orientations or binding site types.
+The models also differ in whether a mobile phase modifier (e.g., salt) is supported to modulate the binding behavior.
+
+.. _MBFeatureMatrix:
+.. list-table:: Supported features of the different binding models
+ :widths: 30 15 25 15 15
+ :header-rows: 1
+
+ * - Binding model
+ - Competitive
+ - Mobile phase modifier
+ - External function
+ - Multi-state
+ * - :ref:`linear_model`
+ - ×
+ - ×
+ - ✓
+ - ×
+ * - :ref:`multi_component_langmuir_model`
+ - ✓
+ - ×
+ - ✓
+ - ×
+ * - :ref:`multi_component_langmuir_ldf_model`
+ - ✓
+ - ×
+ - ✓
+ - ×
+ * - :ref:`multi_component_langmuir_ldf_liquid_phase_model`
+ - ✓
+ - ×
+ - ✓
+ - ×
+ * - :ref:`mobile_phase_modulator_langmuir_model`
+ - ✓
+ - ✓
+ - ✓
+ - ×
+ * - :ref:`extended_mobile_phase_modulator_langmuir_model`
+ - ✓
+ - ✓
+ - ✓
+ - ×
+ * - :ref:`multi_component_bi_langmuir_model`
+ - ✓
+ - ×
+ - ✓
+ - ✓
+ * - :ref:`multi_component_bi_langmuir_ldf_model`
+ - ✓
+ - ×
+ - ✓
+ - ✓
+ * - :ref:`multi_component_anti_langmuir_model`
+ - ✓
+ - ×
+ - ✓
+ - ×
+ * - :ref:`multi_component_spreading_model`
+ - ✓
+ - ×
+ - ✓
+ - ✓
+ * - :ref:`steric_mass_action_model`
+ - ✓
+ - ✓
+ - ✓
+ - ×
+ * - :ref:`multi_state_steric_mass_action_model`
+ - ✓
+ - ✓
+ - ✓
+ - ✓
+ * - :ref:`simplified_multi_state_steric_mass_action_model`
+ - ✓
+ - ✓
+ - ×
+ - ✓
+ * - :ref:`bi_steric_mass_action_model`
+ - ✓
+ - ✓
+ - ✓
+ - ✓
+ * - :ref:`multi_component_colloidal_model`
+ - ✓
+ - ✓
+ - ✓
+ - ×
+ * - :ref:`generalized_ion_exchange_model`
+ - ✓
+ - ✓
+ - ✓
+ - ×
+ * - :ref:`saska_model`
+ - ×
+ - ×
+ - ✓
+ - ×
+ * - :ref:`self_association_model`
+ - ✓
+ - ✓
+ - ✓
+ - ×
+ * - :ref:`freundlich_ldf_model`
+ - ×
+ - ×
+ - ✓
+ - ×
+ * - :ref:`hic_water_on_hydrophobic_surfaces_model`
+ - ✓
+ - x
+ - ✓
+ - x
+ * - :ref:`hic_constant_water_activity_model`
+ - ✓
+ - x
+ - ✓
+ - x
+
+
+.. toctree::
+ :hidden:
+ :glob:
+
+ *
+
diff --git a/v5.0.1/_sources/modelling/binding/linear.rst.txt b/v5.0.1/_sources/modelling/binding/linear.rst.txt
new file mode 100644
index 000000000..e275e16ab
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/linear.rst.txt
@@ -0,0 +1,15 @@
+.. _linear_model:
+
+Linear
+~~~~~~
+
+A linear binding model, which is often employed for low concentrations or in analytic settings :cite:`Guiochon2006`.
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} = k_{a,i} c_{p,i} - k_{d,i} q_i && i = 0, \dots, N_{\text{comp}} - 1.
+ \end{aligned}
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`linear_config`.
diff --git a/v5.0.1/_sources/modelling/binding/mobile_phase_modulator_langmuir.rst.txt b/v5.0.1/_sources/modelling/binding/mobile_phase_modulator_langmuir.rst.txt
new file mode 100644
index 000000000..98c29335e
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/mobile_phase_modulator_langmuir.rst.txt
@@ -0,0 +1,28 @@
+.. _mobile_phase_modulator_langmuir_model:
+
+Mobile Phase Modulator Langmuir
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This model is a modified Langmuir model (see Section :ref:`multi_component_langmuir_model`) which can be used to describe hydrophobic interaction chromatography :cite:`Melander1989,Karlsson2004`.
+A modulator component (termed “salt”, :math:`c_{p,0}` and :math:`q_0`) influences ad- and desorption processes:
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} = k_{a,i} e^{\gamma_i c_{p,0}} c_{p,i}\: q_{\text{max},i} \left( 1 - \sum_{j=1}^{N_{\text{comp}} - 1} \frac{q_j}{q_{\text{max},j}} \right) - k_{d,i} \: c_{p,0}^{\beta_i} \: q_i && i = 1, \dots, N_{\text{comp}} - 1.
+ \end{aligned}
+
+where :math:`c_{p,0}` and :math:`q_0` denote the salt concentrations in the liquid and solid phase of the beads respectively.
+Salt is considered to be inert, therefore either
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_0}{\mathrm{d} t} = 0
+ \end{aligned}
+
+is used if salt has one bound state, or salt can be used without a bound state.
+The parameter :math:`\gamma` describes the hydrophobicity and :math:`\beta` the ion-exchange characteristics.
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`mobile_phase_modulator_langmuir_config`.
diff --git a/v5.0.1/_sources/modelling/binding/multi_component_anti_langmuir.rst.txt b/v5.0.1/_sources/modelling/binding/multi_component_anti_langmuir.rst.txt
new file mode 100644
index 000000000..a544b5903
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/multi_component_anti_langmuir.rst.txt
@@ -0,0 +1,18 @@
+.. _multi_component_anti_langmuir_model:
+
+Multi Component Anti-Langmuir
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The Anti-Langmuir (or generalized Langmuir) binding model extends the Langmuir model (see Section :ref:`multi_component_langmuir_model`).
+The factor :math:`p_j \in \{ -1, 1 \}` determines the shape of the isotherm.
+For :math:`p_j = 1` (standard Langmuir) the chromatograms have sharp fronts and a dispersed tail (isotherm is concave).
+In case of the Anti-Langmuir (:math:`p_j = -1`) it is the other way around (isotherm is convex).
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} = k_{a,i} c_{p,i} q_{\text{max},i} \left( 1 - \sum_{j=0}^{N_{\text{comp}} - 1} p_j \frac{q_j}{q_{\text{max},j}} \right) - k_{d,i} q_i && i = 0, \dots, N_{\text{comp}} - 1.
+ \end{aligned}
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`multi_component_anti_langmuir_config`.
diff --git a/v5.0.1/_sources/modelling/binding/multi_component_bi_langmuir.rst.txt b/v5.0.1/_sources/modelling/binding/multi_component_bi_langmuir.rst.txt
new file mode 100644
index 000000000..261f25595
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/multi_component_bi_langmuir.rst.txt
@@ -0,0 +1,21 @@
+.. _multi_component_bi_langmuir_model:
+
+Multi Component Bi-Langmuir
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The multi component Bi-Langmuir model :cite:`Guiochon2006` adds :math:`M - 1` additional types of binding sites :math:`q_{i,j}` (:math:`0 \leq j \leq M - 1`) to the Langmuir model (see Section :ref:`multi_component_langmuir_model`) without allowing an exchange between the different sites :math:`q_{i,j}` and :math:`q_{i,k}` (:math:`k \neq j`).
+Therefore, there are no competitivity effects between the different types of binding sites and they have independent capacities.
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_{i,j}}{\mathrm{d} t} &= k_{a,i}^{(j)}\: c_{p,i}\: q_{\text{max},i}^{(j)} \left( 1 - \sum_{k=0}^{N_{\text{comp}} - 1} \frac{q_{k,j}}{q_{\text{max},k}^{(j)}}\right) - k_{d,i}^{(j)} q_{i,j} & i = 0, \dots, N_{\text{comp}} - 1, \: j = 0, \dots, M - 1.% (0 \leq i \leq N_{\text{comp}} - 1, \: 0 \leq j \leq M - 1).
+ \end{aligned}
+
+Note that all binding components must have exactly the same number of binding site types :math:`M \geq 1`.
+See the Section :ref:`multi_component_langmuir_model`.
+
+Originally, the Bi-Langmuir model is limited to two different binding site types.
+Here, the model has been extended to arbitrary many binding site types.
+
+For more information on model parameters required to define in CADET file format, see :ref:`multi_component_bi_langmuir_config`.
diff --git a/v5.0.1/_sources/modelling/binding/multi_component_bi_langmuir_ldf.rst.txt b/v5.0.1/_sources/modelling/binding/multi_component_bi_langmuir_ldf.rst.txt
new file mode 100644
index 000000000..090a9b3d6
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/multi_component_bi_langmuir_ldf.rst.txt
@@ -0,0 +1,15 @@
+.. _multi_component_bi_langmuir_ldf_model:
+
+Multi Component Bi-Langmuir LDF
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This a linear driving force model variant of the :ref:`multi_component_bi_langmuir_model` model.
+It is based on the equilibrium concentration :math:`q^*` for a given liquid phase concentration :math:`c` (see also :ref:`ldf_model`).
+
+.. math::
+ \begin{aligned}
+ q_{i,j}^*=\frac{q_{m,i,j} k_{eq,i,j} c_i}{1 + \sum_{k=1}^{N_{comp}}{k_{eq,k,j} c_k}} && i = 0, \dots, N_{\text{comp}} - 1, \: j = 0, \dots, M - 1.% (0 \leq i \leq N_{\text{comp}} - 1, \: 0 \leq j \leq M - 1).
+ \end{aligned}
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`multi_component_bi_langmuir_ldf_config`.
diff --git a/v5.0.1/_sources/modelling/binding/multi_component_colloidal.rst.txt b/v5.0.1/_sources/modelling/binding/multi_component_colloidal.rst.txt
new file mode 100644
index 000000000..c0ec0d40c
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/multi_component_colloidal.rst.txt
@@ -0,0 +1,77 @@
+.. _multi_component_colloidal_model:
+
+Multi Component Colloidal
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The colloidal isotherm assumes that adsorbed protein molecules are evenly distributed in a hexagonal arrangement at equilibrium, with the coverage varying via adjustment of the lattice size :cite:`Xu2009`.
+Protein-surface interactions are captured in a parameter :math:`K_{e}`.
+The surface coverage is modulated at higher coverage, described by a Yukawa potential.
+The Yukawa constant :math:`b_{pp}` characterizes protein-protein interactions.
+Since these are long-ranged, they are assumed to be primarily electrostatic for ion-exchange chromatography, with the range of interactions determined by the Debye parameter, :math:`\kappa`.
+
+.. math::
+ \begin{aligned}
+ \frac{{dq}_{i}}{dt} = & k_{kin,i} \left( c_{p,i} - c_{p,i}^\star \right)
+ \quad
+ i = 0, \dots, N_{comp} - 1,
+ \\
+ c_{p,i}^\star = & q_{i} \exp \Biggl[ \frac{n\left( 3 + \kappa R \right)}{4 q_{tot}} \sum_{j=0}^{N_{bound}} {q_{j} \sqrt{b_{pp,i} b_{pp,j}}} \frac{r_{i} + r_{j}}{2R}
+ \exp \bigl[ - \kappa \left( R - \left( r_{i} + r_{j} \right) \right) \bigr] \\
+ &\phantom{q_{i} \exp \Biggl[} - ln \left(K_{e,i} \right) \Biggr],
+ \end{aligned}
+
+where :math:`n` is the coordination number describing the two-dimensional lattice agreement of protein molecules on the resin surface (:math:`n=6` for hexagonal arrangement).
+:math:`r_{i}` is the radius of the protein, and :math:`K_{kin}` is the kinetic rate of adsorption.
+
+
+For the surface coverage factor :math:`R`, the following equation is used:
+
+.. math::
+
+ R = \sqrt{\frac{2 \phi}{N_{A} \cdot 10^{23} \cdot \sqrt{3} \cdot q_{tot}}},
+
+where :math:`\phi` is the phase ratio (surface area/solid phase volume), :math:`N_{A}` is Avogadro's number, and with
+
+.. math::
+
+ q_{tot} = \sum q_{i}.
+
+
+The screening term :math:`\kappa` is a Debye parameter based on the ideal colloidal phase behavior of the protein.
+In the case of ion exchange chromatography, this is the inverse of the Debye length.
+For other interaction mechanisms, this term can also be used to describe protein-protein interactions in general:
+
+.. math::
+
+ \kappa = \frac{1}{\kappa_f {c_{p,0}}^{\kappa_{ef}} + \kappa_{c}}.
+
+:math:`\kappa_{c}`, :math:`\kappa_{ef}`, and :math:`\kappa_{f}` are fitting constants which can be used to custom define the protein-protein interaction behavior based on additives in the mobile phase.
+:math:`c_{p,0}` is the total ionic strength, represented by the first component (non-binding pseudo component).
+
+Also the terms for protein-resin interaction, :math:`K_{e,i}`, and protein-protein interaction, :math:`b_{pp,i}`, are varied as a function of the ionic strength.
+
+.. math::
+
+ ln \left( K_{e, i} \right) &= k_{a,i} {c_{p, 0}}^{-k_{b,i}} + k_{c,i} \exp \left( k_{d,i} c_{p,0} \right) \\
+ b_{pp,i} &= b_{a,i} {c_{p,0}}^{b_{b,i}} + b_{c,i} \exp \left( b_{d,i} c_{p,0} \right),
+
+Optionally, they can also be varied as a function of the pH, then represented by the second component (non-binding pseudo component, :math:`c_{p,1}`).
+
+.. math::
+
+ ln \left( K_{e, i} \right) &= {c_{p,1}}^{k_{e,i}} \left( k_{a,i} {c_{p, 0}}^{-k_{b,i}} + k_{c,i} \exp \left( k_{d,i} c_{p,0} \right) \right) \\
+ b_{pp,i} &= {c_{p,1}}^{b_{e,i}} \left( b_{a,i} {c_{p,0}}^{b_{b,i}} + b_{c,i} \exp \left( b_{d,i} c_{p,0} \right) \right),
+
+where :math:`k_{a-e}`, :math:`b_{a-e}` are fitting constants.
+
+
+Because the model becomes mathematically singular at zero concentration, the original equation is replaced by its mathematical limit below a threshold concentration :math:`c_\epsilon > 0`.
+
+.. math::
+
+ \frac{{dq}_{i}}{dt} = k_{kin,i} \left(c_{p,i} - q_{i} \cdot \exp \left[ - ln \left( K_{e,i} \right) \right] \right).
+
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`multi_component_colloidal_config`.
+
diff --git a/v5.0.1/_sources/modelling/binding/multi_component_langmuir.rst.txt b/v5.0.1/_sources/modelling/binding/multi_component_langmuir.rst.txt
new file mode 100644
index 000000000..f98b758d3
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/multi_component_langmuir.rst.txt
@@ -0,0 +1,16 @@
+.. _multi_component_langmuir_model:
+
+Multi Component Langmuir
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The Langmuir binding model includes a saturation term and takes into account the capacity of the resin :cite:`Langmuir1916,Guiochon2006`.
+All components compete for the same binding sites.
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} = k_{a,i}\: c_{p,i}\: q_{\text{max},i} \left( 1 - \sum_{j=0}^{N_{\text{comp}} - 1} \frac{q_j}{q_{\text{max},j}} \right) - k_{d,i} q_i && i = 0, \dots, N_{\text{comp}} - 1.
+ \end{aligned}
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`multi_component_langmuir_config`.
diff --git a/v5.0.1/_sources/modelling/binding/multi_component_langmuir_ldf.rst.txt b/v5.0.1/_sources/modelling/binding/multi_component_langmuir_ldf.rst.txt
new file mode 100644
index 000000000..6c0c99032
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/multi_component_langmuir_ldf.rst.txt
@@ -0,0 +1,15 @@
+.. _multi_component_langmuir_ldf_model:
+
+Multi Component Langmuir LDF
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This a linear driving force model variant of the :ref:`multi_component_langmuir_model` model.
+It is based on the equilibrium concentration :math:`q^*` for a given liquid phase concentration :math:`c` (see also :ref:`ldf_model`).
+
+.. math::
+
+ \begin{aligned}
+ q_i^*=\frac{q_{m,i} k_{eq,i} c_i}{1 + \sum_{j=1}^{n_{comp}}{k_{eq,j} c_j}} && i = 0, \dots, N_{\text{comp}} - 1.
+ \end{aligned}
+
+For more information on model parameters required to define in CADET file format, see :ref:`multi_component_langmuir_ldf_config`.
diff --git a/v5.0.1/_sources/modelling/binding/multi_component_langmuir_ldf_liquid_phase.rst.txt b/v5.0.1/_sources/modelling/binding/multi_component_langmuir_ldf_liquid_phase.rst.txt
new file mode 100644
index 000000000..f1f4b9403
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/multi_component_langmuir_ldf_liquid_phase.rst.txt
@@ -0,0 +1,16 @@
+.. _multi_component_langmuir_ldf_liquid_phase_model:
+
+Multi Component Langmuir LDF Liquid Phase
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This a linear driving force model variant of the :ref:`multi_component_langmuir_model` model.
+It is based on the equilibrium concentration :math:`c^*` for a given solid phase concentration :math:`q` (see also :ref:`ldf_model`).
+
+.. math::
+
+ \begin{aligned}
+ c_i^*=\frac{q_{i}}{k_{eq,i} q_{m,i} \left(1 - \sum_{j=1}^{N_{\text{comp}}} \frac{q_j}{q_{m,j}}\right) } && i = 0, \dots, N_{\text{comp}} - 1.
+ \end{aligned}
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`multi_component_langmuir_ldf_liquid_phase_config`.
diff --git a/v5.0.1/_sources/modelling/binding/multi_component_spreading.rst.txt b/v5.0.1/_sources/modelling/binding/multi_component_spreading.rst.txt
new file mode 100644
index 000000000..1e3b93bc9
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/multi_component_spreading.rst.txt
@@ -0,0 +1,20 @@
+.. _multi_component_spreading_model:
+
+Multi Component Spreading
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The multi component spreading model adds a second bound state :math:`q_{i,2}` to the Langmuir model (see Section :ref:`multi_component_langmuir_model`) and allows the exchange between the two bound states :math:`q_{i,1}` and :math:`q_{i,2}`.
+In the spreading model a second state of the bound molecule (e.g., a different orientation on the surface or a different folding state) is added.
+The exchange of molecules between the two states is allowed and, since the molecules can potentially bind in both states at the same binding site, competitivity effects are present.
+This is different to the Bi-Langmuir model in which another type of binding sites is added and no exchange between the different bound states is considered (see Section :ref:`multi_component_bi_langmuir_model`).
+For all components :math:`i = 0, \dots, N_{\text{comp}} - 1` the equations are given by
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_{i,1}}{\mathrm{d} t} &= \left( k_a^A\: c_{p,i} - k_{12} q_{i,1} \right) q_{\text{max},i}^A \left( 1 - \sum_{j=0}^{N_{\text{comp}} - 1} \frac{q_j^A}{q_{\text{max},j}^A} - \sum_{j=0}^{N_{\text{comp}} - 1} \frac{q_j^B}{q_{\text{max},j}^B} \right) - k_d^A q_{i,1} + k_{21} q_{i,2}, \\
+ \frac{\mathrm{d} q_{i,2}}{\mathrm{d} t} &= \left( k_a^B\: c_{p,i} + k_{12} q_{i,1} \right) q_{\text{max},i}^A \left( 1 - \sum_{j=0}^{N_{\text{comp}} - 1} \frac{q_j^A}{q_{\text{max},j}^A} - \sum_{j=0}^{N_{\text{comp}} - 1} \frac{q_j^B}{q_{\text{max},j}^B} \right) - \left( k_d^B + k_{21} \right) q_{i,2}.
+ \end{aligned}
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`multi_component_spreading_config`.
diff --git a/v5.0.1/_sources/modelling/binding/multi_state_steric_mass_action.rst.txt b/v5.0.1/_sources/modelling/binding/multi_state_steric_mass_action.rst.txt
new file mode 100644
index 000000000..43e8d20fe
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/multi_state_steric_mass_action.rst.txt
@@ -0,0 +1,47 @@
+.. _multi_state_steric_mass_action_model:
+
+Multi-State Steric Mass Action
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The multi-state steric mass action model adds :math:`M_i-1` *additional* bound states :math:`q_{i,j}` (:math:`j = 0, \dots, M_i - 1`) for each component :math:`i` to the steric mass action model (see Section :ref:`steric_mass_action_model`) and allows the exchange between the different bound states :math:`q_{i,0}, \dots, q_{i,M-1}` of each component.
+In the multi-state SMA model a variable number of states of the bound molecule (e.g., different orientations on the surface, binding strength of tentacle adsorbers) is added which are more and more strongly bound, i.e.,
+
+.. math::
+
+ \begin{aligned}
+ \nu_{i,j} \leq \nu_{i,j+1} \qquad i = 1, \dots, N_{\text{comp}} - 1, \quad j = 0,\dots, M_i - 1.
+ \end{aligned}
+
+The exchange between the different states of each component is allowed and, since the molecules can potentially bind in all states at the same binding site, competitive effects are present.
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_{i,j}}{\mathrm{d} t} =& \phantom{+} k_{a,i}^{(j)} c_{p,i} \left(\frac{\bar{q}_0}{q_{\text{ref}}}\right)^{\nu_{i,j}} - k_{d,i}^{(j)}\: q_{i,j}\: \left(\frac{c_{p,0}}{c_{\text{ref}}}\right)^{\nu_{i,j}} \\
+ &- \sum_{\ell = 0}^{j-1} \underbrace{k^{(i)}_{j\ell}\: q_{i,j}\: \left(\frac{c_{p,0}}{c_{\text{ref}}}\right)^{\left(\nu_{i,j} - \nu_{i,\ell}\right)}}_{\text{to weak state}} - \sum_{\ell = j+1}^{M_i - 1} \underbrace{k^{(i)}_{j\ell}\: q_{i,j}\: \left(\frac{\bar{q}_0}{q_{\text{ref}}}\right)^{\left(\nu_{i,\ell} - \nu_{i,j}\right)}}_{\text{to strong state}} \\
+ &+ \sum_{\ell = 0}^{j-1} \underbrace{k^{(i)}_{\ell j}\: q_{i,\ell}\: \left(\frac{\bar{q}_0}{q_{\text{ref}}}\right)^{\left(\nu_{i,j} - \nu_{i,\ell}\right)}}_{\text{from weak state}} + \sum_{\ell = j+1}^{M_i - 1} \underbrace{k^{(i)}_{\ell j}\: q_{i,\ell}\: \left(\frac{c_{p,0}}{c_{\text{ref}}}\right)^{\left(\nu_{i,\ell} - \nu_{i,j}\right)}}_{\text{from strong state}} & \begin{aligned}
+ i &= 1, \dots, N_{\text{comp}} - 1, \\ j &= 0, \dots, M_i - 1, \end{aligned}
+ \end{aligned}
+
+where :math:`c_{p,0}` and :math:`q_0` denote the salt concentrations in the liquid and solid phase of the beads respectively.
+The number of available salt ions :math:`\bar{q}_0` is given by
+
+.. math::
+
+ \begin{aligned}
+ \bar{q}_0 = \Lambda - \sum_{j=1}^{N_{\text{comp}} - 1} \sum_{\ell=0}^{M_j - 1} \left( \nu_{j,\ell} + \sigma_{j,\ell} \right) q_{j,\ell}.
+ \end{aligned}
+
+A neutrality condition compensating for the missing equation for :math:`\frac{\mathrm{d} q_0}{\mathrm{d}t}` is required:
+
+.. math::
+
+ \begin{aligned}
+ q_0 = \Lambda - \sum_{j=1}^{N_{\text{comp}} - 1} \sum_{\ell=0}^{M_j - 1} \nu_{j,\ell} q_{j,\ell}.
+ \end{aligned}
+
+
+The concept of reference concentrations (:math:`c_{\text{ref}}` and :math:`q_{\text{ref}}`) is explained in the respective paragraph in Section :ref:`reference_concentrations`.
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`multi_state_steric_mass_action_config`.
diff --git a/v5.0.1/_sources/modelling/binding/saska.rst.txt b/v5.0.1/_sources/modelling/binding/saska.rst.txt
new file mode 100644
index 000000000..33a06989a
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/saska.rst.txt
@@ -0,0 +1,16 @@
+.. _saska_model:
+
+Saska
+~~~~~
+
+In this binding model an additional quadratic term is added to the linear model :cite:`Saska1992`.
+The quadratic term allows to take interactions of liquid phase components into account.
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} = H_i c_{p,i} + \sum_{j=0}^{N_{\text{comp}} - 1} k_{ij} c_{p,i} c_{p,j} - q_i && i = 0, \dots, N_{\text{comp}} - 1
+ \end{aligned}
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`saska_config`.
diff --git a/v5.0.1/_sources/modelling/binding/self_association.rst.txt b/v5.0.1/_sources/modelling/binding/self_association.rst.txt
new file mode 100644
index 000000000..233da1a72
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/self_association.rst.txt
@@ -0,0 +1,28 @@
+.. _self_association_model:
+
+Self Association
+~~~~~~~~~~~~~~~~
+
+This binding model is similar to the steric mass action model (see Section :ref:`steric_mass_action_model`) but is also capable of describing dimerization :cite:`Mollerup2008,Westerberg2012`.
+The dimerization, which is the immobilization of protein at some already bound protein, is also termed “self-association”.
+It is modeled by adding a quadratic (in :math:`c_{p,i}`) term to the adsorption part of the equation.
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} &= c_{p,i}\left( \frac{\bar{q}_0}{q_{\text{ref}}} \right)^{\nu_i} \left[ k_{a,i,1} + k_{a,i,2} c_{p,i} \right] - k_{d,i}\: q_i\: \left(\frac{c_{p,0}}{c_{\text{ref}}}\right)^{\nu_i} && i = 1, \dots, N_{\text{comp}} - 1, \\
+ q_0 &= \Lambda - \sum_{j=1}^{N_{\text{comp}} - 1} \nu_j q_j,
+ \end{aligned}
+
+where the number of available binding sites is given by
+
+.. math::
+
+ \begin{aligned}
+ \bar{q}_0 = \Lambda - \sum_{j=1}^{N_{\text{comp}} - 1} \left( \nu_j + \sigma_j \right) q_j = q_0 - \sum_{j=1}^{N_{\text{comp}} - 1} \sigma_j q_j.
+ \end{aligned}
+
+The concept of reference concentrations (:math:`c_{\text{ref}}` and :math:`q_{\text{ref}}`) is explained in the respective paragraph in Section :ref:`reference_concentrations`.
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`self_association_config`.
diff --git a/v5.0.1/_sources/modelling/binding/simplified_multi_state_steric_mass_action.rst.txt b/v5.0.1/_sources/modelling/binding/simplified_multi_state_steric_mass_action.rst.txt
new file mode 100644
index 000000000..479714240
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/simplified_multi_state_steric_mass_action.rst.txt
@@ -0,0 +1,29 @@
+.. _simplified_multi_state_steric_mass_action_model:
+
+Simplified Multi-State Steric Mass Action
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The simplified multi-state steric mass action is the same as the multi-state SMA model described above (see Section :ref:`multi_state_steric_mass_action_model`), but with additional assumptions:
+
+- Molecules are only exchanged between two adjacent states, that is, no transfer from state :math:`q_{i,1}` to state :math:`q_{i,3}` is allowed.
+
+- Characteristic charge :math:`\nu_{i,j}` and shielding factor :math:`\sigma_{i,j}` only depend on the index of the state :math:`j`.
+
+Thus, the exchange parameters :math:`k^{(i)}_{j\ell}`, the characteristic charge :math:`\nu_{i,j}`, and the shielding :math:`\sigma_{i,j}` can be parameterized with few degrees of freedom.
+For all :math:`i = 1,\dots,N_{\text{comp}} - 1` and :math:`j,\ell = 0,\dots,M_i - 1` let
+
+.. math::
+
+ \begin{aligned}
+ k^{(i)}_{j\ell} &= \begin{cases}
+ 0, & \text{for } \left\lvert j-\ell\right\rvert \neq 1 \\
+ K^{(i)}_{ws} + j K^{(i)}_{ws,\text{lin}} - K^{(i)}_{ws,\text{quad}} j(j - M_i+2), & \text{for } \ell = j+1 \\
+ K^{(i)}_{sw} + \ell K^{(i)}_{sw,\text{lin}} - K^{(i)}_{sw,\text{quad}} \ell(\ell - M_i+2), & \text{for } \ell = j-1, \end{cases}\\
+ \nu_{i,j} &= \nu_{\text{min},i} + \frac{j}{M_i-1} \left( \nu_{\text{max},i} - \nu_{\text{min},i} \right) - \nu_{\text{quad},i} j (j-M_i+1), \\
+ \sigma_{i,j} &= \sigma_{\text{min},i} + \frac{j}{M_i-1} \left( \sigma_{\text{max},i} - \sigma_{\text{min},i} \right) - \sigma_{\text{quad},i} j (j-M_i+1).
+ \end{aligned}
+
+Note that the characteristic charge :math:`\nu_{i,j}` has to be monotonically non-decreasing in the second index :math:`j` and all other rates and the steric factor :math:`\sigma_{i,j}` have to be non-negative.
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`simplified_multi_state_steric_mass_action_config`.
diff --git a/v5.0.1/_sources/modelling/binding/steric_mass_action.rst.txt b/v5.0.1/_sources/modelling/binding/steric_mass_action.rst.txt
new file mode 100644
index 000000000..16c82f388
--- /dev/null
+++ b/v5.0.1/_sources/modelling/binding/steric_mass_action.rst.txt
@@ -0,0 +1,39 @@
+.. _steric_mass_action_model:
+
+Steric Mass Action
+~~~~~~~~~~~~~~~~~~
+
+The steric mass action model takes charges of the molecules into account :cite:`Brooks1992` and is, thus, often used in ion-exchange chromatography.
+Each component has a characteristic charge :math:`\nu` that determines the number of available binding sites :math:`\Lambda` (ionic capacity) used up by a molecule.
+Due to the molecule’s shape, some additional binding sites (steric shielding factor :math:`\sigma`) may be shielded from other molecules and are not available for binding.
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d} q_i}{\mathrm{d} t} = k_{a,i} c_{p,i}\left( \frac{\bar{q}_0 }{q_{\text{ref}}} \right)^{\nu_i} - k_{d,i}\: q_i\: \left(\frac{c_{p,0}}{c_{\text{ref}}}\right)^{\nu_i} && i = 1, \dots, N_{\text{comp}} - 1,
+ \end{aligned}
+
+where :math:`c_{p,0}` and :math:`q_0` denote the salt concentrations in the liquid and solid phase of the beads, respectively.
+The number of free binding sites
+
+.. math::
+
+ \begin{aligned}
+ \bar{q}_0 = \Lambda - \sum_{j=1}^{N_{\text{comp}} - 1} \left( \nu_j + \sigma_j \right) q_j = q_0 - \sum_{j=1}^{N_{\text{comp}} - 1} \sigma_j q_j
+ \end{aligned}
+
+is calculated from the number of bound counter ions :math:`q_0` by taking steric shielding into account.
+In turn, the number of bound counter ions :math:`q_0` (electro-neutrality condition) is given by
+
+.. math::
+
+ \begin{aligned}
+ q_0 = \Lambda - \sum_{j=1}^{N_{\text{comp}} - 1} \nu_j q_j,
+ \end{aligned}
+
+which also compensates for the missing equation for :math:`\frac{\mathrm{d} q_0}{\mathrm{d}t}`.
+
+The concept of reference concentrations (:math:`c_{\text{ref}}` and :math:`q_{\text{ref}}`) is explained in the respective paragraph in Section :ref:`reference_concentrations`.
+
+
+For more information on model parameters required to define in CADET file format, see :ref:`steric_mass_action_config`.
diff --git a/v5.0.1/_sources/modelling/crystallization.rst.txt b/v5.0.1/_sources/modelling/crystallization.rst.txt
new file mode 100644
index 000000000..82c276f6b
--- /dev/null
+++ b/v5.0.1/_sources/modelling/crystallization.rst.txt
@@ -0,0 +1,174 @@
+.. _pbm_model:
+
+Population Balance Models
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The population balance model (PBM) is given by a particle-number continuity equation which describes the evolution of the number density :math:`n` of the particles over time :math:`t` and with respect to a so-called internal coordinate :math:`x` and external coordinate :math:`z`.
+The internal coordinate can be chosen as any characteristic property of the particles such as the particle size or volume.
+The external coordinate can be a characteristic dimension of the reactor itself, including its axial length.
+
+In CADET, we chose particle size and axial coordinate as the internal and external coodinate respectively.
+The PBM in CADET is implemented so that it can be used in any unit operation that supports reactions.
+Typical applications consider crystallization in a CSTR or, to model continuous processes, in a Dispersive Plug-Flow Reactor (DPFR), which is described by the LRM without solid phase.
+
+In the following, we give a brief overview on the modelling equations, for more information on the PBM as implemented in CADET, please refer to :cite:`zhang2024solving`.
+
+.. figure:: PBM_Part_I.png
+
+ Nucleation, growth and growth rate dispersion in PBM. Note that dispersion is used to model (random) variance in growth speed, not the reduction of particle size, which is feasible for a convection dominated process.
+
+Population Balance Model in a CSTR
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+We assume a well-mixed tank and choose the particle size :math:`x\in (x_c, \infty)` as the internal coodinate, with :math:`x_c>0` being the minimal particle size considered.
+The corresponding PBM is given as
+
+.. math::
+
+ \begin{aligned}
+ \frac{\partial (n V)}{\partial t} = F_{in}n_{in} - F_{out}n - V \left( \frac{\partial (v_{G}n)}{\partial x} - D_g \frac{\partial^2 n}{\partial x^2} - B_0 \delta (x-x_c) \right),
+ \end{aligned}
+
+where :math:`F_{in}, F_{out}\in \mathbb{R}^+` are the volumetric inflow and outflow rates, :math:`V\in\mathbb{R}^+` is the reactor volume,
+:math:`n(t, x)\colon [0, T_\text{end}] \times (x_c, \infty) \mapsto \mathbb{R}^+` is the number density distribution,
+:math:`n_{in}\in\mathbb{R}^+` is the number density distribution of the inlet feed, :math:`v_{G}\in\mathbb{R}^+` is the particle growth rate,
+:math:`D_g\in\mathbb{R}^+` is the growth dispersion rate.
+
+The boundary conditions are given by the regularity boundary condition
+
+.. math::
+ :label: RegularityBC
+
+ \begin{aligned}
+ \left. \left( nv_{G} - D_g \frac{\partial n}{\partial x} \right) \right|_{x \to \infty}=0,
+ \end{aligned}
+
+and the nucleation kinetics boundary condition
+
+.. math::
+ :label: NucleationBC
+
+ \begin{aligned}
+ \left. \left( nv_{G}-D_g \frac{\partial n}{\partial x} \right)\right|_{x=x_c} = B_0,
+ \end{aligned}
+
+where :math:`B_0\in\mathbb{R}^+` is the nucleation kinetics factor representing particle nucleations of size :math:`x_c\in\mathbb{R}^+`.
+
+The model is complemented by the following mass balance equation which accounts for the mass transfer between the particle phase and the solute phase
+
+.. math::
+
+ \begin{aligned}
+ \frac{\partial (cV)}{\partial t} = F_{in}c_{in} - F_{out}c -\rho k_v V \left( B_0x^3_c + 3\int_{x_c}^{\infty} v_{G}n\ x^2 \;\mathrm{d}x \right),
+ \end{aligned}
+
+where :math:`c(t)\colon [0, T_\text{end}] \mapsto \mathbb{R}^+` is the solute concentration in the bulk phase, :math:`c_{in}\in\mathbb{R}^+` is the inlet solute mass concentration, :math:`\rho > 0` is the nuclei mass density and :math:`k_v > 0` is the volumetric shape factor of the particles.
+
+Evolution of the reactor's volume is governed by
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d}V}{\mathrm{d}t} &= F_{\text{in}} - F_{\text{out}}.
+ \end{aligned}
+
+
+Population Balance Model in a DPFR
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The PBM can also be formulated for a DPFR to model continuous processes.
+That is, we choose the axial position within a DPFR as the external coordinate :math:`z\in[0, L]` and formulate the :math:`2D` PBM
+
+.. math::
+
+ \begin{aligned}
+ \frac{\partial n}{\partial t} = -v_\text{ax} \frac{\partial n}{\partial z} +D_{ax} \frac{\partial^2 n}{\partial z^2} - \frac{\partial (v_{G}n)}{\partial x} + D_g \frac{\partial^2 n}{\partial x^2},
+ \end{aligned}
+
+where :math:`n(t, x, z)\colon [0, T_\text{end}] \times (x_c, \infty) \times [0, L] \mapsto \mathbb{R}^+` is the number density distribution,
+:math:`v_\text{ax}\in\mathbb{R}^+` is the axial velocity and :math:`D_{ax}\in\mathbb{R}^+` is the axial dispersion coefficient.
+
+Boundary conditions for the internal coordinate are again given by Eq. :eq:`RegularityBC` and Eq. :eq:`NucleationBC`.
+
+For the external coordinate :math:`z`, Danckwerts boundary conditions are applied:
+
+.. math::
+
+ \begin{aligned}
+ \left. \left( n v_\text{ax}-D_{ax}\frac{\partial n}{\partial z} \right) \right|_{z=0} = v_\text{ax} n_{in,x}, \qquad \left.\frac{\partial n}{\partial z}\right|_{z=L}=0.
+ \end{aligned}
+
+The mass balance equation for the solute :math:`c(t, z)\colon [0,T-\text{end}] \times [0,L] \mapsto \mathbb{R}^+` is given by
+
+.. math::
+
+ \begin{aligned}
+ \frac{\partial c}{\partial t} = -v_\text{ax} \frac{\partial c}{\partial z} +D_{ax} \frac{\partial^2 c}{\partial z^2} -\rho k_v \left( B_0x^3_c + 3\int_{x_c}^{\infty} v_{G}n x^2 \;\mathrm{d}x \right).
+ \end{aligned}
+
+As for the particle phase, the solute mass concentration subjects to the Danckwerts boundary conditions
+
+.. math::
+
+ \begin{aligned}
+ \left.\left( c v_\text{ax}-D_{ax}\frac{\partial c}{\partial z} \right) \right|_{z=0} = v_\text{ax} c_{in}, \qquad \left.\frac{\partial c}{\partial z}\right|_{z=L}=0.
+ \end{aligned}
+
+
+Constitutive equations
+^^^^^^^^^^^^^^^^^^^^^^
+
+Constitutive equations describe the kinetic processes in the governing equations. The relative supersaturation :math:`s>0` is:
+
+.. math::
+
+ \begin{aligned}
+ s=\frac{c-c_{eq}}{c_{eq}},
+ \end{aligned}
+
+where :math:`c_{eq}>0` is the solute solubility in the solvent.
+The nucleation kinetics can be split into primary and secondary nucleation:
+
+.. math::
+
+ \begin{aligned}
+ B_0 = B_p + B_s,
+ \end{aligned}
+
+Which are in turn defined by the following constitutive equations.
+An empirical equation for primary nucleation is given by:
+
+.. math::
+
+ \begin{aligned}
+ B_p=k_ps^u,
+ \end{aligned}
+
+where :math:`k_p\in\mathbb{R}^+` is the primary nucleation rate constant and :math:`u\in\mathbb{R}^+` is a constant.
+An empirical power-law expression is used for the secondary nucleation:
+
+.. math::
+
+ \begin{aligned}
+ B_s=k_bs^bM^k,
+ \end{aligned}
+
+where :math:`k_b\in\mathbb{R}^+` is the secondary nucleation rate constant, :math:`b\in\mathbb{R}^+` and :math:`k\in\mathbb{R}^+` are system-related parameters and :math:`M\in\mathbb{R}^+` is the suspension density defined as
+
+.. math::
+
+ \begin{aligned}
+ M=k_v\rho\int_{0}^{\infty}n\ x^3\;\mathrm{d}x.
+ \end{aligned}
+
+The following expression for the growth rate is implemented:
+
+.. math::
+
+ \begin{aligned}
+ v_{G}=k_gs^g(a+\gamma x^p),
+ \end{aligned}
+
+where :math:`k_g\in\mathbb{R}^+` is the growth rate constant, :math:`\gamma\in\mathbb{R}^+` quantifies the size dependence, and :math:`g, a, p\in\mathbb{R}^+` are system-related constants.
+
+For information on model parameters and how to specify the model interface, see :ref:`pbm_config`.
diff --git a/v5.0.1/_sources/modelling/equations.rst.txt b/v5.0.1/_sources/modelling/equations.rst.txt
new file mode 100644
index 000000000..0cf107e21
--- /dev/null
+++ b/v5.0.1/_sources/modelling/equations.rst.txt
@@ -0,0 +1,18 @@
+.. File for the substitution for the declaration in the equations of unit operations.
+
+.. -----------------------------------------------------------components ------------------------------------------------------------------------------------------------------------
+.. |component_li| replace:: :math:`c^\ell_i` concentration of component :math:`i` in the liquid phase.
+.. |component_sij| replace:: :math:`c^s_{j,i,m_{j,i}}` concentration of component :math:`i` in the solid phase of particle type :math:`j` and particle type :math:`m_{j,i}`.
+
+.. ----------------------------------------------------------- flow ------------------------------------------------------------------------------------------------------------
+.. |flow_in_out| replace:: :math:`F_{\text{in}}` and :math:`F_{\text{out}}` flow rates of liquid into and out of the tank.
+
+.. ----------------------------------------------------------- reaction ------------------------------------------------------------------------------------------------------------
+.. |reaction| replace:: :math:`f_{\text{react},i}^l\left( c^\ell \right)` and :math:`f_{\text{react},j,i}^s\left( c^\ell, c_j^s \right)` reaction rates of component :math:`i` in the liquid and solid phase.
+.. |reaction_ads| replace:: :math:`f_{\text{ads},j}\left( c^\ell, c^s_j\right)` adsorption rate of component :math:`i` in the solid phase of particle type :math:`j` .
+.. -----------------------------------------------------------volume_fac ------------------------------------------------------------------------------------------------------------
+.. |volume_fac_pat| replace:: :math:`d_j` volume fraction of the different solid volume in the tank.
+
+.. -----------------------------------------------------------volume ------------------------------------------------------------------------------------------------------------
+.. |volume_liquid| replace:: :math:`V^{\ell}` liquid volume in the tank.
+.. |volume_solid| replace:: :math:`V^{s}` solid volume in the tank.
diff --git a/v5.0.1/_sources/modelling/index.rst.txt b/v5.0.1/_sources/modelling/index.rst.txt
new file mode 100644
index 000000000..8f0beb9b0
--- /dev/null
+++ b/v5.0.1/_sources/modelling/index.rst.txt
@@ -0,0 +1,13 @@
+.. _modelling:
+
+Modelling
+=========
+
+This section gives complete information about the supported unit operations, binding and reaction models, and creating a network among all the unit operations in CADET. For details on file format specifications related to define each unit operation in CADET, see section :ref:`file_format`.
+
+.. toctree::
+ unit_operations/index
+ binding/index
+ reaction/index
+ networks
+ crystallization
diff --git a/v5.0.1/_sources/modelling/networks.rst.txt b/v5.0.1/_sources/modelling/networks.rst.txt
new file mode 100644
index 000000000..d613a64e7
--- /dev/null
+++ b/v5.0.1/_sources/modelling/networks.rst.txt
@@ -0,0 +1,148 @@
+.. _networks:
+
+Networks of unit operations
+===========================
+
+Unit operation models can be composed into a network or graph, in which a node represents a unit operation and an edge denotes a connection between two unit operations.
+When utilized to full extent, this allows the simulation of complicated setups and processes (e.g., SMB, MCSGP).
+A more simple use case is the addition of plug flows and stirred tanks up- and downstream of a column in order to account for dead volume and additional dispersion from the tubing.
+
+In a network, outlet ports of unit operations can be connected to any number of inlet ports of unit operations.
+Even direct cycles, where an outlet port of a unit operation is connected to its own inlet, are possible.
+A unit operation does not have to possess both inlet and outlet, but it has to have at least one of them.
+Pseudo unit operations such as inlet and outlet serve as sources and sinks for the network.
+However, the latter is not strictly required as any terminal node (i.e., a unit operation that possesses an outlet but does not have an outgoing connection) serves as a sink.
+
+Each connection between two unit operation ports (i.e., an edge in the graph) is equipped with a volumetric flow rate that determines the mass flow from source to target port.
+These flow rates are used to determine the weight of the different incoming feeds at a unit operation’s inlet port.
+Some unit operations can infer their internal flow rate (e.g., interstitial velocity) from their total incoming volumetric flow rate.
+In general, the mass balance at a unit operation has to be closed, except for unit operations that act as source or sink in the network and variable volume units (e.g., stirred tanks).
+
+The network of unit operations uses “connection”-variables :math:`c_{\text{con}}` to connect the different unit operation ports with each other.
+The inlet port variables :math:`c_{\text{in},n,k}` of unit operation :math:`n` are attached to :math:`c_{\text{con},n}` via
+
+.. math::
+ :label: NetworkInletConnection
+
+ \begin{aligned}
+ c_{\text{in},n,k,i} &= c_{\text{con},n,k,i}, \qquad k = 1, \dots, N_{\text{port},\text{in},n},\quad i = 1, \dots, N_{\text{comp},n}.
+ \end{aligned}
+
+While :math:`N_{\text{port},\text{in},n}` denotes the number of inlet ports of unit operation :math:`n`, the number of outlet ports is given by :math:`N_{\text{port},\text{out},n}`.
+The connection variables :math:`c_{\text{con},n,k,i}` collect all inflows of component :math:`i` into port :math:`k` of unit operation :math:`n`:
+
+.. math::
+ :label: NetworkConnection
+
+ \begin{aligned}
+ c_{\text{con},n,k,i} &= \frac{\sum_{m=1}^{N_{\text{units}}} \sum_{\ell = 1}^{N_{\text{port},\text{out},n}} \sum_{j = 1}^{N_{\text{comp},m}} S_{(n,k,i),(m,\ell,j)} Q_{m,\ell} c_{\text{out},m,\ell,j}}{\sum_{m=1}^{N_{\text{units}}} \sum_{\ell=1}^{N_{\text{port},\text{out},m}} \hat{S}_{(n,k),(m,\ell)} Q_{m,\ell} },
+ \end{aligned}
+
+where :math:`F_{m,\ell}` denotes the volumetric flow rate from outlet port :math:`\ell` of unit operation :math:`m`, :math:`S_{(n,k,i),(m,\ell,j)} \in \{0, 1\}` is a connection matrix indicating whether component :math:`i` at outlet port :math:`k` of unit operation :math:`n` is connected to component :math:`j` at inlet port :math:`\ell` of unit operation :math:`m`, and :math:`\hat{S}_{(n,k),(m,\ell)} \in \{0, 1\}` is another connection matrix indicating whether outlet port :math:`k` of unit operation :math:`n` is connected to inlet port :math:`\ell` of unit operation :math:`m`, that is
+
+.. math::
+
+ \begin{aligned}
+ \hat{S}_{(n,k),(m,\ell)} = \begin{cases}
+ 1 & \text{if } \sum_{i = 1}^{N_{\text{comp},n}} \sum_{j = 1}^{N_{\text{comp},m}} S_{(n,k,i),(m,\ell,j)} \geq 1, \\
+ 0 & \text{otherwise}. \end{cases}
+ \end{aligned}
+
+Note that for each unit operation the number of inlet ports may be different from the number of outlet ports.
+Hence, the mass balance of a single unit operation is taken with respect to all its ports combined.
+
+.. _MUOPNetworkConfig:
+
+Specification of network connections
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The connections between the different unit operations in the network are specified by a table.
+There are two table formats:
+
+- The long format includes seven columns.
+ The first two columns specify source and destination unit operation id.
+ The next two columns give source and destination port indices.
+ Source and destination component indices are given by the following two columns.
+ Finally, the seventh column specifies the volumetric flow rate of this connection (see :ref:`FFModelConnectionSwitch`).
+
+- The short format includes five columns.
+ The first two columns specify source and destination unit operation id.
+ Source and destination component indices are given by the following two columns.
+ Finally, the fifth column specifies the volumetric flow rate of this connection.
+ Here, the omitted port indices default to :math:`-1`, which connects all ports of the source unit operation to the corresponding ports of the target.
+
+By default, the short format is used (i.e., a table with five columns is expected).
+However, if a unit operation with multiple ports is present, a table with seven columns is required.
+The default format can be overruled by setting a field.
+
+With this setup, it is possible to connect single components of unit operations with each other yielding a maximum in flexibility.
+However, the predominant case is to connect all components of the source unit operations with their respective counterparts in the destination unit.
+This can easily be done by setting both component indices to :math:`-1` instead of writing a separate row for each component of the connection.
+The same setting (i.e., setting both port indices to :math:`-1`) can be used to connect all ports of one unit operation with all corresponding ports of another one.
+
+Note that in case of multiple rows for one connection between two unit operation ports (e.g., in case of separate component connections) the flow rate of the first row of that connection is used and all following flow rates are ignored.
+Consequently, there can only be one flow rate for a connection between two unit operations regardless of which components are connected.
+
+The connection table is expected in row-major storage format (i.e., the rows are appended to one long array).
+
+.. _MUOPNetworkValveSwitches:
+
+Valve switches
+~~~~~~~~~~~~~~
+
+The connectivity of the network can only change on a discontinuous section transition.
+Such a transition with changing connectivity is referred to as valve switch and the connectivity itself as valve configuration.
+
+A list of valve configurations with at least one entry is required.
+Each valve configuration consists of a network connectivity table as described in Section :ref:`MUOPNetworkConfig` and a section index.
+The latter denotes the section in which the connectivity table becomes active.
+Hence, the one required (i.e., the first) entry must have a section index of :math:`0` denoting the initial connectivity.
+
+Note that the section index has to be monotonically increasing throughout the list of valve configurations.
+See Tables :ref:`FFModelSystemConnections` and :ref:`FFModelConnectionSwitch`.
+
+
+.. _MUOPNetworkDynamicFlowRates:
+
+Dynamic flow rates
+~~~~~~~~~~~~~~~~~~
+
+The volumetric flow rates may vary over time while the valve configuration is active.
+The rates are assumed to be cubic polynomials,
+
+.. math::
+
+ Q = Q_0 + Q_1(t - t_s) + Q_2(t-t_s)^2 + Q_3(t-t_s)^3,
+
+where :math:`t_s` is the beginning of the time section that triggers the valve switch.
+
+Note that the denominator in Eq. :eq:`NetworkConnection` must always be positive.
+That is, the flow rate coefficients have to be chosen such that the flow into every connected inlet port is strictly positive at all times.
+
+
+.. _MUOPNetworkLinearSolver:
+
+Solution of the linear systems
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each time step in the simulation requires the solution of a nonlinear system Eq. :eq:`BDFNonlinSystem` (see Sec. :ref:`SimTimeIntegration`).
+The nonlinear problem is solved by a Newton iteration, which, in turn, requires the solution of a linear system that essentially consists of the Jacobians of the unit operations and some coupling matrices from Eqs. :eq:`NetworkInletConnection` and :eq:`NetworkConnection`.
+
+These linear systems are either solved in parallel or sequentially. The parallel method first solves each unit operation (in parallel) to compute the solution at its outlet.
+Using these values, the inlets are adjusted and the unit operations are solved again.
+This is iterated until the system is fully solved.
+
+In contrast, the sequential method first determines an ordering of the unit operations such that each unit only receives inflow from the previous units in the ordering.
+Such an ordering requires an acyclic graph of unit operations.
+Finally, the linear system is solved by solving the unit operations in the ordering determined above.
+Before a unit is solved, its inlet is calculated from the outlets of the previously solved units.
+This means, the system is solved from system inlets to system outlets.
+
+The parallel method works regardless of the network topology (i.e., cycles in the graph), but requires to solve each unit operation at least twice.
+The sequential method solvs each unit exactly once, but is restricted to acyclic networks and works best for small graphs.
+By default, CADET uses a heuristic to select an appropriate solution method.
+This default can be overridden by a flag (see Table :ref:`FFModelSolver`).
+
+The solution method is selected for each valve switch individually.
+If some network configurations contain cycles, the parallel method is chosen for them regardless of the method used for the other configurations.
+
diff --git a/v5.0.1/_sources/modelling/reaction/index.rst.txt b/v5.0.1/_sources/modelling/reaction/index.rst.txt
new file mode 100644
index 000000000..172908182
--- /dev/null
+++ b/v5.0.1/_sources/modelling/reaction/index.rst.txt
@@ -0,0 +1,41 @@
+.. _reaction_models:
+
+Reaction models
+===============
+
+
+Reaction models describe the (net) fluxes :math:`f_{\mathrm{react}}` of a
+reaction mechanism.
+CADET features one reaction type:
+
+ - :ref:`mass_action_law_model` (most commonly used)
+ - :ref:`michaelis_menten_kinetics_model`
+
+
+.. _dependence-on-external-function_react:
+
+Dependence on external function
+-------------------------------
+
+A reaction model may depend on an external function or profile :math:`T\colon \left[ 0, T_{\mathrm{end}}\right] \times [0, L] \to \mathbb{R}`, where :math:`L` denotes the physical length of the unit operation, or :math:`T\colon \left[0, T_{\mathrm{end}}\right] \to \mathbb{R}` if the unit operation model has no axial length.
+By using an external profile, it is possible to account for effects that are not directly modeled in CADET (e.g., temperature).
+The dependence of each parameter is modeled by a polynomial of third degree.
+For example, the forward rate constant :math:`k_{\mathrm{fwd}}` is really given by
+
+.. math::
+
+ \begin{aligned}
+ k_{\mathrm{fwd}}(T) &= k_{\mathrm{fwd},3} T^3 + k_{\mathrm{fwd},2} T^2 + k_{\mathrm{fwd},1} T + k_{\mathrm{fwd},0}.
+ \end{aligned}
+
+While :math:`k_{\mathrm{fwd},0}` is set by the original parameter ``XXX_KFWD`` of the file format (``XXX`` being a placeholder for the reaction model), the parameters :math:`k_{\mathrm{fwd},3}`, :math:`k_{\mathrm{fwd},2}`, and :math:`k_{\mathrm{fwd},1}` are given by ``XXX_KFWD_TTT``, ``XXX_KFWD_TT``, and ``XXX_KFWD_T``, respectively.
+The identifier of the externally dependent reaction model is constructed from the original identifier by prepending ``EXT_`` (e.g., ``MASS_ACTION_LAW`` is changed into ``EXT_MASS_ACTION_LAW``).
+This pattern applies to all parameters and supporting reaction models.
+Note that the parameter units have to be adapted to the unit of the external profile by dividing with an appropriate power.
+
+Each parameter of the externally dependent reaction model can depend on a different external source.
+The 0-based indices of the external source for each parameter is given in the dataset ``EXTFUN``.
+By assigning only one index to ``EXTFUN``, all parameters use the same source.
+The ordering of the parameters in ``EXTFUN`` is given by the ordering in the file format specification.
+
+For the configuration of external function dependence and more information on model parameters required to define in CADET file format, see section :ref:`FFReaction`.
\ No newline at end of file
diff --git a/v5.0.1/_sources/modelling/reaction/mass_action_law.rst.txt b/v5.0.1/_sources/modelling/reaction/mass_action_law.rst.txt
new file mode 100644
index 000000000..79b25a400
--- /dev/null
+++ b/v5.0.1/_sources/modelling/reaction/mass_action_law.rst.txt
@@ -0,0 +1,108 @@
+.. _mass_action_law_model:
+
+Mass action law
+---------------
+
+The mass action law reaction model is suitable for most reactions.
+Note that the concentrations are directly used for calculating the fluxes.
+Hence, the model only holds for dilute solutions under the assumption of a well-stirred reaction vessel.
+These assumptions can be weakened by passing to the generalized mass action law, which uses chemical activities instead of concentrations.
+
+The mass action law states that the speed of a reaction is proportional to the product of the concentrations of their reactants.
+The net flux for component :math:`i` is given by
+
+.. math::
+
+ \begin{aligned}
+ f_{\mathrm{react},i}^l\left(c^l\right) &= \sum_{j=0}^{N_{\mathrm{react}}-1} s_{i,j}^l \varphi^l_j\left(c^l\right), \\
+ \varphi^l_j(c^l) &= k^l_{\mathrm{fwd},j} \prod_{\ell=0}^{N_{\mathrm{comp}}-1} \left(c^l_{\ell}\right)^{e^l_{\mathrm{fwd},\ell,j}} - k^l_{\mathrm{bwd},j} \prod_{\ell=0}^{N_{\mathrm{comp}}-1} \left(c^l_{\ell}\right)^{e^l_{\mathrm{bwd},\ell,j}},
+ \end{aligned}
+
+where :math:`S^l = (s^l_{i,j}) \in \mathbb{R}^{N_{\mathrm{comp}} \times N_{\mathrm{react}}}` is the stoichiometric matrix, :math:`\varphi^l_j(c)` is the net flux of reaction :math:`j`, and :math:`k^l_{\mathrm{fwd},j}` and :math:`k^l_{\mathrm{bwd},j}` are the rate constants.
+The matrices :math:`E^l_{\mathrm{fwd}} = (e^l_{\mathrm{fwd},\ell,j}) \in \mathbb{R}^{N_{\mathrm{comp}} \times N_{\mathrm{react}}}` and :math:`E^l_{\mathrm{bwd}} = (e^l_{\mathrm{bwd},\ell,j}) \in \mathbb{R}^{N_{\mathrm{comp}} \times N_{\mathrm{react}}}` are usually derived by the order of the reaction, that is,
+
+.. math::
+ :label: MRMassActionLawExpMatDefault
+
+ \begin{aligned}
+ e^l_{\mathrm{fwd},\ell,j} &= \max(0, -s^l_{\ell,j}), \\
+ e^l_{\mathrm{bwd},\ell,j} &= \max(0, s^l_{\ell,j}).
+ \end{aligned}
+
+However, these defaults can be changed by providing those matrices.
+
+In situations where both liquid and solid phase are present (e.g., in a bead), the respective other phase may act as a modifier in the net flux equation.
+For example, consider reactions in the liquid phase of a particle given by
+
+.. math::
+
+ \begin{aligned}
+ f_{\mathrm{react},i}^p\left(c^p, c^s\right) &= \sum_{j=0}^{N_{\mathrm{react}}-1} s_{i,j}^p \varphi^p_j\left(c^p, c^s\right),\end{aligned}
+
+where
+
+.. math::
+
+ \begin{split}
+ \varphi^p_j(c^p, c^s) = k^p_{\mathrm{fwd},j} &\left[\prod_{\ell=0}^{N_{\mathrm{comp}}-1} \left(c^p_{\ell}\right)^{e^p_{\mathrm{fwd},\ell,j}}\right] \left[\prod_{m=0}^{\sum_{i=0}^{N_{\mathrm{comp}}-1} N_{\mathrm{bnd},i}-1} \left(c^s_{m}\right)^{e^{ps}_{\mathrm{fwd},m,j}}\right] \\
+ - k^p_{\mathrm{bwd},j} &\left[\prod_{\ell=0}^{N_{\mathrm{comp}}-1} \left(c^p_{\ell}\right)^{e^p_{\mathrm{bwd},\ell,j}}\right] \left[\prod_{m=0}^{\sum_{i=0}^{N_{\mathrm{comp}}-1} N_{\mathrm{bnd},i}-1} \left(c^s_{m}\right)^{e^{ps}_{\mathrm{bwd},m,j}}\right].
+ \end{split}
+
+The forward and backward rates of the liquid phase particle reactions can be modified by a power of every bound state in the solid phase of the particle.
+The exponents of these powers are given by the matrices :math:`E^{ps}_{\mathrm{fwd}} = (e^{ps}_{\mathrm{fwd},m,j})` and :math:`E^{ps}_{\mathrm{bwd}} = (e^{ps}_{\mathrm{bwd},m,j})`, which are both of size :math:`(\sum_i N_{\mathrm{bnd},i}) \times N_{\mathrm{react}}`.
+Whereas the exponent matrices :math:`E^{p}_{\mathrm{fwd}}, E^{p}_{\mathrm{bwd}} \in \mathbb{R}^{N_{\mathrm{comp}} \times N_{\mathrm{react}}}` are initialized based on the stoichiometric matrix :math:`S^{p} \in \mathbb{R}^{N_{\mathrm{comp}} \times N_{\mathrm{react}}}`, see Eq.:eq:`MRMassActionLawExpMatDefault`, the exponent matrices :math:`E^{ps}_{\mathrm{fwd}}, E^{ps}_{\mathrm{bwd}}` of the modifier terms default to :math:`0`.
+
+Vice versa, the rates of solid phase reactions can be modified by liquid phase concentrations.
+The corresponding exponent matrices :math:`E^{sp}_{\mathrm{fwd}} = (e^{sp}_{\mathrm{fwd},\ell,j})` and :math:`E^{sp}_{\mathrm{bwd}} = (e^{sp}_{\mathrm{bwd},\ell,j})` are both of size :math:`N_{\mathrm{comp}} \times N_{\mathrm{react}}`.
+
+.. math::
+
+ \begin{aligned}
+ f_{\mathrm{react},i}^s\left(c^s, c^p\right) &= \sum_{j=0}^{N_{\mathrm{react}}-1} s_{i,j}^s \varphi^s_j\left(c^s, c^p\right),
+ \end{aligned}
+
+where
+
+.. math::
+
+ \begin{split}
+ \varphi^s_j(c^s, c^p) = k^s_{\mathrm{fwd},j} &\left[\prod_{m=0}^{\sum_{i=0}^{N_{\mathrm{comp}}-1} N_{\mathrm{bnd},i}-1} \left(c^s_{m}\right)^{e^{s}_{\mathrm{fwd},m,j}}\right] \left[\prod_{\ell=0}^{N_{\mathrm{comp}}-1} \left(c^p_{\ell}\right)^{e^{sp}_{\mathrm{fwd},\ell,j}}\right] \\
+ - k^p_{\mathrm{bwd},j} &\left[\prod_{m=0}^{\sum_{i=0}^{N_{\mathrm{comp}}-1} N_{\mathrm{bnd},i}-1} \left(c^s_{m}\right)^{e^{s}_{\mathrm{bwd},m,j}}\right] \left[\prod_{\ell=0}^{N_{\mathrm{comp}}-1} \left(c^p_{\ell}\right)^{e^{sp}_{\mathrm{bwd},\ell,j}}\right].
+ \end{split}
+
+Whereas the exponent matrices :math:`E^{s}_{\mathrm{fwd}}, E^{s}_{\mathrm{bwd}} \in \mathbb{R}^{(\sum_i N_{\mathrm{bnd},i}) \times N_{\mathrm{react}}}` are initialized based on the stoichiometric matrix :math:`S^{s} \in \mathbb{R}^{(\sum_i N_{\mathrm{bnd},i}) \times N_{\mathrm{react}}}`, see Eq.:eq:`MRMassActionLawExpMatDefault`, the exponent matrices :math:`E^{sp}_{\mathrm{fwd}}, E^{sp}_{\mathrm{bwd}}` of the modifier terms default to :math:`0`.
+
+
+Correlation of forward- and backward rate constants
+---------------------------------------------------
+
+Note that forward rate constant :math:`k_{\mathrm{fwd},i}` and backward
+rate constant :math:`k_{\mathrm{bwd},i}` of reaction :math:`i` are
+linearly correlated due to the form of the equilibrium constant
+:math:`k_{\mathrm{eq},i}`:
+
+.. math::
+
+ \begin{aligned}
+ k_{\mathrm{fwd},i} = k_{\mathrm{eq},i} k_{\mathrm{bwd},i}.
+ \end{aligned}
+
+This correlation can potentially degrade performance of some optimization algorithms.
+The parameters can be decoupled by reparameterization:
+
+.. math::
+
+ \begin{aligned}
+ r_{\mathrm{net},i} &= k_{\mathrm{fwd},i} f_{\mathrm{fwd},i} - k_{\mathrm{bwd},i} f_{\mathrm{bwd},i}\\
+ &= k_{\mathrm{bwd},i} \left[ k_{\mathrm{eq},i} f_{\mathrm{fwd},i} - f_{\mathrm{bwd},i} \right] \\
+ &= k_{\mathrm{fwd},i} \left[ f_{\mathrm{fwd},i} - \frac{1}{k_{\mathrm{eq},i}} f_{\mathrm{bwd},i} \right].
+ \end{aligned}
+
+This can be achieved by a (nonlinear) parameter transform
+
+.. math::
+
+ \begin{aligned}
+ F\left( k_{\mathrm{eq},i}, k_{\mathrm{bwd},i} \right) &= \begin{pmatrix} k_{\mathrm{eq},i} k_{\mathrm{bwd},i} \\ k_{\mathrm{bwd},i} \end{pmatrix} \\
+ \text{ with Jacobian } J_F\left( k_{\mathrm{eq},i}, k_{\mathrm{bwd},i} \right) &= \begin{pmatrix} k_{\mathrm{bwd},i} & k_{\mathrm{eq},i} \\ 0 & 1 \end{pmatrix}.
+ \end{aligned}
diff --git a/v5.0.1/_sources/modelling/reaction/michaelis_menten_kinetics.rst.txt b/v5.0.1/_sources/modelling/reaction/michaelis_menten_kinetics.rst.txt
new file mode 100644
index 000000000..2efe7cc40
--- /dev/null
+++ b/v5.0.1/_sources/modelling/reaction/michaelis_menten_kinetics.rst.txt
@@ -0,0 +1,40 @@
+.. _michaelis_menten_kinetics_model:
+
+Michaelis Menten kinetics
+-------------------------
+
+Implements liquid phase Michaelis-Menten reaction kinetics of the form
+
+.. math::
+
+ \begin{aligned}
+ f_\text{react} = S \mathbf{\nu},
+ \end{aligned}
+
+where :math:`S` is the stoichiometric matrix and the fluxes are given by
+
+.. math::
+
+ \begin{aligned}
+ \nu_j = \frac{\mu_{\mathrm{max},j} \, c_S}{k_{\mathrm{MM},j} + c_S},
+ \end{aligned}
+
+where
+
+- :math:`j` is the reaction index,
+- :math:`c_S` is the substrate component,
+- :math:`\mu_{\mathrm{max},j}`, is the limiting rate approached by the system at saturation,
+- :math:`k_{\mathrm{MM},j}` is the Michaelis constant, which is defined as the concentration of substrate at which the reaction rate is half ov :math:`\mu_{\mathrm{max},j}`.
+
+
+In addition, the reaction might be inhibited by other components.
+In this case, the flux has the form
+
+.. math::
+
+ \begin{aligned}
+ \nu_j = \frac{\mu_{\mathrm{max},j} \, c_S}{k_{\mathrm{MM},j} + c_S} \prod_i \frac{k_{\mathrm{I},j,i}}{k_{\mathrm{I},j,i} + c_{\mathrm{I},i}}.
+ \end{aligned}
+
+Here, :math:`k_{\mathrm{I},j,i}` is the inhibition constant w.r.t component :math:`i` and reaction :math:`j`.
+If :math:`k_{\mathrm{I},j,i} <= 0`, component :math:`i` does not inhibit the reaction.
diff --git a/v5.0.1/_sources/modelling/unit_operations/2d_general_rate_model.rst.txt b/v5.0.1/_sources/modelling/unit_operations/2d_general_rate_model.rst.txt
new file mode 100644
index 000000000..6684f475e
--- /dev/null
+++ b/v5.0.1/_sources/modelling/unit_operations/2d_general_rate_model.rst.txt
@@ -0,0 +1,92 @@
+.. _2d_general_rate_model_model:
+
+Two Dimensional General rate model (GRM2D)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The general rate model as introduced in Section :ref:`general_rate_model_model` assumes homogeneity in the cross sections of the column.
+This allows to consider transport along the axial dimension only.
+However, due to packing irregularity and inhomogeneous flow at the inlet (i.e., frits), this assumption may be a crude approximation.
+This model can be improved by introducing a radial coordinate :math:`\rho \in [0, R]`, where :math:`R` is the column radius, in the interstitial volume Eq. :eq:`ModelColumn`:
+
+.. math::
+ :label: ModelColumn2D
+
+ \varepsilon_c \frac{\partial c^\ell_i}{\partial t} = &-\varepsilon_c u \frac{\partial c^\ell_i}{\partial z} + \varepsilon_c D_{\text{ax},i} \frac{\partial^2 c^\ell_i}{\partial z^2} + \frac{1}{\rho} \frac{\partial}{\partial \rho} \left( \rho D_{\text{rad},i} \frac{\partial}{\partial \rho} \left( \varepsilon_c c^\ell_i \right) \right) \\
+ &- \left(1 - \varepsilon_c\right) \sum_j d_j \frac{ 3 k_{f,j,i} }{r_{p,j}} \left[ c^\ell_i - c^p_{j,i}(\cdot, \cdot, \cdot, r_{p,j}) \right] + \varepsilon_c f_{\text{react},i}^\ell\left(c^\ell\right).
+
+Here,
+
+ - :math:`c^\ell_i\colon \left[0, T_{\text{end}}\right] \times [0, L] \times [0, R] \rightarrow \mathbb{R}^{\geq 0}`,
+ - :math:`c^p_{j,i}\colon \left[0, T_{\text{end}}\right] \times [0, L] \times [0, R] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}`, and
+ - :math:`c^s_{j,i,m_{j,i}}\colon \left[0, T_{\text{end}}\right] \times [0, L] \times [0, R] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}`
+
+depend on :math:`\rho`.
+Additionally, the porosity :math:`\varepsilon_c`, axial dispersion coefficient :math:`D_{\text{ax},i}`, radial dispersion coefficient :math:`D_{\text{rad},i}`, and interstitial velocity :math:`u` may depend on :math:`\rho`.
+
+The dependence of the parameters on :math:`\rho` is not arbitrary.
+For simplicity, it is assumed that the parameters are piecewise constant, that is, the range :math:`[0, R]` is divided into disjoint zones in which all parameters are constant.
+These zones are used for radial discretization and can be supplied to the simulator.
+Continuous dependence of the parameters can be realized by piecewise constant approximation.
+
+The Danckwerts boundary conditions at the column in- and outlet, Eq. :eq:`BCInlet` and :eq:`BCOutlet`, are modified to account for the radial coordinate:
+
+.. math::
+ :label: BCInlet2D
+
+ \begin{aligned}
+ u(\rho) c_{\text{in},i}(t,\rho) &= u(\rho) c^\ell_i(t,0,\rho) - D_{\text{ax},i}(\rho) \frac{\partial c^\ell_i}{\partial z}(t, 0, \rho) & \forall t > 0, \rho \in (0,R),
+ \end{aligned}
+
+.. math::
+ :label: BCOutlet2D
+
+ \begin{aligned}
+ \frac{\partial c^\ell_i}{\partial z}(t, L, \rho) &= 0 & \forall t > 0, \rho \in (0,R).
+ \end{aligned}
+
+Conditions for the radial direction are added:
+
+.. math::
+ :label: BCRadial2DInner
+
+ \begin{aligned}
+ \frac{\partial{c^\ell_i}}{\partial \rho}(\cdot, \cdot, 0) &= 0, \\
+ \end{aligned}
+
+.. math::
+ :label: BCRadial2DOuter
+
+ \begin{aligned}
+ \frac{\partial{c^\ell_i}}{\partial \rho}(\cdot, \cdot, R) &= 0.
+ \end{aligned}
+
+While the inner condition Eq.\ :eq:`BCRadial2DInner` represents symmetry at the column center, the outer condition Eq. :eq:`BCRadial2DOuter` is a no-flux condition.
+
+Using the inlet boundary condition Eq. :eq:`BCInlet2D`, each radial zone is equipped with its own inlet and outlet port.
+That is, this unit operation has as many inlet and outlet ports as it has radial zones (parameter ``NRAD`` in the ``discretization`` group).
+This allows each radial zone to have its own inlet profile, which enables modeling of flow distribution in the frits by sending the feed through varying hold-up volumes before injecting it into a radial zone.
+
+
+.. _MUOPGRMflow2D:
+
+Specification of flow rate / velocity and direction
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Since the column radius :math:`R` and the zones :math:`(\rho_k, \rho_{k+1})`, :math:`k = 0, \dots, N_{\text{rad}} - 1`, are known, the interstitial velocities :math:`u_k` are inferred from the volumetric flow rates via
+
+.. math::
+
+ \begin{aligned}
+ u_k = u_{\text{int},k} = \frac{F_{\text{in},k}}{\pi \left( \rho_{k+1}^2 - \rho_k^2 \right) \varepsilon_{c,k}},
+ \end{aligned}
+
+where :math:`F_{\text{in},k}` denotes the volumetric flow rate into zone :math:`k`.
+
+The direction of flow inside the radial zone of the unit operation is governed by the sign of the interstitial velocity :math:`u_k`.
+A positive sign results in (standard) forward flow, whereas a negative sign reverses the flow direction.
+Note that in case of reversed flow, the chromatogram is returned at the unit operation’s *inlet* port, which may not be returned from simulation by default.
+
+Note that, contrary to the standard general rate model as presented in Section :ref:`general_rate_model_model`, the interstitial flow rate is always given by the volumetric flow rate.
+The velocity parameter only determines the flow direction.
+
+For information on model parameters see :ref:`2d_general_rate_model_config`.
diff --git a/v5.0.1/_sources/modelling/unit_operations/cstr.rst.txt b/v5.0.1/_sources/modelling/unit_operations/cstr.rst.txt
new file mode 100644
index 000000000..dc6ab7730
--- /dev/null
+++ b/v5.0.1/_sources/modelling/unit_operations/cstr.rst.txt
@@ -0,0 +1,55 @@
+.. _cstr_model:
+
+Continuous stirred tank reactor model (CSTR)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. include:: ../equations.rst
+
+The continuous stirred tank reactor model is a basic building block in unit operation networks and often used to model holdup volume.
+When combined with a binding model, it can be used to model batch uptake experiments.
+
+Assuming that the fluid inside the tank is well-mixed and that the liquid volume :math:`V^{\ell}` can vary, the governing equations are given by
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d}}{\mathrm{d}t} (V^{\ell} c^\ell_i) + V^{s} \sum_j d_j \sum_{m_{j,i}}^{N_{\text{bnd},j,i}} \frac{\mathrm{d}}{\mathrm{d}t} (c^s_{j,i,m_{j,i}}) &= F_{\text{in}} c^\ell_{\text{in},i} - F_{\text{out}} c^\ell_i + V^{\ell} f_{\text{react},i}^l\left( c^\ell \right) \\
+ &+V^{s}\sum_j d_j f_{\text{react},j,i}^s\left( c^\ell, c_j^s \right)
+ \end{aligned}
+where:
+
+- |component_li|
+- |component_sij|
+- |volume_liquid|
+- |volume_solid|
+- |flow_in_out|
+- |reaction|
+- |volume_fac_pat|
+
+Depending on whether quasi-stationary or dynamic binding is used the binding behavior of :math:`c_i^{\ell}` and :math:`c^s_j` is described by
+
+.. math::
+
+ \begin{aligned}
+ \text{quasi-stationary: }& & 0 &= f_{\text{ads},j}\left( c_i^\ell, c^s_j\right), \\
+ \text{dynamic: }& & \frac{\partial c^s_j}{\partial t} &= f_{\text{ads},j}\left( c_i^\ell, c^s_j\right) + f_{\text{react},j}^s\left( c_i^\ell, c_j^s \right),
+ \end{aligned}
+
+where :math:`f_{\text{ads},j}` is the adsorption rate in the solid phase of particle type :math:`j`.
+
+The evolution of volume of the liquid volume
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d}V^{\ell}}{\mathrm{d}t}= F_{\text{in}} - F_{\text{out}} - F_{\text{filter}}.
+ \end{aligned}
+
+Removing all bound states by setting :math:`N_{\text{bnd},j,i} = 0` for all components :math:`i` and particle types :math:`j`, and applying no binding model results in a simple tank.
+The additional parameter :math:`F_{\text{filter}}`, which denotes the flow rate of pure liquid (without any components) out of the tank, can be used to model a filtering unit.
+
+Note that it is the user’s duty to make sure that the volume of the CSTR does not fall below 0. If it does, the simulation may fail to run or may produce unreasonable (e.g., unphysical) results.
+
+See :ref:`cstr_config`.
+
+
diff --git a/v5.0.1/_sources/modelling/unit_operations/general_rate_model.rst.txt b/v5.0.1/_sources/modelling/unit_operations/general_rate_model.rst.txt
new file mode 100644
index 000000000..071177948
--- /dev/null
+++ b/v5.0.1/_sources/modelling/unit_operations/general_rate_model.rst.txt
@@ -0,0 +1,347 @@
+.. _general_rate_model_model:
+
+General rate model (GRM)
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The general rate model is the most comprehensive model of mass transfer in column liquid chromatography, when only the axial coordinate in the column and the radial coordinate in the beads are considered :cite:`Kucera1965,Gu1995,Guiochon2006,Felinger2004`.
+
+The main assumptions are:
+
+- The cross sections of the column are homogenous in terms of interstitial volume, fluid flow, and distribution of components.
+ Thus, only one spatial coordinate in axial direction is needed and radial transport is neglected in the column bulk volume.
+
+- The bead radii :math:`r_{p}` are much smaller than the column radius :math:`\mathrm{P}` and the column length :math:`L`.
+ Therefore, the beads can be seen as continuously distributed inside the column (i.e., at each point there is interstitial and bead volume).
+
+.. _table_features:
+.. list-table:: Variables and unknowns
+ :widths: 20 30 50
+ :header-rows: 1
+
+ * - Variable
+ - Domain
+ - Description
+ * - :math:`i`
+ - :math:`\left\{ 0, \dots, N_{\text{comp}} - 1 \right\}`
+ - Component index
+ * - :math:`j`
+ - :math:`\left\{ 0, \dots, N_{\text{partype}} - 1 \right\}`
+ - Particle type index
+ * - :math:`m_{j,i}`
+ - :math:`\left\{ 0, \dots, N_{\text{bnd},j,i} - 1 \right\}`
+ - Bound state index of :math:`i`\ th component in :math:`j`\ th particle type
+ * - :math:`m_j`
+ - :math:`\left\{ 0, \dots, \sum_{i=0}^{N_{\text{comp}}-1} N_{\text{bnd},j,i} - 1 \right\}`
+ - Total bound state index in particle type :math:`j`
+ * - :math:`t`
+ - :math:`\left[0, T_{\text{end}}\right]`
+ - Time coordinate
+ * - :math:`z`
+ - :math:`\left[0, L\right]`
+ - Axial coordinate
+ * - :math:`r`
+ - :math:`\left[r_{c,j}, r_{p,j}\right]`
+ - Generic bead radial coordinate
+ * - :math:`c^\ell_{i}(t,z)`
+ - :math:`\left[0, T_{\text{end}}\right] \times [0, L]`
+ - Interstitial concentration of the :math:`i`\ th component
+ * - :math:`c^p_{j,i}(t, z, r)`
+ - :math:`\left[0, T_{\text{end}}\right] \times [0, L] \times \left[r_{c,j}, r_{p,j}\right]`
+ - Mobile phase concentration of the :math:`i`\ th component in the :math:`j`\th particle type
+ * - :math:`c^s_{j,i,m_{j,i}}(t, z, r)`
+ - :math:`\left[0, T_{\text{end}}\right] \times [0,L] \times \left[r_{c,j}, r_{p,j}\right]`
+ - Solid phase concentration of the :math:`i`\ th component's :math:`m_{j,i}`\th bound state in particles of type :math:`j`
+ * - :math:`j_{f,j,i}(t, z)`
+ - :math:`\left[0, T_{\text{end}}\right] \times [0, L]`
+ - Flux of the :math:`i`\ th component through stagnant film into the bead of type :math:`j`
+
+.. _ModelGRMColumn:
+.. figure:: column_bulk_model.png
+
+ Column bulk model
+
+The GRM describes transport of solute molecules through the interstitial column volume by convective flow, band broadening caused by axial dispersion, mass transfer resistance through a stagnant film around the beads, pore (and surface) diffusion in the porous beads :cite:`Ma1996,Schneider1968a,Miyabe2007`, and adsorption to the inner bead surfaces.
+
+Consider a column of length :math:`L>0` filled with spherical beads of (possibly) multiple types with radius :math:`r_{p,j} \ll L` (see :numref:`ModelGRMColumn`), where :math:`j` is the particle type index. The mass balance in the interstitial column volume is described by
+
+.. math::
+ :label: ModelColumn
+
+ \begin{aligned}
+ \frac{\partial c^\ell_i}{\partial t} = -u \frac{\partial c^\ell_i}{\partial z} + D_{\text{ax},i} \frac{\partial^2 c^\ell_i}{\partial z^2} &- \frac{1}{\beta_c} \sum_j d_j \frac{3}{r_{p,j}} k_{f,j,i} \left[ c^\ell_i - c^p_{j,i}(\cdot, \cdot, r_{p,j}) \right] \\
+ &+ f_{\text{react},i}^\ell\left(c^\ell\right).
+ \end{aligned}
+
+Here, :math:`c^\ell_i\colon \left[0, T_{\text{end}}\right] \times [0, L] \rightarrow \mathbb{R}^{\geq 0}` denotes the concentration in the interstitial column volume, :math:`c^p_{j,i}\colon \left[0, T_{\text{end}}\right] \times [0, L] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}` the liquid phase concentration in the beads, :math:`k_{f,j,i}\geq 0` the film diffusion coefficient, :math:`D_{\text{ax},i}\geq 0` the dispersion coefficient, :math:`u\in\mathbb{R}` the interstitial velocity, :math:`d_j > 0` the volume fraction of particle type :math:`j`, and :math:`\frac{1}{\beta_c} = (1 - \varepsilon_c) / \varepsilon_c` the column phase ratio, where :math:`\varepsilon_c\in (0,1]` is the column porosity (ratio of interstitial volume to total column volume).
+If reactions are considered, the term :math:`f_{\text{react},i}^\ell\left(c^\ell\right)` represents the net change of concentration :math:`c_i` due to reactions involving component :math:`i`.
+
+Danckwerts boundary conditions :cite:`Danckwerts1953` are applied to inlet and outlet of the column:
+
+.. math::
+ :label: BCOutlet
+
+ \begin{aligned}
+ u c_{\text{in},i}(t) &= u c^\ell_i(t,0) - D_{\text{ax},i} \frac{\partial c^\ell_i}{\partial z}(t, 0) & \forall t > 0,
+ \end{aligned}
+
+.. math::
+ :label: BCInlet
+
+ \begin{aligned}
+ \frac{\partial c^\ell_i}{\partial z}(t, L) &= 0 & \forall t > 0.
+ \end{aligned}
+
+Note that the outlet boundary condition Eq. :eq:`BCOutlet` is also known as “do nothing” or natural outflow condition.
+
+In the liquid phase of the porous beads (see :numref:`ModelGRMColumn`) the mass balance is given by
+
+.. math::
+ :label: ModelBead
+
+ \begin{aligned}
+ \frac{\partial c^p_{j,i}}{\partial t} &+ \frac{1 - \varepsilon_{p,j}}{F_{\text{acc},j,i} \varepsilon_{p,j}} \frac{\partial}{\partial t} \sum_{m_{j,i}} c^s_{j,i,m_{j,i}} \\
+ &= \underbrace{D_{p,j,i} \left[\frac{\partial^2}{\partial r^2} + \frac{2}{r} \frac{\partial}{\partial r} \right]c^p_{j,i}}_{\text{Pore diffusion}} \\
+ &+ \underbrace{\frac{1 - \varepsilon_{p,j}}{F_{\text{acc},j,i} \varepsilon_{p,j}} D_{s,j,i} \left[\frac{\partial^2}{\partial r^2} + \frac{2}{r} \frac{\partial }{\partial r} \right] \sum_{m_{j,i}} c^s_{j,i,m_{j,i}} }_{\text{Surface diffusion}} \\
+ &+ f_{\text{react},j,i}^p\left( c_j^p, c_j^s \right) + \frac{1 - \varepsilon_{p,j}}{F_{\text{acc},j,i} \varepsilon_{p,j}} f_{\text{react},j,i}^s\left( c_j^p, c_j^s \right),
+ \end{aligned}
+
+
+where :math:`c^s_{j,i,m_{j,i}}\colon \left[0, T_{\text{end}}\right] \times [0,L] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}` denotes the solid phase concentration of the :math:`i`\ th component’s :math:`m_{j,i}`\ th bound state in the beads of :math:`j`\ th type, :math:`D_{p,j,i}>0` the effective diffusion coefficient in the beads, :math:`D_{s,j,i}\geq 0` the surface diffusion coefficient, :math:`F_{\text{acc},j,i}\geq 0 \in [0,1]` the pore accessibility factor, and :math:`\varepsilon_{p,j}\in (0,1]` the particle porosity (ratio of pore volume to total bead volume).
+The inner bead radius :math:`r_{c,j} \in [0, r_{p,j})` is assumed to be :math:`0` by default, but can be positive in order to account for core-shell particles that have an impermeable core.
+Reaction terms in liquid and solid phase are collected in :math:`f_{\text{react},j,i}^p( c_j^p, c_j^s)` and :math:`f_{\text{react},j,i}^s(c_j^p, c_j^s)`, respectively.
+
+The GRM is used with both quasi-stationary (Eq. :eq:`REqBinding`) and dynamic (Eq. :eq:`DynBinding`) binding models.
+
+.. math::
+ :label: REqBinding
+
+ \begin{aligned}
+ \text{quasi-stationary: } 0 &= f_{\text{ads},j}\left( c^p_j, c^s_j\right)
+ \end{aligned}
+
+.. math::
+ :label: DynBinding
+
+ \begin{aligned}
+ \text{dynamic: } \frac{\partial c^s_j}{\partial t} &= D_{s,j} \left[\frac{\partial^2}{\partial r^2} + \frac{2}{r} \frac{\partial }{\partial r} \right] c^s_{j} \\
+ &+ f_{\text{ads},j}\left( c^p_j, c^s_j\right) + f_{\text{react},j}^s\left( c_j^p, c_j^s \right).
+ \end{aligned}
+
+Note that :math:`c^p_j` and :math:`c^s_j` denote the vector of all :math:`c^p_{j,i}` and :math:`c^s_{j,i,m_{j,i}}`, respectively.
+
+The boundary conditions of the bead model the film diffusion and are given for all :math:`{t \in (0,\infty)}` and :math:`z \in [0,L]` by
+
+.. math::
+ :label: BCBeadIn
+
+ \begin{aligned}
+ k_{f,j,i}\left[ c^\ell_i - c^p_{j,i}(\cdot, \cdot, r_{p,j}) \right] &= F_{\text{acc},j,i} \varepsilon_{p,j} D_{p,j,i} \frac{\partial c^p_{j,i}}{\partial r}(\cdot, \cdot, r_{p,j}) \\
+ &+ \left( 1 - \varepsilon_{p,j}\right) D_{s,j,i} \sum_{m_{j,i}} \frac{\partial c^s_{j,i,m_{j,i}}}{\partial r}(\cdot, \cdot, r_{p,j}),
+ \end{aligned}
+
+.. math::
+ :label: BCBeadCenter
+
+ \begin{aligned}
+ \frac{\partial c^p_{j,i}}{\partial r}(\cdot, \cdot, r_{c,j}) &= 0.
+ \end{aligned}
+
+By default, the following initial conditions are applied for all :math:`z \in [0,L]` and :math:`r \in \left[r_{c,j}, r_{p,j}\right]`:
+
+.. math::
+ :label: InitialConditions
+
+ \begin{aligned}
+ c^\ell_i(0, z) &= 0, & c^p_{j,i}(0, z, r) &= 0, & c^s_{j,i,m_{j,i}}(0,z,r) &= 0.
+ \end{aligned}
+
+.. _ModelGRMBead:
+.. figure:: column_bead_model.png
+
+ Column bead model
+
+.. _ModelGRMStates:
+.. figure:: multiple_bound_states.png
+ :scale: 50 %
+
+ Binding with multiple bound states
+
+
+See Table :ref:`general_rate_model_config`.
+
+
+.. _MUOPGRMParticleGeometry:
+
+Particle Geometry
+^^^^^^^^^^^^^^^^^
+
+In the model above, spherical particles are considered.
+Other supported particle forms are cylinders and slabs.
+For cylinders, it is assumed that molecules can only enter through the lateral surface (i.e., the caps are sealed).
+Slabs are assumed to have two large sides such that molecules enter through the two large faces (i.e., the remaining four small faces are sealed).
+
+All particle forms support core-shell beads that have an impermeable core.
+The particles are characterized by their (outer) "radius" :math:`r_{p,j}` and their (inner) core "radius" :math:`r_{c,j} \in [0, r_{p,j})`.
+See :numref:`ModelGRMParticleGeometries`.
+
+.. _ModelGRMParticleGeometries:
+.. figure:: column_particle_geometries.png
+
+ Particle geometries
+
+For cylinders, the factor :math:`3 / r_{p,j}` in Eq. (:eq:`ModelColumn`) changes to :math:`2 / r_{p,j}` and the diffusion operator in Eq. (:eq:`ModelBead`) and Eq. (:eq:`DynBinding`) changes as
+
+.. math::
+
+ \begin{aligned}
+ \left[\frac{\partial^2}{\partial r^2} + \frac{2}{r} \frac{\partial }{\partial r} \right] \quad \rightarrow \quad \left[\frac{\partial^2}{\partial r^2} + \frac{1}{r} \frac{\partial }{\partial r} \right].
+ \end{aligned}
+
+For slabs, the factor :math:`3 / r_{p,j}` in (see Eq. (:eq:`ModelColumn`)) changes to :math:`1 / r_{p,j}` and the diffusion operator in Eq. (:eq:`ModelBead`) and Eq. (:eq:`DynBinding`) changes as
+
+.. math::
+
+ \begin{aligned}
+ \left[\frac{\partial^2}{\partial r^2} + \frac{2}{r} \frac{\partial }{\partial r} \right] \quad \rightarrow \quad \frac{\partial^2}{\partial r^2}.
+ \end{aligned}
+
+
+.. _MUOPGRMMultiParticleTypes:
+
+Multiple particle types
+^^^^^^^^^^^^^^^^^^^^^^^
+
+A particle type has its own set of mass transfer parameters :math:`\varepsilon_{p,j}`, :math:`D_{p,j}`, :math:`D_{s,j}`, etc (see Eq. :eq:`ModelBead`) and its own binding model :math:`f_{\mathrm{ads}}` (including a possibly differing number of bound states).
+This allows, for example, modeling of particle size distributions or potential applications with differently functionalized beads (e.g., immobilized enzymes).
+
+The distribution of the particle types is governed by their volume fractions :math:`d_j` in Eq.
+ :eq:`ModelColumn`. The volume fractions have to sum to :math:`1`:
+
+.. math::
+
+ \begin{aligned}
+ \sum_{j=0}^{N_{\text{partype}} - 1} d_j = 1.
+ \end{aligned}
+
+The particle type volume fractions can be spatially constant throughout the column, or depend on the position inside the column bulk volume.
+In the latter case, the user can specify a set of volume fractions for each discretized finite volume cell.
+This allows, for example, the placement of smaller particles near the frits.
+
+.. _MUOPGRMSizeExclusion:
+
+Size exclusion chromatography
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The general rate model can be used to simulate size exclusion chromatography (SEC) :cite:`Gu1995`.
+The particle porosity :math:`\varepsilon_{p,j}` on the mobile phase side of the transport equations is replaced by a component-dependent accessible porosity
+
+.. math::
+
+ \begin{aligned}
+ \varepsilon_{p,j,i} = F_{\text{acc},j,i} \varepsilon_{p,j},
+ \end{aligned}
+
+where the pore accessibility factor :math:`F_{\text{acc},j,i}` ranges in :math:`(0, 1]`.
+
+Small molecules that can enter any pore have :math:`F_{\text{acc},j,i} = 1`, whereas larger molecules that can enter some, but not small pores, have values :math:`0 < F_{\text{acc},j,i} < 1`.
+The other extreme is given by molecules so large that they cannot enter any pore and, consequently, :math:`F_{\text{acc},j,i} = 0`.
+Note that :math:`F_{\text{acc},j,i} = 0` is not allowed in a simulation, which can be circumvented by setting :math:`k_{f,j,i} = 0`.
+
+By default, :math:`F_{\text{acc},j,i} = 1` for all components :math:`i` and all particle types :math:`j`, which disables size exclusion chromatography.
+
+It is important to note that in the presence of size exlusion effects, the saturation capacity (e.g., :math:`q_{\text{max}}` of Langmuir-type binding models) will differ for solutes with different accessible porosity values.
+However, this leads to inconsistencies in the equations which account for the full pore volume fraction :math:`\varepsilon_{p,j}`.
+For this reason, SEC should only be modelled without binding models!
+In order to simulate pure SEC, binding is disabled by setting :math:`N_{\text{bnd},i} = 0` for all components :math:`i` and applying no binding model.
+
+Note that multiple particle types can also be used to aid in modeling size exclusion effects, see Section :ref:`MUOPGRMMultiParticleTypes`.
+
+.. _MUOPGRMflow:
+
+Specification of flow rate / velocity and direction
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Since volumetric flow rates are specified for each network connection, the unit operation can infer its interstitial velocity via
+
+.. math::
+
+ \begin{aligned}
+ u = u_{\text{int}} = \frac{F_{\text{in}}}{A \varepsilon_c},
+ \end{aligned}
+
+where :math:`F_{\text{in}}` denotes the volumetric flow rate and :math:`A` the cross section area.
+Note that without the bulk porosity :math:`\varepsilon_c`, the superficial velocity would be obtained.
+
+The direction of flow inside the unit operation is governed by the sign of the interstitial velocity :math:`u`.
+A positive sign results in (standard) forward flow, whereas a negative sign reverses the flow direction.
+Note that in case of reversed flow, the chromatogram is returned at the unit operation’s `INLET`, which may not be returned from simulation by default.
+
+The final behavior for axial flow models is controlled by the interplay of cross section area and interstitial velocity:
+
+- If cross section area :math:`A` is given and :math:`u` is not, :math:`u` is inferred from the volumetric flow rate.
+
+- If :math:`u` is given and :math:`A` is not, the volumetric flow rate is ignored and the provided interstitial velocity is used.
+
+- If both cross section area :math:`A` and interstitial velocity :math:`u` are given, the magnitude of the actual interstitial velocity :math:`u` is inferred from the volumetric flow rate and the flow direction is given by the sign of the provided :math:`u`.
+
+The final behavior for radial flow models is controlled by the interplay of column length/height and interstitial velocity coefficient:
+
+- If :math:`L` is given, the interstitial velocity field is inferred from the volumetric flow rate.
+
+- If :math:`u` is given and :math:`L` is not, the provided interstitial velocity coefficient is used to calculate the interstitial velocity field.
+
+
+For information on model parameters see :ref:`general_rate_model_config`.
+
+.. _MUOPGRMradialFlow:
+
+Radial flow GRM
+^^^^^^^^^^^^^^^
+
+The radial flow GRM describes transport of solute molecules through the interstitial column volume by radial convective flow, band broadening caused by radial dispersion, mass transfer resistance through a stagnant film around the beads, pore (and surface) diffusion in the porous beads :cite:`Ma1996,Schneider1968a,Miyabe2007`, and adsorption to the inner bead surfaces.
+
+The main assumptions are:
+
+- The cylindrical shells of the column are homogenous in terms of interstitial volume, fluid flow, and distribution of components.
+ Thus, only one spatial coordinate in radial direction :math:`\rho` is needed and axial transport is neglected in the column bulk volume.
+
+- The bead radii :math:`r_{p}` are much smaller than the column radius :math:`\mathrm{P}-\mathrm{P}_c`, with :math:`\mathrm{P}` and :math:`\mathrm{P}_c` being the inner and outer column radius respectively, and the column length :math:`L`.
+ Therefore, the beads can be seen as continuously distributed inside the column (i.e., at each point there is interstitial and bead volume).
+
+- The fluids are incompressible, i.e. the velocity field :math:`\mathrm{V} \colon \mathbb{R}^3 \to \mathbb{R}^3` submits to :math:`\operatorname{div}\left( \mathrm{V} \right) \equiv 0`.
+ That is, the volumetric flow rate at the inner and outer column radius are the same.
+
+Consider a hollow (double walled) column with inner column diameter :math:`\mathrm{P}_c>0` and outer diameter :math:`\mathrm{P}>\mathrm{P}_c`, filled with spherical beads of (possibly) multiple types with radius :math:`r_{p,j} \ll L` (see :numref:`ModelGRMColumn`), where :math:`j` is the particle type index. The mass balance in the interstitial column volume is described by
+
+.. math::
+ :label: ModelRadialColumnGRM
+
+ \begin{aligned}
+ \frac{\partial c^\ell_i}{\partial t} = -\frac{u}{\rho} \frac{\partial c^\ell_i}{\partial \rho} + D_{\text{rad},i} \frac{1}{\rho} \frac{\partial}{\partial \rho} \left(\rho \frac{\partial c^\ell_i}{\partial \rho} \right) &- \frac{1}{\beta_c} \sum_j d_j \frac{3}{r_{p,j}} k_{f,j,i} \left[ c^\ell_i - c^p_{j,i}(\cdot, \cdot, r_{p,j}) \right] \\
+ &+ f_{\text{react},i}^\ell\left(c^\ell\right).
+ \end{aligned}
+
+Here, :math:`c^\ell_i\colon \left[0, T_{\text{end}}\right] \times [\mathrm{P}_c, \mathrm{P}] \rightarrow \mathbb{R}^{\geq 0}` denotes the concentration in the interstitial column volume, :math:`c^p_{j,i}\colon \left[0, T_{\text{end}}\right] \times [P_c, P] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}` the liquid phase concentration in the beads, :math:`k_{f,j,i}\geq 0` the film diffusion coefficient, :math:`D_{\text{rad},i}\geq 0` the dispersion coefficient, :math:`u>0` the interstitial velocity, :math:`d_j>0` the volume fraction of particle type :math:`j`, and :math:`\beta_c = \varepsilon_c / (1 - \varepsilon_c)` the column phase ratio, where :math:`\varepsilon_c\in(0,1)` is the column porosity (ratio of interstitial volume to total column volume).
+If reactions are considered, the term :math:`f_{\text{react},i}^\ell\left(c^\ell\right)` represents the net change of concentration :math:`c_i` due to reactions involving component :math:`i`.
+
+Danckwerts boundary conditions :cite:`Danckwerts1953` are applied to inlet and outlet of the column:
+
+.. math::
+ :label: BCOutletRadial
+
+ \begin{aligned}
+ u c_{\text{in},i}(t) &= u c^\ell_i(t,0) - D_{\text{rad},i} \frac{\partial c^\ell_i}{\partial \rho}(t, 0) & \forall t > 0,
+ \end{aligned}
+
+.. math::
+ :label: BCInletRadial
+
+ \begin{aligned}
+ \frac{\partial c^\ell_i}{\partial \rho}(t, \mathrm{P}) &= 0 & \forall t > 0.
+ \end{aligned}
+
+Note that the outlet boundary condition Eq. :eq:`BCOutletRadial` is also known as “do nothing” or natural outflow condition.
+
+The complementing mass transport and binding equations for the liquid and solid phases of the porous beads are described by the same equations as for the axial GRM.
+
+For information on model parameters see :ref:`radial_flow_models_config` in addition to :ref:`general_rate_model_config`.
diff --git a/v5.0.1/_sources/modelling/unit_operations/index.rst.txt b/v5.0.1/_sources/modelling/unit_operations/index.rst.txt
new file mode 100644
index 000000000..12cc6fae8
--- /dev/null
+++ b/v5.0.1/_sources/modelling/unit_operations/index.rst.txt
@@ -0,0 +1,79 @@
+.. _unit_operation_models:
+
+Unit operation models
+=====================
+
+A short comparison of the most prominent unit operation model features
+is given in :numref:`table_features_unit_operations`.
+
+.. _table_features_unit_operations:
+.. list-table:: Supported features of the different unit operations models
+ :widths: 30 14 14 14 14 14
+ :header-rows: 1
+
+ * - Unit operation model
+ - Radial dispersion
+ - Pore diffusion
+ - Film diffusion
+ - Particle geometries
+ - Multiple particle types
+ * - :ref:`general_rate_model_model`
+ - ×
+ - ✓
+ - ✓
+ - ✓
+ - ✓
+ * - :ref:`lumped_rate_model_with_pores_model`
+ - ×
+ - ×
+ - ✓
+ - ✓
+ - ✓
+ * - :ref:`lumped_rate_model_without_pores_model`
+ - ×
+ - ×
+ - ×
+ - ×
+ - ×
+ * - :ref:`2d_general_rate_model_model`
+ - ✓
+ - ✓
+ - ✓
+ - ✓
+ - ✓
+ * - :ref:`cstr_model`
+ - ×
+ - ×
+ - ×
+ - ×
+ - ✓
+ * - :ref:`multi_channel_transport_model_model`
+ - ×
+ - ×
+ - ×
+ - ×
+ - ×
+ * - :ref:`pbm_model`
+ - ×
+ - ×
+ - ×
+ - ×
+ - ×
+
+
+Moreover, the pseudo unit operations :ref:`inlet_model`, and :ref:`outlet_model` act as sources and sinks for the system.
+We further note that radial flow model variants are available for the LRM, LRMP and GRM.
+
+
+.. toctree::
+ :hidden:
+ :glob:
+
+ general_rate_model
+ lumped_rate_model_without_pores
+ lumped_rate_model_with_pores
+ 2d_general_rate_model
+ multi_channel_transport_model
+ cstr
+ inlet
+ outlet
diff --git a/v5.0.1/_sources/modelling/unit_operations/inlet.rst.txt b/v5.0.1/_sources/modelling/unit_operations/inlet.rst.txt
new file mode 100644
index 000000000..c727738bd
--- /dev/null
+++ b/v5.0.1/_sources/modelling/unit_operations/inlet.rst.txt
@@ -0,0 +1,23 @@
+.. _inlet_model:
+
+Inlet
+~~~~~
+
+A system inlet unit operation is a pseudo unit operation since there is no physical correspondence.
+The inlet serves as a mass source in the network of unit operations.
+Consequently, it only possesses an outlet port and no inlet port.
+Note that an inlet unit operation can provide arbitrary many components and there can be arbitrary many inlet unit operations in a network.
+
+An inlet unit operation provides a feed in which the concentration of each component is given by a profile.
+The most common profile is a piecewise cubic polynomial, which can both represent discontinuous signals (e.g., pulse or step) and smooth :math:`C^2` signals (cubic spline):
+
+.. math::
+
+ \begin{aligned}
+ c_i(t) = \sum_{k = 1}^{N_{\text{sect}}} \mathbb{R}_{\left[t_k, t_{k+1} \right)}(t) \left[ a_{k,i} \left( t - t_k \right)^3 + b_{k,i} \left( t - t_k \right)^2 + d_{k,i} \left( t - t_k \right) + f_{k,i} \right],
+ \end{aligned}
+
+where :math:`0 \leq t_1 < t_2 < \dots < t_{N_{\text{sect}} + 1} \leq T_{\text{sim}}` is a decomposition of the simulation time interval :math:`\left[0, T_{\text{sim}}\right]` into pieces :math:`\left[t_k, t_{k+1} \right)`.
+On each piece, the profile is given by a cubic (fourth order) polynomial shifted to the beginning :math:`t_k` of the piece.
+
+For information on model parameters see :ref:`inlet_config`.
diff --git a/v5.0.1/_sources/modelling/unit_operations/lumped_rate_model_with_pores.rst.txt b/v5.0.1/_sources/modelling/unit_operations/lumped_rate_model_with_pores.rst.txt
new file mode 100644
index 000000000..dd091e233
--- /dev/null
+++ b/v5.0.1/_sources/modelling/unit_operations/lumped_rate_model_with_pores.rst.txt
@@ -0,0 +1,94 @@
+.. _lumped_rate_model_with_pores_model:
+
+Lumped rate model with pores (LRMP)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The lumped rate model with pores :cite:`Guiochon2006,Felinger2004` deviates from the general rate model (see Section :ref:`general_rate_model_model`) by neglecting pore diffusion.
+The particle phase :math:`c^p_j` is still there, but no mass transfer happens except for binding and film diffusion.
+Hence, the model equations are given by
+
+.. math::
+ :label: ModelColumnGRM
+
+ \begin{aligned}
+ \frac{\partial c^\ell_i}{\partial t} &= -u \frac{\partial c^\ell_i}{\partial z} + D_{\text{ax},i} \frac{\partial^2 c^\ell_i}{\partial z^2} - \frac{1}{\beta_c} \sum_{j} d_j \frac{3}{r_{p,j}} k_{f,j,i}\left[ c^\ell_i - c^p_{j,i} \right] + f_{\text{react},i}^\ell\left(c^\ell\right),
+ \end{aligned}
+
+.. math::
+ :label: ModelParticleLRMP
+
+ \begin{aligned}
+ \frac{\partial c^p_{j,i}}{\partial t} + \frac{1 - \varepsilon_{p,j}}{F_{\text{acc},j,i} \varepsilon_{p,j}} \frac{\partial}{\partial t} \sum_{m_{j,i}} c^s_{j,i,m_{j,i}} &= \frac{3}{F_{\text{acc},j,i} \varepsilon_{p,j} r_{p,j}}k_{f,j,i}\left[ c^\ell_i - c^p_{j,i} \right] \\
+ &+ f_{\text{react},j,i}^p\left( c_j^p, c_j^s \right) + \frac{1 - \varepsilon_{p,j}}{F_{\text{acc},j,i} \varepsilon_{p,j}} f_{\text{react},j,i}^s\left( c_j^p, c_j^s \right)
+ \end{aligned}
+
+with the same meanings of variables and parameters as in the general rate model.
+The equations are complemented by Danckwerts boundary conditions :cite:`Danckwerts1953`
+
+.. math::
+
+ \begin{aligned}
+ u c_{\text{in},i}(t) &= u c^\ell_i(t,0) - D_{\text{ax},i} \frac{\partial c^\ell_i}{\partial z}(t, 0) & \forall t > 0,\\
+ \frac{\partial c^\ell_i}{\partial z}(t, L) &= 0 & \forall t > 0.
+ \end{aligned}
+
+As for the general rate model, both quasi-stationary and dynamic binding models are supported:
+
+.. math::
+
+ \begin{aligned}
+ \text{quasi-stationary: }& & 0 &= f_{\text{ads},j}\left( c^p_j, c^s_j\right), \\
+ \text{dynamic: }& & \frac{\partial c^s_j}{\partial t} &= f_{\text{ads},j}\left( c^p_j, c^s_j\right) + f_{\text{react},j}^s\left( c_j^p, c_j^s \right).
+ \end{aligned}
+
+By default, the following initial conditions are applied for all :math:`z \in [0,L]`:
+
+.. math::
+
+ \begin{aligned}
+ c^\ell_i(0, z) &= 0, & c^p_{j,i}(0, z) &= 0, & c^s_{j,i,m_{j,i}}(0,z) &= 0.
+ \end{aligned}
+
+:ref:`MUOPGRMMultiParticleTypes` types are supported.
+This model can also be used to simulate :ref:`MUOPGRMSizeExclusion`.
+For the specification of flow rate and direction, the same holds as for the general rate model (see Section :ref:`MUOPGRMflow`).
+
+For information on model parameters see :ref:`lumped_rate_model_with_pores_config`.
+
+Radial flow LRMP
+^^^^^^^^^^^^^^^^
+
+The radial flow LRMP describes transport of solute molecules through the interstitial column volume by radial convective flow, band broadening caused by radial dispersion, mass transfer resistance through a stagnant film around the beads, and adsorption to the inner bead surfaces.
+
+The main assumptions are:
+
+- The shells of the column are homogenous in terms of interstitial volume, fluid flow, and distribution of components.
+ Thus, only one spatial coordinate in radial direction :math:`\rho` is needed and axial transport is neglected in the column bulk volume.
+
+- The bead radii :math:`r_{p}` are much smaller than the column radius :math:`\mathrm{P}-\mathrm{P}_c`, with :math:`\mathrm{P}` and :math:`\mathrm{P}_c` being the inner and outer column radius respectively, and the column length :math:`L`.
+ Therefore, the beads can be seen as continuously distributed inside the column (i.e., at each point there is interstitial and bead volume).
+
+- The fluids are incompressible, i.e. the velocity field :math:`\mathrm{V} \colon \mathbb{R}^3 \to \mathbb{R}^3` submits to :math:`\operatorname{div}\left( \mathrm{V} \right) \equiv 0`.
+ That is, the volumetric flow rate at the inner and outer column radius are the same.
+
+Consider a hollow (double walled) column with inner column diameter :math:`\mathrm{P}_c>0` and outer diameter :math:`\mathrm{P}>\mathrm{P}_c`, filled with spherical beads of (possibly) multiple types with radius :math:`r_{p,j} \ll L` (see :numref:`ModelGRMColumn`), where :math:`j` is the particle type index. The mass balance in the interstitial column volume is described by
+
+.. math::
+ :label: ModelRadialColumnGRM
+
+ \begin{aligned}
+ \frac{\partial c^\ell_i}{\partial t} &= -\frac{u}{\rho} \frac{\partial c^\ell_i}{\partial \rho} + D_{\text{rad},i} \frac{1}{\rho} \frac{\partial}{\partial \rho} \left( \rho \frac{\partial c^\ell_i}{\partial \rho} \right) - \frac{1}{\beta_c} \sum_{j} d_j \frac{3}{r_{p,j}} k_{f,j,i}\left[ c^\ell_i - c^p_{j,i} \right] + f_{\text{react},i}^\ell\left(c^\ell\right),
+ \end{aligned}
+
+The equations are complemented by Eq. :eq:`ModelParticleLRMP` and the Danckwerts boundary conditions :cite:`Danckwerts1953`
+
+.. math::
+
+ \begin{aligned}
+ u c_{\text{in},i}(t) &= u c^\ell_i(t,0) - D_{\text{rad},i} \frac{\partial c^\ell_i}{\partial \rho}(t, 0) & \forall t > 0,\\
+ \frac{\partial c^\ell_i}{\partial \rho}(t, \mathrm{P}) &= 0 & \forall t > 0.
+ \end{aligned}
+
+The complementing binding equations are described by the same equations as for the axial LRMP.
+
+For information on model parameters see :ref:`radial_flow_models_config` in addition to :ref:`lumped_rate_model_with_pores_config`.
diff --git a/v5.0.1/_sources/modelling/unit_operations/lumped_rate_model_without_pores.rst.txt b/v5.0.1/_sources/modelling/unit_operations/lumped_rate_model_without_pores.rst.txt
new file mode 100644
index 000000000..438cd5802
--- /dev/null
+++ b/v5.0.1/_sources/modelling/unit_operations/lumped_rate_model_without_pores.rst.txt
@@ -0,0 +1,94 @@
+.. _lumped_rate_model_without_pores_model:
+
+Lumped rate model without pores (LRM)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The lumped rate model without pores :cite:`Guiochon2006,Felinger2004` deviates from the lumped rate model with pores (see Section :ref:`lumped_rate_model_with_pores_model`) by neglecting pores completely.
+The particle phase :math:`c^p` is removed and the porosity :math:`\varepsilon_t` is taken as total porosity
+
+.. math::
+ :label: TotalPorosity
+
+ \begin{aligned}
+ \varepsilon_t = \varepsilon_c + \left( 1 - \varepsilon_c \right) \varepsilon_p.
+ \end{aligned}
+
+The phase ratio is denoted by :math:`\beta_t = \varepsilon_t / (1 - \varepsilon_t)` accordingly.
+The model equations are given by
+
+.. math::
+ :label: ModelColumnLRM
+
+ \begin{aligned}
+ \frac{\partial c^\ell_i}{\partial t} + \frac{1}{\beta_t} \frac{\partial}{\partial t} \sum_{m_i} c^s_{i,m_i} &= -u \frac{\partial c^\ell_i}{\partial z} + D_{\text{ax},i} \frac{\partial^2 c^\ell_i}{\partial z^2} + f_{\text{react},i}^\ell\left( c^\ell, c^s \right) + \frac{1}{\beta_t} f_{\text{react},i}^s\left( c^\ell, c^s \right),
+ \end{aligned}
+
+where :math:`\beta_t = \varepsilon_t / (1 - \varepsilon_t)` denotes the (total) phase ratio.
+The equations are complemented by Danckwerts boundary conditions :cite:`Danckwerts1953`
+
+.. math::
+
+ \begin{aligned}
+ u c_{\text{in},i}(t) &= u c^\ell_i(t,0) - D_{\text{ax},i} \frac{\partial c^\ell_i}{\partial z}(t, 0) & \forall t > 0,\\
+ \frac{\partial c^\ell_i}{\partial z}(t, L) &= 0 & \forall t > 0.
+ \end{aligned}
+
+Both quasi-stationary and dynamic binding models are supported:
+
+.. math::
+
+ \begin{aligned}
+ \text{quasi-stationary: }& & 0 &= f_{\text{ads}}\left( c^\ell, c^s\right), \\
+ \text{dynamic: }& & \frac{\partial q}{\partial t} &= f_{\text{ads}}\left( c^\ell, c^s\right) + f_{\text{react}}^s\left( c^\ell, c^s \right).
+ \end{aligned}
+
+By default, the following initial conditions are applied for all :math:`z \in [0,L]`:
+
+.. math::
+
+ \begin{aligned}
+ c^\ell_i(0, z) &= 0, & c^s_{i,m_i}(0,z) &= 0.
+ \end{aligned}
+
+Note that by setting :math:`\varepsilon_t = 1`, removing all bound states by setting :math:`N_{\text{bnd},i} = 0` for all components :math:`i`, and applying no binding model, a dispersive plug flow reactor (DPFR) is obtained.
+For the specification of flow rate and direction, the same holds as for the general rate model (see Section :ref:`MUOPGRMflow`).
+
+For information on model parameters see :ref:`lumped_rate_model_without_pores_config`.
+
+Radial flow LRM
+^^^^^^^^^^^^^^^
+
+The radial flow LRM describes transport of solute molecules through the interstitial column volume by radial convective flow, band broadening caused by radial dispersion, and adsorption to the bead surfaces.
+
+The main assumptions are:
+
+- The shells of the column are homogenous in terms of interstitial volume, fluid flow, and distribution of components.
+ Thus, only one spatial coordinate in radial direction :math:`\rho` is needed and axial transport is neglected in the column bulk volume.
+
+- The bead radii :math:`r_{p}` are much smaller than the column radius :math:`\mathrm{P}-\mathrm{P}_c`, with :math:`\mathrm{P}` and :math:`\mathrm{P}_c` being the inner and outer column radius respectively, and the column length :math:`L`.
+ Therefore, the beads can be seen as continuously distributed inside the column (i.e., at each point there is interstitial and bead volume).
+
+- The fluids are incompressible, i.e. the velocity field :math:`\mathrm{V} \colon \mathbb{R}^3 \to \mathbb{R}^3` submits to :math:`\operatorname{div}\left( \mathrm{V} \right) \equiv 0`.
+ That is, the volumetric flow rate at the inner and outer column radius are the same.
+
+Consider a hollow (double walled) column with inner column diameter :math:`\mathrm{P}_c>0` and outer diameter :math:`\mathrm{P}>\mathrm{P}_c`, filled with spherical beads. The mass balance in the interstitial column volume is described by
+
+.. math::
+ :label: ModelRadialColumnLRM
+
+ \begin{aligned}
+ \frac{\partial c^\ell_i}{\partial t} + \frac{1}{\beta_t} \frac{\partial}{\partial t} \sum_{m_i} c^s_{i,m_i} &= -\frac{u}{\rho} \frac{\partial c^\ell_i}{\partial \rho} + D_{\text{rad},i} \frac{1}{\rho} \frac{\partial}{\partial \rho} \left( \rho \frac{\partial c^\ell_i}{\partial \rho} \right) + f_{\text{react},i}^\ell\left( c^\ell, c^s \right) + \frac{1}{\beta_t} f_{\text{react},i}^s\left( c^\ell, c^s \right),
+ \end{aligned}
+
+The equations are complemented by Danckwerts boundary conditions :cite:`Danckwerts1953`
+
+.. math::
+
+ \begin{aligned}
+ u c_{\text{in},i}(t) &= u c^\ell_i(t,0) - D_{\text{rad},i} \frac{\partial c^\ell_i}{\partial \rho}(t, 0) & \forall t > 0,\\
+ \frac{\partial c^\ell_i}{\partial \rho}(t, \mathrm{P}) &= 0 & \forall t > 0.
+ \end{aligned}
+
+The complementing binding equations are described by the same equations as for the axial LRM.
+
+For information on model parameters see :ref:`radial_flow_models_config` in addition to :ref:`lumped_rate_model_without_pores_config`.
diff --git a/v5.0.1/_sources/modelling/unit_operations/multi_channel_transport_model.rst.txt b/v5.0.1/_sources/modelling/unit_operations/multi_channel_transport_model.rst.txt
new file mode 100644
index 000000000..7f5cd8e25
--- /dev/null
+++ b/v5.0.1/_sources/modelling/unit_operations/multi_channel_transport_model.rst.txt
@@ -0,0 +1,145 @@
+.. _multi_channel_transport_model_model:
+
+Multichannel Transport model (MCT model)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The Multichannel Transport (MCT) model in CADET is based on a class of compartment models introduced by Jonas Bühler et al. :cite:`Buehler2014`, which was originally developed in the field of plant sciences.
+There it is used to determine transport and storage parameters of radioactive labelled tracer molecules from positron emission tomography (PET) or magnetic resonance imaging (MRI) based experimental data.
+The model represents main functions of vascular transport pathways: axial transport of the tracer, diffusion in axial direction, lateral exchange between compartments and storage of tracer in compartments. Here, the axial direction represents the length of the stem of the plant and the lateral dimension its cross section. In the MCT context, the compartments of the model class are also referred to as channels.
+
+The same model equations arise in describing other biological and technical processes outside of the field of plant sciences, where solutes are transported and exchanged between spatially separated compartments, for example liquid-liquid chromatography (LLC). Here, components in a mixture are separated based on their interactions with two immiscible phases of a biphasic solvent system :cite:`Morley2020`. The MCT model represents these phases by channels with respective transport and exchange properties. While the current implementation only covers linear driving forces for the exchange processes, the reaction module in CADET allows to add non-linear driving forces for the exchange processes and other chemical reactions in the channels.
+
+The MCT model equations are given for all channels :math:`l \in \{1, \dots, N_k\}` and components :math:`i \in \{1, \dots, N_c\}` by
+
+.. math::
+ :label: ModelMCT
+
+ \begin{aligned}
+ \frac{\partial c_{i,l}^\ell}{\partial t}
+ =
+ - u_l \frac{\partial c_{i,l}^\ell}{\partial z}
+ + D_{\text{ax},i,l} \frac{\partial^2 c_{i,l}^\ell}{\partial z^2}
+ + \sum_{k=1}^{N_k} e^i_{kl} c_{i,k}^\ell A_k / A_l - e^i_{lk} c_{i,l}^\ell
+ + f_{\text{react},i,l}\left( c^\ell_l \right),
+ \end{aligned}
+
+where :math:`e^i_{lk}` denotes the exchange rate of component :math:`i` from channel :math:`l` to channel :math:`k`, and :math:`A_l` denotes the cross section area of channel :math:`l`.
+The equations are complemented by Danckwerts boundary conditions :cite:`Danckwerts1953`
+
+.. math::
+
+ \begin{aligned}
+ u_l c^\ell_{\text{in},i,l}(t) &= u_l c^\ell_{i,l}(t,0) - D_{\text{ax},i,l} \frac{\partial c^\ell_{i,l}}{\partial z}(t, 0) & \forall t > 0,\\
+ \frac{\partial c^\ell_{i,l}}{\partial z}(t, L) &= 0 & \forall t > 0.
+ \end{aligned}
+
+
+The MCT model describes :math:`N_k` one-dimensional spatially parallel channels (see :numref:`fig-model-class`).
+In each channel :math:`l`, molecules of different species :math:`i`, represented by a liquid phase concentration :math:`c^\ell_{i,l}`, can be transported with flux velocities :math:`v_{i,l}` while undergoing axial diffusion: :math:`D_{\text{ax},i,l}`.
+Molecules can be laterally exchanged between any pair of channels :math:`l` and :math:`k` with rate constant :math:`e^i_{lk}`.
+We note that the exchange fluxes are computed from the exchange rates w.r.t. the source channel volume, that is, channels with the same exchange rate but different volume will produce differently large exchange fluxes.
+For further elaboration on this, please refer to the second use-case section below.
+If reactions are considered, the term :math:`f_{\text{react},i,l}\left(c^\ell_l\right)` represents the net change of concentration :math:`c^\ell_{il}` due to reactions in channel :math:`l` involving component :math:`i`.
+
+For information on model parameters see :ref:`multi_channel_transport_model_config`.
+
+.. _fig-model-class:
+.. figure:: multi_channel_transport_model_class.png
+
+ Illustration of the Multichannel Transport model class and relevant parameters.
+ Figure taken from Jonas Bühler et al. :cite:`Buehler2014`.
+
+The cross-section area :math:`A_N` is individually specified for each channel (see :numref:`fig-variable-areas`). The MCT is agnostic to the shape of these cross sections, while their ratio determines the distribution of the volumetric flow.
+
+
+.. _fig-variable-areas:
+.. figure:: mct_variable_areas.png
+
+ Scheme of exemplary channels with different cross section areas and arbitrary exchange between channels.
+
+Use-case: Tracer transport in plants
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The MCT can be used to model tracer transport in plants, following Jonas Bühler et al. :cite:`Buehler2014`.
+There, the model class is defined by a system of partial differential equations:
+
+.. math::
+
+ \frac{\partial \boldsymbol{\rho}(x,t)}{\partial t} = \left({A}^T-{V}\frac{\partial}{\partial x}+{D}\frac{\partial^2}{\partial x^2} \right){\boldsymbol{\rho}(x,t)}
+
+- :math:`\boldsymbol{\rho}=({\rho}_1 \dots {\rho}_N)^T` is the tracer density within each channel :math:`N` at position :math:`x` and time :math:`t`.
+- The coupling matrix :math:`A` contains exchange rates :math:`e_{lk}` describing the lateral tracer transport from channel :math:`l` to channel :math:`k`. All diagonal elements :math:`e_{ll}` in the first term are zero indicating there is no tracer exchange of one channel with itself. The second term ensures mass conservation and removes exchanged tracer from each channel respectively, by subtracting the sum of all exchange rates of a row (and therefore channel) from the diagonal. The third term describes the decay of a radioactive tracer at a tracer specific rate :math:`\lambda`.
+
+.. math::
+
+ A=\begin{bmatrix}
+ 0 & e_{12} & \dots & e_{1N} \\
+ e_{21} & \ddots & & \vdots\\
+ \vdots & & \ddots & e_{(N-1)N}\\
+ e_{N1} & \dots & e_{N(N-1)} & 0
+ \end{bmatrix}-
+ \begin{bmatrix}
+ {\sum_{k=1}^{N} e_{1k}} & & 0 \\
+ & \ddots & \\
+ 0 & & {\sum_{k=1}^{N} e_{Nk}}
+ \end{bmatrix}-
+ \lambda {I}
+
+- The diagonal matrix :math:`V` contains the flux velocities :math:`v_{l}` for each channel.
+
+.. math::
+
+ V=\begin{bmatrix}
+ v_1 & & 0 \\
+ & \ddots & \\
+ 0 & & v_N
+ \end{bmatrix}
+
+- The diagolal matrix :math:`D` contains the dispersion coefficients :math:`d_{l}` for each channel.
+
+.. math::
+
+ D=\begin{bmatrix}
+ d_1 & & 0 \\
+ & \ddots & \\
+ 0 & & d_N
+ \end{bmatrix}
+
+
+All parameters can be zero to exclude the respective mechanism from the model.
+A chart of all resulting valid models of the model family can be found in Bühler et al. :cite:`Buehler2014`.
+
+
+Use-case: Lumped Rate Model without pores and linear kinetic binding
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The MCT can be used to model a LRM with linear binding, if specific parameters are chosen.
+To demonstrate this, we derive the LRM with linear binding equations from the MCT defined above.
+
+We consider the MCT with two channels, which are used to represent the liquid and solid phase of the LRM, and only take one component into account, for the sake of brevity.
+The channel volumes :math:`V_1, V_2 > 0` and cross section areas :math:`A_1,A_2>0` are chosen according to the total column porosity (here :math:`\varepsilon_t \in (0,1)` of the LRM, i.e. e.g. :math:`A_1 = \varepsilon_t A`, with :math:`A` being the LRM column cross section area.
+We set the transport parameters of the second channel to zero, change notation for the concentrations, :math:`c_{0,1}^\ell, c_{0,2}^\ell \rightarrow c^\ell, c^s`, and get
+
+.. math::
+
+ \frac{\partial c^\ell}{\partial t} = - u \frac{\partial c^\ell}{\partial z} + D_\text{ax} \frac{\partial^2 c^\ell}{\partial z^2} + e_{21}^0 c^s A_2 / A_1 - e_{12}^0 c^\ell,
+ \\
+ \frac{\partial c^s}{\partial t} = e_{12}^0 c^\ell A_1 / A_2 - e_{21}^0 c^s.
+
+To model the linear binding, we define the exchange rates according to the adsorption and desorption rates and adjust for the channel volumes:
+Since the binding fluxes are computed from the binding rates w.r.t bead surface area (i.e. solid volume), we need to adjust the exchange rate from the first to the second channel accordingly; remember that exchange fluxes are computed based on exchange rates w.r.t channel (in this case liquid) volume.
+That is, we define :math:`e_{12}^0 = k_a A_2 / A_1 = k_a \frac{1-\varepsilon_t}{\varepsilon_t}` and :math:`e_{12}^0 = k_d` and get
+
+.. math::
+
+ \frac{\partial c^\ell}{\partial t} = - u \frac{\partial c^\ell}{\partial z} + D_\text{ax} \frac{\partial^2 c^\ell}{\partial z^2} + k_d A_2 / A_1 c^s - k_a A_2 / A_1 c^\ell,
+ \\
+ \frac{\partial c^s}{\partial t} = k_a c^\ell - k_d c^s.
+
+Adding :math:`\frac{1-\varepsilon_t}{\varepsilon_t}` times the second channel equation to the first channel equation, we get the standard formulation of the :ref:`lumped_rate_model_without_pores_model` with (kinetic) linear binding:
+
+.. math::
+
+ \frac{\partial c^\ell}{\partial t} + \frac{1-\varepsilon_t}{\varepsilon_t} \frac{\partial c^s}{\partial t} = - u \frac{\partial c^\ell}{\partial z} + D_\text{ax} \frac{\partial^2 c^\ell}{\partial z^2},
+ \\
+ \frac{\partial c^s}{\partial t} = k_a c^\ell - k_d c^s.
\ No newline at end of file
diff --git a/v5.0.1/_sources/modelling/unit_operations/outlet.rst.txt b/v5.0.1/_sources/modelling/unit_operations/outlet.rst.txt
new file mode 100644
index 000000000..461436f62
--- /dev/null
+++ b/v5.0.1/_sources/modelling/unit_operations/outlet.rst.txt
@@ -0,0 +1,15 @@
+.. _outlet_model:
+
+Outlet
+~~~~~~
+
+A system outlet unit operation is a pseudo unit operation since there is no physical correspondence.
+The outlet serves as a sink (terminal node) in the network of unit operations.
+Since any terminal node in the network is a sink (see Section :ref:`networks`), outlet unit operations are not strictly necessary.
+However, in some applications (e.g., SMB) only a certain fraction of a unit operation’s output is taken out of the system and the rest is recycled.
+In this case, outlet unit operations are required in order to avoid unbalanced mass flow in the other unit operations.
+
+Outlets can also be of help if the output of multiple unit operations merges together leaving the network.
+Instead of manually adding the streams together in a post-processing step, the unit operations can be connected to the same outlet unit.
+
+For information on model parameters see :ref:`outlet_config`.
diff --git a/v5.0.1/_sources/publications.md.txt b/v5.0.1/_sources/publications.md.txt
new file mode 100644
index 000000000..22db96e46
--- /dev/null
+++ b/v5.0.1/_sources/publications.md.txt
@@ -0,0 +1,28 @@
+
+**General CADET-Core:**
+
+- Leweke, S.; von Lieres, E.: `Chromatography Analysis and Design Toolkit (CADET) `_, Computers and Chemical Engineering **113** (2018), 274294.
+
+- von Lieres, E.; Andersson, J.: `A fast and accurate solver for the general rate model of column liquid chromatography `_, Computers and Chemical Engineering **34,8** (2010), 11801191.
+
+**CADET-Core numerics:**
+
+- Breuer, J. M.; Leweke, S.; Schmlder, J.; Gassner, G.; von Lieres, E.: `Spatial discontinuous Galerkin spectral element method for a family of chromatography models in CADET `_, Computers and Chemical Engineering **177** (2023), 108340.
+
+- Leweke, S.; von Lieres, E.: `Fast arbitrary order moments and arbitrary precision solution of the general rate model of column liquid chromatography with linear isotherm `_, Computers and Chemical Engineering **84** (2016), 350362.
+
+- Pttmann, A.; Schnittert, S.; Naumann, U.; von Lieres, E.: `Fast and accurate parameter sensitivities for the general rate model of column liquid chromatography `_, Computers and Chemical Engineering **56** (2013), 4657.
+
+**Selected applications and use-cases of CADET-Core:**
+
+- Heymann, W.; Glaser, J.; Schlegel, F.; Johnson, W.; Rolandi, P.; von Lieres, E.: `Advanced score system and automated search strategies for parameter estimation in mechanistic chromatography modeling `_, Journal of Chromatography A **1661** (2022): 462693.
+
+- He, Q.-L.; Leweke, S.; von Lieres, E.: `Efficient numerical simulation of simulated moving bed chromatography with a single-column solver `_, Computers and Chemical Engineering **111** (2018), 183198.
+
+- Freier, L.; von Lieres, E.: `Robust multi-objective global optimization of stochastic processes with a case study in gradient elution chromatography `_, Biotechnology Journal **13,1** (2018), 1700257.
+
+- Freier, L.; von Lieres, E.: [Multi-objective global optimization (MOGO): `Algorithm and case study in gradient elution chromatography `_, Biotechnology Journal **12,7** (2017), 1600613.
+
+- Diedrich, J.; Heymann, W.; Leweke, S.; Kunert, C.; Johnson, W.; Hunt, S.; Todd, B.; von Lieres, E.: `Multi-state steric mass-action model and case study on complex high loading behavior of mAb on ion exchange tentacle resin `_, Journal of Chromatography A **1525** (2017), 6070.
+
+- Pttmann, A.; Schnittert, S.; Leweke, S.; von Lieres, E.: `Utilizing algorithmic differentiation to efficiently compute chromatograms and parameter sensitivities `_, Chemical Engineering Science, **139** (2016), 152162.
diff --git a/v5.0.1/_sources/requirements.txt b/v5.0.1/_sources/requirements.txt
new file mode 100644
index 000000000..d68e57434
--- /dev/null
+++ b/v5.0.1/_sources/requirements.txt
@@ -0,0 +1,5 @@
+sphinx
+sphinx-sitemap
+sphinxcontrib-bibtex
+sphinx_multiversion
+myst-parser
diff --git a/v5.0.1/_sources/simulation/index.rst.txt b/v5.0.1/_sources/simulation/index.rst.txt
new file mode 100644
index 000000000..a242b5862
--- /dev/null
+++ b/v5.0.1/_sources/simulation/index.rst.txt
@@ -0,0 +1,269 @@
+.. _simulation:
+
+Simulation
+==========
+
+This chapter gives an overview of the simulation process and the different steps involved.
+
+CADET uses a backward-differentiation-formula (BDF) time discretization as implemented by the IDAS solver from SUNDIALS :cite:`Hindmarsh2005`.
+Each time step requires the solution of a nonlinear algebraic system of equations is performed by a Newton method.
+Since chromatographic systems can exhibit strong nonlinearity and stiff systems, the Jacobian of the equation system is always updated (i.e., an “exact” Newton method is used).
+
+.. _SimFlowchart:
+.. figure:: time_integration.png
+
+ General time integration procedure
+
+The general control flow of a simulation is shown in :numref:`SimFlowchart`.
+Some aspects of the tasks involved are discussed below.
+
+.. _SimTimeSectionsTransitions:
+
+Time sections and transitions
+-----------------------------
+
+The timespan :math:`\left[t_0, t_{\text{end}}\right]` of the simulation can be divided into multiple time sections :math:`\left[t_i, t_{i+1}\right]` with
+
+.. math::
+
+ \begin{aligned}
+ t_0 < t_1 < \dots < t_i < t_{i+1} < \dots < t_{\text{end}}.
+ \end{aligned}
+
+Time sections are used for various purposes, for example, for defining piecewise polynomials used as inlet profiles or external function, for changing operating conditions such as flow rates, or for changing the connectivity in a network of unit operations.
+A sequence of (one or more) time sections with smooth transitions is called a time slice (see :numref:`SimTimeSections`).
+
+A transition from one section to the next can either be smooth or discontinuous.
+On smooth transitions, the time integrator can just step over the section transition.
+Contrary to smooth transitions, a discontinuous transition requires some extra work in resetting the time integrator and finding consistent initial conditions for the next time slice.
+
+.. _SimTimeSections:
+.. figure:: sections.png
+
+ Time sections, time slices, and transitions between them
+
+.. _SimTimeSectionsSpecification:
+
+Time section specification
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Time sections are specified by an array (``SECTION_TIMES``, see Tab. :ref:`FFSolverSections`) which contains the :math:`t_i` that denote the start- and endpoint of a time section :math:`\left[t_i, t_{i+1}\right]`.
+This means, that the array contains :math:`n+1` values if there are :math:`n` sections.
+The smoothness of a section transition is indicated by the array ``SECTION_CONTINUITY``, which contains :math:`n-1` elements if there are :math:`n` sections.
+
+.. _SimSetup:
+
+Setup
+-----
+
+In the setup phase, the model specification is checked and data structures are prepared for the simulation.
+The simulation can be run multiple times with different initial conditions, which also allows to continue a simulation.
+However, the model structure must not change after this point.
+This means, the different model and submodel types (e.g., unit operation model, binding model) as well as their discretization (i.e., number of cells) and structure (i.e., number of components, number of reactions) are fixed. On the contrary, their parameters (e.g., flow rates, porosities, dispersion coefficients) may change on different runs of a prepared simulation.
+
+This assumption allows an accelerated simulation as there is no memory allocation performed during time integration.
+
+.. _SimConsistentInit:
+
+Consistent initialization
+-------------------------
+
+At the beginning of the simulation and on discontinuous section transitions, consistent initial conditions have to be computed.
+In CADET, the general differential-algebraic equation (DAE)
+
+.. math::
+
+ \begin{aligned}
+ F(t, y, \dot{y}, p) = 0
+ \end{aligned}
+
+consists of purely algebraic equations that do not contain :math:`\dot{y}` and dynamic equations.
+Let :math:`\mathcal{I}_d` be the index set of dynamic equations and :math:`\mathcal{I}_a` the index set of algebraic equations.
+The general DAE can be decomposed into
+
+.. math::
+
+ \begin{aligned}
+ M \dot{y}_{\mathcal{I}_d} + G_{\mathcal{I}_d}(t, y, p) &= 0, \\
+ G_{\mathcal{I}_a}(t, y, p) &= 0,
+ \end{aligned}
+
+where :math:`M` is the so called “mass matrix”, which essentially consist of the state time derivative Jacobian :math:`\partial F / \partial \dot{y}`.
+Furthermore, it is assumed that the Jacobian of the algebraic equations with respect to the algebraic variables :math:`\partial G_{\mathcal{I}_a} / \partial y_{\mathcal{I}_a}` is invertible.
+Hence, the original DAE is of differential index 1.
+
+Given :math:`y_{\mathcal{I}_d}`, consistently initialization means finding :math:`y_{\mathcal{I}_a}`, :math:`y_{\mathcal{I}_d}`, and :math:`\dot{y}` such that the DAE holds at the initial time point :math:`t_0` and can be solved for some non-empty time span.
+Thus, consistent initial conditions :math:`y_0` and :math:`\dot{y}_0` satisfy
+
+.. math::
+
+ \begin{aligned}
+ 0 &= M \dot{y}_{\mathcal{I}_d} + G_{\mathcal{I}_d}\left(t_0, y, p\right), \\
+ 0 &= G_{\mathcal{I}_a}\left(t_0, y, p\right), \\
+ 0 &= \frac{\partial G_{\mathcal{I}_a}}{\partial t}\left(t_0, y, p\right) + \frac{\partial G_{\mathcal{I}_a}}{\partial y}\left(t_0, \dot{y}, p\right).
+ \end{aligned}
+
+The last equation, which determines :math:`\dot{y}_{\mathcal{I}_a}`, arises from taking the total derivative with respect to time :math:`t` of the second equation.
+
+Concluding, a nonlinear algebraic equation system has to be solved in order to compute consistent initial conditions.
+The error in the solution of these systems is controlled by the ``ALGTOL`` setting (see Tab. :ref:`FFSolverTime`).
+
+.. _SimTimeIntegration:
+
+Time stepping
+-------------
+
+Given the general differential-algebraic equation
+
+.. math::
+
+ \begin{aligned}
+ F(t, y, \dot{y}, p) = 0, \qquad y\left(t_0 \right) = y_0, \qquad \dot{y}\left(t_0 \right) = \dot{y}_0
+ \end{aligned}
+
+with consistent initial values :math:`y_0` and :math:`\dot{y}_0`, the BDF discretization uses past time steps :math:`y\left( t_{\tau - i} \right)` to compute the current :math:`\dot{y}\left(t_\tau\right)` as
+
+.. math::
+
+ \begin{aligned}
+ \dot{y}\left(t_\tau\right) = \frac{1}{\Delta t_\tau} \sum_{i=0}^{q_{\tau}} \alpha_{\tau,i} y\left(t_{\tau-i}\right),
+ \end{aligned}
+
+where :math:`t_\tau` denotes some time step.
+The IDAS time integrator adaptively changes the step size :math:`{\Delta t_\tau = t_\tau-t_{\tau-1}}` and order :math:`1 \le q_{\tau} \le 5` in each time step and automatically determines the corresponding coefficients :math:`\alpha_{\tau,i}`.
+This *ansatz* is inserted into the DAE and the resulting nonlinear algebraic equation system is solved for :math:`y_{\tau} = y\left( t_\tau \right)` using a Newton method.
+
+.. math::
+ :label: BDFNonlinSystem
+
+ \begin{aligned}
+ H(y_\tau) = F\left(t_\tau,y_\tau,\frac{1}{\Delta t_\tau} \,\sum_{i=0}^{q_\tau}{\alpha_{\tau,i} \, y_{\tau-i}}, p\right) = 0
+ \end{aligned}
+
+This requires (possibly many) solutions of linear equation systems involving the Jacobian of :math:`H` given by
+
+.. math::
+
+ \begin{aligned}
+ \frac{\mathrm{d}H}{\mathrm{d}y_\tau} = \frac{\partial F}{\partial y} + \frac{\alpha_{\tau,0}}{\Delta t_\tau} \frac{\partial F}{\partial \dot{y}}.
+ \end{aligned}
+
+The Jacobian of :math:`H`, which is the linear combination of the partial derivatives :math:`\partial F / \partial y` and :math:`\partial F / \partial \dot{y}`, can be calculated in two ways.
+The fastest way is the analytic computation, which is to be preferred if available.
+However, the implementation of the analytic Jacobian can be time consuming and complicated, especially when quickly testing new models.
+As a remedy, CADET offers to compute the complicated Jacobian :math:`\partial F / \partial y` automatically by automatic differentiation (AD).
+The much simpler Jacobian :math:`\partial F / \partial \dot{y}` has to be implemented manually.
+
+.. _SimTimeIntegrationAdaptivity:
+
+Adaptivity
+~~~~~~~~~~
+
+The BDF order :math:`q_{\tau}` and size of the time step :math:`t_\tau` are chosen such that the error bounds are satisfied with minimal work.
+Equation :eq:`BDFNonlinSystem` is solved with a Newton iteration using very few iterations (``MAX_NEWTON_ITER`` from Table :ref:`FFSolverTime`) since the starting point is assumed to be close to the solution as the time steps are small.
+If the solution of the Newton iteration does not pass the *convergence test*, the step size :math:`t_\tau` is reduced and the Newton iteration is tried again.
+This may happen at most ``MAX_CONVTEST_FAIL`` times, otherwise time integration is aborted with failure.
+Having a solution of the Newton iteration at hand, a *local truncation error test* is performed which controls the error of the BDF method.
+If this test fails, step size :math:`t_\tau` and order :math:`q_{\tau}` are adapted and the process restarts with solving the nonlinear system Eq. :eq:`BDFNonlinSystem`.
+The error test may be failed at most ``MAX_ERRTEST_FAIL`` times before time integration is aborted with failure.
+
+Error bounds for the local truncation error test are specified by an absolute tolerance (``ABSTOL``) and a relative tolerance (``RELTOL``).
+Note that the relative tolerance only works for non-zero values, whereas zero values are accounted for by the absolute tolerance.
+For example, a relative tolerance of :math:`10^{-4}` and absolute tolerance of :math:`10^{-8}` requests :math:`3` significant digits (correct digits after the comma in scientific notation) and considers all numbers with magnitude smaller than :math:`10^{-8}` as :math:`0`.
+
+The size of the first time step in a time slice is given by ``INIT_STEP_SIZE`` from Table :ref:`FFSolverTime`.
+If a simulation fails on the first time step, it might help to reduce the initial step size.
+It can also help to increase the error tolerances, at the cost of imprecise results over the whole course of the simulation.
+
+It can happen that due to severe stiffness or ill-posed models a simulation may exceed its computational budget given by the maximum number of time steps (per time slice) ``MAX_STEPS``.
+In this case, the formulation of the model should be checked and, if necessary, the error tolerances increased.
+Note that the number of time steps is independent of possible ``USER_SOLUTION_TIMES`` and refers to internal steps of the time integrator.
+
+On the other extreme, the time integrator might jump over an important change in the solution or not capture some feature of the solution because of too large time steps.
+This can be avoided by specifying the maximum time step size ``MAX_STEP_SIZE``.
+However, such a situation is unlikely to occur and can also be alleviated by placing a discontinuous section transition at the time of the event.
+
+Note that while the error in time integration is controlled and can (in theory) be made arbitrarily small, the spatial discretization error is not.
+Hence, it is important and necessary to test different spatial resolutions (number of cells) in order to find a sufficiently accurate (but minimal) number of grid cells.
+This is particularly relevant for problems with steep fronts as a low spatial resolution adds a substantial amount of numerical dispersion to the solution.
+
+.. _SimParamSens:
+
+Parameter sensitivities
+-----------------------
+
+Parameter sensitivities :math:`s = \partial y / \partial p` of a solution :math:`y` to the DAE with respect to some parameter :math:`p` are required for various tasks, for example, parameter estimation, process design, and process analysis.
+The CADET simulator implements the forward sensitivity approach which creates a linear companion DAE for each sensitive parameter
+
+.. math::
+
+ \begin{aligned}
+ 0 &= \frac{\mathrm{d}}{\mathrm{d}p} F(t, y, \dot{y}, p) = \frac{\partial F}{\partial y}(t, y, \dot{y}, p) \frac{\partial y}{\partial p} + \frac{\partial F}{\partial \dot{y}}(t, y, \dot{y}, p) \frac{\partial \dot{y}}{\partial p} + \frac{\partial F}{\partial p}(t, y, \dot{y}, p) \\
+ &= \frac{\partial F}{\partial y}(t, y, \dot{y}, p) s + \frac{\partial F}{\partial \dot{y}}(t, y, \dot{y}, p) \dot{s} + \frac{\partial F}{\partial p}(t, y, \dot{y}, p).
+ \end{aligned}
+
+These linear DAEs depend on the solution :math:`y`, :math:`\dot{y}` of the original DAE system.
+Consequently, the sensitivity systems are solved together with the original DAE system in a staggered approach :cite:`Feehery1997`.
+
+After the nonlinear Eq. :eq:`BDFNonlinSystem` has been successfully solved using Newton iteration (i.e., it has passed the convergence test), each sensitivity is solved using the same Newton iteration.
+If direct linear solvers were used, this iteration would convergence with a single iteration as there is no nonlinearity.
+The Newton method for the sensitivities performs at most ``MAX_NEWTON_ITER_SENS`` (see Table :ref:`FFSolverTime`) iterations.
+Assuming the convergence test has passed for each sensitivity, the local truncation error test is performed for the full set of variables (i.e., original system and sensitivities).
+The sensitivities can be excluded from the local truncation error test by setting ``ERRORTEST_SENS`` appropriately.
+Note that time integration step size is always affected by sensitivities due to possible convergence test failures.
+
+While the Jacobians :math:`\partial F / \partial y` and :math:`\partial F / \partial \dot{y}` can be computed either analytically or via AD, the last term :math:`\partial F / \partial p` is always computed by AD.
+In fact, the terms :math:`\partial F / \partial y` and :math:`\partial F / \partial p` can be computed by one AD-enabled evaluation of :math:`F` using the vector mode with appropriate seed vectors :cite:`Puttmann2016`.
+
+A parameter sensitivity is specified by identifying the involved parameters, which can be more than one (see below).
+Parameters are identified by name and multiple indices, which may not all be used (see Tab. :ref:`FFSensitivityParam`). Indices that are not used for identification (e.g., flow rate is independent of bound phase or component) are set to :math:`-1`. All other indices are zero-based.
+
+Note that the sensitivity systems need to be consistently initialized, too.
+However, since only linear systems are involved, no nonlinear equation system has to be solved and the procedure is much simpler computationally.
+
+.. _SimParamSensJointParams:
+
+Joint parameters
+~~~~~~~~~~~~~~~~
+
+The use of AD also enables support of meta parameters or joint parameters.
+Consider the situation in which several parameters :math:`p_1, p_2, \dots, p_n` depend (linearly) on a single meta parameter :math:`p`
+
+.. math::
+
+ \begin{aligned}
+ p_i = p_i(p) = \alpha_i p \qquad \text{ for } i = 1, \dots, n
+ \end{aligned}
+
+and some coefficients :math:`\alpha_i \in \mathbb{R}`.
+Hence, the DAE residual function :math:`F` becomes
+
+.. math::
+
+ \begin{aligned}
+ F(t, y, \dot{y}, p_1(p), \dots, p_n(p)) = 0
+ \end{aligned}
+
+and the partial derivative :math:`\partial F / \partial p` can be computed automatically by AD:
+
+.. math::
+
+ \begin{aligned}
+ \frac{\partial F}{\partial p} = \frac{\partial F}{\partial p_1} \alpha_1 + \dots + \frac{\partial F}{\partial p_n} \alpha_n.
+ \end{aligned}
+
+In order to use this functionality, all parameters involved have to be specified in a single sensitivity instance (``param_XXX`` group, see Tables :ref:`FFSensitivity` and `FFSensitivityParam`) by using arrays for the name and indices instead of scalar values.
+The coefficients :math:`\alpha_i` are provided in the ``SENS_FACTOR`` vector.
+
+A simple example for a situation, which benefits from having a single meta parameter, would be a chain of unit operations in a network in which the sensitivity with respect to the flow rate is to be computed.
+Instead of computing the sensitivity with respect to each single flow rate and fusing them together in a postprocessing step, a meta parameter that maps to all flow rates can be introduced.
+
+Note that nonlinear relationships between original parameter and meta parameters are supported by updating the coefficients :math:`\alpha_i` before each simulation:
+
+.. math::
+
+ \begin{aligned}
+ \alpha_i = \frac{\partial p_i}{\partial p}.
+ \end{aligned}
+
+
diff --git a/v5.0.1/_sources/zbibliography.rst.txt b/v5.0.1/_sources/zbibliography.rst.txt
new file mode 100644
index 000000000..e012803d1
--- /dev/null
+++ b/v5.0.1/_sources/zbibliography.rst.txt
@@ -0,0 +1,9 @@
+Bibliography
+============
+
+.. bibliography::
+ :style: unsrt
+
+
+
+
diff --git a/v5.0.1/_static/alabaster.css b/v5.0.1/_static/alabaster.css
new file mode 100644
index 000000000..d92336b01
--- /dev/null
+++ b/v5.0.1/_static/alabaster.css
@@ -0,0 +1,668 @@
+/* -- page layout ----------------------------------------------------------- */
+
+body {
+ font-family: Georgia, serif;
+ font-size: 17px;
+ background-color: #fff;
+ color: #000;
+ margin: 0;
+ padding: 0;
+}
+
+
+div.document {
+ width: 940px;
+ margin: 30px auto 0 auto;
+}
+
+div.documentwrapper {
+ float: left;
+ width: 100%;
+}
+
+div.bodywrapper {
+ margin: 0 0 0 220px;
+}
+
+div.sphinxsidebar {
+ width: 220px;
+ font-size: 14px;
+ line-height: 1.5;
+}
+
+hr {
+ border: 1px solid #B1B4B6;
+}
+
+div.body {
+ background-color: #fff;
+ color: #3E4349;
+ padding: 0 30px 0 30px;
+}
+
+div.body > .section {
+ text-align: left;
+}
+
+div.footer {
+ width: 940px;
+ margin: 20px auto 30px auto;
+ font-size: 14px;
+ color: #888;
+ text-align: right;
+}
+
+div.footer a {
+ color: #888;
+}
+
+p.caption {
+ font-family: inherit;
+ font-size: inherit;
+}
+
+
+div.relations {
+ display: none;
+}
+
+
+div.sphinxsidebar {
+ max-height: 100%;
+ overflow-y: auto;
+}
+
+div.sphinxsidebar a {
+ color: #444;
+ text-decoration: none;
+ border-bottom: 1px dotted #999;
+}
+
+div.sphinxsidebar a:hover {
+ border-bottom: 1px solid #999;
+}
+
+div.sphinxsidebarwrapper {
+ padding: 18px 10px;
+}
+
+div.sphinxsidebarwrapper p.logo {
+ padding: 0;
+ margin: -10px 0 0 0px;
+ text-align: center;
+}
+
+div.sphinxsidebarwrapper h1.logo {
+ margin-top: -10px;
+ text-align: center;
+ margin-bottom: 5px;
+ text-align: left;
+}
+
+div.sphinxsidebarwrapper h1.logo-name {
+ margin-top: 0px;
+}
+
+div.sphinxsidebarwrapper p.blurb {
+ margin-top: 0;
+ font-style: normal;
+}
+
+div.sphinxsidebar h3,
+div.sphinxsidebar h4 {
+ font-family: Georgia, serif;
+ color: #444;
+ font-size: 24px;
+ font-weight: normal;
+ margin: 0 0 5px 0;
+ padding: 0;
+}
+
+div.sphinxsidebar h4 {
+ font-size: 20px;
+}
+
+div.sphinxsidebar h3 a {
+ color: #444;
+}
+
+div.sphinxsidebar p.logo a,
+div.sphinxsidebar h3 a,
+div.sphinxsidebar p.logo a:hover,
+div.sphinxsidebar h3 a:hover {
+ border: none;
+}
+
+div.sphinxsidebar p {
+ color: #555;
+ margin: 10px 0;
+}
+
+div.sphinxsidebar ul {
+ margin: 10px 0;
+ padding: 0;
+ color: #000;
+}
+
+div.sphinxsidebar ul li.toctree-l1 > a {
+ font-size: 120%;
+}
+
+div.sphinxsidebar ul li.toctree-l2 > a {
+ font-size: 110%;
+}
+
+div.sphinxsidebar input {
+ border: 1px solid #CCC;
+ font-family: Georgia, serif;
+ font-size: 1em;
+}
+
+div.sphinxsidebar #searchbox {
+ margin: 1em 0;
+}
+
+div.sphinxsidebar .search > div {
+ display: table-cell;
+}
+
+div.sphinxsidebar hr {
+ border: none;
+ height: 1px;
+ color: #AAA;
+ background: #AAA;
+
+ text-align: left;
+ margin-left: 0;
+ width: 50%;
+}
+
+div.sphinxsidebar .badge {
+ border-bottom: none;
+}
+
+div.sphinxsidebar .badge:hover {
+ border-bottom: none;
+}
+
+/* To address an issue with donation coming after search */
+div.sphinxsidebar h3.donation {
+ margin-top: 10px;
+}
+
+/* -- body styles ----------------------------------------------------------- */
+
+a {
+ color: #004B6B;
+ text-decoration: underline;
+}
+
+a:hover {
+ color: #6D4100;
+ text-decoration: underline;
+}
+
+div.body h1,
+div.body h2,
+div.body h3,
+div.body h4,
+div.body h5,
+div.body h6 {
+ font-family: Georgia, serif;
+ font-weight: normal;
+ margin: 30px 0px 10px 0px;
+ padding: 0;
+}
+
+div.body h1 { margin-top: 0; padding-top: 0; font-size: 240%; }
+div.body h2 { font-size: 180%; }
+div.body h3 { font-size: 150%; }
+div.body h4 { font-size: 130%; }
+div.body h5 { font-size: 100%; }
+div.body h6 { font-size: 100%; }
+
+a.headerlink {
+ color: #DDD;
+ padding: 0 4px;
+ text-decoration: none;
+}
+
+a.headerlink:hover {
+ color: #444;
+ background: #EAEAEA;
+}
+
+div.body p, div.body dd, div.body li {
+ line-height: 1.4em;
+}
+
+div.admonition {
+ margin: 20px 0px;
+ padding: 10px 30px;
+ background-color: #EEE;
+ border: 1px solid #CCC;
+}
+
+div.admonition tt.xref, div.admonition code.xref, div.admonition a tt {
+ background-color: #FBFBFB;
+ border-bottom: 1px solid #fafafa;
+}
+
+div.admonition p.admonition-title {
+ font-family: Georgia, serif;
+ font-weight: normal;
+ font-size: 24px;
+ margin: 0 0 10px 0;
+ padding: 0;
+ line-height: 1;
+}
+
+div.admonition p.last {
+ margin-bottom: 0;
+}
+
+dt:target, .highlight {
+ background: #FAF3E8;
+}
+
+div.warning {
+ background-color: #FCC;
+ border: 1px solid #FAA;
+}
+
+div.danger {
+ background-color: #FCC;
+ border: 1px solid #FAA;
+ -moz-box-shadow: 2px 2px 4px #D52C2C;
+ -webkit-box-shadow: 2px 2px 4px #D52C2C;
+ box-shadow: 2px 2px 4px #D52C2C;
+}
+
+div.error {
+ background-color: #FCC;
+ border: 1px solid #FAA;
+ -moz-box-shadow: 2px 2px 4px #D52C2C;
+ -webkit-box-shadow: 2px 2px 4px #D52C2C;
+ box-shadow: 2px 2px 4px #D52C2C;
+}
+
+div.caution {
+ background-color: #FCC;
+ border: 1px solid #FAA;
+}
+
+div.attention {
+ background-color: #FCC;
+ border: 1px solid #FAA;
+}
+
+div.important {
+ background-color: #EEE;
+ border: 1px solid #CCC;
+}
+
+div.note {
+ background-color: #EEE;
+ border: 1px solid #CCC;
+}
+
+div.tip {
+ background-color: #EEE;
+ border: 1px solid #CCC;
+}
+
+div.hint {
+ background-color: #EEE;
+ border: 1px solid #CCC;
+}
+
+div.seealso {
+ background-color: #EEE;
+ border: 1px solid #CCC;
+}
+
+div.topic {
+ background-color: #EEE;
+}
+
+p.admonition-title {
+ display: inline;
+}
+
+p.admonition-title:after {
+ content: ":";
+}
+
+pre, tt, code {
+ font-family: 'Consolas', 'Menlo', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', monospace;
+ font-size: 0.9em;
+}
+
+.hll {
+ background-color: #FFC;
+ margin: 0 -12px;
+ padding: 0 12px;
+ display: block;
+}
+
+img.screenshot {
+}
+
+tt.descname, tt.descclassname, code.descname, code.descclassname {
+ font-size: 0.95em;
+}
+
+tt.descname, code.descname {
+ padding-right: 0.08em;
+}
+
+img.screenshot {
+ -moz-box-shadow: 2px 2px 4px #EEE;
+ -webkit-box-shadow: 2px 2px 4px #EEE;
+ box-shadow: 2px 2px 4px #EEE;
+}
+
+table.docutils {
+ border: 1px solid #888;
+ -moz-box-shadow: 2px 2px 4px #EEE;
+ -webkit-box-shadow: 2px 2px 4px #EEE;
+ box-shadow: 2px 2px 4px #EEE;
+}
+
+table.docutils td, table.docutils th {
+ border: 1px solid #888;
+ padding: 0.25em 0.7em;
+}
+
+table.field-list, table.footnote {
+ border: none;
+ -moz-box-shadow: none;
+ -webkit-box-shadow: none;
+ box-shadow: none;
+}
+
+table.footnote {
+ margin: 15px 0;
+ width: 100%;
+ border: 1px solid #EEE;
+ background: #FDFDFD;
+ font-size: 0.9em;
+}
+
+table.footnote + table.footnote {
+ margin-top: -15px;
+ border-top: none;
+}
+
+table.field-list th {
+ padding: 0 0.8em 0 0;
+}
+
+table.field-list td {
+ padding: 0;
+}
+
+table.field-list p {
+ margin-bottom: 0.8em;
+}
+
+/* Cloned from
+ * https://github.com/sphinx-doc/sphinx/commit/ef60dbfce09286b20b7385333d63a60321784e68
+ */
+.field-name {
+ -moz-hyphens: manual;
+ -ms-hyphens: manual;
+ -webkit-hyphens: manual;
+ hyphens: manual;
+}
+
+table.footnote td.label {
+ width: .1px;
+ padding: 0.3em 0 0.3em 0.5em;
+}
+
+table.footnote td {
+ padding: 0.3em 0.5em;
+}
+
+dl {
+ margin-left: 0;
+ margin-right: 0;
+ margin-top: 0;
+ padding: 0;
+}
+
+dl dd {
+ margin-left: 30px;
+}
+
+blockquote {
+ margin: 0 0 0 30px;
+ padding: 0;
+}
+
+ul, ol {
+ /* Matches the 30px from the narrow-screen "li > ul" selector below */
+ margin: 10px 0 10px 30px;
+ padding: 0;
+}
+
+pre {
+ background: unset;
+ padding: 7px 30px;
+ margin: 15px 0px;
+ line-height: 1.3em;
+}
+
+div.viewcode-block:target {
+ background: #ffd;
+}
+
+dl pre, blockquote pre, li pre {
+ margin-left: 0;
+ padding-left: 30px;
+}
+
+tt, code {
+ background-color: #ecf0f3;
+ color: #222;
+ /* padding: 1px 2px; */
+}
+
+tt.xref, code.xref, a tt {
+ background-color: #FBFBFB;
+ border-bottom: 1px solid #fff;
+}
+
+a.reference {
+ text-decoration: none;
+ border-bottom: 1px dotted #004B6B;
+}
+
+a.reference:hover {
+ border-bottom: 1px solid #6D4100;
+}
+
+/* Don't put an underline on images */
+a.image-reference, a.image-reference:hover {
+ border-bottom: none;
+}
+
+a.footnote-reference {
+ text-decoration: none;
+ font-size: 0.7em;
+ vertical-align: top;
+ border-bottom: 1px dotted #004B6B;
+}
+
+a.footnote-reference:hover {
+ border-bottom: 1px solid #6D4100;
+}
+
+a:hover tt, a:hover code {
+ background: #EEE;
+}
+div.sphinxsidebar {
+ position: fixed;
+ margin-left: 0;
+}
+
+@media screen and (max-width: 940px) {
+
+ body {
+ margin: 0;
+ padding: 20px 30px;
+ }
+
+ div.documentwrapper {
+ float: none;
+ background: #fff;
+ margin-left: 0;
+ margin-top: 0;
+ margin-right: 0;
+ margin-bottom: 0;
+ }
+
+ div.sphinxsidebar {
+ display: block;
+ float: none;
+ width: unset;
+ margin: -20px -30px 20px -30px;
+ position: static;
+ padding: 10px 20px;
+ background: #333;
+ color: #FFF;
+ }
+
+ div.sphinxsidebar h3, div.sphinxsidebar h4, div.sphinxsidebar p,
+ div.sphinxsidebar h3 a {
+ color: #fff;
+ }
+
+ div.sphinxsidebar a {
+ color: #AAA;
+ }
+
+ div.sphinxsidebar p.logo {
+ display: none;
+ }
+
+ div.document {
+ width: 100%;
+ margin: 0;
+ }
+
+ div.footer {
+ display: none;
+ }
+
+ div.bodywrapper {
+ margin: 0;
+ }
+
+ div.body {
+ min-height: 0;
+ min-width: auto; /* fixes width on small screens, breaks .hll */
+ padding: 0;
+ }
+
+ .hll {
+ /* "fixes" the breakage */
+ width: max-content;
+ }
+
+ .rtd_doc_footer {
+ display: none;
+ }
+
+ .document {
+ width: auto;
+ }
+
+ .footer {
+ width: auto;
+ }
+
+ .github {
+ display: none;
+ }
+
+ ul {
+ margin-left: 0;
+ }
+
+ li > ul {
+ /* Matches the 30px from the "ul, ol" selector above */
+ margin-left: 30px;
+ }
+}
+
+
+/* misc. */
+
+.revsys-inline {
+ display: none!important;
+}
+
+/* Hide ugly table cell borders in ..bibliography:: directive output */
+table.docutils.citation, table.docutils.citation td, table.docutils.citation th {
+ border: none;
+ /* Below needed in some edge cases; if not applied, bottom shadows appear */
+ -moz-box-shadow: none;
+ -webkit-box-shadow: none;
+ box-shadow: none;
+}
+
+
+/* relbar */
+
+.related {
+ line-height: 30px;
+ width: 100%;
+ font-size: 0.9rem;
+}
+
+.related.top {
+ border-bottom: 1px solid #EEE;
+ margin-bottom: 20px;
+}
+
+.related.bottom {
+ border-top: 1px solid #EEE;
+}
+
+.related ul {
+ padding: 0;
+ margin: 0;
+ list-style: none;
+}
+
+.related li {
+ display: inline;
+}
+
+nav#rellinks {
+ float: right;
+}
+
+nav#rellinks li+li:before {
+ content: "|";
+}
+
+nav#breadcrumbs li+li:before {
+ content: "\00BB";
+}
+
+/* Hide certain items when printing */
+@media print {
+ div.related {
+ display: none;
+ }
+}
+
+img.github {
+ position: absolute;
+ top: 0;
+ border: 0;
+ right: 0;
+}
\ No newline at end of file
diff --git a/v5.0.1/_static/basic.css b/v5.0.1/_static/basic.css
new file mode 100644
index 000000000..d9846dacb
--- /dev/null
+++ b/v5.0.1/_static/basic.css
@@ -0,0 +1,914 @@
+/*
+ * Sphinx stylesheet -- basic theme.
+ */
+
+/* -- main layout ----------------------------------------------------------- */
+
+div.clearer {
+ clear: both;
+}
+
+div.section::after {
+ display: block;
+ content: '';
+ clear: left;
+}
+
+/* -- relbar ---------------------------------------------------------------- */
+
+div.related {
+ width: 100%;
+ font-size: 90%;
+}
+
+div.related h3 {
+ display: none;
+}
+
+div.related ul {
+ margin: 0;
+ padding: 0 0 0 10px;
+ list-style: none;
+}
+
+div.related li {
+ display: inline;
+}
+
+div.related li.right {
+ float: right;
+ margin-right: 5px;
+}
+
+/* -- sidebar --------------------------------------------------------------- */
+
+div.sphinxsidebarwrapper {
+ padding: 10px 5px 0 10px;
+}
+
+div.sphinxsidebar {
+ float: left;
+ width: 230px;
+ margin-left: -100%;
+ font-size: 90%;
+ word-wrap: break-word;
+ overflow-wrap : break-word;
+}
+
+div.sphinxsidebar ul {
+ list-style: none;
+}
+
+div.sphinxsidebar ul ul,
+div.sphinxsidebar ul.want-points {
+ margin-left: 20px;
+ list-style: square;
+}
+
+div.sphinxsidebar ul ul {
+ margin-top: 0;
+ margin-bottom: 0;
+}
+
+div.sphinxsidebar form {
+ margin-top: 10px;
+}
+
+div.sphinxsidebar input {
+ border: 1px solid #98dbcc;
+ font-family: sans-serif;
+ font-size: 1em;
+}
+
+div.sphinxsidebar #searchbox form.search {
+ overflow: hidden;
+}
+
+div.sphinxsidebar #searchbox input[type="text"] {
+ float: left;
+ width: 80%;
+ padding: 0.25em;
+ box-sizing: border-box;
+}
+
+div.sphinxsidebar #searchbox input[type="submit"] {
+ float: left;
+ width: 20%;
+ border-left: none;
+ padding: 0.25em;
+ box-sizing: border-box;
+}
+
+
+img {
+ border: 0;
+ max-width: 100%;
+}
+
+/* -- search page ----------------------------------------------------------- */
+
+ul.search {
+ margin-top: 10px;
+}
+
+ul.search li {
+ padding: 5px 0;
+}
+
+ul.search li a {
+ font-weight: bold;
+}
+
+ul.search li p.context {
+ color: #888;
+ margin: 2px 0 0 30px;
+ text-align: left;
+}
+
+ul.keywordmatches li.goodmatch a {
+ font-weight: bold;
+}
+
+/* -- index page ------------------------------------------------------------ */
+
+table.contentstable {
+ width: 90%;
+ margin-left: auto;
+ margin-right: auto;
+}
+
+table.contentstable p.biglink {
+ line-height: 150%;
+}
+
+a.biglink {
+ font-size: 1.3em;
+}
+
+span.linkdescr {
+ font-style: italic;
+ padding-top: 5px;
+ font-size: 90%;
+}
+
+/* -- general index --------------------------------------------------------- */
+
+table.indextable {
+ width: 100%;
+}
+
+table.indextable td {
+ text-align: left;
+ vertical-align: top;
+}
+
+table.indextable ul {
+ margin-top: 0;
+ margin-bottom: 0;
+ list-style-type: none;
+}
+
+table.indextable > tbody > tr > td > ul {
+ padding-left: 0em;
+}
+
+table.indextable tr.pcap {
+ height: 10px;
+}
+
+table.indextable tr.cap {
+ margin-top: 10px;
+ background-color: #f2f2f2;
+}
+
+img.toggler {
+ margin-right: 3px;
+ margin-top: 3px;
+ cursor: pointer;
+}
+
+div.modindex-jumpbox {
+ border-top: 1px solid #ddd;
+ border-bottom: 1px solid #ddd;
+ margin: 1em 0 1em 0;
+ padding: 0.4em;
+}
+
+div.genindex-jumpbox {
+ border-top: 1px solid #ddd;
+ border-bottom: 1px solid #ddd;
+ margin: 1em 0 1em 0;
+ padding: 0.4em;
+}
+
+/* -- domain module index --------------------------------------------------- */
+
+table.modindextable td {
+ padding: 2px;
+ border-collapse: collapse;
+}
+
+/* -- general body styles --------------------------------------------------- */
+
+div.body {
+ min-width: inherit;
+ max-width: 800px;
+}
+
+div.body p, div.body dd, div.body li, div.body blockquote {
+ -moz-hyphens: auto;
+ -ms-hyphens: auto;
+ -webkit-hyphens: auto;
+ hyphens: auto;
+}
+
+a.headerlink {
+ visibility: hidden;
+}
+
+a:visited {
+ color: #551A8B;
+}
+
+h1:hover > a.headerlink,
+h2:hover > a.headerlink,
+h3:hover > a.headerlink,
+h4:hover > a.headerlink,
+h5:hover > a.headerlink,
+h6:hover > a.headerlink,
+dt:hover > a.headerlink,
+caption:hover > a.headerlink,
+p.caption:hover > a.headerlink,
+div.code-block-caption:hover > a.headerlink {
+ visibility: visible;
+}
+
+div.body p.caption {
+ text-align: inherit;
+}
+
+div.body td {
+ text-align: left;
+}
+
+.first {
+ margin-top: 0 !important;
+}
+
+p.rubric {
+ margin-top: 30px;
+ font-weight: bold;
+}
+
+img.align-left, figure.align-left, .figure.align-left, object.align-left {
+ clear: left;
+ float: left;
+ margin-right: 1em;
+}
+
+img.align-right, figure.align-right, .figure.align-right, object.align-right {
+ clear: right;
+ float: right;
+ margin-left: 1em;
+}
+
+img.align-center, figure.align-center, .figure.align-center, object.align-center {
+ display: block;
+ margin-left: auto;
+ margin-right: auto;
+}
+
+img.align-default, figure.align-default, .figure.align-default {
+ display: block;
+ margin-left: auto;
+ margin-right: auto;
+}
+
+.align-left {
+ text-align: left;
+}
+
+.align-center {
+ text-align: center;
+}
+
+.align-default {
+ text-align: center;
+}
+
+.align-right {
+ text-align: right;
+}
+
+/* -- sidebars -------------------------------------------------------------- */
+
+div.sidebar,
+aside.sidebar {
+ margin: 0 0 0.5em 1em;
+ border: 1px solid #ddb;
+ padding: 7px;
+ background-color: #ffe;
+ width: 40%;
+ float: right;
+ clear: right;
+ overflow-x: auto;
+}
+
+p.sidebar-title {
+ font-weight: bold;
+}
+
+nav.contents,
+aside.topic,
+div.admonition, div.topic, blockquote {
+ clear: left;
+}
+
+/* -- topics ---------------------------------------------------------------- */
+
+nav.contents,
+aside.topic,
+div.topic {
+ border: 1px solid #ccc;
+ padding: 7px;
+ margin: 10px 0 10px 0;
+}
+
+p.topic-title {
+ font-size: 1.1em;
+ font-weight: bold;
+ margin-top: 10px;
+}
+
+/* -- admonitions ----------------------------------------------------------- */
+
+div.admonition {
+ margin-top: 10px;
+ margin-bottom: 10px;
+ padding: 7px;
+}
+
+div.admonition dt {
+ font-weight: bold;
+}
+
+p.admonition-title {
+ margin: 0px 10px 5px 0px;
+ font-weight: bold;
+}
+
+div.body p.centered {
+ text-align: center;
+ margin-top: 25px;
+}
+
+/* -- content of sidebars/topics/admonitions -------------------------------- */
+
+div.sidebar > :last-child,
+aside.sidebar > :last-child,
+nav.contents > :last-child,
+aside.topic > :last-child,
+div.topic > :last-child,
+div.admonition > :last-child {
+ margin-bottom: 0;
+}
+
+div.sidebar::after,
+aside.sidebar::after,
+nav.contents::after,
+aside.topic::after,
+div.topic::after,
+div.admonition::after,
+blockquote::after {
+ display: block;
+ content: '';
+ clear: both;
+}
+
+/* -- tables ---------------------------------------------------------------- */
+
+table.docutils {
+ margin-top: 10px;
+ margin-bottom: 10px;
+ border: 0;
+ border-collapse: collapse;
+}
+
+table.align-center {
+ margin-left: auto;
+ margin-right: auto;
+}
+
+table.align-default {
+ margin-left: auto;
+ margin-right: auto;
+}
+
+table caption span.caption-number {
+ font-style: italic;
+}
+
+table caption span.caption-text {
+}
+
+table.docutils td, table.docutils th {
+ padding: 1px 8px 1px 5px;
+ border-top: 0;
+ border-left: 0;
+ border-right: 0;
+ border-bottom: 1px solid #aaa;
+}
+
+th {
+ text-align: left;
+ padding-right: 5px;
+}
+
+table.citation {
+ border-left: solid 1px gray;
+ margin-left: 1px;
+}
+
+table.citation td {
+ border-bottom: none;
+}
+
+th > :first-child,
+td > :first-child {
+ margin-top: 0px;
+}
+
+th > :last-child,
+td > :last-child {
+ margin-bottom: 0px;
+}
+
+/* -- figures --------------------------------------------------------------- */
+
+div.figure, figure {
+ margin: 0.5em;
+ padding: 0.5em;
+}
+
+div.figure p.caption, figcaption {
+ padding: 0.3em;
+}
+
+div.figure p.caption span.caption-number,
+figcaption span.caption-number {
+ font-style: italic;
+}
+
+div.figure p.caption span.caption-text,
+figcaption span.caption-text {
+}
+
+/* -- field list styles ----------------------------------------------------- */
+
+table.field-list td, table.field-list th {
+ border: 0 !important;
+}
+
+.field-list ul {
+ margin: 0;
+ padding-left: 1em;
+}
+
+.field-list p {
+ margin: 0;
+}
+
+.field-name {
+ -moz-hyphens: manual;
+ -ms-hyphens: manual;
+ -webkit-hyphens: manual;
+ hyphens: manual;
+}
+
+/* -- hlist styles ---------------------------------------------------------- */
+
+table.hlist {
+ margin: 1em 0;
+}
+
+table.hlist td {
+ vertical-align: top;
+}
+
+/* -- object description styles --------------------------------------------- */
+
+.sig {
+ font-family: 'Consolas', 'Menlo', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', monospace;
+}
+
+.sig-name, code.descname {
+ background-color: transparent;
+ font-weight: bold;
+}
+
+.sig-name {
+ font-size: 1.1em;
+}
+
+code.descname {
+ font-size: 1.2em;
+}
+
+.sig-prename, code.descclassname {
+ background-color: transparent;
+}
+
+.optional {
+ font-size: 1.3em;
+}
+
+.sig-paren {
+ font-size: larger;
+}
+
+.sig-param.n {
+ font-style: italic;
+}
+
+/* C++ specific styling */
+
+.sig-inline.c-texpr,
+.sig-inline.cpp-texpr {
+ font-family: unset;
+}
+
+.sig.c .k, .sig.c .kt,
+.sig.cpp .k, .sig.cpp .kt {
+ color: #0033B3;
+}
+
+.sig.c .m,
+.sig.cpp .m {
+ color: #1750EB;
+}
+
+.sig.c .s, .sig.c .sc,
+.sig.cpp .s, .sig.cpp .sc {
+ color: #067D17;
+}
+
+
+/* -- other body styles ----------------------------------------------------- */
+
+ol.arabic {
+ list-style: decimal;
+}
+
+ol.loweralpha {
+ list-style: lower-alpha;
+}
+
+ol.upperalpha {
+ list-style: upper-alpha;
+}
+
+ol.lowerroman {
+ list-style: lower-roman;
+}
+
+ol.upperroman {
+ list-style: upper-roman;
+}
+
+:not(li) > ol > li:first-child > :first-child,
+:not(li) > ul > li:first-child > :first-child {
+ margin-top: 0px;
+}
+
+:not(li) > ol > li:last-child > :last-child,
+:not(li) > ul > li:last-child > :last-child {
+ margin-bottom: 0px;
+}
+
+ol.simple ol p,
+ol.simple ul p,
+ul.simple ol p,
+ul.simple ul p {
+ margin-top: 0;
+}
+
+ol.simple > li:not(:first-child) > p,
+ul.simple > li:not(:first-child) > p {
+ margin-top: 0;
+}
+
+ol.simple p,
+ul.simple p {
+ margin-bottom: 0;
+}
+
+aside.footnote > span,
+div.citation > span {
+ float: left;
+}
+aside.footnote > span:last-of-type,
+div.citation > span:last-of-type {
+ padding-right: 0.5em;
+}
+aside.footnote > p {
+ margin-left: 2em;
+}
+div.citation > p {
+ margin-left: 4em;
+}
+aside.footnote > p:last-of-type,
+div.citation > p:last-of-type {
+ margin-bottom: 0em;
+}
+aside.footnote > p:last-of-type:after,
+div.citation > p:last-of-type:after {
+ content: "";
+ clear: both;
+}
+
+dl.field-list {
+ display: grid;
+ grid-template-columns: fit-content(30%) auto;
+}
+
+dl.field-list > dt {
+ font-weight: bold;
+ word-break: break-word;
+ padding-left: 0.5em;
+ padding-right: 5px;
+}
+
+dl.field-list > dd {
+ padding-left: 0.5em;
+ margin-top: 0em;
+ margin-left: 0em;
+ margin-bottom: 0em;
+}
+
+dl {
+ margin-bottom: 15px;
+}
+
+dd > :first-child {
+ margin-top: 0px;
+}
+
+dd ul, dd table {
+ margin-bottom: 10px;
+}
+
+dd {
+ margin-top: 3px;
+ margin-bottom: 10px;
+ margin-left: 30px;
+}
+
+.sig dd {
+ margin-top: 0px;
+ margin-bottom: 0px;
+}
+
+.sig dl {
+ margin-top: 0px;
+ margin-bottom: 0px;
+}
+
+dl > dd:last-child,
+dl > dd:last-child > :last-child {
+ margin-bottom: 0;
+}
+
+dt:target, span.highlighted {
+ background-color: #fbe54e;
+}
+
+rect.highlighted {
+ fill: #fbe54e;
+}
+
+dl.glossary dt {
+ font-weight: bold;
+ font-size: 1.1em;
+}
+
+.versionmodified {
+ font-style: italic;
+}
+
+.system-message {
+ background-color: #fda;
+ padding: 5px;
+ border: 3px solid red;
+}
+
+.footnote:target {
+ background-color: #ffa;
+}
+
+.line-block {
+ display: block;
+ margin-top: 1em;
+ margin-bottom: 1em;
+}
+
+.line-block .line-block {
+ margin-top: 0;
+ margin-bottom: 0;
+ margin-left: 1.5em;
+}
+
+.guilabel, .menuselection {
+ font-family: sans-serif;
+}
+
+.accelerator {
+ text-decoration: underline;
+}
+
+.classifier {
+ font-style: oblique;
+}
+
+.classifier:before {
+ font-style: normal;
+ margin: 0 0.5em;
+ content: ":";
+ display: inline-block;
+}
+
+abbr, acronym {
+ border-bottom: dotted 1px;
+ cursor: help;
+}
+
+.translated {
+ background-color: rgba(207, 255, 207, 0.2)
+}
+
+.untranslated {
+ background-color: rgba(255, 207, 207, 0.2)
+}
+
+/* -- code displays --------------------------------------------------------- */
+
+pre {
+ overflow: auto;
+ overflow-y: hidden; /* fixes display issues on Chrome browsers */
+}
+
+pre, div[class*="highlight-"] {
+ clear: both;
+}
+
+span.pre {
+ -moz-hyphens: none;
+ -ms-hyphens: none;
+ -webkit-hyphens: none;
+ hyphens: none;
+ white-space: nowrap;
+}
+
+div[class*="highlight-"] {
+ margin: 1em 0;
+}
+
+td.linenos pre {
+ border: 0;
+ background-color: transparent;
+ color: #aaa;
+}
+
+table.highlighttable {
+ display: block;
+}
+
+table.highlighttable tbody {
+ display: block;
+}
+
+table.highlighttable tr {
+ display: flex;
+}
+
+table.highlighttable td {
+ margin: 0;
+ padding: 0;
+}
+
+table.highlighttable td.linenos {
+ padding-right: 0.5em;
+}
+
+table.highlighttable td.code {
+ flex: 1;
+ overflow: hidden;
+}
+
+.highlight .hll {
+ display: block;
+}
+
+div.highlight pre,
+table.highlighttable pre {
+ margin: 0;
+}
+
+div.code-block-caption + div {
+ margin-top: 0;
+}
+
+div.code-block-caption {
+ margin-top: 1em;
+ padding: 2px 5px;
+ font-size: small;
+}
+
+div.code-block-caption code {
+ background-color: transparent;
+}
+
+table.highlighttable td.linenos,
+span.linenos,
+div.highlight span.gp { /* gp: Generic.Prompt */
+ user-select: none;
+ -webkit-user-select: text; /* Safari fallback only */
+ -webkit-user-select: none; /* Chrome/Safari */
+ -moz-user-select: none; /* Firefox */
+ -ms-user-select: none; /* IE10+ */
+}
+
+div.code-block-caption span.caption-number {
+ padding: 0.1em 0.3em;
+ font-style: italic;
+}
+
+div.code-block-caption span.caption-text {
+}
+
+div.literal-block-wrapper {
+ margin: 1em 0;
+}
+
+code.xref, a code {
+ background-color: transparent;
+ font-weight: bold;
+}
+
+h1 code, h2 code, h3 code, h4 code, h5 code, h6 code {
+ background-color: transparent;
+}
+
+.viewcode-link {
+ float: right;
+}
+
+.viewcode-back {
+ float: right;
+ font-family: sans-serif;
+}
+
+div.viewcode-block:target {
+ margin: -1px -10px;
+ padding: 0 10px;
+}
+
+/* -- math display ---------------------------------------------------------- */
+
+img.math {
+ vertical-align: middle;
+}
+
+div.body div.math p {
+ text-align: center;
+}
+
+span.eqno {
+ float: right;
+}
+
+span.eqno a.headerlink {
+ position: absolute;
+ z-index: 1;
+}
+
+div.math:hover a.headerlink {
+ visibility: visible;
+}
+
+/* -- printout stylesheet --------------------------------------------------- */
+
+@media print {
+ div.document,
+ div.documentwrapper,
+ div.bodywrapper {
+ margin: 0 !important;
+ width: 100%;
+ }
+
+ div.sphinxsidebar,
+ div.related,
+ div.footer,
+ #top-link {
+ display: none;
+ }
+}
\ No newline at end of file
diff --git a/v5.0.1/_static/cadet_icon.png b/v5.0.1/_static/cadet_icon.png
new file mode 100644
index 000000000..77ea45003
Binary files /dev/null and b/v5.0.1/_static/cadet_icon.png differ
diff --git a/v5.0.1/_static/cadet_logo.png b/v5.0.1/_static/cadet_logo.png
new file mode 100644
index 000000000..f56f4fef3
Binary files /dev/null and b/v5.0.1/_static/cadet_logo.png differ
diff --git a/v5.0.1/_static/css/custom.css b/v5.0.1/_static/css/custom.css
new file mode 100644
index 000000000..2c242be84
--- /dev/null
+++ b/v5.0.1/_static/css/custom.css
@@ -0,0 +1,12 @@
+/** css/custom.css **/
+
+/* This line is theme specific - it includes the base theme CSS */
+@import '../basic.css'; /* to produce identical results as Alabaster v0.7.16 with Alabaster v1.0.0 */
+@import '../alabaster.css'; /* for Alabaster */
+/*@import 'theme.css'; /* for the Read the Docs theme */
+
+div.sphinxsidebar {
+ height: 100vh;
+ overflow: auto;
+}
+
diff --git a/v5.0.1/_static/custom.css b/v5.0.1/_static/custom.css
new file mode 100644
index 000000000..2a924f1d6
--- /dev/null
+++ b/v5.0.1/_static/custom.css
@@ -0,0 +1 @@
+/* This file intentionally left blank. */
diff --git a/v5.0.1/_static/doctools.js b/v5.0.1/_static/doctools.js
new file mode 100644
index 000000000..0398ebb9f
--- /dev/null
+++ b/v5.0.1/_static/doctools.js
@@ -0,0 +1,149 @@
+/*
+ * Base JavaScript utilities for all Sphinx HTML documentation.
+ */
+"use strict";
+
+const BLACKLISTED_KEY_CONTROL_ELEMENTS = new Set([
+ "TEXTAREA",
+ "INPUT",
+ "SELECT",
+ "BUTTON",
+]);
+
+const _ready = (callback) => {
+ if (document.readyState !== "loading") {
+ callback();
+ } else {
+ document.addEventListener("DOMContentLoaded", callback);
+ }
+};
+
+/**
+ * Small JavaScript module for the documentation.
+ */
+const Documentation = {
+ init: () => {
+ Documentation.initDomainIndexTable();
+ Documentation.initOnKeyListeners();
+ },
+
+ /**
+ * i18n support
+ */
+ TRANSLATIONS: {},
+ PLURAL_EXPR: (n) => (n === 1 ? 0 : 1),
+ LOCALE: "unknown",
+
+ // gettext and ngettext don't access this so that the functions
+ // can safely bound to a different name (_ = Documentation.gettext)
+ gettext: (string) => {
+ const translated = Documentation.TRANSLATIONS[string];
+ switch (typeof translated) {
+ case "undefined":
+ return string; // no translation
+ case "string":
+ return translated; // translation exists
+ default:
+ return translated[0]; // (singular, plural) translation tuple exists
+ }
+ },
+
+ ngettext: (singular, plural, n) => {
+ const translated = Documentation.TRANSLATIONS[singular];
+ if (typeof translated !== "undefined")
+ return translated[Documentation.PLURAL_EXPR(n)];
+ return n === 1 ? singular : plural;
+ },
+
+ addTranslations: (catalog) => {
+ Object.assign(Documentation.TRANSLATIONS, catalog.messages);
+ Documentation.PLURAL_EXPR = new Function(
+ "n",
+ `return (${catalog.plural_expr})`
+ );
+ Documentation.LOCALE = catalog.locale;
+ },
+
+ /**
+ * helper function to focus on search bar
+ */
+ focusSearchBar: () => {
+ document.querySelectorAll("input[name=q]")[0]?.focus();
+ },
+
+ /**
+ * Initialise the domain index toggle buttons
+ */
+ initDomainIndexTable: () => {
+ const toggler = (el) => {
+ const idNumber = el.id.substr(7);
+ const toggledRows = document.querySelectorAll(`tr.cg-${idNumber}`);
+ if (el.src.substr(-9) === "minus.png") {
+ el.src = `${el.src.substr(0, el.src.length - 9)}plus.png`;
+ toggledRows.forEach((el) => (el.style.display = "none"));
+ } else {
+ el.src = `${el.src.substr(0, el.src.length - 8)}minus.png`;
+ toggledRows.forEach((el) => (el.style.display = ""));
+ }
+ };
+
+ const togglerElements = document.querySelectorAll("img.toggler");
+ togglerElements.forEach((el) =>
+ el.addEventListener("click", (event) => toggler(event.currentTarget))
+ );
+ togglerElements.forEach((el) => (el.style.display = ""));
+ if (DOCUMENTATION_OPTIONS.COLLAPSE_INDEX) togglerElements.forEach(toggler);
+ },
+
+ initOnKeyListeners: () => {
+ // only install a listener if it is really needed
+ if (
+ !DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS &&
+ !DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS
+ )
+ return;
+
+ document.addEventListener("keydown", (event) => {
+ // bail for input elements
+ if (BLACKLISTED_KEY_CONTROL_ELEMENTS.has(document.activeElement.tagName)) return;
+ // bail with special keys
+ if (event.altKey || event.ctrlKey || event.metaKey) return;
+
+ if (!event.shiftKey) {
+ switch (event.key) {
+ case "ArrowLeft":
+ if (!DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS) break;
+
+ const prevLink = document.querySelector('link[rel="prev"]');
+ if (prevLink && prevLink.href) {
+ window.location.href = prevLink.href;
+ event.preventDefault();
+ }
+ break;
+ case "ArrowRight":
+ if (!DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS) break;
+
+ const nextLink = document.querySelector('link[rel="next"]');
+ if (nextLink && nextLink.href) {
+ window.location.href = nextLink.href;
+ event.preventDefault();
+ }
+ break;
+ }
+ }
+
+ // some keyboard layouts may need Shift to get /
+ switch (event.key) {
+ case "/":
+ if (!DOCUMENTATION_OPTIONS.ENABLE_SEARCH_SHORTCUTS) break;
+ Documentation.focusSearchBar();
+ event.preventDefault();
+ }
+ });
+ },
+};
+
+// quick alias for translations
+const _ = Documentation.gettext;
+
+_ready(Documentation.init);
diff --git a/v5.0.1/_static/documentation_options.js b/v5.0.1/_static/documentation_options.js
new file mode 100644
index 000000000..7e4c114f2
--- /dev/null
+++ b/v5.0.1/_static/documentation_options.js
@@ -0,0 +1,13 @@
+const DOCUMENTATION_OPTIONS = {
+ VERSION: '',
+ LANGUAGE: 'en',
+ COLLAPSE_INDEX: false,
+ BUILDER: 'html',
+ FILE_SUFFIX: '.html',
+ LINK_SUFFIX: '.html',
+ HAS_SOURCE: true,
+ SOURCELINK_SUFFIX: '.txt',
+ NAVIGATION_WITH_KEYS: false,
+ SHOW_SEARCH_SUMMARY: true,
+ ENABLE_SEARCH_SHORTCUTS: true,
+};
\ No newline at end of file
diff --git a/v5.0.1/_static/file.png b/v5.0.1/_static/file.png
new file mode 100644
index 000000000..a858a410e
Binary files /dev/null and b/v5.0.1/_static/file.png differ
diff --git a/v5.0.1/_static/github-banner.svg b/v5.0.1/_static/github-banner.svg
new file mode 100644
index 000000000..c47d9dc0c
--- /dev/null
+++ b/v5.0.1/_static/github-banner.svg
@@ -0,0 +1,5 @@
+
diff --git a/v5.0.1/_static/language_data.js b/v5.0.1/_static/language_data.js
new file mode 100644
index 000000000..c7fe6c6fa
--- /dev/null
+++ b/v5.0.1/_static/language_data.js
@@ -0,0 +1,192 @@
+/*
+ * This script contains the language-specific data used by searchtools.js,
+ * namely the list of stopwords, stemmer, scorer and splitter.
+ */
+
+var stopwords = ["a", "and", "are", "as", "at", "be", "but", "by", "for", "if", "in", "into", "is", "it", "near", "no", "not", "of", "on", "or", "such", "that", "the", "their", "then", "there", "these", "they", "this", "to", "was", "will", "with"];
+
+
+/* Non-minified version is copied as a separate JS file, if available */
+
+/**
+ * Porter Stemmer
+ */
+var Stemmer = function() {
+
+ var step2list = {
+ ational: 'ate',
+ tional: 'tion',
+ enci: 'ence',
+ anci: 'ance',
+ izer: 'ize',
+ bli: 'ble',
+ alli: 'al',
+ entli: 'ent',
+ eli: 'e',
+ ousli: 'ous',
+ ization: 'ize',
+ ation: 'ate',
+ ator: 'ate',
+ alism: 'al',
+ iveness: 'ive',
+ fulness: 'ful',
+ ousness: 'ous',
+ aliti: 'al',
+ iviti: 'ive',
+ biliti: 'ble',
+ logi: 'log'
+ };
+
+ var step3list = {
+ icate: 'ic',
+ ative: '',
+ alize: 'al',
+ iciti: 'ic',
+ ical: 'ic',
+ ful: '',
+ ness: ''
+ };
+
+ var c = "[^aeiou]"; // consonant
+ var v = "[aeiouy]"; // vowel
+ var C = c + "[^aeiouy]*"; // consonant sequence
+ var V = v + "[aeiou]*"; // vowel sequence
+
+ var mgr0 = "^(" + C + ")?" + V + C; // [C]VC... is m>0
+ var meq1 = "^(" + C + ")?" + V + C + "(" + V + ")?$"; // [C]VC[V] is m=1
+ var mgr1 = "^(" + C + ")?" + V + C + V + C; // [C]VCVC... is m>1
+ var s_v = "^(" + C + ")?" + v; // vowel in stem
+
+ this.stemWord = function (w) {
+ var stem;
+ var suffix;
+ var firstch;
+ var origword = w;
+
+ if (w.length < 3)
+ return w;
+
+ var re;
+ var re2;
+ var re3;
+ var re4;
+
+ firstch = w.substr(0,1);
+ if (firstch == "y")
+ w = firstch.toUpperCase() + w.substr(1);
+
+ // Step 1a
+ re = /^(.+?)(ss|i)es$/;
+ re2 = /^(.+?)([^s])s$/;
+
+ if (re.test(w))
+ w = w.replace(re,"$1$2");
+ else if (re2.test(w))
+ w = w.replace(re2,"$1$2");
+
+ // Step 1b
+ re = /^(.+?)eed$/;
+ re2 = /^(.+?)(ed|ing)$/;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ re = new RegExp(mgr0);
+ if (re.test(fp[1])) {
+ re = /.$/;
+ w = w.replace(re,"");
+ }
+ }
+ else if (re2.test(w)) {
+ var fp = re2.exec(w);
+ stem = fp[1];
+ re2 = new RegExp(s_v);
+ if (re2.test(stem)) {
+ w = stem;
+ re2 = /(at|bl|iz)$/;
+ re3 = new RegExp("([^aeiouylsz])\\1$");
+ re4 = new RegExp("^" + C + v + "[^aeiouwxy]$");
+ if (re2.test(w))
+ w = w + "e";
+ else if (re3.test(w)) {
+ re = /.$/;
+ w = w.replace(re,"");
+ }
+ else if (re4.test(w))
+ w = w + "e";
+ }
+ }
+
+ // Step 1c
+ re = /^(.+?)y$/;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ re = new RegExp(s_v);
+ if (re.test(stem))
+ w = stem + "i";
+ }
+
+ // Step 2
+ re = /^(.+?)(ational|tional|enci|anci|izer|bli|alli|entli|eli|ousli|ization|ation|ator|alism|iveness|fulness|ousness|aliti|iviti|biliti|logi)$/;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ suffix = fp[2];
+ re = new RegExp(mgr0);
+ if (re.test(stem))
+ w = stem + step2list[suffix];
+ }
+
+ // Step 3
+ re = /^(.+?)(icate|ative|alize|iciti|ical|ful|ness)$/;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ suffix = fp[2];
+ re = new RegExp(mgr0);
+ if (re.test(stem))
+ w = stem + step3list[suffix];
+ }
+
+ // Step 4
+ re = /^(.+?)(al|ance|ence|er|ic|able|ible|ant|ement|ment|ent|ou|ism|ate|iti|ous|ive|ize)$/;
+ re2 = /^(.+?)(s|t)(ion)$/;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ re = new RegExp(mgr1);
+ if (re.test(stem))
+ w = stem;
+ }
+ else if (re2.test(w)) {
+ var fp = re2.exec(w);
+ stem = fp[1] + fp[2];
+ re2 = new RegExp(mgr1);
+ if (re2.test(stem))
+ w = stem;
+ }
+
+ // Step 5
+ re = /^(.+?)e$/;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ re = new RegExp(mgr1);
+ re2 = new RegExp(meq1);
+ re3 = new RegExp("^" + C + v + "[^aeiouwxy]$");
+ if (re.test(stem) || (re2.test(stem) && !(re3.test(stem))))
+ w = stem;
+ }
+ re = /ll$/;
+ re2 = new RegExp(mgr1);
+ if (re.test(w) && re2.test(w)) {
+ re = /.$/;
+ w = w.replace(re,"");
+ }
+
+ // and turn initial Y back to y
+ if (firstch == "y")
+ w = firstch.toLowerCase() + w.substr(1);
+ return w;
+ }
+}
+
diff --git a/v5.0.1/_static/minus.png b/v5.0.1/_static/minus.png
new file mode 100644
index 000000000..d96755fda
Binary files /dev/null and b/v5.0.1/_static/minus.png differ
diff --git a/v5.0.1/_static/plus.png b/v5.0.1/_static/plus.png
new file mode 100644
index 000000000..7107cec93
Binary files /dev/null and b/v5.0.1/_static/plus.png differ
diff --git a/v5.0.1/_static/pygments.css b/v5.0.1/_static/pygments.css
new file mode 100644
index 000000000..04a41742e
--- /dev/null
+++ b/v5.0.1/_static/pygments.css
@@ -0,0 +1,84 @@
+pre { line-height: 125%; }
+td.linenos .normal { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; }
+span.linenos { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; }
+td.linenos .special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; }
+span.linenos.special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; }
+.highlight .hll { background-color: #ffffcc }
+.highlight { background: #f8f8f8; }
+.highlight .c { color: #8f5902; font-style: italic } /* Comment */
+.highlight .err { color: #a40000; border: 1px solid #ef2929 } /* Error */
+.highlight .g { color: #000000 } /* Generic */
+.highlight .k { color: #004461; font-weight: bold } /* Keyword */
+.highlight .l { color: #000000 } /* Literal */
+.highlight .n { color: #000000 } /* Name */
+.highlight .o { color: #582800 } /* Operator */
+.highlight .x { color: #000000 } /* Other */
+.highlight .p { color: #000000; font-weight: bold } /* Punctuation */
+.highlight .ch { color: #8f5902; font-style: italic } /* Comment.Hashbang */
+.highlight .cm { color: #8f5902; font-style: italic } /* Comment.Multiline */
+.highlight .cp { color: #8f5902 } /* Comment.Preproc */
+.highlight .cpf { color: #8f5902; font-style: italic } /* Comment.PreprocFile */
+.highlight .c1 { color: #8f5902; font-style: italic } /* Comment.Single */
+.highlight .cs { color: #8f5902; font-style: italic } /* Comment.Special */
+.highlight .gd { color: #a40000 } /* Generic.Deleted */
+.highlight .ge { color: #000000; font-style: italic } /* Generic.Emph */
+.highlight .ges { color: #000000 } /* Generic.EmphStrong */
+.highlight .gr { color: #ef2929 } /* Generic.Error */
+.highlight .gh { color: #000080; font-weight: bold } /* Generic.Heading */
+.highlight .gi { color: #00A000 } /* Generic.Inserted */
+.highlight .go { color: #888888 } /* Generic.Output */
+.highlight .gp { color: #745334 } /* Generic.Prompt */
+.highlight .gs { color: #000000; font-weight: bold } /* Generic.Strong */
+.highlight .gu { color: #800080; font-weight: bold } /* Generic.Subheading */
+.highlight .gt { color: #a40000; font-weight: bold } /* Generic.Traceback */
+.highlight .kc { color: #004461; font-weight: bold } /* Keyword.Constant */
+.highlight .kd { color: #004461; font-weight: bold } /* Keyword.Declaration */
+.highlight .kn { color: #004461; font-weight: bold } /* Keyword.Namespace */
+.highlight .kp { color: #004461; font-weight: bold } /* Keyword.Pseudo */
+.highlight .kr { color: #004461; font-weight: bold } /* Keyword.Reserved */
+.highlight .kt { color: #004461; font-weight: bold } /* Keyword.Type */
+.highlight .ld { color: #000000 } /* Literal.Date */
+.highlight .m { color: #990000 } /* Literal.Number */
+.highlight .s { color: #4e9a06 } /* Literal.String */
+.highlight .na { color: #c4a000 } /* Name.Attribute */
+.highlight .nb { color: #004461 } /* Name.Builtin */
+.highlight .nc { color: #000000 } /* Name.Class */
+.highlight .no { color: #000000 } /* Name.Constant */
+.highlight .nd { color: #888888 } /* Name.Decorator */
+.highlight .ni { color: #ce5c00 } /* Name.Entity */
+.highlight .ne { color: #cc0000; font-weight: bold } /* Name.Exception */
+.highlight .nf { color: #000000 } /* Name.Function */
+.highlight .nl { color: #f57900 } /* Name.Label */
+.highlight .nn { color: #000000 } /* Name.Namespace */
+.highlight .nx { color: #000000 } /* Name.Other */
+.highlight .py { color: #000000 } /* Name.Property */
+.highlight .nt { color: #004461; font-weight: bold } /* Name.Tag */
+.highlight .nv { color: #000000 } /* Name.Variable */
+.highlight .ow { color: #004461; font-weight: bold } /* Operator.Word */
+.highlight .pm { color: #000000; font-weight: bold } /* Punctuation.Marker */
+.highlight .w { color: #f8f8f8 } /* Text.Whitespace */
+.highlight .mb { color: #990000 } /* Literal.Number.Bin */
+.highlight .mf { color: #990000 } /* Literal.Number.Float */
+.highlight .mh { color: #990000 } /* Literal.Number.Hex */
+.highlight .mi { color: #990000 } /* Literal.Number.Integer */
+.highlight .mo { color: #990000 } /* Literal.Number.Oct */
+.highlight .sa { color: #4e9a06 } /* Literal.String.Affix */
+.highlight .sb { color: #4e9a06 } /* Literal.String.Backtick */
+.highlight .sc { color: #4e9a06 } /* Literal.String.Char */
+.highlight .dl { color: #4e9a06 } /* Literal.String.Delimiter */
+.highlight .sd { color: #8f5902; font-style: italic } /* Literal.String.Doc */
+.highlight .s2 { color: #4e9a06 } /* Literal.String.Double */
+.highlight .se { color: #4e9a06 } /* Literal.String.Escape */
+.highlight .sh { color: #4e9a06 } /* Literal.String.Heredoc */
+.highlight .si { color: #4e9a06 } /* Literal.String.Interpol */
+.highlight .sx { color: #4e9a06 } /* Literal.String.Other */
+.highlight .sr { color: #4e9a06 } /* Literal.String.Regex */
+.highlight .s1 { color: #4e9a06 } /* Literal.String.Single */
+.highlight .ss { color: #4e9a06 } /* Literal.String.Symbol */
+.highlight .bp { color: #3465a4 } /* Name.Builtin.Pseudo */
+.highlight .fm { color: #000000 } /* Name.Function.Magic */
+.highlight .vc { color: #000000 } /* Name.Variable.Class */
+.highlight .vg { color: #000000 } /* Name.Variable.Global */
+.highlight .vi { color: #000000 } /* Name.Variable.Instance */
+.highlight .vm { color: #000000 } /* Name.Variable.Magic */
+.highlight .il { color: #990000 } /* Literal.Number.Integer.Long */
\ No newline at end of file
diff --git a/v5.0.1/_static/searchtools.js b/v5.0.1/_static/searchtools.js
new file mode 100644
index 000000000..2c774d17a
--- /dev/null
+++ b/v5.0.1/_static/searchtools.js
@@ -0,0 +1,632 @@
+/*
+ * Sphinx JavaScript utilities for the full-text search.
+ */
+"use strict";
+
+/**
+ * Simple result scoring code.
+ */
+if (typeof Scorer === "undefined") {
+ var Scorer = {
+ // Implement the following function to further tweak the score for each result
+ // The function takes a result array [docname, title, anchor, descr, score, filename]
+ // and returns the new score.
+ /*
+ score: result => {
+ const [docname, title, anchor, descr, score, filename, kind] = result
+ return score
+ },
+ */
+
+ // query matches the full name of an object
+ objNameMatch: 11,
+ // or matches in the last dotted part of the object name
+ objPartialMatch: 6,
+ // Additive scores depending on the priority of the object
+ objPrio: {
+ 0: 15, // used to be importantResults
+ 1: 5, // used to be objectResults
+ 2: -5, // used to be unimportantResults
+ },
+ // Used when the priority is not in the mapping.
+ objPrioDefault: 0,
+
+ // query found in title
+ title: 15,
+ partialTitle: 7,
+ // query found in terms
+ term: 5,
+ partialTerm: 2,
+ };
+}
+
+// Global search result kind enum, used by themes to style search results.
+class SearchResultKind {
+ static get index() { return "index"; }
+ static get object() { return "object"; }
+ static get text() { return "text"; }
+ static get title() { return "title"; }
+}
+
+const _removeChildren = (element) => {
+ while (element && element.lastChild) element.removeChild(element.lastChild);
+};
+
+/**
+ * See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions#escaping
+ */
+const _escapeRegExp = (string) =>
+ string.replace(/[.*+\-?^${}()|[\]\\]/g, "\\$&"); // $& means the whole matched string
+
+const _displayItem = (item, searchTerms, highlightTerms) => {
+ const docBuilder = DOCUMENTATION_OPTIONS.BUILDER;
+ const docFileSuffix = DOCUMENTATION_OPTIONS.FILE_SUFFIX;
+ const docLinkSuffix = DOCUMENTATION_OPTIONS.LINK_SUFFIX;
+ const showSearchSummary = DOCUMENTATION_OPTIONS.SHOW_SEARCH_SUMMARY;
+ const contentRoot = document.documentElement.dataset.content_root;
+
+ const [docName, title, anchor, descr, score, _filename, kind] = item;
+
+ let listItem = document.createElement("li");
+ // Add a class representing the item's type:
+ // can be used by a theme's CSS selector for styling
+ // See SearchResultKind for the class names.
+ listItem.classList.add(`kind-${kind}`);
+ let requestUrl;
+ let linkUrl;
+ if (docBuilder === "dirhtml") {
+ // dirhtml builder
+ let dirname = docName + "/";
+ if (dirname.match(/\/index\/$/))
+ dirname = dirname.substring(0, dirname.length - 6);
+ else if (dirname === "index/") dirname = "";
+ requestUrl = contentRoot + dirname;
+ linkUrl = requestUrl;
+ } else {
+ // normal html builders
+ requestUrl = contentRoot + docName + docFileSuffix;
+ linkUrl = docName + docLinkSuffix;
+ }
+ let linkEl = listItem.appendChild(document.createElement("a"));
+ linkEl.href = linkUrl + anchor;
+ linkEl.dataset.score = score;
+ linkEl.innerHTML = title;
+ if (descr) {
+ listItem.appendChild(document.createElement("span")).innerHTML =
+ " (" + descr + ")";
+ // highlight search terms in the description
+ if (SPHINX_HIGHLIGHT_ENABLED) // set in sphinx_highlight.js
+ highlightTerms.forEach((term) => _highlightText(listItem, term, "highlighted"));
+ }
+ else if (showSearchSummary)
+ fetch(requestUrl)
+ .then((responseData) => responseData.text())
+ .then((data) => {
+ if (data)
+ listItem.appendChild(
+ Search.makeSearchSummary(data, searchTerms, anchor)
+ );
+ // highlight search terms in the summary
+ if (SPHINX_HIGHLIGHT_ENABLED) // set in sphinx_highlight.js
+ highlightTerms.forEach((term) => _highlightText(listItem, term, "highlighted"));
+ });
+ Search.output.appendChild(listItem);
+};
+const _finishSearch = (resultCount) => {
+ Search.stopPulse();
+ Search.title.innerText = _("Search Results");
+ if (!resultCount)
+ Search.status.innerText = Documentation.gettext(
+ "Your search did not match any documents. Please make sure that all words are spelled correctly and that you've selected enough categories."
+ );
+ else
+ Search.status.innerText = Documentation.ngettext(
+ "Search finished, found one page matching the search query.",
+ "Search finished, found ${resultCount} pages matching the search query.",
+ resultCount,
+ ).replace('${resultCount}', resultCount);
+};
+const _displayNextItem = (
+ results,
+ resultCount,
+ searchTerms,
+ highlightTerms,
+) => {
+ // results left, load the summary and display it
+ // this is intended to be dynamic (don't sub resultsCount)
+ if (results.length) {
+ _displayItem(results.pop(), searchTerms, highlightTerms);
+ setTimeout(
+ () => _displayNextItem(results, resultCount, searchTerms, highlightTerms),
+ 5
+ );
+ }
+ // search finished, update title and status message
+ else _finishSearch(resultCount);
+};
+// Helper function used by query() to order search results.
+// Each input is an array of [docname, title, anchor, descr, score, filename, kind].
+// Order the results by score (in opposite order of appearance, since the
+// `_displayNextItem` function uses pop() to retrieve items) and then alphabetically.
+const _orderResultsByScoreThenName = (a, b) => {
+ const leftScore = a[4];
+ const rightScore = b[4];
+ if (leftScore === rightScore) {
+ // same score: sort alphabetically
+ const leftTitle = a[1].toLowerCase();
+ const rightTitle = b[1].toLowerCase();
+ if (leftTitle === rightTitle) return 0;
+ return leftTitle > rightTitle ? -1 : 1; // inverted is intentional
+ }
+ return leftScore > rightScore ? 1 : -1;
+};
+
+/**
+ * Default splitQuery function. Can be overridden in ``sphinx.search`` with a
+ * custom function per language.
+ *
+ * The regular expression works by splitting the string on consecutive characters
+ * that are not Unicode letters, numbers, underscores, or emoji characters.
+ * This is the same as ``\W+`` in Python, preserving the surrogate pair area.
+ */
+if (typeof splitQuery === "undefined") {
+ var splitQuery = (query) => query
+ .split(/[^\p{Letter}\p{Number}_\p{Emoji_Presentation}]+/gu)
+ .filter(term => term) // remove remaining empty strings
+}
+
+/**
+ * Search Module
+ */
+const Search = {
+ _index: null,
+ _queued_query: null,
+ _pulse_status: -1,
+
+ htmlToText: (htmlString, anchor) => {
+ const htmlElement = new DOMParser().parseFromString(htmlString, 'text/html');
+ for (const removalQuery of [".headerlink", "script", "style"]) {
+ htmlElement.querySelectorAll(removalQuery).forEach((el) => { el.remove() });
+ }
+ if (anchor) {
+ const anchorContent = htmlElement.querySelector(`[role="main"] ${anchor}`);
+ if (anchorContent) return anchorContent.textContent;
+
+ console.warn(
+ `Anchored content block not found. Sphinx search tries to obtain it via DOM query '[role=main] ${anchor}'. Check your theme or template.`
+ );
+ }
+
+ // if anchor not specified or not found, fall back to main content
+ const docContent = htmlElement.querySelector('[role="main"]');
+ if (docContent) return docContent.textContent;
+
+ console.warn(
+ "Content block not found. Sphinx search tries to obtain it via DOM query '[role=main]'. Check your theme or template."
+ );
+ return "";
+ },
+
+ init: () => {
+ const query = new URLSearchParams(window.location.search).get("q");
+ document
+ .querySelectorAll('input[name="q"]')
+ .forEach((el) => (el.value = query));
+ if (query) Search.performSearch(query);
+ },
+
+ loadIndex: (url) =>
+ (document.body.appendChild(document.createElement("script")).src = url),
+
+ setIndex: (index) => {
+ Search._index = index;
+ if (Search._queued_query !== null) {
+ const query = Search._queued_query;
+ Search._queued_query = null;
+ Search.query(query);
+ }
+ },
+
+ hasIndex: () => Search._index !== null,
+
+ deferQuery: (query) => (Search._queued_query = query),
+
+ stopPulse: () => (Search._pulse_status = -1),
+
+ startPulse: () => {
+ if (Search._pulse_status >= 0) return;
+
+ const pulse = () => {
+ Search._pulse_status = (Search._pulse_status + 1) % 4;
+ Search.dots.innerText = ".".repeat(Search._pulse_status);
+ if (Search._pulse_status >= 0) window.setTimeout(pulse, 500);
+ };
+ pulse();
+ },
+
+ /**
+ * perform a search for something (or wait until index is loaded)
+ */
+ performSearch: (query) => {
+ // create the required interface elements
+ const searchText = document.createElement("h2");
+ searchText.textContent = _("Searching");
+ const searchSummary = document.createElement("p");
+ searchSummary.classList.add("search-summary");
+ searchSummary.innerText = "";
+ const searchList = document.createElement("ul");
+ searchList.setAttribute("role", "list");
+ searchList.classList.add("search");
+
+ const out = document.getElementById("search-results");
+ Search.title = out.appendChild(searchText);
+ Search.dots = Search.title.appendChild(document.createElement("span"));
+ Search.status = out.appendChild(searchSummary);
+ Search.output = out.appendChild(searchList);
+
+ const searchProgress = document.getElementById("search-progress");
+ // Some themes don't use the search progress node
+ if (searchProgress) {
+ searchProgress.innerText = _("Preparing search...");
+ }
+ Search.startPulse();
+
+ // index already loaded, the browser was quick!
+ if (Search.hasIndex()) Search.query(query);
+ else Search.deferQuery(query);
+ },
+
+ _parseQuery: (query) => {
+ // stem the search terms and add them to the correct list
+ const stemmer = new Stemmer();
+ const searchTerms = new Set();
+ const excludedTerms = new Set();
+ const highlightTerms = new Set();
+ const objectTerms = new Set(splitQuery(query.toLowerCase().trim()));
+ splitQuery(query.trim()).forEach((queryTerm) => {
+ const queryTermLower = queryTerm.toLowerCase();
+
+ // maybe skip this "word"
+ // stopwords array is from language_data.js
+ if (
+ stopwords.indexOf(queryTermLower) !== -1 ||
+ queryTerm.match(/^\d+$/)
+ )
+ return;
+
+ // stem the word
+ let word = stemmer.stemWord(queryTermLower);
+ // select the correct list
+ if (word[0] === "-") excludedTerms.add(word.substr(1));
+ else {
+ searchTerms.add(word);
+ highlightTerms.add(queryTermLower);
+ }
+ });
+
+ if (SPHINX_HIGHLIGHT_ENABLED) { // set in sphinx_highlight.js
+ localStorage.setItem("sphinx_highlight_terms", [...highlightTerms].join(" "))
+ }
+
+ // console.debug("SEARCH: searching for:");
+ // console.info("required: ", [...searchTerms]);
+ // console.info("excluded: ", [...excludedTerms]);
+
+ return [query, searchTerms, excludedTerms, highlightTerms, objectTerms];
+ },
+
+ /**
+ * execute search (requires search index to be loaded)
+ */
+ _performSearch: (query, searchTerms, excludedTerms, highlightTerms, objectTerms) => {
+ const filenames = Search._index.filenames;
+ const docNames = Search._index.docnames;
+ const titles = Search._index.titles;
+ const allTitles = Search._index.alltitles;
+ const indexEntries = Search._index.indexentries;
+
+ // Collect multiple result groups to be sorted separately and then ordered.
+ // Each is an array of [docname, title, anchor, descr, score, filename, kind].
+ const normalResults = [];
+ const nonMainIndexResults = [];
+
+ _removeChildren(document.getElementById("search-progress"));
+
+ const queryLower = query.toLowerCase().trim();
+ for (const [title, foundTitles] of Object.entries(allTitles)) {
+ if (title.toLowerCase().trim().includes(queryLower) && (queryLower.length >= title.length/2)) {
+ for (const [file, id] of foundTitles) {
+ const score = Math.round(Scorer.title * queryLower.length / title.length);
+ const boost = titles[file] === title ? 1 : 0; // add a boost for document titles
+ normalResults.push([
+ docNames[file],
+ titles[file] !== title ? `${titles[file]} > ${title}` : title,
+ id !== null ? "#" + id : "",
+ null,
+ score + boost,
+ filenames[file],
+ SearchResultKind.title,
+ ]);
+ }
+ }
+ }
+
+ // search for explicit entries in index directives
+ for (const [entry, foundEntries] of Object.entries(indexEntries)) {
+ if (entry.includes(queryLower) && (queryLower.length >= entry.length/2)) {
+ for (const [file, id, isMain] of foundEntries) {
+ const score = Math.round(100 * queryLower.length / entry.length);
+ const result = [
+ docNames[file],
+ titles[file],
+ id ? "#" + id : "",
+ null,
+ score,
+ filenames[file],
+ SearchResultKind.index,
+ ];
+ if (isMain) {
+ normalResults.push(result);
+ } else {
+ nonMainIndexResults.push(result);
+ }
+ }
+ }
+ }
+
+ // lookup as object
+ objectTerms.forEach((term) =>
+ normalResults.push(...Search.performObjectSearch(term, objectTerms))
+ );
+
+ // lookup as search terms in fulltext
+ normalResults.push(...Search.performTermsSearch(searchTerms, excludedTerms));
+
+ // let the scorer override scores with a custom scoring function
+ if (Scorer.score) {
+ normalResults.forEach((item) => (item[4] = Scorer.score(item)));
+ nonMainIndexResults.forEach((item) => (item[4] = Scorer.score(item)));
+ }
+
+ // Sort each group of results by score and then alphabetically by name.
+ normalResults.sort(_orderResultsByScoreThenName);
+ nonMainIndexResults.sort(_orderResultsByScoreThenName);
+
+ // Combine the result groups in (reverse) order.
+ // Non-main index entries are typically arbitrary cross-references,
+ // so display them after other results.
+ let results = [...nonMainIndexResults, ...normalResults];
+
+ // remove duplicate search results
+ // note the reversing of results, so that in the case of duplicates, the highest-scoring entry is kept
+ let seen = new Set();
+ results = results.reverse().reduce((acc, result) => {
+ let resultStr = result.slice(0, 4).concat([result[5]]).map(v => String(v)).join(',');
+ if (!seen.has(resultStr)) {
+ acc.push(result);
+ seen.add(resultStr);
+ }
+ return acc;
+ }, []);
+
+ return results.reverse();
+ },
+
+ query: (query) => {
+ const [searchQuery, searchTerms, excludedTerms, highlightTerms, objectTerms] = Search._parseQuery(query);
+ const results = Search._performSearch(searchQuery, searchTerms, excludedTerms, highlightTerms, objectTerms);
+
+ // for debugging
+ //Search.lastresults = results.slice(); // a copy
+ // console.info("search results:", Search.lastresults);
+
+ // print the results
+ _displayNextItem(results, results.length, searchTerms, highlightTerms);
+ },
+
+ /**
+ * search for object names
+ */
+ performObjectSearch: (object, objectTerms) => {
+ const filenames = Search._index.filenames;
+ const docNames = Search._index.docnames;
+ const objects = Search._index.objects;
+ const objNames = Search._index.objnames;
+ const titles = Search._index.titles;
+
+ const results = [];
+
+ const objectSearchCallback = (prefix, match) => {
+ const name = match[4]
+ const fullname = (prefix ? prefix + "." : "") + name;
+ const fullnameLower = fullname.toLowerCase();
+ if (fullnameLower.indexOf(object) < 0) return;
+
+ let score = 0;
+ const parts = fullnameLower.split(".");
+
+ // check for different match types: exact matches of full name or
+ // "last name" (i.e. last dotted part)
+ if (fullnameLower === object || parts.slice(-1)[0] === object)
+ score += Scorer.objNameMatch;
+ else if (parts.slice(-1)[0].indexOf(object) > -1)
+ score += Scorer.objPartialMatch; // matches in last name
+
+ const objName = objNames[match[1]][2];
+ const title = titles[match[0]];
+
+ // If more than one term searched for, we require other words to be
+ // found in the name/title/description
+ const otherTerms = new Set(objectTerms);
+ otherTerms.delete(object);
+ if (otherTerms.size > 0) {
+ const haystack = `${prefix} ${name} ${objName} ${title}`.toLowerCase();
+ if (
+ [...otherTerms].some((otherTerm) => haystack.indexOf(otherTerm) < 0)
+ )
+ return;
+ }
+
+ let anchor = match[3];
+ if (anchor === "") anchor = fullname;
+ else if (anchor === "-") anchor = objNames[match[1]][1] + "-" + fullname;
+
+ const descr = objName + _(", in ") + title;
+
+ // add custom score for some objects according to scorer
+ if (Scorer.objPrio.hasOwnProperty(match[2]))
+ score += Scorer.objPrio[match[2]];
+ else score += Scorer.objPrioDefault;
+
+ results.push([
+ docNames[match[0]],
+ fullname,
+ "#" + anchor,
+ descr,
+ score,
+ filenames[match[0]],
+ SearchResultKind.object,
+ ]);
+ };
+ Object.keys(objects).forEach((prefix) =>
+ objects[prefix].forEach((array) =>
+ objectSearchCallback(prefix, array)
+ )
+ );
+ return results;
+ },
+
+ /**
+ * search for full-text terms in the index
+ */
+ performTermsSearch: (searchTerms, excludedTerms) => {
+ // prepare search
+ const terms = Search._index.terms;
+ const titleTerms = Search._index.titleterms;
+ const filenames = Search._index.filenames;
+ const docNames = Search._index.docnames;
+ const titles = Search._index.titles;
+
+ const scoreMap = new Map();
+ const fileMap = new Map();
+
+ // perform the search on the required terms
+ searchTerms.forEach((word) => {
+ const files = [];
+ const arr = [
+ { files: terms[word], score: Scorer.term },
+ { files: titleTerms[word], score: Scorer.title },
+ ];
+ // add support for partial matches
+ if (word.length > 2) {
+ const escapedWord = _escapeRegExp(word);
+ if (!terms.hasOwnProperty(word)) {
+ Object.keys(terms).forEach((term) => {
+ if (term.match(escapedWord))
+ arr.push({ files: terms[term], score: Scorer.partialTerm });
+ });
+ }
+ if (!titleTerms.hasOwnProperty(word)) {
+ Object.keys(titleTerms).forEach((term) => {
+ if (term.match(escapedWord))
+ arr.push({ files: titleTerms[term], score: Scorer.partialTitle });
+ });
+ }
+ }
+
+ // no match but word was a required one
+ if (arr.every((record) => record.files === undefined)) return;
+
+ // found search word in contents
+ arr.forEach((record) => {
+ if (record.files === undefined) return;
+
+ let recordFiles = record.files;
+ if (recordFiles.length === undefined) recordFiles = [recordFiles];
+ files.push(...recordFiles);
+
+ // set score for the word in each file
+ recordFiles.forEach((file) => {
+ if (!scoreMap.has(file)) scoreMap.set(file, {});
+ scoreMap.get(file)[word] = record.score;
+ });
+ });
+
+ // create the mapping
+ files.forEach((file) => {
+ if (!fileMap.has(file)) fileMap.set(file, [word]);
+ else if (fileMap.get(file).indexOf(word) === -1) fileMap.get(file).push(word);
+ });
+ });
+
+ // now check if the files don't contain excluded terms
+ const results = [];
+ for (const [file, wordList] of fileMap) {
+ // check if all requirements are matched
+
+ // as search terms with length < 3 are discarded
+ const filteredTermCount = [...searchTerms].filter(
+ (term) => term.length > 2
+ ).length;
+ if (
+ wordList.length !== searchTerms.size &&
+ wordList.length !== filteredTermCount
+ )
+ continue;
+
+ // ensure that none of the excluded terms is in the search result
+ if (
+ [...excludedTerms].some(
+ (term) =>
+ terms[term] === file ||
+ titleTerms[term] === file ||
+ (terms[term] || []).includes(file) ||
+ (titleTerms[term] || []).includes(file)
+ )
+ )
+ break;
+
+ // select one (max) score for the file.
+ const score = Math.max(...wordList.map((w) => scoreMap.get(file)[w]));
+ // add result to the result list
+ results.push([
+ docNames[file],
+ titles[file],
+ "",
+ null,
+ score,
+ filenames[file],
+ SearchResultKind.text,
+ ]);
+ }
+ return results;
+ },
+
+ /**
+ * helper function to return a node containing the
+ * search summary for a given text. keywords is a list
+ * of stemmed words.
+ */
+ makeSearchSummary: (htmlText, keywords, anchor) => {
+ const text = Search.htmlToText(htmlText, anchor);
+ if (text === "") return null;
+
+ const textLower = text.toLowerCase();
+ const actualStartPosition = [...keywords]
+ .map((k) => textLower.indexOf(k.toLowerCase()))
+ .filter((i) => i > -1)
+ .slice(-1)[0];
+ const startWithContext = Math.max(actualStartPosition - 120, 0);
+
+ const top = startWithContext === 0 ? "" : "...";
+ const tail = startWithContext + 240 < text.length ? "..." : "";
+
+ let summary = document.createElement("p");
+ summary.classList.add("context");
+ summary.textContent = top + text.substr(startWithContext, 240).trim() + tail;
+
+ return summary;
+ },
+};
+
+_ready(Search.init);
diff --git a/v5.0.1/_static/sections.png b/v5.0.1/_static/sections.png
new file mode 100644
index 000000000..cea9b3cca
Binary files /dev/null and b/v5.0.1/_static/sections.png differ
diff --git a/v5.0.1/_static/sphinx_highlight.js b/v5.0.1/_static/sphinx_highlight.js
new file mode 100644
index 000000000..8a96c69a1
--- /dev/null
+++ b/v5.0.1/_static/sphinx_highlight.js
@@ -0,0 +1,154 @@
+/* Highlighting utilities for Sphinx HTML documentation. */
+"use strict";
+
+const SPHINX_HIGHLIGHT_ENABLED = true
+
+/**
+ * highlight a given string on a node by wrapping it in
+ * span elements with the given class name.
+ */
+const _highlight = (node, addItems, text, className) => {
+ if (node.nodeType === Node.TEXT_NODE) {
+ const val = node.nodeValue;
+ const parent = node.parentNode;
+ const pos = val.toLowerCase().indexOf(text);
+ if (
+ pos >= 0 &&
+ !parent.classList.contains(className) &&
+ !parent.classList.contains("nohighlight")
+ ) {
+ let span;
+
+ const closestNode = parent.closest("body, svg, foreignObject");
+ const isInSVG = closestNode && closestNode.matches("svg");
+ if (isInSVG) {
+ span = document.createElementNS("http://www.w3.org/2000/svg", "tspan");
+ } else {
+ span = document.createElement("span");
+ span.classList.add(className);
+ }
+
+ span.appendChild(document.createTextNode(val.substr(pos, text.length)));
+ const rest = document.createTextNode(val.substr(pos + text.length));
+ parent.insertBefore(
+ span,
+ parent.insertBefore(
+ rest,
+ node.nextSibling
+ )
+ );
+ node.nodeValue = val.substr(0, pos);
+ /* There may be more occurrences of search term in this node. So call this
+ * function recursively on the remaining fragment.
+ */
+ _highlight(rest, addItems, text, className);
+
+ if (isInSVG) {
+ const rect = document.createElementNS(
+ "http://www.w3.org/2000/svg",
+ "rect"
+ );
+ const bbox = parent.getBBox();
+ rect.x.baseVal.value = bbox.x;
+ rect.y.baseVal.value = bbox.y;
+ rect.width.baseVal.value = bbox.width;
+ rect.height.baseVal.value = bbox.height;
+ rect.setAttribute("class", className);
+ addItems.push({ parent: parent, target: rect });
+ }
+ }
+ } else if (node.matches && !node.matches("button, select, textarea")) {
+ node.childNodes.forEach((el) => _highlight(el, addItems, text, className));
+ }
+};
+const _highlightText = (thisNode, text, className) => {
+ let addItems = [];
+ _highlight(thisNode, addItems, text, className);
+ addItems.forEach((obj) =>
+ obj.parent.insertAdjacentElement("beforebegin", obj.target)
+ );
+};
+
+/**
+ * Small JavaScript module for the documentation.
+ */
+const SphinxHighlight = {
+
+ /**
+ * highlight the search words provided in localstorage in the text
+ */
+ highlightSearchWords: () => {
+ if (!SPHINX_HIGHLIGHT_ENABLED) return; // bail if no highlight
+
+ // get and clear terms from localstorage
+ const url = new URL(window.location);
+ const highlight =
+ localStorage.getItem("sphinx_highlight_terms")
+ || url.searchParams.get("highlight")
+ || "";
+ localStorage.removeItem("sphinx_highlight_terms")
+ url.searchParams.delete("highlight");
+ window.history.replaceState({}, "", url);
+
+ // get individual terms from highlight string
+ const terms = highlight.toLowerCase().split(/\s+/).filter(x => x);
+ if (terms.length === 0) return; // nothing to do
+
+ // There should never be more than one element matching "div.body"
+ const divBody = document.querySelectorAll("div.body");
+ const body = divBody.length ? divBody[0] : document.querySelector("body");
+ window.setTimeout(() => {
+ terms.forEach((term) => _highlightText(body, term, "highlighted"));
+ }, 10);
+
+ const searchBox = document.getElementById("searchbox");
+ if (searchBox === null) return;
+ searchBox.appendChild(
+ document
+ .createRange()
+ .createContextualFragment(
+ '
For builds on MS Windows, the CMake command arguments are specified for every build configuration in the cmakeSettings.json.
+For builds on Linux and MacOs, the CMake command arguments must be specified from the command line.
The cmakeSettings.json provides standard build configurations for a DEBUG build, a RELEASE build and a RELEASE_with_Debug_Info build.
+
The DEBUG build compiles code suited for debugging, i.e. the code is compiled such that every line of code is individually executed.
+This way, it is possible to go through the code line by line and to set breakpoints in an IDE such as MS Visual Studio.
+Additionally, the DEBUG build will print additional information during the simulation, such as the current step size and time point of the simulation.
+
The RELEASE build compiles optimized code and should be used to actually use CADET for simulations.
+
The RELEASE_with_Debug_Info build compiles optimized code but some debug information will still be printed.
+
The RELEASE_with_Tests and DEBUG_with_Test build options additionally build the testRunner, which is required to run the integrated tests in CADET-Core.
The following build arguments can be set in the cmakeSettings.json or from the cmake command line:
+
+
DCMAKE_INSTALL_PREFIX: location for the installed CADET-Core framework.
+
DENABLE_STATIC_LINK_LAPACK Prefer static over dynamic linking of LAPACK and BLAS into the CADET-Core framework. Static linking incorporates all necessary libraries into the final executable at compile time, while dynamic linking loads libraries at runtime. Static linking produces larger executables that are less dependent on changes in the operating system. Dynamic linking allows for dynamic updates of underlying libraries and smaller compiled software.
+
DENABLE_STATIC_LINK_DEPS: Prefer static over dynamic linking of dependencies into the CADET-Core framework.
+
DENABLE_STATIC_LINK_CLI: Prefers static over dynamic linking for CADET CLI.
+
DENABLE_TESTS: Build the restRunner executable to evaluate the integrated tests in CADET-Core.
+
DENABLE_ANALYTIC_JACOBIAN_CHECK: Computes both the analytical and AD Jacobian and compares them for testing purpose.
+
DENABLE_THREADING: Enables multi-threading capabilities. Parallelized code will be compiled, using the TBB library. Note that the non-parallelized code is faster compared to the parallelized code when only one thread is being used. The number of threads is specified in the filed N_THREADS.
+
DBLA_VENDOR: Vendor for the BLAS & LAPACK library. If unset, the system library will be used. By default on Windows we use the Intel OneApi library, specified with Intel10_64lp_seq. If a parallelized build is generated, this should be set to Intel10_64lp.
+
DENABLE_LOGGING: Enables logging functionality.
+
DENABLE_BENCHMARK: Activates benchmark mode for fine-grained timing.
+
DENABLE_PLATFORM_TIMER: Utilizes a platform-dependent timer.
+
DENABLE_DEBUG_THREADING: Activates multi-threading in debug builds.
+
DENABLE_2D_MODELS: Builds 2D models such as the 2D general rate model and multichannel transport.
+
DENABLE_DG: Constructs DG variants of models.
+
DENABLE_SUNDIALS_OPENMP: Prefers the OpenMP vector implementation of SUNDIALS for large problems if available.
+
DENABLE_CADET_CLI: Builds the CADET command line interface.
DENABLE_IPO: Enables interprocedural optimization if the compiler supports it.
+
DCMAKE_INSTALL_RPATH_USE_LINK_PATH: Adds paths to linker search and installed rpath.
+
DNUM_MAX_AD_DIRS: Specifies the number of allowed AD directions (default value is 80). Increasing this value can decrease performance when AD is being used.
+
+
The following build arguments are exclusive to builds on MS windows:
+
+
DVCPKG_TARGET_TRIPLET: We use vcpkg to manage our dependencies. This triplet specifies which version of the dependencies should be installed. It takes the form of architecture-os-linking, so x64-windows-static for our use cases.
+
+
The following build arguments can only be used with the Clang or GCC compilers:
+
+
DENABLE_ASAN: enables the address sanitizer.
+
DENABLE_UBSAN: enables the undefined behaviour sanitizer.
This section gives a general overview of the object-oriented c++ implementation of CADET-Core and is based on the Software Architecture chapter 3.2 in Samuel Lewekes PhD thesis [1].
+
The CADET-Core software is designed to be modular, extendable, maintainable and computationally efficient and robust.
+To promote these goals, CADET-Core is implemented in C++, a highly performant, object-oriented language that supports cross-platform compatibility.
Allows to easily add new frontends as the core simulator is implemented in the library libcadet, which can be called from different frontends.
+Currently, CADET-Core features the command line interface cadet-cli and CADET-Python, which includes a Cadet class that serves as a generic HDF5 frontend and calls the cadet-cli.
+The CADET-Process frontend is a separate software that wraps CADET-Python and supports additional pre- and post-processing functionality, as described in the CADET-Process documentation.
+The Matlab frontend was deprecated in commit 4b34e0d5 due to its maintenance overhead.
+
Can compute parameter sensitivities via a custom Algorithmic Differentiation (AD) implementation. The AD infrastructure allows for easy extension of new models to support parameter sensitivities, as described in the AD section of the Model Expansion chapter.
+
Allows arbitrary systems of unit operations, including cycles.
+
Implements a method of lines approach to solve the model equations: Custom implementations of model equations and, if required, spatial discretizations, are complemented by the well-established and publicly available time integration software library SUNDIALS.
+Their IDAS solver implements a variable order (up to fifth order) BDF with adaptive time stepping and has proven to be stable and robust.
+Additionally, IDAS supports the forward computation of parameter sensitivities, i.e. solves the forward sensitivity equation system as described in their documentation.
Fig. 15 Selected relationships of classes in libcadet[1].¶
+
+
+
+
In the following, we briefly describe the purpose of some of the items in the figure above:
+
Classes with capital letter I as prefix are abstract classes that define the interface for the derived classes.
+
ISimulator
+Exported interface to the simulator.
+
Simulator
+Implements time integration including parameter sensitivities.
+
IModelSystem
+Defines basic functions that users of libcadet can use to modify a system of submodels (e.g., add submodels, access parameters).
+
ISimulatableModel
+Defines functions that the time integration process needs to run.
+This includes, for example, evaluation of model equations, solution of linearized model equations, and consistent initialization.
+
ModelSystem
+Implements the system of submodels.
+It also owns external functions that can be used to modify model parameters based on externally given data (e.g., pH profile).
+
IExternalFunction
+Defines the functions for evaluating an externally given function.
+For example, an external function can be represented by a piecewise cubic polynomial.
+It could also interpolate between given data points or delegate the calls to a MATLAB function.
+Besides evaluating the function itself, certain derivatives have to be provided.
+
IUnitOperation
+Corresponds to a black box submodel which meets the Unit Operation submodel assumption.
+Besides evaluation of model equations, solution of linearized model equations, and consistent initialization, it also handles ports and their volumetric flow rates.
+
GeneralRateModel
+Implements the General rate model (GRM).
+It serves as an example for an IUnitOperation implementation in the diagram.
+Common functionality between submodels is moved into separate classes or functions (e.g., ConvectionDispersionOperator).
+
ConvectionDispersionOperator
+Implements the operator \(-u \frac{\partial c}{\partial z} + D_\text{ax} \frac{\partial^2 c}{\partial z^2}\), which is used in many transport models.
+It also converts the volumetric flow rate to the interstitial velocity \(u\) using the cross section area of the column and the porosity.
+
IBindingModel
+Defines functions for evaluating the binding rates \(f_\text{ads,j}\left(c^p_j, c^s_j\right)\) (as used in, e.g., the General rate model (GRM)), according to some Binding models. This interface fully encapsulates a binding model.
+If supported, binding model parameters may have a Dependence on external function.
+
IDynamicReactionModel
+Defines functions for evaluating the reaction rates \(f_\text{react,i}\left( c \right)\) (as used in, e.g., the General rate model (GRM)), according to some Reaction models.
+If supported, reaction model parameters may have a Dependence on external function.
\(\mathbf{q}_{in,n}, \mathbf{q}_{out,n} \in \mathbb{R}^{N_{in, n}}\) are the inlet port and outlet port volumetric flow rates, respectively,
+
\(\mathbf{y}_{in,n} \in \mathbb{R}^{N_{in, n} N_c,n}\) is the inlet concentration of all ports and components,
+
\(\mathbf{y}_{n}\) contains the state variables of the submodel, and \(\frac{\partial \mathbf{y}_{n}}{\partial t}\) contains its time derivatives.
+
+
+
+
+
The outlet concentration \(\mathbf{c}_{out,n,j} \ \colon (0, T_\text{end}) \mapsto \mathbb{R}^{N_{c,n}}\) of port \(j\in\{1,\dots , N_{out,n}\}\) of submodel \(n\) is a linear function of its state vector \(\mathbf{y}_n\).
The CADET-Python API can be very useful for developers as it allows to create an arbitrary input configuration for CADET-Core.
+This is especially useful when new methods and models are added, which are not (yet) supported by the CADET-Process frontend.
+To demonstrate the use of CADET-Python, we set up a simulation in the following.
+
+
Performing a forward simulation comprises several steps:
+
Setting up the model including all parameters and discretization options
+
Defining sections and switches
+
Setting up the simulator and actually running the simulation
+
Evaluating results (e.g., plotting)
+
+
+
+
In this tutorial, we will build a simple forward simulation with a breakthrough of one component using the following system:
+
+
+
+
For this purpose, we use CADET-Python, a file based frontend for CADET.
+CADET still must be downloaded (or built from source) as explained in the installation guide.
+The Python frontend almost exactly maps to the documented CADET file format except that all dataset names are lowercase.
+This simplifies using the frontend.
+The package includes a Cadet class which serves as a generic HDF5 frontend.
+
As an example, we consider setting the external porosity for the column model (unit_001).
+From file format, the path for this is /input/model/unit_001/COL_POROSITY.
+In the Python frontend, this becomes:
First, we need to import some libraries and specify the location of the cadet-cli executable (core simulator).
+It is located in the bin folder where CADET was installed.
To create the model and specify its parameters, we create an instance of the Cadet class.
+In the root attribute of this object, the parameter structure is defined as described in the file format reference.
+It is implemented as a Dict of the addict package.
+This allows for creating arbitrary nested dictionaries using dot-notation.
+
+
Warning
+
Note, that the Cadet class does not provide any sanity checks.
+If parameters are misspelled or have the wrong dimensions, they are simply ignored.
+This can cause problems later on, when the simulator is run.
Although the order of the parameter specification does not matter, it is reasonable to first specify the number of unit operations before we select the models and define the parameters.
+
model.root.input.model.nunits=3
+
+
+
The available models are listed in the unit operation chapter.
+The units of the different parameters and quantities are given in the corresponding file format of the respective unit operation.
In CADET, the INLET pseudo unit operation serves as a source for the system and is used to create arbitary concentration profiles as boundary conditions.
+First, we define an INLET as the first unit operation by adding the field unit_000 in the /input/model/ group.
+The concentration profile is described using a piecewise cubic polynomial (cubic spline in the continuous case) for each component, where the pieces are given by the time sections.
+Later, we will define the polynomials, when we look at time sections.
We now add a second unit operation, the column model.
+For the general rate model model, we set the unit_type parameter of the corresponding unit operation model to GENERAL_RATE_MODEL.
+In this group, we set the parameters related to transport and column geometry.
+For a more detailed description of the parameters and their units, see the corresponding file format.
+
model.root.input.model.unit_001.unit_type='GENERAL_RATE_MODEL'
+model.root.input.model.unit_001.ncomp=1
+
+## Geometry
+model.root.input.model.unit_001.col_length=0.1# m
+model.root.input.model.unit_001.cross_section_area=0.01# m
+model.root.input.model.unit_001.col_porosity=0.37# -
+model.root.input.model.unit_001.par_porosity=0.33# -
+model.root.input.model.unit_001.par_radius=1e-6# m
+
+## Transport
+model.root.input.model.unit_001.col_dispersion=1e-8# m^2 / s (interstitial volume)
+model.root.input.model.unit_001.film_diffusion=[1e-5]# m / s
+model.root.input.model.unit_001.par_diffusion=[1e-10,]# m^2 / s (mobile phase)
+model.root.input.model.unit_001.par_surfdiffusion=[0.0,]# m^2 / s (solid phase)
+
+
+
Note that film, particle, and surface diffusion are all component-specific, that is, they are vectors of length n_components.
Every column model can be equipped with an adsorption model.
+The available models are listed in the binding model chapter.
+
For the Langmuir model, we set the adsorption_model parameter of the corresponding unit operation model to MULTI_COMPONENT_LANGMUIR.
+Then, we decide if we want to use the rapid-equilibrium assumption in the binding model (is_kinetic=False), which is not the case here (dynamic binding).
+Finally, the parameters of the binding model have to be set for each component (they are vectors of length n_components).
+They are described in the corresponding file format specification.
+In case of the Langmuir model, we have to specify the parameters kA, kD, and qMAX.
Next, we specify the initial conditions (concentration of the components in the mobile and stationary phases) for the column.
+These concentrations are entered as vectors, where each entry gives the concentration for the corresponding component.
+In this example, we start with an empty column.
There are several options for adapting the spatial discretization of the PDE model.
+However, the two most important ones are the number of grid cells in the column (axial direction) and the particles, which are also set in this example.
+We choose 20 axial cells in the column ncol and 5 radial cells in the particle npar.
+
+
Warning
+
These are rather low values to make the examples run faster, since they are only for educational purposes.
+In practice, much higher values are expected (say 100-200 axial cells and 16-32 particle cells).
+Note that the WENO scheme, which handles the advection, drastically reduces the required amount of cells compared to an upwind scheme.
+
+
Moreover, we have to specify the number of bound states for each component.
+Finally, we set some other options for the discretization, which usually do not need to be changed.
Time sections are used to specify changes of parameter values during the simulation.
+A section typically corresponds to an operating step (load, wash, elute etc.), but can also be used to indicate changes in connectivity, or even discontinuities of model parameters.
+
In the /input/solver/sections/ group, nsec denotes the number of sections.
+The start and end times of a section are given in the section_times vector.
+It should always start at 0.0 and contains nsec+1 values, that is, the ith section goes from section_times[i] to section_times[i+1].
+
The section_continuity indicates whether a transition from one section to the next is continuous in both the inlet and the parameters.
+It has nsec-1 number of values, since there is one transition less than there are sections.
+The continuity is used in CADET’s time integrator, which needs to decide whether to restart on entering a new section.
+If the transition is continuous, the time integrator can try to step over the transition without restarting, thus saving some computation time (since the restart is costly).
+If you are unsure about the continuity, just leave it at 0.
+
model.root.input.solver.sections.nsec=1
+model.root.input.solver.sections.section_times=[0.0,1200,]# s
+model.root.input.solver.sections.section_continuity=[]
+
+
+
As mentioned earlier, we now define the INLET profile using a piecewise cubic polynomial.
+On each section \([ t_i, t_{i+1} ]\) a cubic polynomial \(p_i\) is defined:
+
+\[p_i( t ) = d * (t - t_i)^3 + c * (t - t_i)^2 + b * (t - t_i) + a,\]
+
where the coefficients of the polynomial are const_coeff (a), lin_coeff (b), quad_coeff (c), and cube_coeff (d).
+Note that the constant coefficient const_coeff determines the starting concentration on each section.
+The stopping concentration is given by \(p_i( t_{i+1} )\) or \(p_{i+1}( t_{i+1} )\) in case of a continuous profile.
+
In this example, which has only one section, we define its coefficients by adding the field sec_000 to the inlet unit (unit_000).
+Since the column should be constantly fed with \(1.0 \cdot 10^{-3} mol / m^3\), we set const_coeff to [1.0e-3] and all other cofficients to [0.0].
+Note that for more components, a vector of coefficients needs to be specified.
In order to specify the connectivity of the network, we have to provide a list of connections.
+CADET requires that we append all connections to a long vector (i.e., if each connection is a row in a matrix, CADET wants this matrix in row-major storage).
+Moreover, we have to specify the section in which the specified connectivity should be applied.
Usually, Componentfrom and Componentto can be set to -1, which will connect all components from the origin and destination unit operations.
+
+
Note
+
Since CADET version 4.1, the flow rates can also be defined with piecewise cubic polynomials.
+Also, for the 2D General rate model inlet ports need to be speciefied.
+For more information on the parameters, see the file format specification.
+
+
In this case, we connect all components of unit_000 to unit_001, and from unit_001 to unit_002.
+
model.root.input.model.connections.nswitches=1
+model.root.input.model.connections.switch_000.section=0
+model.root.input.model.connections.switch_000.connections=[
+ 0,1,-1,-1,60/1e6,# [unit_000, unit_001, all components, all components, Q/ m^3*s^-1
+ 1,2,-1,-1,60/1e6]# [unit_001, unit_002, all components, all components, Q/ m^3*s^-1
+
+
+
+
Note
+
Since the flow in the column models is incompressible, the total entering flow rate must equal the total outgoing flow rate.
+This restriction does not apply to a CSTR model, because it has a variable volume.
+
+
+
+
+
3. Setting Up the Simulator and Running the Simulation¶
+
Before we can start the simulation, we have to specify some settings for the simulator.
+
First, we set some options for the solver and the time integrator.
+Usually, these only need to be adapted in special cases.
+
model.root.input.model.solver.gs_type=1
+model.root.input.model.solver.max_krylov=0
+model.root.input.model.solver.max_restarts=10
+model.root.input.model.solver.schur_safety=1e-8
+
+# Number of cores for parallel simulation
+model.root.input.solver.nthreads=1
+
+# Tolerances for the time integrator
+model.root.input.solver.time_integrator.abstol=1e-6
+model.root.input.solver.time_integrator.algtol=1e-10
+model.root.input.solver.time_integrator.reltol=1e-6
+model.root.input.solver.time_integrator.init_step_size=1e-6
+model.root.input.solver.time_integrator.max_steps=1000000
+
+
+
Of these options, the most interesting ones are time_integrator.abstol and time_integrator.reltol, which control the errors during time integration, and nthreads, which sets the number of CPU cores CADET is allowed to use.
+
Second, we have to specify which results we want CADET to return.
+For this, we have to specify the /input/return/ group.
+For more information, see the file format specification.
+
In this example, we want to write the concentration profile of the inlet and outlet of each unit operation.
+In addition, we are interested in the concentration in the interstitial volume (bulk volume) of the column.
+
# Return data
+model.root.input['return'].split_components_data=0
+model.root.input['return'].split_ports_data=0
+model.root.input['return'].unit_000.write_solution_bulk=1
+model.root.input['return'].unit_000.write_solution_inlet=1
+model.root.input['return'].unit_000.write_solution_outlet=1
+
+# Copy settings to the other unit operations
+model.root.input['return'].unit_001=model.root.input['return'].unit_000
+model.root.input['return'].unit_002=model.root.input['return'].unit_000
+
+
+
Finally, we have to set the time points at which we want to evaluate the solution.
+Note that the end time must not exceed the last section time specified in the model.
+If the time points are not set explicitly, the time integrator outputs the solution at arbitrary time points between 0 and section_times[-1].
+
# Solution times
+model.root.input.solver.user_solution_times=np.linspace(0,1200,1001)
+
+
+
The last remaining step is to actually run the simulation.
+For this, we have to specify a filename, save the configuration to H5-format and call call the model’s run() function.
+We check if the simulation has completed successfully and load the results.
The data is stored in the /output/ group of the Cadet object.
+The structure and format of the data is described in the file format specification.
+Finally, we plot the concentration signal at the outlet of the column.
We advice to use an IDE like MS Visual Studio to debug CADET-Core.
+
If the debugger does not stop at a breakpoint even though it is set in the correct source file, this might be because a corresponding libcadet file was build and is being run. You can find these files under build/src/libcadet. Alternatively, you can set a breakpoint in an early stage, e.g. in the driver file and manually step through the code.
+
To run a specific simulation with the Visual Studio debugguer, you can add the launch.vs.json file provided here to the .vs folder
To debug memory related issues, you can compile the code with the address sanitizer ASAN and the undefined behaviour sanitizer UBSAN by enabling the cmake arguments DENABLE_ASAN and DENABLE_UBSAN.
This developer guide is intended to help expand and maintain CADET-Core and is written to serve developers with diverse backgrounds.
+
If you find any gaps or have suggestions for improvement, your input is valuable in refining our documentation for better comprehension by all developers.
+Please feel free to open an issue on GitHub or, even better, write a draft and create a pull request.
+
When planning to extend or contribute to CADET-Core, please adhere to our notation style and research software engineering (RSE) best practices.
+For detailed guidance, you can e.g. refer to the RSE guidelines.
+Since some developers may be new to collaborative software development using Git and GitHub, we specifically recommend consulting the Git RSE guide.
There are 7+ transport models and 20+ adsorption models implemented in CADET.
+Please make sure that the one you are interested in is not implemented.
+Additionally, some models can be mimicked by or are even equivalent to already implemented models when specific parameters are chosen, see e.g. the LRM use-case section for the Multichannel Transport model (MCT model).
+
The implementation of a new model follows three main steps:
+1. Create a template binding/unit/reaction model from existing code
+2. Register the binding/unit/reaction model in the respective CADET binding/unit/reaction model factory and add it to cmake
+3. Implementation of model equations and Jacobian matrix
+4. Testing
An extensive description on how to add a new binding model to CADET-Core is given in a forum post, where such an extension is described using the example of a Langmuir binding.
+A more concise description is given in the following:
+
1.
+Use the binding model template to create a new binding model file in the CADET binding model source directory
and rename the model in the file (i.e. Template to YoureModelName).
+Note that the provided template binding model is an implementation of the multi-component Langmuir binding.
to the BindingModelFactory.cpp at the end of all the other registering functions such as model::binding::registerLinearModel(_bindingModels).
+The final step to register your model is to add your model to the \src\libcadet\CMakeLists.txt (again look for similar statements for the other binding models) by adding
Before continuing with the third step, you should rebuild CADET-Core to verify that the first two steps went well.
+
3.
+The actual implementation of the new binding model follows two main steps: the configuration of the relevant mechanistic parameters and implementation of adsorption flux and Jacobian.
+To set up the configuration of isotherm parameters a macro (.json script) has been included in the code, which generates the relevant code section when the user defines the parameters in the scope of this script.
+To modify the script go to Line 30 in the provided file template and adjust the parameters to your needs, a more detailed description for that is provided in the aforementioned forum post.
+
Next, the adsorption flux equations need to be implemented int the corresponding function
For an explanation of active types for the template arguments StateType, ParamType, ResidualType, please refer to the Algorithmic Differentiation section.
+
Finally, the Jacobian needs to be implemented in the function
+
voidjacobianImpl()
+
We note that the Jacobian implementation is optional but highly recommended to speed up the simulation.
+If you have trouble with deriving the Jacobian or if you want to test you model first, modify the
+implementsAnalyticJacobian()
+function to return false.
+By doing so, CADET-Core defaults to computing the binding Jacobian via Algorithmic differentiation (AD).
The easiest way to create a new unit operation in CADET-Core is to start from an existing unit operation (e.g. src/libcadet/StirredTankModel, but optimally the most similar one) and make adjustments from there.
+The first, model independent steps are:
+
+
Add NewModel.cpp and NewModel.hpp files in src\libcadet\model folder (copy and rename existing ones). Note that we’ll call the new model “NewModel” from here on, so make sure to substitute this with the actual name of your model.
+
Add ${CMAKE_SOURCE_DIR}/src/libcadet/model/NewModel.cpp to the src/libcadet/CMakeLists.txt
+
(Optional) In the root/CMakeLists.txt file, you can add a build option to make building your new model optional. This enables building CADET versions with and without the new extension. This can be done, e.g., when additional dependencies are required or when build time should be reduced. See e.g. ENABLE_GRM_2D or ENABLE_DG.
+
Add new model to ModelBuilder (in ModelBuilderImpl.cpp, just like the other models are included):
+
Rename everything to the new model
+a. Change the identifier() function in the NewModel.hpp to return a new unique model name (here: “NewModel”)
+b. Adjust the registerNewModel() function in the NewModel.cpp accordingly
+c. rename all functions, i.e. substitute the previous (copied) model name by your model name. Also do this for the header guards in the hpp file and the include in the cpp (essentially every occurrence of the old model name has to be changed).
+
Try to build (and maybe even run) the new unit operation, which at this point is essentially still the same as the copied one, to make sure everything is set up correctly.
+
+
You are now ready to implement your model in CADET-Core.
+Note that you will probably have to clean up a lot of things from the copied unit operation and that you also need to change the documentation comments to match your model and implementation.
+
Most important functionality to be implemented:
+
+
configure(): Model configuration parameters are read from the .h5 file and exceptions are thrown if parameters are missing or have the wrong size or format. Furthermore, if required, implicitly given parameters are determined and memory is allocated.
+
configureModelDiscretization(): Similar to the function above but treats the numerical discretization part.
+
residualImpl(): Implements the residual formulation (i.e. function \(F = 0\)) of the equations. Triggers updates of the (possibly state dependent) system Jacobian.
+
System Jacobian: Owned by the unit operation. Defined given by \(J := \frac{\partial F}{\partial y} + \alpha \frac{\partial F}{\partial \dot{y}}\), i.e. both the state and state derivative Jacobian need to be implemented.
+
Linear solve: Solves the system \(J x = b\) with given \(b\).
+
Algorithmic differentiation (AD):
+a. Parameter sensitivities: Use ParamType for all parameters and ResidualType for the residual.
+b. Jacobian calculation via AD (can be used to verify the analytical implementation): Use StateType for the state and ResidualType for the residual. Additionally, you need to implement the following functions to enable the AD Jacobian: requiredADdirs(), prepareADvectors, extractJacobianFromAD(), useAnalyticJacobian(). For details please refer to P?ttmann et al..
Many extensions of CADET-Core result in both software and paper publications.
+Over the years we have established standard procedures to ensure good quality of the publication, including research data management and reproducability of the results.
+An important part of the publication procedure on the software side is the implementation of tests:
+Every model or method extension of CADET-Core has to be tested adequatly before it can be merged into the master branch.
+Even if your extension is not planned to become a contribution to the master branch, rigorous testing should still be implemented as it is essential to ensure confidence in your code.
+Please refer to the CADET-Core testing section for more technical information on the implementation of tests in CADET-Core.
+
We highly recommend reading the reference tests subsection within the CADET-Core testing section before writing the paper, as the testing procedure that we describe strongly overlaps with the model/method validation part, which should be part of the publication.
AD in CADET-Core can be used to compute parameter sensitivities and/or the Jacobian of the system.
+The custom AD implementation introduces an active type (see AutoDiff.hpp), which is treated as a scalar but holds multiple double values.
+The first active entry holds the actual double value of the variable.
+The latter active entries hold the derivatives of that variable w.r.t different directions.
+Directions can either be the parameter(s) whose sensitivity we want to calculate or, if we compute the Jacobian via AD, an entry of the discrete state vector.
+
To use AD for a new binding model, you only need to use the template types properly:
+Use ParamType and ResidualType for parameters and residual res to enable parameter sensitivities; that is, all parameters must be defined as actives in the binding model and used as ParamType in the residual function.
+Use StateType and ResidualType for the state y and residual res to enable the AD Jacobian.
+
To use AD for a new unit operation, you can either apply dense AD or, in case of a model with many states or spatial resolution, you need to think of the shape of the Jacobian and apply sparse AD.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/developer_guide/release_new_version.html b/v5.0.1/developer_guide/release_new_version.html
new file mode 100644
index 000000000..376358eec
--- /dev/null
+++ b/v5.0.1/developer_guide/release_new_version.html
@@ -0,0 +1,192 @@
+
+
+
+
+
+
+
+ CADET-Core version release — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The release tests contain extensive testing that is not included in our CI, such as EOC tests.
+Running these tests might take a while and this should be done on the server.
+
Some tests are implemented in CADET-Core, and can be run with the [ReleaseCI] flag.
+
More tests are implemented in Python, the code can be found in CADET-Verification
+
+
Compare the results with the previous run.
+The release process can only be continued if the results are reasonable.
+
+
Run performance benchmarks:
+
+
If numerical algorithms were refactored or if performance-critical infrastructure was changed, you should run performance benchmarks to compare the latest release with the planned new one.
+To this end, you can refer to the performance benchmark templates in CADET-Reference, e.g. the benchmark for the modified Newton method
+
+
+
Create a version bump commit, which will be the target commit for the release.
+The bump commit contains:
+
+
Update of the version number in the version.txt and in the zenodo.json
+
Update of the authors list if needed: CONTRIBUTING.md and zenodo.json
Add the version number according to the semantic versioning system as the tag and set the master branch as target.
+
Add release notes with these categories:
+
+
Added: New features, enhancements, or functionalities introduced in this release.
+
Fixed: Bug fixes and corrections made to resolve issues from previous versions.
+
Changed: Modifications to existing features and breaking changes for major releases including changes in the interface.
+
Updated: Improvements to documentation, minor tweaks, or other updates that don’t fit into the other categories.
+
+
+
Attach the (zipped) source code.
+
+
+
Check success of zenodo archiving:
+
+
Upon release, Zenodo automatically archives the release, generating a version-specific DOI (Digital Object Identifier) for it and storing a copy of the source code, along with any associated files.
+The concept DOI, which is also given in the repository README, does not change but represents the repository as a whole and always points to the latest version.
To ensure CADET-Core is accessible to a broad community, it is available as a Python package on conda-forge.
+Other software, such as our Python interface, CADET-Python, and the frontend, CADET-Process, import this package.
After building, you can find the testRunner.exe in CADET-root/build/test/Release or, when build in debug mode, in CADET-root/build/test/Debug.
+
To debug specific tests (with flag [testHere]) from the Visual Studio IDE, you can add the following configuration to the launch.vs.json file mentioned in the CADET-Core debugging section:
+
Select the testRunner.exe in the startup item dropdown menu and you can start debugging tests with the specified flag.
Every model and numerical method implemented in CADET-Core has to be tested adequatly.
+Here, we distinguish between unit tests and numerical reference tests.
Unit tests are designed to verify the correctness of individual units or components of code in isolation.
+Unit tests in CADET-Core typically encompass tests for the Jacobian implementation and consistent initialization of the model, which can be adapted from corresponding existing tests.
+Testing the Jacobian typically involves comparing the analytical Jacobian to the AD Jacobian to verify that the residual implementation is consistent to the analytical Jacobian.
+To this end, it might be necessary to increase the maximum number of AD directions for your test case, which can be done via the cmake argument NUM_MAX_AD_DIRS, as described in the CADET build options.
Every major feature of the model or numerical method should be tested in a separate test case, preferably recreating examples from literature, including your own publication on the corresponding CADET extension.
+This section provides a guide on creating reference tests, including convergence tables and research data management (RDM).
+We strongly emphasize that the procedure described here should be taken into consideration not just as part of the software testing but also for method/model validation, especially when a paper publication is planned.
We recommend using this procedure not only for the tests but also for the publication to make good standards regarding RDM.
+
The general procedure how to add a reference test is as follows:
+
1. Define your model setup in CADET-Database:
+The easiest way to do this, is to clone the CADET-Database, checkout the core_tests branch and store your model setup file as a json file in the cadet-config folder.
+You can create this json config file by translating the standard CADET h5 file to a json using python, see the utility/h5ToJson.py script for reference.
+Make sure to give your model setup a meaningful and unique name (follow the naming logic of other setups in that folder).
+Note that the return data should only specify the output required for the reference test, i.e. usually the outlet of a single unit.
+
2. Add a CADET-Verification script:
+This python script reads the model setup from CADET-Database and generates all the reference data that will be used in your tests.
+This includes a specific low resolution reference solution as well as convergence (EOC) tables computed using a high precision solution.
+If analytical solutions are available for the considered model, you should use that as the high precision solution.
+Otherwise, you additionally need to generate a very high resolution numerical reference solution, preferably with an accuracy of at least \(\mathcal{L}_\text{inf} \approx 1e-8\).
+
3. Add numerical reference tests to CADET-Core:
+These tests should read the model setups previously defined in CADET-Database and run them with the same numerical specification as used to compute the reference solutions computed by the CADET-Verification script.
+The resulta are compared to the reference solution generated by CADET-Verification.
+This type of tests ensures that the model is still functional and that the numerics for this model have not changed.
+Hence, every major feature of the model should be tested in a separete tests.
+This way, we make sure that ongoing CADET-Core development doesnt break the model and these tests should be included in the CI pipeline by adding the [CI] flag as described in the implementation procedure section.
+
4. Add EOC tests to CADET-Core (optional):
+These tests should be part of the paper publication which introduces the new model implemented in CADET-Core and can also be included in the CADET-Core tests.
+Verifying the experimental order of convergence (EOC) is widely considered the most rigorous and best scientific practice in model and method validation, which is why we recommend including the EOC tables in your publication.
+The convergence tests should not be added to the standard CI but only be rerun on release, i.e. by adding the [releaseCI] flag.
+Details on how to compute EOC tables can be found elsewhere, please also refer to the already implemented EOC tests in CADET-Verification.
If no analytical solution is available for your model, you can use a so-called “manufactured solution” to verify your implementation.
+A manufactured solution was implemented e.g. for the radial flow model, see test/testRadialKernel.cpp.
Create a new test file test\NewModelMethod.cpp, an easy way to begin with is to copy one of the files that implements tests which are the closest to the ones that you are planning on, e.g. LumpedRateModelWithPores to test a new unit operation.
+Add your tests to the testrunner executable by adding NewModelMethod.cpp to the list in the command add_executable(testrunner within the test\CmakeList.txt file.
+Note that every test needs an unique name, which is specified for each test by TEST_CASE("Myfirsttest","[FLAG1],[FLAG2]").
+Flags are used as options for the testrunner.exe and are specified within square brackets.
+Reuse existing flags and add new ones for your extension.
+The [CI] flag is used for tests that shall be rerun as part of our github continuous integration (CI) pipeline.
Some changes will break the tests without them being necessarily wrong. A change in the numerics for instance, will most likely break some tests.
+This can be fixed by carefully adapting the absolute and relative tolerances for the broken tests. These changes should not change the magnitude of the tolerances, except if this is within an acceptable and expected new tolerance).
Note that the version numbers of the files and packages below are subject to change and will not always reflect the most recent version.
+
Also note that you have to use the same compiler for all packages. This is especially important if some of the packages are installed via a package manager such as Homebrew which uses the system compiler (Clang).
You can either use the native LAPACK implementation provided by Mac OS X (vecLib, Accelerate)
+or install the freely available Intel MKL which is very fast and probably faster than Accelerate.
Microsoft Visual Studio 2022 (Community Edition, or better)
+
Intel OneAPI MKL
+
Optional: Git
+
Optional but not generally recommended*: Intel OneAPI TBB
+
+
*For most use-cases it is more efficient to parallelize by running multiple CADET simulations instead
+of parallelizing within one CADET simulation. Including the parallelization code in CADET can lead to performance
+losses, even if parallelization within CADET is not used.
+Therefore, we recommend not including the parallelization library TBB
+unless you know your simulations are large enough to benefit from it.
Navigate to the install location cdCADET\out\install\aRELEASE\bin
+
Run:
+
+
cadet-cli.exe--version
+
createLWE.exe
+
cadet-cli.exeLWE.h5
+
+
+
And confirm the output of the LWE.h5 by opening it in HDF5view or loading it in CADET-Process.
+
If you get no printed return from the first command, run cadet-cli.exe by double-clicking it in the file explorer.
+This raises error messages that are not raised from a cmd or PowerShell window.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/getting_started/index.html b/v5.0.1/getting_started/index.html
new file mode 100644
index 000000000..9447bc047
--- /dev/null
+++ b/v5.0.1/getting_started/index.html
@@ -0,0 +1,138 @@
+
+
+
+
+
+
+
+ Getting started — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
This section details the steps to install CADET, as pre-built binaries or building from scratch, and also provides the series of tutorials that will help in building complete model from scratch in CADET.
The core simulator can be compiled from source, or you can download pre-built binaries.
+If you want to extend or modify CADET (e.g., add a custom binding model), you will need to build CADET from source.
CADET provides a Python API, called CADET-Python, which can be used to set the model input according to the Interface specifications section.
+Setting up the model using CADET-Python can become very tedious, especially for systems, and is outdated now that an actual frontend is available:
+
We recommend using the CADET-Process frontend, which facilitates modeling processes using an object oriented model builder.
+This interface layer provides convenient access to all model parameters in the system.
+It automatically checks validity of the parameter values and sets reasonable default values where possible.
Performing a forward simulation comprises several steps:
+
Setting up the model including all parameters
+
Defining connectivity and dynamic events
+
Setting up the simulator and actually running the simulation
+
Evaluating results (e.g., plotting)
+
+
+
+
In this tutorial, we will build a simple forward simulation with a breakthrough of one component using the following system:
+
+
+
+
For this purpose, we use CADET-Process, an object oriented Python frontend for CADET.
+CADET still must be downloaded (or built from source) as explained in the installation guide.
+
+
+
+
Fig. 1 Relations between CADET-Core, CADET-Python, and CADET-Process.¶
+
+
+
For more information on how to set up models using CADET-Python, a plain file based API for CADET, please refer to the CADET-Python Introduction.
We first create a ComponentSystem.
+The ComponentSystem ensures that all parts of the process have the same number of components.
+Moreover, components can be named which automatically adds legends to the plot methods.
In CADET, the Inlet pseudo unit operation serves as a source for the system and is used to create arbitary concentration profiles as boundary conditions.
+The concentration profile is described using a piecewise cubic polynomial (cubic spline in the continuous case) for each component, where the pieces are given by the time sections.
+In this example we set a constant inlet concentration of 1 mM.
Every unit operation model can be equipped with an adsorption model.
+The available models are listed in the binding model chapter.
+
For the Langmuir model, we use the Langmuir class.
+Then, we decide if we want to use the rapid-equilibrium assumption in the binding model (binding_model.is_kinetic=False), which is not the case here (dynamic binding).
+Finally, the parameters of the binding model have to be set for each component (they are vectors of length n_components).
+All model parameters can be listed using the parameters attribute.
+In case of the Langmuir model, we have to specify the parameters adsorption_rate, desorption_rate, and capacity.
We now add a second unit operation, the column model.
+For the general rate model model, we use the GeneralRateModel class.
+In this class, we set the parameters related to transport and column geometry.
+
fromCADETProcess.processModelimportGeneralRateModel
+
+column=GeneralRateModel(component_system,name='column')
+column.binding_model=binding_model
+
+column.length=0.014# m
+column.diameter=0.02# m
+column.bed_porosity=0.37# -
+column.particle_porosity=0.75# -
+column.particle_radius=4.5e-5# m
+
+column.axial_dispersion=5.75e-8# m^2 / s (interstitial volume)
+column.film_diffusion=[6.9e-6]# m / s
+column.pore_diffusion=[7e-10,]# m^2 / s (mobile phase)
+column.surface_diffusion=[0.0]# m^2 / s (solid phase)
+
+
+
Note that film, pore, and surface diffusion are all component-specific, that is, they are vectors of length n_components.
Next, we specify the initial conditions (concentration of the components in the mobile and stationary phases) for the column.
+These concentrations are entered as vectors, where each entry gives the concentration for the corresponding component.
+In this example, we start with an empty column.
+
column.c=[0]
+column.cp=[0]
+column.q=[0]
+
+
+
+
The OUTLET is another pseudo unit operation that serves as sink for the system.
+
+
Note
+
In this case, the outlet unit is actually not required. We could use the outlet concentration signal of the column model instead.
The connectivity of unit operations is defined in the FlowSheet class.
+This class provides a directed graph structure that allows for the simple definition of configurations for multiple columns or reactor-separator networks, even when they are cyclic.
+We add the previously defined units to the flow sheet and add connections between them.
Since the flow in the column models is incompressible, the total entering flow rate must equal the total outgoing flow rate.
+This restriction does not apply to a CSTR model, because it has a variable volume.
The Process class is used to define dynamic changes of model parameters or flow sheet connections.
+This includes the duration of a simulation (cycle_time).
+To instantiate a Process, a FlowSheet needs to be passed as argument, as well as a string to name that process.
3. Setting Up the Simulator and Running the Simulation¶
+
To simulate a Process, a simulator needs to be configured.
+The simulator translates the Process configuration into the API of the corresponding simulator.
CADET is developed at the Institute of Bio- and Geosciences 1 (IBG-1) of Forschungszentrum Jülich (FZJ) under supervision of Dr. Eric von Lieres.
+The heart of the CADET software is a fast and accurate solver for a comprehensive model family.
+Typical applications include (but are by far not limited to) chromatography, filtration, crystallization, and fermentation.
+CADET can handle arbitrary sequences and networks of unit operations, including reactors, tanks, tubes, pumps, valves, detectors, etc.
+The resulting models are solved with state-of-the-art mathematical algorithms and scientific computing techniques.
We do our best to provide you with a stable API.
+However, CADET is actively developed and breaking changes can sometimes be unavoidable.
+For non-developers, it is recommended to upgrade from release to release instead of always working with the most recent commit.
The development of CADET has been a collaborative effort, with multiple dedicated individuals contributing their expertise to create a powerful and versatile open-source software tool.
+Countless hours of hard work have been invested to provide the scientific community with a valuable resource.
+As an open-source project, CADET relies on the support and recognition from users and researchers to thrive.
+Therefore, we kindly ask that any publications or projects leveraging the capabilities of CADET acknowledge its creators and their contributions by citing an adequate selection of our publications.
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
BISMA_KA
Adsorption rate constants in state-major ordering
+
+
+
Unit:\(m_{MP}^{3}~m_{SP}^{-3}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NSTATES \(\cdot\) NCOMP
+
+
+
+
+
BISMA_KD
Desorption rate constants in state-major ordering
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NSTATES \(\cdot\) NCOMP
+
+
+
+
+
BISMA_NU
Characteristic charges \(\nu_{i,j}\) of the \(i\)th protein
+with respect to the \(j\)th binding site type in state-major
+ordering
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NSTATES \(\cdot\) NCOMP
+
+
+
+
+
BISMA_SIGMA
Steric factors \(\sigma_{i,j}\) of the \(i\)th protein with
+respect to the \(j\)th binding site type in state-major
+ordering
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NSTATES \(\cdot\) NCOMP
+
+
+
+
+
BISMA_LAMBDA
Stationary phase capacity (monovalent salt counterions) of the
+different binding site types \(\lambda_j\)
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NSTATES
+
+
+
+
+
BISMA_REFC0
Reference liquid phase concentration for each binding site type or
+one value for all types (optional, defaults to \(1.0\))
+
+
+
Unit:\(mol~m_{MP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: {1,NSTATES}
+
+
+
+
+
BISMA_REFQ
Reference solid phase concentration for each binding site type or one
+value for all types (optional, defaults to \(1.0\))
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: {1,NSTATES}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/extended_mobile_phase_modulator_langmuir.html b/v5.0.1/interface/binding/extended_mobile_phase_modulator_langmuir.html
new file mode 100644
index 000000000..3052a043c
--- /dev/null
+++ b/v5.0.1/interface/binding/extended_mobile_phase_modulator_langmuir.html
@@ -0,0 +1,243 @@
+
+
+
+
+
+
+
+ Extended Mobile Phase Modulator Langmuir — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
EMPM_COMP_MODE
Determines the mode of each component (\(0\) denotes the modifier
+component, \(1\) is linear binding, \(2\) is modified Langmuir
+binding). At most one modifier component is allowed, that is, a
+modifier is not required.
+
Note that this field has the same name for the externally dependent
+variant of the model.
+
+
+
+
+
Type: int
+
Range:\(\{0,1,2\}\)
+
Length: NCOMP
+
+
+
+
+
EMPM_KA
Adsorption rate constants
+
+
+
Unit:\(m_{MP}^3~mol^{-1}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
EMPM_KD
Desorption rate constants
+
+
+
Unit:\(m_{MP}^{3\beta}~mol^{-\beta}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
EMPM_QMAX
Maximum adsorption capacities
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
EMPM_BETA
Parameters describing the ion-exchange characteristics (IEX)
Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = FREUNDLICH_LDF
+
For information on model equations, refer to Freundlich LDF.
+
+
IS_KINETIC
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
FLDF_KKIN
Driving force coefficient for each component
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1/NTOTALBND
+
+
+
+
+
FLDF_KF
Freundlich coefficient for each component
+
+
+
Unit:\(m_{MP}^{3/n}~m_{SP}^{-3}~mol^{1-1/n}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1/NTOTALBND
+
+
+
+
+
FLDF_N
Freundlich exponent for each component
+
+
+
Unit: [-]
+
+
+
Type: double
+
Range:\(> 0\)
+
Length: 1/NTOTALBND
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/generalized_ion_exchange.html b/v5.0.1/interface/binding/generalized_ion_exchange.html
new file mode 100644
index 000000000..75ca38c3a
--- /dev/null
+++ b/v5.0.1/interface/binding/generalized_ion_exchange.html
@@ -0,0 +1,384 @@
+
+
+
+
+
+
+
+ Generalized Ion Exchange — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
GIEX_KA
Base value of adsorption rate constant
+
+
+
Unit:\(m_{MP}^{3}~m_{SP}^{-3}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
GIEX_KA_LIN
Coefficient of linear dependence of adsorption rate constant on
+modifier component
+
+
+
Unit:\(\text{[Mod]}^{-1}\)
+
+
+
Type: double
+
Length: NCOMP
+
+
+
+
+
GIEX_KA_QUAD
Coefficient of quadratic dependence of adsorption rate constant on
+modifier component
+
+
+
Unit:\(\text{[Mod]}^{-2}\)
+
+
+
Type: double
+
Length: NCOMP
+
+
+
+
+
GIEX_KA_SALT
Salt coefficient of adsorption rate constants; difference of
+water-protein and salt-protein interactions
+
+
+
+
+
Type: double
+
Length: NCOMP
+
+
+
+
+
GIEX_KA_PROT
Protein coefficient of adsorption rate constants; difference of
+water-protein and protein-protein interactions
+
+
+
Unit:\(m_{MP}^{3} mol^{-1}\)
+
+
+
Type: double
+
Length: NCOMP
+
+
+
+
+
GIEX_KD
Base value of desorption rate constant
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
GIEX_KD_LIN
Coefficient of linear dependence of desorption rate constant on
+modifier component
+
+
+
Unit:\(\text{[Mod]}^{-1}\)
+
+
+
Type: double
+
Length: NCOMP
+
+
+
+
+
GIEX_KD_QUAD
Coefficient of quadratic dependence of desorption rate constant on
+modifier component
+
+
+
Unit:\(\text{[Mod]}^{-2}\)
+
+
+
Type: double
+
Length: NCOMP
+
+
+
+
+
GIEX_KD_SALT
Salt coefficient of desorption rate constants; difference of
+water-protein and salt-protein interactions
+
+
+
+
+
Type: double
+
Length: NCOMP
+
+
+
+
+
GIEX_KD_PROT
Protein coefficient of desorption rate constants; difference of
+water-protein and protein-protein interactions
+
+
+
Unit:\(m_{MP}^{3} mol^{-1}\)
+
+
+
Type: double
+
Length: NCOMP
+
+
+
+
+
GIEX_NU
Base value for characteristic charges of the protein; The number of
+sites \(\nu\) that the protein interacts with on the resin
+surface
+
+
+
+
+
Type: double
+
Length: NCOMP
+
+
+
+
+
GIEX_NU_LIN
Coefficient of linear dependence of characteristic charge on modifier
+component
+
+
+
Unit:\(\text{[Mod]}^{-1}\)
+
+
+
Type: double
+
Length: NCOMP
+
+
+
+
+
GIEX_NU_QUAD
Coefficient of quadratic dependence of characteristic charge on
+modifier component
+
+
+
Unit:\(\text{[Mod]}^{-2}\)
+
+
+
Type: double
+
Length: NCOMP
+
+
+
+
+
GIEX_SIGMA
Steric factors of the protein; The number of sites \(\sigma\) on
+the surface that are shielded by the protein and prevented from
+exchange with the salt counterions in solution
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
GIEX_LAMBDA
Stationary phase capacity (monovalent salt counterions); The total
+number of binding sites available on the resin surface
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1
+
+
+
+
+
GIEX_REFC0
Reference liquid phase concentration (optional, defaults to
+\(1.0\))
+
+
+
Unit:\(mol~m_{MP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: 1
+
+
+
+
+
GIEX_REFQ
Reference solid phase concentration (optional, defaults to
+\(1.0\))
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/hic_constant_water_activity.html b/v5.0.1/interface/binding/hic_constant_water_activity.html
new file mode 100644
index 000000000..bde687f77
--- /dev/null
+++ b/v5.0.1/interface/binding/hic_constant_water_activity.html
@@ -0,0 +1,243 @@
+
+
+
+
+
+
+
+ HIC Constant Water Activity — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
HICCWA_KA
Adsorption rate constant
+
+
+
Unit:\(m_{MP}^{3}~m_{SP}^{-3}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
HICCWA_KD
Desorption rate constant
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
HICCWA_NU
Number of ligands per ligand-protein interaction
+
+
+
Unit: [-]
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
HICCWA_QMAX
Maximum binding capacity
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
HICCWA_BETA0
Parameters describing the number of highly ordered water molecules
+that stabilize the hydrophobic surfaces at infinitely diluted
+salt concentration
+
+
+
Unit: [-]
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1
+
+
+
+
+
HICCWA_BETA1
Parameters describing the change in the number of highly ordered
+water molecules that stabilize the hydrophobic surfaces with
+respect to changes in the salt concentration
+
+
+
Unit:\(m_{MP}^{3}~mol^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/hic_water_on_hydrophobic_surfaces.html b/v5.0.1/interface/binding/hic_water_on_hydrophobic_surfaces.html
new file mode 100644
index 000000000..85bc07031
--- /dev/null
+++ b/v5.0.1/interface/binding/hic_water_on_hydrophobic_surfaces.html
@@ -0,0 +1,243 @@
+
+
+
+
+
+
+
+ HIC Water on Hydrophobic Surfaces — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
HICWHS_KA
Adsorption rate constant
+
+
+
Unit:\(m_{MP}^{3}~m_{SP}^{-3}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
HICWHS_KD
Desorption rate constant
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
HICWHS_NU
Number of ligands per ligand-protein interaction
+
+
+
Unit: [-]
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
HICWHS_QMAX
Maximum binding capacity
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
HICWHS_BETA0
Parameters describing the number of highly ordered water molecules
+that stabilize the hydrophobic surfaces at infinitely diluted
+salt concentration
+
+
+
Unit: [-]
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1
+
+
+
+
+
HICWHS_BETA1
Parameters describing the change in the number of highly ordered
+water molecules that stabilize the hydrophobic surfaces with
+respect to changes in the salt concentration
Some binding models have a variant that can use external sources as specified in /input/model/external/ (also see Section Dependence on external function for more information, and Section Binding model feature matrix on which binding models support this feature).
+For the sake of brevity, only the standard variant of those binding models is specified below.
+In order to obtain the format for the externally dependent variant, first replace the binding model name XXX by EXT_XXX.
+Each parameter \(p\) (except for reference concentrations XXX_REFC0 and XXX_REFQ) depends on a (possibly distinct) external source in a polynomial way:
+
+\[\begin{aligned}
+ p(T) &= p_{\texttt{TTT}} T^3 + p_{\texttt{TT}} T^2 + p_{\texttt{T}} T + p.
+\end{aligned}\]
+
Thus, a parameter XXX_YYY of the standard binding model variant is replaced by the four parameters EXT_XXX_YYY, EXT_XXX_YYY_T, EXT_XXX_YYY_TT, and EXT_XXX_YYY_TTT.
+Since each parameter can depend on a different external source, the dataset EXTFUN (not listed in the standard variants below) should contain a vector of 0-based integer indices of the external source of each parameter.
+The ordering of the parameters in EXTFUN is given by the ordering in the standard variant.
+However, if only one index is passed in EXTFUN, this external source is used for all parameters.
+
Note that parameter sensitivities with respect to column radius, column length, particle core radius, and particle radius may be wrong when using externally dependent binding models.
+This is caused by not taking into account the derivative of the external profile with respect to column position.
For binding models that do not support multiple bound states, many parameters can vary per component and their length is taken as NCOMP.
+However, these models still support non-binding components.
+In this case, the entries in their parameters that correspond to non-binding components are simply ignored.
The group that contains the parameters of a binding model in unit operation with index XXX reads /input/model/unit_XXX/adsorption.
+This is valid for models with a single particle type.
+If a model has multiple particle types, it may have a different binding model in each type.
+The parameters are then placed in the group /input/model/unit_XXX/adsorption_YYY instead, where YYY denotes the index of the particle type.
+
Note that, in any case, /input/model/unit_XXX/adsorption_000 contains the parameters of the first (and possibly sole) particle type.
+This group also takes precedence over a possibly existing /input/model/unit_XXX/adsorption group.
Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = LINEAR
+
For information on model equations, refer to Linear.
+
+
IS_KINETIC
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
LIN_KA
Adsorption rate constants for each component
+
+
+
Unit:\(m_{MP}^3~m_{SP}^{-3}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1/NTOTALBND
+
+
+
+
+
LIN_KD
Desorption rate constants for each component
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1/NTOTALBND
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/mobile_phase_modulator_langmuir.html b/v5.0.1/interface/binding/mobile_phase_modulator_langmuir.html
new file mode 100644
index 000000000..133786ed1
--- /dev/null
+++ b/v5.0.1/interface/binding/mobile_phase_modulator_langmuir.html
@@ -0,0 +1,226 @@
+
+
+
+
+
+
+
+ Mobile Phase Modulator Langmuir — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
MPM_KA
Adsorption rate constants
+
+
+
Unit:\(m_{MP}^3~mol^{-1}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
MPM_KD
Desorption rate constants
+
+
+
Unit:\(m_{MP}^{3\beta}~mol^{-\beta}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
MPM_QMAX
Maximum adsorption capacities
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
MPM_BETA
Parameters describing the ion-exchange characteristics (IEX)
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
MPM_GAMMA
Parameters describing the hydrophobicity (HIC)
+
+
+
Unit:\(m_{MP}^{3} mol^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/multi_component_anti_langmuir.html b/v5.0.1/interface/binding/multi_component_anti_langmuir.html
new file mode 100644
index 000000000..c60565570
--- /dev/null
+++ b/v5.0.1/interface/binding/multi_component_anti_langmuir.html
@@ -0,0 +1,213 @@
+
+
+
+
+
+
+
+ Multi Component Anti-Langmuir — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
MCAL_KA
Adsorption rate constants
+
+
+
Unit:\(m_{MP}^3~mol^{-1}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
MCAL_KD
Desorption rate constants
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
MCAL_QMAX
Maximum adsorption capacities
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: NCOMP
+
+
+
+
+
MCAL_ANTILANGMUIR
Anti-Langmuir coefficients (optional)
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range: {-1,1}
+
Length: NCOMP
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/multi_component_bi_langmuir.html b/v5.0.1/interface/binding/multi_component_bi_langmuir.html
new file mode 100644
index 000000000..6b233f88b
--- /dev/null
+++ b/v5.0.1/interface/binding/multi_component_bi_langmuir.html
@@ -0,0 +1,200 @@
+
+
+
+
+
+
+
+ Multi Component Bi-Langmuir — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = MULTI_COMPONENT_COLLOIDAL
+
+
IS_KINETIC
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
COL_PHI
Phase ratio \(\Phi\)
+
+
+
Unit:\(m^{2} m_{s}^{-3}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1
+
+
+
+
+
COL_KAPPA_EXP
Screening term exponent factor \(\kappa_{ef}\)
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1
+
+
+
+
+
COL_KAPPA_FACT
Screening term factor \(\kappa_{f}\)
+
+
+
Unit:\(m \cdot mM^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1
+
+
+
+
+
COL_KAPPA_CONST
Screening term constant \(\kappa_{c}\)
+
+
+
Unit:\(m\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1
+
+
+
+
+
COL_CORDNUM
Coordination number \(n\)
+
+
+
+
+
Type: int
+
Range:\(\ge 0\)
+
Length: 1
+
+
+
+
+
COL_LOGKEQ_PH_EXP
Protein-resin interaction \(K_{e,i}\) equilibrium: Constant exponent \(k_{e,i}\) for pH
+If pH is not considered, this value will be not be used but must still be specified, i.e. can be any number.
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
COL_LOGKEQ_SALT_POWEXP
Protein-resin interaction \(K_{e,i}\) equilibrium: Constant pre-factor \(k_{a,i}\) for salt power
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
COL_LOGKEQ_SALT_POWFAC
Protein-resin interaction \(K_{e,i}\) equilibrium: Constant exponent \(k_{b,i}\) for salt power
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
COL_LOGKEQ_SALT_EXPFAC
Protein-resin interaction \(K_{e,i}\) equilibrium: Constant pre-factor \(k_{c,i}\) for e-function with salt power
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
COL_LOGKEQ_SALT_EXPARGMULT
Protein-resin interaction \(K_{e,i}\) equilibrium: Constant power factor \(k_{d,i}\) for salt in e-function
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
COL_BPP_PH_EXP
Protein-protein interaction \(b_{pp,i}\): Constant power term \(b_{e,i}\) for pH.
+If pH is not considered, this value will be not be used but must still be specified, i.e. can be any number.
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
COL_BPP_SALT_POWFACT
Protein-protein interaction \(b_{pp,i}\): Constant power pre-factor \(b_{a,i}\) for salt
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
COL_BPP_SALT_POWEX
Protein-protein interaction \(b_{pp,i}\): Constant power \(b_{b,i}\) for salt
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
COL_BPP_SALT_EXPFACT
Protein-protein interaction \(b_{pp,i}\): Constant pre-factor \(b_{c,i}\) e-function with salt power
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
COL_BPP_SALT_EXPARGMULT
Protein-protein interaction \(b_{pp,i}\): Constant power factor \(b_{d,i}\) for salt in e-function
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
COL_PROTEIN_RADIUS
Protein radius \(r_i\)
+
+
+
Unit:\(m\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
COL_KKIN
Adsorption rate constants \(K_\text{kin}\) in state-major ordering
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
COL_LINEAR_THRESHOLD
Threshold concentration \(c_\epsilon\) for switching to linear approximation
+
+
+
+
COL_USE_PH
Selects if pH is included in the model or not: 1 = yes, 0 = no.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/multi_component_langmuir.html b/v5.0.1/interface/binding/multi_component_langmuir.html
new file mode 100644
index 000000000..fb93acc8c
--- /dev/null
+++ b/v5.0.1/interface/binding/multi_component_langmuir.html
@@ -0,0 +1,200 @@
+
+
+
+
+
+
+
+ Multi Component Langmuir — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
MCL_KA
Adsorption rate constants
+
+
+
Unit:\(m_{MP}^3~mol^{-1}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
MCL_KD
Desorption rate constants
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
MCL_QMAX
Maximum adsorption capacities
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: NCOMP
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/multi_component_langmuir_ldf.html b/v5.0.1/interface/binding/multi_component_langmuir_ldf.html
new file mode 100644
index 000000000..af3ce9036
--- /dev/null
+++ b/v5.0.1/interface/binding/multi_component_langmuir_ldf.html
@@ -0,0 +1,200 @@
+
+
+
+
+
+
+
+ Multi Component Langmuir LDF — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
MCLLDF_KEQ
Equillibrium loading constants
+
+
+
Unit:\(m_{MP}^3~mol^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
MCLLDF_KKIN
Linear driving force coefficients
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
MCLLDF_QMAX
Maximum adsorption capacities
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: NCOMP
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/multi_component_langmuir_ldf_liquid_phase.html b/v5.0.1/interface/binding/multi_component_langmuir_ldf_liquid_phase.html
new file mode 100644
index 000000000..c25cbd7db
--- /dev/null
+++ b/v5.0.1/interface/binding/multi_component_langmuir_ldf_liquid_phase.html
@@ -0,0 +1,200 @@
+
+
+
+
+
+
+
+ Multi Component Langmuir LDF Liquid Phase — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
MCLLDFC_KEQ
Equillibrium loading constants
+
+
+
Unit:\(m_{MP}^3~mol^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
MCLLDFC_KKIN
Linear driving force coefficients
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
MCLLDFC_QMAX
Maximum adsorption capacities
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: NCOMP
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/multi_component_spreading.html b/v5.0.1/interface/binding/multi_component_spreading.html
new file mode 100644
index 000000000..522c65a77
--- /dev/null
+++ b/v5.0.1/interface/binding/multi_component_spreading.html
@@ -0,0 +1,226 @@
+
+
+
+
+
+
+
+ Multi Component Spreading — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
MCSPR_KA
Adsorption rate constants in state-major ordering
+
+
+
Unit:\(m_{MP}^3~mol^{-1}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
MCSPR_KD
Desorption rate constants in state-major ordering
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
MCSPR_QMAX
Maximum adsorption capacities in state-major ordering
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: NTOTALBND
+
+
+
+
+
MCSPR_K12
Exchange rates from the first to the second bound state
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
MCSPR_K21
Exchange rates from the second to the first bound state
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/multi_state_steric_mass_action.html b/v5.0.1/interface/binding/multi_state_steric_mass_action.html
new file mode 100644
index 000000000..3e226c6f5
--- /dev/null
+++ b/v5.0.1/interface/binding/multi_state_steric_mass_action.html
@@ -0,0 +1,271 @@
+
+
+
+
+
+
+
+ Multi-State Steric Mass Action — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
MSSMA_KA
Adsorption rate constants of the components to the different bound
+states in component-major ordering
+
+
+
Unit:\(m_{MP}^3~m_{SP}^{-3}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
MSSMA_KD
Desorption rate constants of the components in the different bound
+states in component-major ordering
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
MSSMA_NU
Characteristic charges of the components in the different bound
+states in component-major ordering
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
MSSMA_SIGMA
Steric factors of the components in the different bound states in
+component-major ordering
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
MSSMA_RATES
Conversion rates between different bound states in
+component-row-major ordering
Group /input/model/unit_XXX/adsorption – ADSORPTION_MODEL = SASKA
+
For information on model equations, refer to Saska.
+
+
IS_KINETIC
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
SASKA_H
Henry coefficient
+
+
+
Unit:\(m_{MP}^3~m_{SP}^{-3}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\mathbb {R}\)
+
Length: NCOMP
+
+
+
+
+
SASKA_K
Quadratic factors
+
+
+
Unit:\(m_{MP}^6~m_{SP}^{-3}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\mathbb {R}\)
+
Length:\(\text{NCOMP}^2\)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/self_association.html b/v5.0.1/interface/binding/self_association.html
new file mode 100644
index 000000000..87ac9dfae
--- /dev/null
+++ b/v5.0.1/interface/binding/self_association.html
@@ -0,0 +1,266 @@
+
+
+
+
+
+
+
+ Self Association — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
SAI_KA1
Adsorption rate constants
+
+
+
Unit:\(m_{MP}^3~m_{SP}^{-3}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SAI_KA2
Adsorption rate constants
+
+
+
Unit:\(m_{MP}^6~m_{SP}^{-3}~mol^{-1}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SAI_KD
Desorption rate constants
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SAI_NU
Characteristic charges \(\nu\) of the protein
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SAI_SIGMA
Steric factors \(\sigma\) of the protein
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SAI_LAMBDA
Stationary phase capacity (monovalent salt counterions); The total
+number of binding sites available on the resin surface
+
+
+
Unit:\(mol m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1
+
+
+
+
+
SAI_REFC0
Reference liquid phase concentration (optional, defaults to
+\(1.0\))
+
+
+
Unit:\(mol m_{MP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: 1
+
+
+
+
+
SAI_REFQ
Reference solid phase concentration (optional, defaults to
+\(1.0\))
+
+
+
Unit:\(mol m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/simplified_multi_state_steric_mass_action.html b/v5.0.1/interface/binding/simplified_multi_state_steric_mass_action.html
new file mode 100644
index 000000000..9ee10a033
--- /dev/null
+++ b/v5.0.1/interface/binding/simplified_multi_state_steric_mass_action.html
@@ -0,0 +1,392 @@
+
+
+
+
+
+
+
+ Simplified Multi-State Steric Mass Action — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
SMSSMA_LAMBDA
Stationary phase capacity (monovalent salt counterions); The total
+number of binding sites available on the resin surface
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1
+
+
+
+
+
SMSSMA_KA
Adsorption rate constants of the components to the different bound
+states in component-major ordering
+
+
+
Unit:\(m_{MP}^{3}~m_{SP}^{-3}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
SMSSMA_KD
Desorption rate constants of the components to the different bound
+states in component-major ordering
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NTOTALBND
+
+
+
+
+
SMSSMA_NU_MIN
Characteristic charges of the components in the first (weakest) bound
+state
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SMSSMA_NU_MAX
Characteristic charges of the components in the last (strongest)
+bound state
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SMSSMA_NU_QUAD
Quadratic modifiers of the characteristic charges of the different
+components depending on the index of the bound state
+
+
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: NCOMP
+
+
+
+
+
SMSSMA_SIGMA_MIN
Steric factors of the components in the first (weakest) bound state
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SMSSMA_SIGMA_MAX
Steric factors of the components in the last (strongest) bound state
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SMSSMA_SIGMA_QUAD
Quadratic modifiers of steric factors of the different components
+depending on the index of the bound state
+
+
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: NCOMP
+
+
+
+
+
SMSSMA_KWS
Exchange rates from a weakly bound state to the next stronger bound
+state
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SMSSMA_KWS_LIN
Linear exchange rate coefficients from a weakly bound state to the
+next stronger bound state
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: NCOMP
+
+
+
+
+
SMSSMA_KWS_QUAD
Quadratic exchange rate coefficients from a weakly bound state to the
+next stronger bound state
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: NCOMP
+
+
+
+
+
SMSSMA_KSW
Exchange rates from a strongly bound state to the next weaker bound
+state
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SMSSMA_KSW_LIN
Linear exchange rate coefficients from a strongly bound state to the
+next weaker bound state
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: NCOMP
+
+
+
+
+
SMSSMA_KSW_QUAD
Quadratic exchange rate coefficients from a strongly bound state to
+the next weaker bound state
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: NCOMP
+
+
+
+
+
SMSSMA_REFC0
Reference liquid phase concentration (optional, defaults to
+\(1.0\))
+
+
+
Unit:\(mol~m_{MP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: 1
+
+
+
+
+
SMSSMA_REFQ
Reference solid phase concentration (optional, defaults to
+\(1.0\))
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/binding/steric_mass_action.html b/v5.0.1/interface/binding/steric_mass_action.html
new file mode 100644
index 000000000..6332f61f0
--- /dev/null
+++ b/v5.0.1/interface/binding/steric_mass_action.html
@@ -0,0 +1,256 @@
+
+
+
+
+
+
+
+ Steric Mass Action — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Selects kinetic or quasi-stationary adsorption mode: 1 = kinetic, 0 =
+quasi-stationary. If a single value is given, the mode is set for all
+bound states. Otherwise, the adsorption mode is set for each bound
+state separately.
+
+
+
+
+
Type: int
+
Range: {0,1}
+
Length: 1/NTOTALBND
+
+
+
+
+
SMA_KA
Adsorption rate constants
+
+
+
Unit:\(m_{MP}^3~m_{SP}^{-3}~s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SMA_KD
Desorption rate constants
+
+
+
Unit:\(s^{-1}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SMA_NU
Characteristic charges of the protein; The number of sites
+\(\nu\) that the protein interacts with on the resin surface
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SMA_SIGMA
Steric factors of the protein; The number of sites \(\sigma\) on
+the surface that are shielded by the protein and prevented from
+exchange with the salt counterions in solution
+
+
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: NCOMP
+
+
+
+
+
SMA_LAMBDA
Stationary phase capacity (monovalent salt counterions); The total
+number of binding sites available on the resin surface
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\ge 0\)
+
Length: 1
+
+
+
+
+
SMA_REFC0
Reference liquid phase concentration (optional, defaults to
+\(1.0\))
+
+
+
Unit:\(mol~m_{MP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: 1
+
+
+
+
+
SMA_REFQ
Reference solid phase concentration (optional, defaults to
+\(1.0\))
+
+
+
Unit:\(mol~m_{SP}^{-3}\)
+
+
+
Type: double
+
Range:\(\gt 0\)
+
Length: 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/consistent_initialization.html b/v5.0.1/interface/consistent_initialization.html
new file mode 100644
index 000000000..d5305bca3
--- /dev/null
+++ b/v5.0.1/interface/consistent_initialization.html
@@ -0,0 +1,193 @@
+
+
+
+
+
+
+
+ Nonlinear solver for consistent initialization — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Group /input/model/unit_XXX/discretization/reconstruction = WENO¶
+
BOUNDARY_MODEL
+
+
Boundary model type:
+0. Lower WENO order (stable)
+1. Zero weights (unstable for small \(D_{\mathrm{ax}}\))
+2. Zero weights for \(p \neq 0\) (less stable)
+
+
+
Type: int
+
Range:\(\{0, 1, 2\}\)
+
Length: 1
+
+
+
+
+
WENO_EPS
+
+
WENO \(\varepsilon\)
+
+
+
Type: double
+
Range:\(\mathbb{R}^{>0}\)
+
Length: 1
+
+
+
+
+
WENO_ORDER
+
+
WENO order, also called WENO \(k\):
+
+
Standard upwind scheme (order 1)
+
WENO 2 (order 3)
+
WENO 3 (order 5)
+
+
+
+
Type: int
+
Range:\(\{1, 2, 3\}\)
+
Length: 1
+
+
+
+
+
+
+
Group /input/model/unit_XXX/discretization/reconstruction = KOREN¶
+
The Koren scheme implemented in CADET intrinsically uses a van Leer flux limiter. It can reach a maximum order of 2 depending on the smoothness of the solution. The
+BOUNDARY_MODEL is intrinsically set to 0 (stable).
The CADET framework is designed to work on a file format structured into groups and datasets.
+This concept may be implemented by different file formats.
+At the moment, CADET natively supports HDF5 and XML as file formats.
+The choice is not limited to those two formats but can be extended as needed.
+In this section the general layout and structure of the file format is described.
The global structure (see Fig. 11) is divided into three parts: input, output, and meta.
+Every valid CADET file needs an input group (see Fig. 12) which contains all relevant information for simulating a model.
+It does not need an output (see Fig. 14) or meta (see Fig. 11) group, since those are created when results are written.
+Whereas the output group is solely used as output and holds the results of the simulation, the meta group is used for input and output.
+Details such as file format version and simulator version are read from and written to the meta group.
+
If not explicitly stated otherwise, all datasets are mandatory.
+By convention all group names are lowercase, whereas all dataset names are uppercase.
+Note that this is just a description of the file format and not a detailed explanation of the meaning of the parameters.
+For the latter, please refer to the corresponding sections in the previous chapter.
+
+
+
+
Fig. 11 Structure of the groups in the root group of the file format¶
+
+
+
+
+
+
Fig. 12 High-level structure of the groups in the input part of the file format¶
+
+
+
+
+
+
Fig. 13 Structure of the groups in a column unit operation (/input/model group)¶
+
+
+
+
+
+
Fig. 14 Structure of the groups in the output part of the file format¶
Some model parameters, especially in certain binding models, require multi dimensional data.
+Since CADET only reads one dimensional arrays, the layout of the data has to be specified (i.e., the way how the data is linearized in memory).
+The term “xyz-major” means that the index corresponding to xyz changes the slowest.
+
For instance, suppose a model with \(2\) components and \(3\) bound states has a “state-major” dataset.
+Then, the requested matrix is stored in memory such that all components are listed for each bound state (i.e., the bound state index changes the slowest and the component index the fastest):
Some model parameters (see Table 5) can be assigned different values for each section.
+For example, the velocity a column is operated with could differ in the load, wash, and elution phases.
+Section dependency is recognized by specifying the appropriate number of values for the parameters (see Length column in the following tables).
+If a parameter depends on both the component and the section, the ordering is section-major.
+
For instance, the Length field of the parameter VELOCITY reads \(1 / NSEC\) which means that it is not recognized as section dependent if only \(1\) value (scalar) is passed. However, if NSEC many values (vector) are present, it will be treated as section dependent.
+
Note that all components of component dependent datasets have to be section dependent (e.g., you cannot have a section dependency on component \(2\) only while the other components are not section dependent).
+
+
Table 5 Section dependent datasets in the 1D unit operation models (/input/model/unit_XXXgroup)¶
+
+
+
+
+
+
+
Dataset
+
Component dependent
+
Section dependent
+
+
+
+
COL_DISPERSION
+
✓
+
✓
+
+
FILM_DIFFUSION
+
✓
+
✓
+
+
PAR_DIFFUSION
+
✓
+
✓
+
+
PAR_SURDIFFUSION
+
✓
+
✓
+
+
VELOCITY
+
+
✓
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/meta_group.html b/v5.0.1/interface/meta_group.html
new file mode 100644
index 000000000..949283f38
--- /dev/null
+++ b/v5.0.1/interface/meta_group.html
@@ -0,0 +1,186 @@
+
+
+
+
+
+
+
+ Meta Group — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Full state vector at the last time point of the time integrator if \(\texttt{WRITE_SOLUTION_LAST}\) in \(\texttt{/input/return}\) is enabled
+
Type: double
+
+
LAST_STATE_YDOT
+
+
Full time derivative state vector at the last time point of the time integrator if \(\texttt{WRITE_SOLUTION_LAST}\) in \(\texttt{/input/return}\) is enabled
+
Type: double
+
+
LAST_STATE_SENSY_XXX
+
+
Full state vector of the XXX th sensitivity system at the last time point of the time integrator if \(\texttt{WRITE_SENS_LAST}\) in \(\texttt{/input/return}\) is enabled
+
Type: double
+
+
LAST_STATE_SENSYDOT_XXX
+
+
Full time derivative state vector of the XXX th sensitivity system at the last time point of the time integrator if \(\texttt{WRITE_SENS_LAST}\) in \(\texttt{/input/return}\) is enabled
Mobile phase solution inside the particles as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if just one particle type is defined.
Mobile phase solution inside the particles of type XXX as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if more than one particle type is defined.
Solid phase solution inside the particles as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if just one particle type is defined.
Solid phase solution inside the particles of type XXX as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if more than one particle type is defined.
Tensor of solutions at the unit operation outlet with components as columns in time-port-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are both disabled. If the unit operation only has a single port, the port-dimension is removed if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
Tensor of solutions at the unit operation inlet with components as columns in time-port-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are both disabled. If the unit operation only has a single port, the port-dimension is removed if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
Component XXX of the solution at all outlet ports of the unit operation as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is enabled and \(\texttt{SPLIT_PORTS_DATA}\) is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
Component XXX of the solution at all inlet ports of the unit operation inlet as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is enabled and \(\texttt{SPLIT_PORTS_DATA}\) is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
All components at outlet port XXX of the solution of the unit operation as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is disabled and \(\texttt{SPLIT_PORTS_DATA}\) is enabled.
All components at inlet port XXX of the solution of the unit operation inlet as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is disabled and \(\texttt{SPLIT_PORTS_DATA}\) is enabled.
Component YYY at outlet port XXX of the solution of the unit operation. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are enabled, and the unit operation has multiple outlet ports. If the unit operation only has a single port, the field is created if \(\texttt{SINGLE_AS_MULTI_PORT}\) is enabled.
Component YYY at inlet port XXX of the solution of the unit operation. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are enabled, and the unit operation has multiple inlet ports. If the unit operation only has a single port, the field is created if \(\texttt{SINGLE_AS_MULTI_PORT}\) is enabled.
Mobile phase solution time derivative inside the particles as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if just one particle type is defined.
Mobile phase solution time derivative inside the particles of type XXX as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if more than one particle type is defined.
Solid phase solution time derivative inside the particles as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if just one particle type is defined.
Solid phase solution time derivative inside the particles of type XXX as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if more than one particle type is defined.
Tensor of solution time derivatives at the unit operation outlet with components as columns in time-port-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are both disabled. If the unit operation only has a single port, the port-dimension is removed if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
Tensor of solution time derivatives at the unit operation inlet with components as columns in time-port-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are both disabled. If the unit operation only has a single port, the port-dimension is removed if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
Component XXX of the solution time derivative at all outlet ports of the unit operation as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is enabled and \(\texttt{SPLIT_PORTS_DATA}\) is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
Component XXX of the solution time derivative at all inlet ports of the unit operation inlet as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is enabled and \(\texttt{SPLIT_PORTS_DATA}\) is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
All components at outlet port XXX of the solution time derivative of the unit operation as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is disabled and \(\texttt{SPLIT_PORTS_DATA}\) is enabled.
All components at inlet port XXX of the solution time derivative of the unit operation inlet as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is disabled and \(\texttt{SPLIT_PORTS_DATA}\) is enabled.
Component YYY at outlet port XXX of the solution time derivative of the unit operation. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are enabled, and the unit operation has multiple outlet ports. If the unit operation only has a single port, the field is created if \(\texttt{SINGLE_AS_MULTI_PORT}\) is enabled.
Component YYY at inlet port XXX of the solution time derivative of the unit operation. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are enabled, and the unit operation has multiple inlet ports. If the unit operation only has a single port, the field is created if \(\texttt{SINGLE_AS_MULTI_PORT}\) is enabled.
State vector of this unit at the last time point of the time integrator if \(\texttt{WRITE_SOLUTION_LAST_UNIT}\) in \(\texttt{/input/return/unit_XXX}\) is enabled.
+Note that the vector includes the dedicated inlet DOFs at the beginning (length: \(\texttt{NCOMP} \cdot \texttt{NPORT}\)).
+
Type: double
+
+
LAST_STATE_YDOT
+
+
Time derivative state vector of this unit at the last time point of the time integrator if \(\texttt{WRITE_SOLUTION_LAST_UNIT}\) in \(\texttt{/input/return/unit_XXX}\) is enabled.
+Note that the vector includes the dedicated inlet DOFs at the beginning (length: \(\texttt{NCOMP} \cdot \texttt{NPORT}\)).
Mobile phase sensitivity inside the particles as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if just one particle type is defined.
Mobile phase sensitivity inside the particles of type XXX as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if more than one particle type is defined.
Solid phase sensitivity inside the particles as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if just one particle type is defined.
Solid phase sensitivity inside the particles of type XXX as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if more than one particle type is defined.
Tensor of sensitivities at the unit operation outlet with components as columns in time-port-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are both disabled. If the unit operation only has a single port, the port-dimension is removed if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
Tensor of sensitivities at the unit operation inlet with components as columns in time-port-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are both disabled. If the unit operation only has a single port, the port-dimension is removed if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
Component XXX of the sensitivity at all outlet ports of the unit operation as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is enabled and \(\texttt{SPLIT_PORTS_DATA}\) is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
Component XXX of the sensitivity at all inlet ports of the unit operation inlet as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is enabled and \(\texttt{SPLIT_PORTS_DATA}\) is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
All components at outlet port XXX of the sensitivity of the unit operation as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is disabled and \(\texttt{SPLIT_PORTS_DATA}\) is enabled.
All components at inlet port XXX of the sensitivity of the unit operation inlet as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is disabled and \(\texttt{SPLIT_PORTS_DATA}\) is enabled.
Component YYY at outlet port XXX of the sensitivity of the unit operation. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are enabled, and the unit operation has multiple outlet ports. If the unit operation only has a single port, the field is created if \(\texttt{SINGLE_AS_MULTI_PORT}\) is enabled.
Component YYY at inlet port XXX of the sensitivity of the unit operation. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are enabled, and the unit operation has multiple inlet ports. If the unit operation only has a single port, the field is created if \(\texttt{SINGLE_AS_MULTI_PORT}\) is enabled.
Mobile phase sensitivity time derivative inside the particles as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if just one particle type is defined.
Mobile phase sensitivity time derivative inside the particles of type XXX as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if more than one particle type is defined.
Solid phase sensitivity time derivative inside the particles as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if just one particle type is defined.
Solid phase sensitivity time derivative inside the particles of type XXX as \(n_{\text{Time}} \times \texttt{UNITOPORDERING}\) tensor in row-major storage. Only present if more than one particle type is defined.
Tensor of sensitivity time derivatives at the unit operation outlet with components as columns in time-port-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are both disabled. If the unit operation only has a single port, the port-dimension is removed if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
Tensor of sensitivity time derivatives at the unit operation inlet with components as columns in time-port-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are both disabled. If the unit operation only has a single port, the port-dimension is removed if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
Component XXX of the sensitivity time derivative at all outlet ports of the unit operation as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is enabled and \(\texttt{SPLIT_PORTS_DATA}\) is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
Component XXX of the sensitivity time derivative at all inlet ports of the unit operation inlet as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is enabled and \(\texttt{SPLIT_PORTS_DATA}\) is disabled. If the unit operation only has a single port, a vector (1D array) is returned instead of a matrix if \(\texttt{SINGLE_AS_MULTI_PORT}\) is disabled.
All components at outlet port XXX of the sensitivity time derivative of the unit operation as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is disabled and \(\texttt{SPLIT_PORTS_DATA}\) is enabled.
All components at inlet port XXX of the sensitivity time derivative of the unit operation inlet as matrix in time-major storage. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) is disabled and \(\texttt{SPLIT_PORTS_DATA}\) is enabled.
Component YYY at outlet port XXX of the sensitivity time derivative of the unit operation. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are enabled, and the unit operation has multiple outlet ports. If the unit operation only has a single port, the field is created if \(\texttt{SINGLE_AS_MULTI_PORT}\) is enabled.
Component YYY at inlet port XXX of the sensitivity time derivative of the unit operation. Only present if \(\texttt{SPLIT_COMPONENTS_DATA}\) and \(\texttt{SPLIT_PORTS_DATA}\) are enabled, and the unit operation has multiple inlet ports. If the unit operation only has a single port, the field is created if \(\texttt{SINGLE_AS_MULTI_PORT}\) is enabled.
Some parameters depend on other parameters (parameter-parameter dependency) or the solution variables (parameter-state dependency).
+Parameter dependencies are defined in the unit operation scope.
Parameter dependence of column dispersion on the interstitial velocity. Available for the LRM, LRMP and GRM units (with FV discretization only at the moment)
+
+
+
Type: string
+
Range:\(\texttt{POWER_LAW}\)
+
Length: 1
+
+
+
+
+
FILM_DIFFUSION_DEP
+
+
Parameter dependence of film diffusion on the interstitial velocity. Available for the LRMP unit (with FV discretization only at the moment)
Different types of parameter correlations are can be applied.
+The following correlations can be used for all parameter-parameter dependencies, but we specify the required input fields only for COL_DISPERSION_DEP, for the sake of conciseness.
+
Power Law
+
+\[\begin{aligned}
+ p_{dep} &= p_{dep} \cdot b \ |p_{on}^x|
+\end{aligned}\]
+
Here, \(p_{dep}\) is the dependent parameter and \(p_{on}\) is the parameter it depends on.
+
COL_DISPERSION_DEP_BASE
+
+
Base \(b\) of the power law parameter dependence. Optional, defaults to \(1.0\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: 1
+
+
+
+
+
COL_DISPERSION_DEP_EXPONENT
+
+
Exponent \(x\) of the power law parameter dependence
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: 1
+
+
+
+
+
COL_DISPERSION_DEP_ABS
+
+
Specifies whether or not the absolute value should be computed. Optional, defaults to \(1\)
Parameter dependence of \(\texttt{PAR_SURFDIFFUSION}\) on the particle liquid salt component (i.e. component with index 0). Valid dependencies are:
+
+
\(\texttt{NONE}\) Original parameter is used unmodified.
+
\(\texttt{LIQUID_SALT_EXPONENTIAL}\) Original parameter is modified by exponential law of liquid phase salt concentration.
+
\(\texttt{LIQUID_SALT_POWER}\) Original parameter is modified by power law of liquid phase salt concentration.
+
\(\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}\) Original parameter is modified by colloidal binding affinity based on liquid phase salt concentration.
+
+
Optional: If left out, no parameter dependence is assumed and the original surface diffusion coefficients are used unmodified.
+
+
+
Type: string
+
Length:\(1 / \texttt{NPARTYPE}\)
+
+
+
+
+
PAR_SURFDIFFUSION_EXPFACTOR
+
+
Factor \(\texttt{p1}\) in exponential law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} exp \left(p_{2, i, m} c_{0}^{p} \right)\), where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient.
+Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_EXPONENTIAL}\).
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
PAR_SURFDIFFUSION_EXPFACTOR
+\(D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient and
+\(k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}\).
+Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}\).
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
+
PAR_SURFDIFFUSION_EXPARGMULT
+
+
Factor \(\texttt{p2}\) in exponential law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} exp \left(p_{2, i, m} c_{0}^{p} \right)\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient. Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_EXPONENTIAL}\).
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
+
PAR_SURFDIFFUSION_POWFACTOR
+
+
Factor \(\texttt{p1}\) in power law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} \left( c_{0}^{p} \right)^{p_{2, i, m}}\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient. Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_POWER}\).
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
+
PAR_SURFDIFFUSION_POWEXP
+
+
Fjactor \(\texttt{p2}\) in power law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} p_{1, i, m} \left( c_{0}^{p} \right)^{p_{2, i, m}}\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient. Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_POWER}\).
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
+
PAR_SURFDIFFUSION_LOGKEQFACTOR
+
+
Factor \(\texttt{p1}\) in colloidal affinity law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient and
+\(k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}\).
+Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}\).
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
+
PAR_SURFDIFFUSION_LOGKEQEXP
+
+
Factor \(\texttt{p2}\) in colloidal affinity law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient and
+\(k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}\).
+Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}\).
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
+
PAR_SURFDIFFUSION_LOGKEQCONST
+
+
Factor \(\texttt{p3}\) in colloidal affinity law particle surface diffusion relation
+\(D_{s, i, m} = \tilde{D}_{s, i, m} \left[ p_{4, i, m} \left( k_{i, m} \left( c_{0}^{p} \right) \right)^{p_{5, i, m}} p_{6, i, m} exp \left( p_{7, i, m} k_{i, m} \left( c_{0}^{p} \right) \right) \right]\)
+where \(\tilde{D}_{s, i, m}\) is the original surface diffusion coefficient and
+\(k_{i, m} \left( c_{0}^{p} \right) = p_{1, i, m}\left( c_{0}^{p} \right)^{p_{2, i, m}} + p_{3, i, m}\).
+Only required if \(\texttt{PAR_SURFDIFFUSION_DEP}\) is \(\texttt{LIQUID_SALT_COLLOIDAL_AFFINITY}\).
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NBOUND}\)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/population_balance_model.html b/v5.0.1/interface/population_balance_model.html
new file mode 100644
index 000000000..a94c5d6ae
--- /dev/null
+++ b/v5.0.1/interface/population_balance_model.html
@@ -0,0 +1,364 @@
+
+
+
+
+
+
+
+ Population balance model — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The PBM in CADET is implemented as part of the reaction module and can thus be used in any unit operation that includes reactions.
+Typical applications consider crystallization in a Continuous stirred tank reactor model or, to model continuous processes, in a Dispersive Plug-Flow Reactor (DPFR), which is modelled by a Lumped Rate Model Without Pores.
+
The particle size domain (internal coordinate) is discretized by the FV method, giving us a finite set of particle sizes under consideration \(\{x_1, \dots, x_{N_x}\}\).
+Every particle size considered is treated as an individual component of the unit operation and the field NCOMP of that unit operation in which the crystallization happens, must be specified accordingly as \(N_x + 2\).
+The two additional components account for the solute \(c\) and solubility \(c_\text{eq}\).
+That is, by setting the ``NCOMP`` field, you specify the number of FV cells for the internal coordinate.
+
Note that the first component must be solute \(c\) and the last component must be the solubility \(c_\text{eq}\).
Number of components, which is given by two plus the number discrete particle sizes, which is given by the number of FV cells discretizing the internal coordinate
+
+
+
Type: int
+
Range:\(\geq 3\)
+
Length: 1
+
+
+
+
+
REACTION_MODEL
+
+
The crystallization code is implemented as a reaction module, which is why crystallization needs to be specified here
+
+
+
Type: String
+
Range:\(\{ CRYSTALLIZATION \}\)
+
Length: 1
+
+
+
+
+
+
+
Group /input/model/unit_XXX/reaction_bulk - REACTION_MODEL = CRYSTALLIZATION - UNIT_TYPE = CSTR¶
+
The following parameters need to be specified under Group /input/model/unit_XXX/reaction/reaction_bulk/ for CSTR units, and Group /input/model/unit_XXX/reaction/reaction/ for transport units like the LRM.
+
CRY_BINS
+
+
Coordinates of the cell faces, e.g. equidistant or logarithmic discretization of the internal coordinate \(x \in [x_c, x_\text{end}]\), including the end points.
+
+
+
Type: double
+
Range:\(\geq 1\)
+
Length:\(\mathrm{N_x} + 1\)
+
+
+
+
+
CRY_NUCLEI_MASS_DENSITY
+
+
Nulcei mass density
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_VOL_SHAPE_FACTOR
+
+
Volumetric shape factor of the particles
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_PRIMARY_NUCLEATION_RATE
+
+
Primary nucleation rate constant \(k_p\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_SECONDARY_NUCLEATION_RATE
+
+
Secondary nucleation rate \(k_b\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_GROWTH_RATE_CONSTANT
+
+
Growth rate constant \(k_g\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_GROWTH_CONSTANT
+
+
Growth constant \(\gamma\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_A
+
+
Defines constant \(a\) used to determine the growth rate
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_G
+
+
Defines constant \(g\) used to determine the growth rate
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_P
+
+
Defines constant \(p\) used to determine the growth rate
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_GROWTH_DISPERSION_RATE
+
+
Growth dispersion rate \(D_g\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_U
+
+
Defines constant \(u\) used to determine the primary nucleation
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_B
+
+
Defines constant \(b\) used to determine the secondary nucleation
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_K
+
+
Defines constant \(k\) used to determine the secondary nucleation
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CRY_GROWTH_SCHEME_ORDER
+
+
Defines the growth flux FV reconstruction scheme. It can only be \(1\): upwind scheme; \(2\): HR Koren scheme; \(3\): WENO23 scheme; \(4\): WENO35 scheme.
+We recommend using the HR Koren scheme, which showed to be the most performant in our benchmarks.
Some reaction models have a variant that can use external sources as specified /input/model/external/ (also see Section?:ref:dependence-on-external-function_react).
+For the sake of brevity, only the standard variant of those reaction models is specified below.
+In order to obtain the format for the externally dependent variant, first replace the reaction model name XXX by EXT_XXX.
+Each parameter \(p\) (except for stoichiometric and exponent matrices) depends on a (possibly distinct) external source in a polynomial way:
+
+\[\begin{aligned}
+ p(T) &= p_{\texttt{TTT}} T^3 + p_{\texttt{TT}} T^2 + p_{\texttt{T}} T + p.
+\end{aligned}\]
+
Thus, a parameter XXX_YYY of the standard reaction model variant is replaced by the four parameters EXT_XXX_YYY, EXT_XXX_YYY_T, EXT_XXX_YYY_TT, and EXT_XXX_YYY_TTT.
+Since each parameter can depend on a different external source, the dataset EXTFUN (not listed in the standard variants below) should contain a vector of 0-based integer indices of the external source of each parameter.
+The ordering of the parameters in EXTFUN is given by the ordering in the standard variant.
+However, if only one index is passed in EXTFUN, this external source is used for all parameters.
+
Note that parameter sensitivities with respect to column radius, column length, particle core radius, and particle radius may be wrong when using externally dependent reaction models.
+This is caused by not taking into account the derivative of the external profile with respect to column position.
The group that contains the parameters of a reaction model in unit operation with index XXX reads /input/model/unit_XXX/reaction_particle.
+This is valid for models with a single particle type.
+If a model has multiple particle types, it may have a different reaction model in each type.
+The parameters are then placed in the group /input/model/unit_XXX/reaction_particle_YYY instead, where YYY denotes the index of the particle type.
+
Note that, in any case, /input/model/unit_XXX/reaction_particle_000 contains the parameters of the first (and possibly sole) particle type.
+This group also takes precedence over a possibly existing /input/model/unit_XXX/adsorption_particle group.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/reaction/mass_action_law.html b/v5.0.1/interface/reaction/mass_action_law.html
new file mode 100644
index 000000000..d56b8e20a
--- /dev/null
+++ b/v5.0.1/interface/reaction/mass_action_law.html
@@ -0,0 +1,360 @@
+
+
+
+
+
+
+
+ Mass Action Law — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Group /input/model/unit_XXX/reaction - REACTION_MODEL = MASS_ACTION_LAW
+
MAL_KFWD_BULK
+
+
Forward rate constants for bulk volume reactions (available for external functions)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length:\(\texttt{NREACT}\)
+
+
+
+
+
MAL_KBWD_BULK
+
+
Backward rate constants for bulk volume reactions (available for external functions)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length:\(\texttt{NREACT}\)
+
+
+
+
+
MAL_KFWD_LIQUID
+
+
Forward rate constants for particle liquid phase reactions (available for external functions)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length:\(\texttt{NREACT}\)
+
+
+
+
+
MAL_KBWD_LIQUID
+
+
Backward rate constants for particle liquid phase reactions (available for external functions)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length:\(\texttt{NREACT}\)
+
+
+
+
+
MAL_KFWD_SOLID
+
+
Forward rate constants for particle solid phase reactions (available for external functions)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length:\(\texttt{NREACT}\)
+
+
+
+
+
MAL_KBWD_SOLID
+
+
Backward rate constants for particle solid phase reactions (available for external functions)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length:\(\texttt{NREACT}\)
+
+
+
+
+
MAL_STOICHIOMETRY_BULK
+
+
Stoichiometric matrix of bulk volume reactions as \(\texttt{NCOMP} \times \texttt{NREACT}\) matrix in row-major storage
+
+
+
Type: double
+
Length:\(\texttt{NCOMP} \cdot \texttt{NREACT}\)
+
+
+
+
+
MAL_EXPONENTS_BULK_FWD
+
+
Forward exponent matrix of bulk volume reactions as \(\texttt{NCOMP} \times \texttt{NREACT}\) matrix in row-major storage (optional, calculated from \(\texttt{MAL_STOICHIOMETRY_BULK}\) by default)
+
+
+
Type: double
+
Length:\(\texttt{NCOMP} \cdot \texttt{NREACT}\)
+
+
+
+
+
MAL_EXPONENTS_BULK_BWD
+
+
Backward exponent matrix of bulk volume reactions as \(\texttt{NCOMP} \times \texttt{NREACT}\) matrix in row-major storage (optional, calculated from \(\texttt{MAL_STOICHIOMETRY_BULK}\) by default)
+
+
+
Type: double
+
Length:\(\texttt{NCOMP} \cdot \texttt{NREACT}\)
+
+
+
+
+
MAL_STOICHIOMETRY_LIQUID
+
+
Stoichiometric matrix of particle liquid phase reactions as \(\texttt{NCOMP} \times \texttt{NREACT}\) matrix in row-major storage
+
+
+
Type: double
+
Length:\(\texttt{NCOMP} \cdot \texttt{NREACT}\)
+
+
+
+
+
MAL_EXPONENTS_LIQUID_FWD
+
+
Forward exponent matrix of particle liquid phase reactions as \(\texttt{NCOMP} \times \texttt{NREACT}\) matrix in row-major storage (optional, calculated from \(\texttt{MAL_STOICHIOMETRY_LIQUID}\) by default)
+
+
+
Type: double
+
Length:\(\texttt{NCOMP} \cdot \texttt{NREACT}\)
+
+
+
+
+
MAL_EXPONENTS_LIQUID_BWD
+
+
Backward exponent matrix of particle liquid phase reactions as \(\texttt{NCOMP} \times \texttt{NREACT}\) matrix in row-major storage (optional, calculated from \(\texttt{MAL_STOICHIOMETRY_LIQUID}\) by default)
+
+
+
Type: double
+
Length:\(\texttt{NCOMP} \cdot \texttt{NREACT}\)
+
+
+
+
+
MAL_EXPONENTS_LIQUID_FWD_MODSOLID
+
+
Forward solid phase modifier exponent matrix of particle liquid phase reactions as \(\texttt{NTOTALBND} \times \texttt{NREACT}\) matrix in row-major storage (optional, defaults to all 0)
Backward solid phase modifier exponent matrix of particle liquid phase reactions as \(\texttt{NTOTALBND} \times \texttt{NREACT}\) matrix in row-major storage (optional, defaults to all 0)
Forward exponent matrix of particle solid phase reactions as \(\texttt{NTOTALBND} \times \texttt{NREACT}\) matrix in row-major storage (optional, calculated from \(\texttt{MAL_STOICHIOMETRY_SOLID}\) by default)
Backward exponent matrix of particle solid phase reactions as \(\texttt{NTOTALBND} \times \texttt{NREACT}\) matrix in row-major storage (optional, calculated from \(\texttt{MAL_STOICHIOMETRY_SOLID}\) by default)
Forward liquid phase modifier exponent matrix of particle solid phase reactions as \(\texttt{NCOMP} \times \texttt{NREACT}\) matrix in row-major storage (optional, defaults to all 0)
+
+
+
Type: double
+
Length:\(\texttt{NCOMP} \cdot \texttt{NREACT}\)
+
+
+
+
+
MAL_EXPONENTS_SOLID_BWD_MODLIQUID
+
+
Backward liquid phase modifier exponent matrix of particle solid phase reactions as \(\texttt{NCOMP} \times \texttt{NREACT}\) matrix in row-major storage (optional, defaults to all 0)
Group /input/model/unit_XXX/reaction - REACTION_MODEL = MICHAELIS_MENTEN
+
MM_STOICHIOMETRY_BULK
+
+
Stochiometric matrix \(S\).
+The substrate component \(c_S\) is identified by the index of the first negative entry in the stoichiometry of the corresponding reaction.
+Input as reaction index major.
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NREACT} \cdot \texttt{NCOMP}\)
+
+
+
+
+
MM_VMAX
+
+
+
Limiting rate \(\mu_{\mathrm{max},j}\) at saturation.
+
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NREACT}\)
+
+
+
+
+
MM_KMM
+
+
+
Michaelis constant \(k_{\mathrm{MM},j}\).
+
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NREACT}\)
+
+
+
+
+
MM_KI
+
+
+
Inhibition constant \(k_{\mathrm{I},j,i}\) w.r.t component \(i\) and reaction \(j\). If \(k_{\mathrm{I},j,i} <= 0\), the component does not inhibit the reaction.
+Input as reaction index major.
+
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NREACT} \cdot \texttt{NCOMP}\)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/return_data.html b/v5.0.1/interface/return_data.html
new file mode 100644
index 000000000..98b952b1f
--- /dev/null
+++ b/v5.0.1/interface/return_data.html
@@ -0,0 +1,557 @@
+
+
+
+
+
+
+
+ Return data — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Write times at which a solution was produced (optional, defaults to 1)
+
+
+
Type: int
+
Range:\(\{0,1\}\)
+
+
+
+
+
WRITE_SOLUTION_LAST
+
+
Write full solution state vector at last time point, including the state derivative vector (optional, defaults to 0)
+
+
+
Type: int
+
Range:\(\{0,1\}\)
+
+
+
+
+
WRITE_SENS_LAST
+
+
Write full sensitivity state vectors at last time point, including the state derivative vector (optional, defaults to 0)
+
+
+
Type: int
+
Range:\(\{0,1\}\)
+
+
+
+
+
SPLIT_COMPONENTS_DATA
+
+
Determines whether a joint dataset (matrix or tensor) for all components is created or if each component is put in a separate dataset (\(\texttt{XXX_COMP_000}\), \(\texttt{XXX_COMP_001}\), etc.) (optional, defaults to 1)
+
+
+
Type: int
+
Range:\(\{0,1\}\)
+
+
+
+
+
SPLIT_PORTS_DATA
+
+
Determines whether a joint dataset (matrix or tensor) for all inlet/outlet ports is created or if each port is put in a separate dataset (\(\texttt{XXX_PORT_000}\), \(\texttt{XXX_PORT_001}\), etc.) (optional, defaults to 1)
+
+
+
Type: int
+
Range:\(\{0,1\}\)
+
+
+
+
+
SINGLE_AS_MULTI_PORT
+
+
Determines whether single port unit operations are treated as multi port unit operations in the output naming scheme (i.e., \(\texttt{_PORT_XYZ_}\) is added to the name) (optional, defaults to 0)
Group /input/model/unit_XXX/discretization/SPATIAL_METHOD - Details on the methods¶
+
CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG).
+While both methods approximate the same solution to the underlying models, they may differ in terms of computational performance.
+Generally, FV can perform better for small problem sizes and solutions with steep gradients, while DG excels for large problem sizes and smooth solutions.
+
In the following, we give a brief introduction to the numerical theory w.r.t. the computational performance of the methods.
+Based on that theory and our experience, we give advice on which method to use in which scenario, how to identify the computationally best performing method, and how to specify discretization parameters.
+For a comprehensive description of the FV and DG variants that are implemented in CADET, we refer to our publications on CADET-FV and CADET-DG.
FV and DG discretize the continuous spatial domain of the partial differential algebraic equations (PDAE) into a finite set of discrete points.
+Then, a system of (semi-discrete) equations is formulated on those points, resulting in a system of ordinary differential algebraic equations (ODAE).
+The system size and number of unknowns, are also referred to as degrees of freedom (DoF), is given by the number of (spatial) discrete points (times the number of components for multi-component systems).
+
The numerical solution becomes more accurate with more discrete points used, but the compute time required to solve the equations also increases.
+That is, we trade compute time for approximation accuracy.
+
For the FV method, the number of axial discrete points in the column is specified by the number of volume cells NCOL.
+For the DG method, the number of axial discrete points in the column is specified by the number of polynomial interpolation nodes (= POLYDEG + 1) times the number of DG elements NELEM.
+The GRM additionally comprises a transport equation along the radial coordinate of the particles which is also spatially discretized and the particle discrete points are correspondingly given by NPAR for FV and for DG via PAR_POLYDEG and PAR_NELEM.
The computational performance of a numerical method depends on its theoretical order of convergence.
+The order of convergence refers to the rate at which the numerical approximation approaches the exact solution under refinement of the spatial grid.
+Consequently, higher order methods often require less spatial discrete points to compute an approximation of the desired accuracy and can thus be computationally more efficient.
+
The theoretical order of convergence for the CADET-FV method is globally limited to 2.
+It is locally (except column boundaries) limited to 3, with an improved order of up to 5 for smooth solutions, and can be varied by specifying the parameters described in the Flux reconstruction methods section.
+For the CADET-DG method, the theoretical order of convergence is \(N_d + 1\) with \(N_d\) denoting the polynomial degree, and can thus be user-defined by specifying the field POLYDEG (and PAR_POLYDEG for the particles in the GRM).
+
The theoretical order of convergence is an asymptotic property, i.e. holds for infinite refinements, but can be numerivcally observed for finite refinements as well.
+Having the exact solution, we can compute an experimental order of convergence (EOC) via the formula
with \(\varepsilon_{k}\) and \(n_{k}\) denoting some error norm and the degrees of freedom of the $k$th approximation.
+The EOC approaches the theoretical order of convergence for \(k \rightarrow \infty\) but is typically lower for underresolved problems.
+High-order methods typically do typically not exhibit their theoretical order on very coarse grids.
+That is, increasing the number of discrete points from, e.g., 2 to 4 does often not improve the solution according to the theoretical order of convergence but by a much smaller EOC.
+
For smooth solutions, we typically observe an EOC of around 2.5 for the default CADET-FV method and around \(N_d\) for the CADET-DG method.
+To our experience, DG with \(N_d>6\) does usually not realize an EOC of \(>6\) for approximation errors within engineering tolerances, i.e. higher rates are achieved only for excessively small error tolerances that are not relevant for most applications.
+We thus recommend to choose \(3 \leq N_d \leq 5\) for the DG method.
+
One could still think that the higher the order of the method, the better the performance, but that is unfortunately not generally true, as the numerical solver performance can strongly depend on the smoothness of the approximated solution.
The smoothness of a function indicates the absence of sudden changes, reflected in the continuity and differentiability of the function and its derivatives.
+In numerical simulation, smoothness indicators are often based on derivatives or moments of the solution.
+That is, the occurrence of strong gradients and high frequencies are used to identify non-smooth parts of the solution.
+Godunov’s order barrier theorem shows why the concept of smoothness plays a crucial role in the deployment of numerical methods.
+It states that linear high-order methods that are monotonous are at most first-order accurate.
+Linear higher-order (\(\gt 1\)) methods thus suffer from artificial oscillations at non-smooth parts of the solution, specifically at discontinuities and strong gradients.
+Some higher-order methods, such as the FV variants implemented in CADET, contain a non-linear mechanism to suppress these oscillations.
+The non-linear WENO mechanism employed in CADET-FV can be fine-tuned via the parameters specified in the Flux reconstruction methods section.
+Unfortunately, non-linear higher-order methods (here \(\geq 3\)) are either not applicable (e.g., undefined boundary treatment) or have other shortcomings, such as parameters whose optimal values can be highly proplem-specific.
+
The DG variant that is implemented in CADET is a linear high-order method (arbitrary order) and can thus exhibit oscillatory behaviour at strong gradients, which increases the approximation error and results in a smaller EOC for lower resolutions.
+Since strong gradients are local phenomena which can be captured by employing more discrete points, DG performs better again for higher spatial resolutions.
+This, however, might happen after the engineering error tolerance is by far surpassed.
+Hence, CADET-FV as a stabilized lower-order method can perform better, depending on the smoothness of the approximated solution.
+The DG method reduces its oscillatory behaviour by adding artificial numerical dispersion at element interfaces.
+Thus, the use of a lower polynomial degree and more elements is recommended for non-smooth solutions.
+
In Chromatography, mathematical discontinuities never happen, as there are always some dispersive effects in reality.
+Chromatography models, however, allow for discontinuities if dispersion parameters are set to zero.
+Moreover, steep and self-sharpening concentration fronts might appear due to competitive adsorption.
+Examples that can cause self-sharpening concentration fronts are often associated with competitive Langmuir type isotherms for components with differently strong binding properties.
+Nonetheless, many chromatography settings yield rather smooth concentration profiles, for which DG is the better choice in terms of computational performance.
+
+
+
Recommendations on the choice of spatial discretization methods¶
+
We recommend the FV method for
+
+
Small problem sizes, e.g., low spatial resolution with the LRM
+
Problems with strong gradients, e.g., no or low dispersion and binding model parameters that create sharp fronts
+
Binding models that mathematically require positive values or exhibit strange behaviour with negative concentration values
+
+
We recommend the DG method for
+
+
Large problem sizes, e.g., high spatial resolutions and more complex models (i.e. the LRMP and specifically the GRM)
Select a lower axial polynomial degree for approximating functions that tend to be less smooth and employ more elements instead. Converse choice for smooth problems
+
Adjust the DG particle polynomial degree to control approximation accuracy; leave the number of elements at one. Make exceptions if very steep gradients occur inside the particles or when specific regions of the particle domain are more interesting (the spatial resolution of certain regions can be refined by a user-defined spacing of multiple elements)
+
The field EXACT_INTEGRATION specifies the DG polynomial integration method. The default value of $0$ (collocation DG) is expected to be slightly more performant in most settings
A common problem in numerical simulation is that the number of discrete points required to yield an accurate approximation within a specific tolerance is unknown.
+We thus recommend determining the approximation error via comparison with a refined reference approximation.
+Both the theoretical order of convergence and the EOC can be used to estimate the required number of discrete points.
+An EOC that is significantly lower than the theoretical order indicates that the problem is numerically underresolved.
Any liquid or solid concentration within the column or particles is reported on the discrete points that are employed by the method.
+That is, DG yields a piece-wise polynomial approximation on Lagrange-Gauss-Lobatto nodes.
+If the solution is desired on a different grid, element-wise polynomial interpolation should be applied, and element interface values must be averaged.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/system.html b/v5.0.1/interface/system.html
new file mode 100644
index 000000000..2db7abde3
--- /dev/null
+++ b/v5.0.1/interface/system.html
@@ -0,0 +1,480 @@
+
+
+
+
+
+
+
+ System of unit operations — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Initial full state vector (optional, unit operation specific initial data is ignored)
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
INIT_STATE_YDOT
+
+
Initial full time derivative state vector (optional, unit operation specific initial data is ignored)
+
+
+
Type: double
+
Length:\(\texttt{NDOF}\)
+
+
+
+
+
INIT_STATE_SENSY_XXX
+
+
Initial full time derivative state vector of the \(\texttt{XXX}\) th sensitivity system (optional, can currently not be specified on unit operation level)
+
+
+
Type: double
+
Length:\(\texttt{NDOF}\)
+
+
+
+
+
INIT_STATE_SENSYDOT_XXX
+
+
Initial full state vector of the \(\texttt{XXX}\) th sensitivity system (optional, can currently not be specified on unit operation level)
Determines whether the \(\texttt{CONNECTIONS}\) table includes ports (\(1\)) or not (\(0\)). Optional, defaults to 0 unless a unit operation model with multiple ports is present.
+
+
+
Type: int
+
Range:\(\{ 0,1 \}\)
+
Length: 1
+
+
+
+
+
CONNECTIONS_INCLUDE_DYNAMIC_FLOW
+
+
Determines whether the \(\texttt{CONNECTIONS}\) table includes linear, quadratic, and cubic flow rate coefficients (1) or not (0). Optional, defaults to 0.
Index of the section that activates this connection set
+
+
+
Type: int
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CONNECTIONS
+
+
+
Matrix with list of connections in row-major storage. Columns are UnitOpID from, UnitOpID to, Port from, Port to, Component from, Component to, volumetric flow rate, linear flow rate coefficient, quadratic flow rate coefficient, cubic flow rate coefficient.
+If both port indices are \(-1\), all ports are connected.
+If both component indices are \(-1\), all components are connected.
where \(t_s\) is the beginning of the section that activates the switch (i.e., \(\texttt{SECTION_TIMES}\) at index \(\texttt{SECTION}\)).
+
The port indices are left out if \(\texttt{CONNECTIONS_INCLUDE_PORTS}\) is set to \(0\) and no unit operation with multiple ports is present in the system. If a unit operation with multiple ports is present, \(\texttt{CONNECTIONS_INCLUDE_PORTS}\) is ignored and port indices are mandatory.
+
The last three flow rate coefficients are left out if \(\texttt{CONNECTIONS_INCLUDE_DYNAMIC_FLOW}\) is set to \(0\).
+Contrary to the constant coefficient, which has the parameter name \(\texttt{CONNECTION}\), the other coefficients are named \(\texttt{CONNECTION_LIN}\), \(\texttt{CONNECTION_QUAD}\), and \(\texttt{CONNECTION_CUB}\), respectively.
+
For addressing the flow rates as a parameter senstivity, the mapping is as follows:
+
+
+
\(\texttt{SENS_UNIT}\) Unused, always set to \(-1\)
+
\(\texttt{SENS_BOUNDPHASE}\)UnitOpID from
+
\(\texttt{SENS_REACTION}\)UnitOpID to
+
\(\texttt{SENS_COMP}\)Port from
+
\(\texttt{SENS_PARTYPE}\)Port to
+
\(\texttt{SENS_SECTION}\)\(\texttt{SECTION}\) that activates the valve switch
Group /input/model/external/source_XXX - EXTFUN_TYPE = LINEAR_INTERP_DATA¶
+
VELOCITY
+
+
Velocity of the external profile in positive column axial direction.
+The velocity is normalized to a column with length 1, hence the unit \(\mathrm{s}^{-1}\).
+
Unit:\(\mathrm{s}^{-1}\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
DATA
+
+
Function values \(T\) at the data points
+
Unit:\([\mathrm{Ext}]\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: Arbitrary
+
+
+
+
+
+
TIME
Time of the data points
+
Unit:\(\mathrm{s}\)
+
+
+
Type: double
+
Range:\(\geq 0.0\)
+
Length: Same as \(\texttt{DATA}\)
+
+
+
+
+
+
+
+
Group /input/model/external/source_XXX - EXTFUN_TYPE = PIECEWISE_CUBIC_POLY¶
+
VELOCITY
+
+
Velocity of the external profile in positive column axial direction.
+The velocity is normalized to a column with length 1, hence the unit \(\mathrm{s}^{-1}\).
+
Unit:\(\mathrm{s}^{-1}\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
CONST_COEFF
+
+
Constant coefficients of piecewise cubic polynomial
+
Unit:\([\mathrm{Ext}]\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: Arbitrary
+
+
+
+
+
LIN_COEFF
+
+
Linear coefficients of piecewise cubic polynomial
+
Unit:\([\mathrm{Ext}]\,\mathrm{s}^{-1}\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: Same as \(\texttt{CONST_COEFF}\)
+
+
+
+
+
QUAD_COEFF
+
+
Quadratic coefficients of piecewise cubic polynomial
+
Unit:\([\mathrm{Ext}]\,\mathrm{s}^{-2}\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: Same as \(\texttt{CONST_COEFF}\)
+
+
+
+
+
CUBE_COEFF
+
+
Cubic coefficients of piecewise cubic polynomial
+
Unit:\([\mathrm{Ext}]\,\mathrm{s}^{-3}\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: Same as \(\texttt{CONST_COEFF}\)
+
+
+
+
+
SECTION_TIMES
+
+
Simulation times at which a new piece begins (breaks of the piecewise polynomial)
Type of Gram-Schmidt orthogonalization, see IDAS guide Section~4.5.7.3, p.~41f. A value of \(0\) enables classical Gram-Schmidt, a value of 1 uses modified Gram-Schmidt.
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
MAX_KRYLOV
+
+
Defines the size of the Krylov subspace in the iterative linear GMRES solver (0: \(\texttt{MAX_KRYLOV} = \texttt{NDOF}\))
+
+
+
Type: int
+
Range:\(\{0, \dots, \texttt{NDOF}\}\)
+
Length: 1
+
+
+
+
+
MAX_RESTARTS
+
+
Maximum number of restarts in the GMRES algorithm. If lack of memory is not an issue, better use a larger Krylov space than restarts.
+
+
+
Type: int
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
SCHUR_SAFETY
+
+
Schur safety factor; Influences the tradeoff between linear iterations and nonlinear error control; see IDAS guide Section~2.1 and 5.
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
LINEAR_SOLUTION_MODE
+
+
Determines whether the system of models is solved in parallel (1) or sequentially (2). A sequential solution is only possible for systems without cyclic connections. The setting can be chosen automatically (0) based on a heuristic (less than 25 unit operations and acyclic network selects sequential mode). Optional, defaults to automatic (0).
+
+
+
Type: int
+
Range:\(\{ 0,1,2 \}\)
+
Length: 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/unit_operations/2d_general_rate_model.html b/v5.0.1/interface/unit_operations/2d_general_rate_model.html
new file mode 100644
index 000000000..3804e4165
--- /dev/null
+++ b/v5.0.1/interface/unit_operations/2d_general_rate_model.html
@@ -0,0 +1,884 @@
+
+
+
+
+
+
+
+ Two dimensional general rate model — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Multiplexing mode of \(\texttt{ADSORPTION_MODEL}\). If set to 0, each particle type has a different binding model and the length of \(\texttt{ADSORPTION_MODEL}\) is \(\texttt{NPARTYPE}\). If set to 1, all particle types share the same binding model and the length of \(\texttt{ADSORPTION_MODEL}\) is 1. This field is optional and inferred from the length of \(\texttt{ADSORPTION_MODEL}\) if left out.
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
NBOUND
+
+
Number of bound states for each component in each particle type in type-major ordering
Specifies the type of reaction model of each particle type (or of all particle types if length is 1). The model is configured in the subgroup \(\texttt{reaction_particle}\), or \(\texttt{reaction_particle_XXX}\) in case of disabled multiplexing.
Multiplexing mode of \(\texttt{REACTION_MODEL_PARTICLES}\). If set to 0, each particle type has a different reaction model and the length of \(\texttt{REACTION_MODEL_PARTICLES}\) is \(\texttt{NPARTYPE}\). If set to 1, all particle types share the same reaction model and the length of \(\texttt{REACTION_MODEL_PARTICLES}\) is 1. This field is optional and inferred from the length of \(\texttt{REACTION_MODEL_PARTICLES}\) if left out.
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
INIT_C
+
+
Initial concentrations for each component in all radial zones the bulk mobile phase (length \(\texttt{NCOMP}\)), or for each component in each radial zone (length \(\texttt{NCOMP} \cdot \texttt{NRAD}\), ordering radial-major)
Initial concentrations for each component in the bead liquid phase (optional, \(\texttt{INIT_C}\) is used if left out). The length of this field can be \(\texttt{NCOMP}\) (same values for each radial zone and particle type), \(\texttt{NPARTYPE} \cdot \texttt{NCOMP}\) (same values for each radial zone), \(\texttt{RAD} \cdot \texttt{NCOMP}\) (same values for each particle type), or \(\texttt{NRAD} \cdot \texttt{NPARTYPE} \cdot \texttt{NCOMP}\). The ordering is radial-type-major. Values for each particle type can only be given when \(\texttt{ADSORPTION_MODEL_MULTIPLEX}\) is 0. In the radial-inhomogeneous case, the \(\texttt{SENS_REACTION}\) field is used for indexing the radial zone when specifying parameter sensitivities.
Initial concentrations for each bound state of each component in the bead solid phase. If \(\texttt{ADSORPTION_MODEL_MULTIPLEX}\) is 0, values for each particle type are required in type-component-major ordering (length is \(\texttt{NTOTALBND}\)). If \(\texttt{ADSORPTION_MODEL_MULTIPLEX}\) is 1, values for one particle type are required in component-major ordering (length is \(\sum_{i = 0}^{\texttt{NCOMP} - 1} \texttt{NBND}_i\)). Alternatively, values for each radial zone can be supplied. If \(\texttt{ADSORPTION_MODEL_MULTIPLEX}\) is 0, values for each radial zone and each particle type are required in radial-type-component-major ordering (length is \(\texttt{NRAD} \cdot \texttt{NTOTALBND}\)). If \(\texttt{ADSORPTION_MODEL_MULTIPLEX}\) is 1, values for each radial zone and all particle types are required in radial-component-major ordering (length is \(\texttt{NRAD} \cdot \sum_{i = 0}^{\texttt{NCOMP} - 1} \texttt{NBND}_i\)). In the radial-inhomogeneous case, the \(\texttt{SENS_REACTION}\) field is used for indexing the radial zone when specifying parameter sensitivities.
Full state vector for initialization (optional, \(\texttt{INIT_C}\), \(\texttt{INIT_CP}\), and \(\texttt{INIT_Q}\) will be ignored; if length is \(2\texttt{NDOF}\), then the second half is used for time derivatives)
+
Unit:\(various\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NDOF} / 2\texttt{NDOF}\)
+
+
+
+
+
COL_DISPERSION
+
+
Axial dispersion coefficient. In case of a spatially inhomogeneous setting, the \(\texttt{SENS_PARTYPE}\) field is used for indexing the radial zone when specifying parameter sensitivities.
Multiplexing mode of \(\texttt{COL_DISPERSION}\). Determines whether \(\texttt{COL_DISPERSION}\) is treated as component-, radial-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{COL_DISPERSION}\). Valid modes are:
+
+
+
Component-independent, radial-independent, section-independent; length of \(\texttt{COL_DISPERSION}\) is 1
+
Component-independent, radial-dependent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NRAD}\)
+
Component-dependent, radial-independent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP}\)
+
Component-dependent, radial-dependent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP} \cdot \texttt{NRAD}\); ordering is radial-major
+
Component-independent, radial-independent, section-dependent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NSEC}\)
+
Component-independent, radial-dependent, section-dependent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NRAD} \cdot \texttt{NSEC}\); ordering is section-major
+
Component-dependent, radial-independent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
+
Component-dependent, radial-dependent, section-dependent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP} \cdot \texttt{NRAD} \cdot \texttt{NSEC}\); ordering is section-radial-major
+
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 7 \}\)
+
Length: 1
+
+
+
+
+
+
COL_DISPERSION_RADIAL
+
+
Radial dispersion coefficient. In case of a spatially inhomogeneous setting, the \(\texttt{SENS_PARTYPE}\) field is used for indexing the radial zone when specifying parameter sensitivities.
Length: see \(\texttt{COL_DISPERSION_RADIAL_MULTIPLEX}\)
+
+
+
+
+
COL_DISPERSION_RADIAL_MULTIPLEX
+
+
+
Multiplexing mode of \(\texttt{COL_DISPERSION_RADIAL}\). Determines whether \(\texttt{COL_DISPERSION_RADIAL}\) is treated as component-, radial-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{COL_DISPERSION_RADIAL}\). Valid modes are:
+
+
+
Component-independent, radial-independent, section-independent; length of \(\texttt{COL_DISPERSION_RADIAL}\) is 1
+
Component-independent, radial-dependent, section-independent; length of \(\texttt{COL_DISPERSION_RADIAL}\) is \(\texttt{NRAD}\)
+
Component-dependent, radial-independent, section-independent; length of \(\texttt{COL_DISPERSION_RADIAL}\) is \(\texttt{NCOMP}\)
+
Component-dependent, radial-dependent, section-independent; length of \(\texttt{COL_DISPERSION_RADIAL}\) is \(\texttt{NCOMP} \cdot \texttt{NRAD}\); ordering is radial-major
+
Component-independent, radial-independent, section-dependent; length of \(\texttt{COL_DISPERSION_RADIAL}\) is \(\texttt{NSEC}\)
+
Component-independent, radial-dependent, section-dependent; length of \(\texttt{COL_DISPERSION_RADIAL}\) is \(\texttt{NRAD} \cdot \texttt{NSEC}\); ordering is section-major
+
Component-dependent, radial-independent, section-independent; length of \(\texttt{COL_DISPERSION_RADIAL}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
+
Component-dependent, radial-dependent, section-dependent; length of \(\texttt{COL_DISPERSION_RADIAL}\) is \(\texttt{NCOMP} \cdot \texttt{NRAD} \cdot \texttt{NSEC}\); ordering is section-radial-major
+
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 7 \}\)
+
Length: 1
+
+
+
+
+
+
COL_LENGTH
+
+
Column length
+
Unit:\(\mathrm{m}\)
+
+
+
Type: double
+
Range:\(> 0\)
+
Length: 1
+
+
+
+
+
COL_RADIUS
+
+
Column radius. This parameter is optional if CROSS_SECTION_AREA is provided.
+
Unit:\(\mathrm{m}\)
+
+
+
Type: double
+
Range:\(> 0\)
+
Length: 1
+
+
+
+
+
CROSS_SECTION_AREA
+
+
Cross section area of the column. This parameter is optional and will be ignored if COL_RADIUS is provided.
+
Unit:\(\mathrm{m}^{2}\)
+
+
+
Type: double
+
Range:\(>0\)
+
Length: 1
+
+
+
+
+
COL_POROSITY
+
+
Column porosity, either constant (length is 1) or for each radial zone (length is \(\texttt{NRAD}\)). In case of a spatially inhomogeneous setting, the \(\texttt{SENS_PARTYPE}\) field is used for indexing the radial zone when specifying parameter sensitivities.
+
+
+
Type: double
+
Range:\((0,1]\)
+
Length:\(1 / \texttt{NRAD}\)
+
+
+
+
+
FILM_DIFFUSION
+
+
Film diffusion coefficients for each component of each particle type
+
Unit:\(\mathrm{m}\,\mathrm{s}^{-1}\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: see \(\texttt{FILM_DIFFUSION_MULTIPLEX}\)
+
+
+
+
+
FILM_DIFFUSION_MULTIPLEX
+
+
+
Multiplexing mode of \(\texttt{FILM_DIFFUSION}\). Determines whether \(\texttt{FILM_DIFFUSION}\) is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{FILM_DIFFUSION}\). Valid modes are:
+
+
+
Component-dependent, type-independent, section-independent; length of \(\texttt{FILM_DIFFUSION}\) is \(\texttt{NCOMP}\)
+
Component-dependent, type-independent, section-dependent; length of \(\texttt{FILM_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
+
Component-dependent, type-dependent, section-independent; length of \(\texttt{FILM_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE}\); ordering is type-major
+
Component-dependent, type-dependent, section-dependent; length of \(\texttt{FILM_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}\); ordering is section-type-major
+
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
+
PAR_POROSITY
+
+
Particle porosity of all particle types or for each particle type
+
+
+
Type: double
+
Range:\((0,1]\)
+
Length:\(1 / \texttt{NPARTYPE}\)
+
+
+
+
+
PAR_RADIUS
+
+
Particle radius of all particle types or for each particle type
+
Unit:\(\mathrm{m}\)
+
+
+
Type: double
+
Range:\(>0\)
+
Length:\(1 / \texttt{NPARTYPE}\)
+
+
+
+
+
PAR_CORERADIUS
+
+
Particle core radius of all particle types or for each particle type (optional, defaults to \(0~m\))
+
Unit:\(\mathrm{m}\)
+
+
+
Type: double
+
Range:\([0, \texttt{PAR_RADIUS})\)
+
Length:\(1 / \texttt{NPARTYPE}\)
+
+
+
+
+
PORE_ACCESSIBILITY
+
+
Pore accessibility factor of each component in each particle type (optional, defaults to 1).
+Note: Should not be used in combination with any binding model!
+
+
+
Type: double
+
Range:\((0, 1]\)
+
Length: see \(\texttt{PORE_ACCESSIBILITY_MULTIPLEX}\)
+
+
+
+
+
PORE_ACCESSIBILITY_MULTIPLEX
+
+
+
Multiplexing mode of \(\texttt{PORE_ACCESSIBILITY}\). Determines whether \(\texttt{PORE_ACCESSIBILITY}\) is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{PORE_ACCESSIBILITY}\). Valid modes are:
+
+
+
Component-dependent, type-independent, section-independent; length of \(\texttt{PORE_ACCESSIBILITY}\) is \(\texttt{NCOMP}\)
+
Component-dependent, type-independent, section-dependent; length of \(\texttt{PORE_ACCESSIBILITY}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
+
Component-dependent, type-dependent, section-independent; length of \(\texttt{PORE_ACCESSIBILITY}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE}\); ordering is type-major
+
Component-dependent, type-dependent, section-dependent; length of \(\texttt{PORE_ACCESSIBILITY}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}\); ordering is section-type-major
+
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
+
PAR_DIFFUSION
+
+
Effective particle diffusion coefficients of each component in each particle type
Multiplexing mode of \(\texttt{PAR_DIFFUSION}\). Determines whether \(\texttt{PAR_DIFFUSION}\) is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{PAR_DIFFUSION}\). Valid modes are:
+
+
+
Component-dependent, type-independent, section-independent; length of \(\texttt{PAR_DIFFUSION}\) is \(\texttt{NCOMP}\)
+
Component-dependent, type-independent, section-dependent; length of \(\texttt{PAR_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
+
Component-dependent, type-dependent, section-independent; length of \(\texttt{PAR_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE}\); ordering is type-major
+
Component-dependent, type-dependent, section-dependent; length of \(\texttt{PAR_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}\); ordering is section-type-major
+
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
+
PAR_SURFDIFFUSION
+
+
Particle surface diffusion coefficients of each bound state of each component in each particle type (optional, defaults to all \(0~m_{SP}^2 s^{-1}\))
Length: see \(\texttt{PAR_SURFDIFFUSION_MULTIPLEX}\)
+
+
+
+
+
PAR_SURFDIFFUSION_MULTIPLEX
+
+
+
Multiplexing mode of \(\texttt{PAR_SURFDIFFUSION}\). Determines whether \(\texttt{PAR_SURFDIFFUSION}\) is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{PAR_SURFDIFFUSION}\). Valid modes are:
+
+
+
Component-dependent, type-independent, section-independent; length of \(\texttt{PAR_SURFDIFFUSION}\) is \(\texttt{NBND}\); ordering is component-major
+
Component-dependent, type-independent, section-dependent; length of \(\texttt{PAR_SURFDIFFUSION}\) is \(\texttt{NBND} \cdot \texttt{NSEC}\); ordering is section-component-major
+
Component-dependent, type-dependent, section-independent; length of \(\texttt{PAR_SURFDIFFUSION}\) is \(\texttt{NTOTALBND}\); ordering is type-component-major
+
Component-dependent, type-dependent, section-dependent; length of \(\texttt{PAR_SURFDIFFUSION}\) is \(\texttt{NTOTALBND} \cdot \texttt{NSEC}\); ordering is section-type-component-major
+
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
+
VELOCITY
+
+
Indicates flow direction in each radial zone (forward if value is positive, backward if value is negative), see Section Specification of flow rate / velocity and direction). In case of a spatially inhomogeneous setting, the \(\texttt{SENS_PARTYPE}\) field is used for indexing the radial cell when specifying parameter sensitivities.
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: see \(\texttt{VELOCITY_MULTIPLEX}\)
+
+
+
+
+
VELOCITY_MULTIPLEX
+
+
+
Multiplexing mode of \(\texttt{VELOCITY}\). Determines whether \(\texttt{VELOCITY}\) is treated as radial- and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{VELOCITY}\). Valid modes are:
+
+
+
Radial-independent, section-independent; length of \(\texttt{VELOCITY}\) is 1
+
Radial-dependent, section-independent; length of \(\texttt{VELOCITY}\) is \(\texttt{NRAD}\)
+
Section-dependent; length of \(\texttt{VELOCITY}\) is \(\texttt{NSEC}\)
+
Radial-dependent, section-dependent; length of \(\texttt{VELOCITY}\) is \(\texttt{NRAD} \cdot \texttt{NSEC}\); ordering is section-major
+
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
+
NPARTYPE
+
+
Number of particle types. Optional, inferred from the length of \(\texttt{NPAR}\) or \(\texttt{NBOUND}\) if left out.
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
PAR_GEOM
+
+
Specifies the particle geometry for all or each particle type. Valid values are \(\texttt{SPHERE}\), \(\texttt{CYLINDER}\), \(\texttt{SLAB}\). Optional, defaults to \(\texttt{SPHERE}\).
+
+
+
Type: string
+
Length:\(1\) / \(\texttt{NPARTYPE}\)
+
+
+
+
+
PAR_TYPE_VOLFRAC
+
+
Volume fractions of the particle types. The volume fractions can be set homogeneous or individually along both axes. For each cell, the volume fractions have to sum to 1. In case of a spatially inhomogeneous setting, the \(\texttt{SENS_SECTION}\) field is used for indexing the axial cell and the \(\texttt{SENS_REACTION}\) field is used for indexing the radial cell when specifying parameter sensitivities. This field is optional in case of only one particle type.
+
+
+
Type: double
+
Range:\([0,1]\)
+
Length: see \(\texttt{PAR_TYPE_VOLFRAC_MULTIPLEX}\)
+
+
+
+
+
PAR_TYPE_VOLFRAC_MULTIPLEX
+
+
+
Multiplexing mode of \(\texttt{PAR_TYPE_VOLFRAC}\). Determines whether \(\texttt{PAR_TYPE_VOLFRAC}\) is treated as radial- and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{PAR_TYPE_VOLFRAC}\). Valid modes are:
+
+
+
Radial-independent, axial-independent; length of \(\texttt{PAR_TYPE_VOLFRAC}\) is \(\texttt{NPARTYPE}\)
+
Radial-dependent, axial-independent; length of \(\texttt{PAR_TYPE_VOLFRAC}\) is \(\texttt{NRAD} \cdot \texttt{NPARTYPE}\); ordering is radial-major
+
Axial-dependent; length of \(\texttt{PAR_TYPE_VOLFRAC}\) is \(\texttt{NCOL} \cdot \texttt{NPARTYPE}\); ordering is axial-major
+
Radial-dependent, axial-dependent; length of \(\texttt{PAR_TYPE_VOLFRAC}\) is \(\texttt{NCOL} \cdot \texttt{NRAD} \cdot \texttt{NPARTYPE}\); ordering is axial-radial-major
+
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
+
+
+
Group /input/model/unit_XXX/discretization - UNIT_TYPE - GENERAL_RATE_MODEL_2D¶
+
NCOL
+
+
Number of axial column discretization cells
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
NRAD
+
+
Number of radial column discretization cells
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
NPAR
+
+
Number of particle (radial) discretization cells for each particle type
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length:\(1 / \texttt{NPARTYPE}\)
+
+
+
+
+
RADIAL_DISC_TYPE
+
+
Specifies the radial discretization scheme. Valid values are \(\texttt{EQUIDISTANT}\), \(\texttt{EQUIVOLUME}\), and \(\texttt{USER_DEFINED}\).
+
+
+
Type: string
+
Length: 1
+
+
+
+
+
RADIAL_COMPARTMENTS
+
+
Coordinates for the radial compartment boundaries (ignored if \(\texttt{RADIAL_DISC_TYPE} \neq \texttt{USER_DEFINED}\)). The coordinates are absolute and have to include the endpoints 0 and \(\texttt{COLUMN_RADIUS}\). The values are expected in ascending order (i.e., 0 is the first and \(\texttt{COLUMN_RADIUS}\) the last value in the array).
+
Unit:\(\mathrm{m}\)
+
+
+
Type: double
+
Range:\([0,\texttt{COLUMN_RADIUS}]\)
+
Length:\(\texttt{NRAD} + 1\)
+
+
+
+
+
PAR_DISC_TYPE
+
+
Specifies the discretization scheme inside the particles for all or each particle type. Valid values are \(\texttt{EQUIDISTANT_PAR}\), \(\texttt{EQUIVOLUME_PAR}\), and \(\texttt{USER_DEFINED_PAR}\).
+
+
+
Type: string
+
Length:\(1 / \texttt{NPARTYPE}\)
+
+
+
+
+
PAR_DISC_VECTOR
+
+
Node coordinates for the cell boundaries (ignored if \(\texttt{PAR_DISC_TYPE} \neq \texttt{USER_DEFINED_PAR}\)). The coordinates are relative and have to include the endpoints 0 and 1. They are later linearly mapped to the true radial range \([r_{c,j}, r_{p,j}]\). The coordinates for each particle type are appended to one long vector in type-major ordering.
+
+
+
Type: double
+
Range:\([0,1]\)
+
Length:\(sum_i (\texttt{NPAR}_i + 1)\)
+
+
+
+
+
PAR_BOUNDARY_ORDER
+
+
Order of accuracy of outer particle boundary condition. Optional, defaults to 2.
+
+
+
Type: int
+
Range:\(\{ 1,2 \}\)
+
Length: 1
+
+
+
+
+
USE_ANALYTIC_JACOBIAN
+
+
Determines whether analytically computed Jacobian matrix (faster) is used (value is 1) instead of Jacobians generated by algorithmic differentiation (slower, value is 0)
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
LINEAR_SOLVER_BULK
+
+
+
Linear solver used for the sparse column bulk block. This field is optional, the best available method is selected (i.e., sparse direct solver if possible). Valid values are:
+
+
+
\(\texttt{DENSE}\) Converts the sparse matrix into a banded matrix and uses regular LAPACK. Slow and memory intensive, but always available.
+
\(\texttt{UMFPACK}\) Uses the UMFPACK sparse direct solver (LU decomposition) from SuiteSparse. Fast, but has to be enabled when compiling and requires UMFPACK library.
+
\(\texttt{SUPERLU}\) Uses the SuperLU sparse direct solver (LU decomposition). Fast, but has to be enabled when compiling and requires SuperLU library.
Type of Gram-Schmidt orthogonalization, see IDAS guide Section~4.5.7.3, p.~41f. A value of 0 enables classical Gram-Schmidt, a value of 1 uses modified Gram-Schmidt.
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
MAX_KRYLOV
+
+
Defines the size of the Krylov subspace in the iterative linear GMRES solver (0: \(\texttt{MAX_KRYLOV} = \texttt{NCOL} \cdot \texttt{NRAD} \cdot \texttt{NCOMP} \cdot \texttt{NPARTYPE}\))
Number of chemical components in the chromatographic medium
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
USE_ANALYTIC_JACOBIAN
+
+
Determines whether analytically computed Jacobian matrix (faster) is used (value is 1) instead of Jacobians generated by algorithmic differentiation (slower, value is 0)
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
ADSORPTION_MODEL
+
+
Specifies the type of binding model of each particle type
Specifies the type of reaction model of each particle type (or of all particle types if length is 1). The model is configured in the subgroup \(\texttt{reaction_particle}\), or \(\texttt{reaction_particle_XXX}\) in case of disabled multiplexing.
Multiplexing mode of \(\texttt{REACTION_MODEL_PARTICLES}\). If set to 0, each particle type has a different reaction model and the length of \(\texttt{REACTION_MODEL_PARTICLES}\) is \(\texttt{NPARTYPE}\). If set to 1, all particle types share the same reaction model and the length of \(\texttt{REACTION_MODEL_PARTICLES}\) is 1. This field is optional and inferred from the length of \(\texttt{REACTION_MODEL_PARTICLES}\) if left out.
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
INIT_C
+
+
Initial concentrations for each component in the mobile phase
Initial concentrations for each bound state of each component in the bead solid phase of each particle type in type-component-major ordering. This field is optional and defaults to all 0.
Full state vector for initialization (optional, \(\texttt{INIT_C}\), \(\texttt{INIT_Q}\), and \(\texttt{INIT_VOLUME}\) will be ignored; if length is \(2\texttt{NDOF}\), then the second half is used for time derivatives)
+
Unit:\(various\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NDOF} / 2\texttt{NDOF}\)
+
+
+
+
+
CONST_SOLID_VOLUME
+
+
Volume of solid phase
+
Unit:\(\mathrm{m}^{3}\) (defaults to 0)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
FLOWRATE_FILTER
+
+
Flow rate of pure liquid without components (optional, defaults to \(\mathrm{m}^{3}\,\mathrm{s}^{-1}\))
+
Unit:\(\mathrm{m}^{3}\,\mathrm{s}^{-1}\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length:\(1 / \texttt{NSEC}\)
+
+
+
+
+
PAR_TYPE_VOLFRAC
+
+
Volume fractions of the particle types, have to sum to 1
+
+
+
Type: double
+
Range:\([0,1]\)
+
Length:\(\texttt{NPARTYPE}\)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/unit_operations/general_rate_model.html b/v5.0.1/interface/unit_operations/general_rate_model.html
new file mode 100644
index 000000000..60f92915a
--- /dev/null
+++ b/v5.0.1/interface/unit_operations/general_rate_model.html
@@ -0,0 +1,824 @@
+
+
+
+
+
+
+
+ General Rate Model — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Multiplexing mode of \(\texttt{ADSORPTION_MODEL}\). If set to \(0\), each particle type has a different binding model and the length of \(\texttt{ADSORPTION_MODEL}\) is \(\texttt{NPARTYPE}\). If set to \(1\), all particle types share the same binding model and the length of \(\texttt{ADSORPTION_MODEL}\) is \(1\). This field is optional and inferred from the length of \(\texttt{ADSORPTION_MODEL}\) if left out.
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
NBOUND
+
+
Number of bound states for each component in each particle type in type-major ordering
Specifies the type of reaction model of each particle type (or of all particle types if length is \(1\)). The model is configured in the subgroup \(\texttt{reaction_particle}\), or \(\texttt{reaction_particle_XXX}\) in case of disabled multiplexing.
Multiplexing mode of \(\texttt{REACTION_MODEL_PARTICLES}\). If set to \(0\), each particle type has a different reaction model and the length of \(\texttt{REACTION_MODEL_PARTICLES}\) is \(\texttt{NPARTYPE}\). If set to \(1\), all particle types share the same reaction model and the length of \(\texttt{REACTION_MODEL_PARTICLES}\) is \(1\). This field is optional and inferred from the length of \(\texttt{REACTION_MODEL_PARTICLES}\) if left out.
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
INIT_C
+
+
Initial concentrations for each component in the bulk mobile phase
Initial concentrations for each component in the bead liquid phase (optional, \(\texttt{INIT_C}\) is used if left out). The length of this field can be \(\texttt{NCOMP}\) (same values for each particle type) or \(\texttt{NPARTYPE} \cdot \texttt{NCOMP}\) Values for each particle type can only be given when \(\texttt{ADSORPTION_MODEL_MULTIPLEX}\) is \(0\). The ordering is type-major.
Initial concentrations for each bound state of each component in the bead solid phase. If \(\texttt{ADSORPTION_MODEL_MULTIPLEX}\) is \(0\), values for each particle type are required in type-component-major ordering (length is \(\texttt{NTOTALBND}\)). If \(\texttt{ADSORPTION_MODEL_MULTIPLEX}\) is \(1\), values for one particle type are required in component-major ordering (length is \(\sum_{i = 0}^{\texttt{NCOMP} - 1} \texttt{NBND}_i\)).
Full state vector for initialization (optional, \(\texttt{INIT_C}\), \(\texttt{INIT_CP}\), and \(\texttt{INIT_Q}\) will be ignored; if length is \(2\texttt{NDOF}\), then the second half is used for time derivatives)
Multiplexing mode of \(\texttt{COL_DISPERSION}\). Determines whether \(\texttt{COL_DISPERSION}\) is treated as component- and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{COL_DISPERSION}\). Valid modes are:
+
+
Component-independent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(1\)
+
Component-dependent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP}\)
+
Component-independent, section-dependent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NSEC}\)
+
Component-dependent, section-dependent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
COL_LENGTH
+
+
Column length
+
Unit:\(\mathrm{m}\)
+
+
+
Type: double
+
Range:\(> 0\)
+
Length: 1
+
+
+
+
+
COL_POROSITY
+
+
Column porosity
+
+
+
Type: double
+
Range:\((0,1]\)
+
Length: 1
+
+
+
+
+
FILM_DIFFUSION
+
+
Film diffusion coefficients for each component of each particle type
+
Unit:\(\mathrm{m}\,\mathrm{s}^{-1}\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: see \(\texttt{FILM_DIFFUSION_MULTIPLEX}\)
+
+
+
+
+
FILM_DIFFUSION_MULTIPLEX
+
+
Multiplexing mode of \(\texttt{FILM_DIFFUSION}\). Determines whether \(\texttt{FILM_DIFFUSION}\) is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{FILM_DIFFUSION}\). Valid modes are:
+
+
Component-dependent, type-independent, section-independent; length of \(\texttt{FILM_DIFFUSION}\) is \(\texttt{NCOMP}\)
+
Component-dependent, type-independent, section-dependent; length of \(\texttt{FILM_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
+
Component-dependent, type-dependent, section-independent; length of \(\texttt{FILM_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE}\); ordering is type-major
+
Component-dependent, type-dependent, section-dependent; length of \(\texttt{FILM_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}\); ordering is section-type-major
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
PAR_POROSITY
+
+
Particle porosity of all particle types or for each particle type
+
+
+
Type: double
+
Range:\((0,1]\)
+
Length:\(1 / \texttt{NPARTYPE}\)
+
+
+
+
+
PAR_RADIUS
+
+
Particle radius of all particle types or for each particle type
+
Unit:\(\mathrm{m}\)
+
+
+
Type: double
+
Range:\(>0\)
+
Length:\(1 / \texttt{NPARTYPE}\)
+
+
+
+
+
PAR_CORERADIUS
+
+
Particle core radius of all particle types or for each particle type (optional, defaults to \(\mathrm{m}\))
+
Unit:\(\mathrm{m}\)
+
+
+
Type: double
+
Range:\([0, \texttt{PAR_RADIUS})\)
+
Length:\(1 / \texttt{NPARTYPE}\)
+
+
+
+
+
PORE_ACCESSIBILITY
+
+
Pore accessibility factor of each component in each particle type (optional, defaults to \(1\)).
+Note: Should not be used in combination with any binding model!
+
+
+
Type: double
+
Range:\((0, 1]\)
+
Length: see \(\texttt{PORE_ACCESSIBILITY_MULTIPLEX}\)
+
+
+
+
+
PORE_ACCESSIBILITY_MULTIPLEX
+
+
Multiplexing mode of \(\texttt{PORE_ACCESSIBILITY}\). Determines whether \(\texttt{PORE_ACCESSIBILITY}\) is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{PORE_ACCESSIBILITY}\). Valid modes are:
+0. Component-dependent, type-independent, section-independent; length of \(\texttt{PORE_ACCESSIBILITY}\) is \(\texttt{NCOMP}\)
+1. Component-dependent, type-independent, section-dependent; length of \(\texttt{PORE_ACCESSIBILITY}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
+2. Component-dependent, type-dependent, section-independent; length of \(\texttt{PORE_ACCESSIBILITY}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE}\); ordering is type-major
+3. Component-dependent, type-dependent, section-dependent; length of \(\texttt{PORE_ACCESSIBILITY}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}\); ordering is section-type-major
+
+
+
Type: int
+
Range:\(\{0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
PAR_DIFFUSION
+
+
Effective particle diffusion coefficients of each component in each particle type
Multiplexing mode of \(\texttt{PAR_DIFFUSION}\). Determines whether \(\texttt{PAR_DIFFUSION}\) is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{PAR_DIFFUSION}\). Valid modes are:
+
+
Component-dependent, type-independent, section-independent; length of \(\texttt{PAR_DIFFUSION}\) is \(\texttt{NCOMP}\)
+
Component-dependent, type-independent, section-dependent; length of \(\texttt{PAR_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
+
Component-dependent, type-dependent, section-independent; length of \(\texttt{PAR_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE}\); ordering is type-major
+
Component-dependent, type-dependent, section-dependent; length of \(\texttt{PAR_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}\); ordering is section-type-major
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
PAR_SURFDIFFUSION
+
+
Particle surface diffusion coefficients of each bound state of each component in each particle type (optional, defaults to all 0 \(\mathrm{m}_{\mathrm{SP}}^{2}\,\mathrm{s}^{-1}\))
Length: see \(\texttt{PAR_SURFDIFFUSION_MULTIPLEX}\)
+
+
+
+
+
+
PAR_SURFDIFFUSION_MULTIPLEX
Multiplexing mode of \(\texttt{PAR_SURFDIFFUSION}\). Determines whether \(\texttt{PAR_SURFDIFFUSION}\) is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{PAR_SURFDIFFUSION}\). Valid modes are:
+
+
Component-dependent, type-independent, section-independent; length of \(\texttt{PAR_SURFDIFFUSION}\) is \(\texttt{NBND}\); ordering is component-major
+
Component-dependent, type-independent, section-dependent; length of \(\texttt{PAR_SURFDIFFUSION}\) is \(\texttt{NBND} \cdot \texttt{NSEC}\); ordering is section-component-major
+
Component-dependent, type-dependent, section-independent; length of \(\texttt{PAR_SURFDIFFUSION}\) is \(\texttt{NTOTALBND}\); ordering is type-component-major
+
Component-dependent, type-dependent, section-dependent; length of \(\texttt{PAR_SURFDIFFUSION}\) is \(\texttt{NTOTALBND} \cdot \texttt{NSEC}\); ordering is section-type-component-major
+
+
+
PAR_SURFDIFFUSION_MULTIPLEX
+
+
Type: int
+
Range:\(\{ 0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
+
PAR_SURFDIFFUSION_DEP
+
+
Parameter dependence of \(\texttt{PAR_SURFDIFFUSION}\), please refer to Parameter Dependencies, section parameter-state dependencies, for more information.
Number of particle types. Optional, inferred from the length of \(\texttt{NPAR}\) or \(\texttt{NBOUND}\) if left out.
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
PAR_GEOM
+
+
Specifies the particle geometry for all or each particle type. Valid values are \(\texttt{SPHERE}\), \(\texttt{CYLINDER}\), \(\texttt{SLAB}\). Optional, defaults to \(\texttt{SPHERE}\).
+
+
+
Type: string
+
Length:\(1\) / \(\texttt{NPARTYPE}\)
+
+
+
+
+
PAR_TYPE_VOLFRAC
+
+
Volume fractions of the particle types. The volume fractions can be set for all axial cells together or for each individual axial cell. For each cell, the volume fractions have to sum to \(1\). In case of a spatially inhomogeneous setting, the data is expected in cell-major ordering and the \(\texttt{SENS_SECTION}\) field is used for indexing the axial cell when specifying parameter sensitivities. This field is optional in case of only one particle type.
Group /input/model/unit_XXX/discretization - UNIT_TYPE - GENERAL_RATE_MODEL¶
+
USE_ANALYTIC_JACOBIAN
+
+
Determines whether analytically computed Jacobian matrix (faster) is used (value is 1) instead of Jacobians generated by algorithmic differentiation (slower, value is 0)
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
PAR_DISC_TYPE
+
+
Specifies the discretization scheme inside the particles for all or each particle type. Valid values are \(\texttt{EQUIDISTANT_PAR}\), \(\texttt{EQUIVOLUME_PAR}\), and \(\texttt{USER_DEFINED_PAR}\).
+
+
+
Type: string
+
Length:\(1\) / \(\texttt{NPARTYPE}\)
+
+
+
+
+
PAR_DISC_VECTOR
+
+
Node coordinates for the cell boundaries (ignored if \(\texttt{PAR_DISC_TYPE} \neq \texttt{USER_DEFINED_PAR}\)). The coordinates are relative and have to include the endpoints \(0\) and \(1\). They are later linearly mapped to the true radial range \([r_{c,j}, r_{p,j}]\). The coordinates for each particle type are appended to one long vector in type-major ordering.
CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Each method has it’s own set of input fields.
+While both methods approximate the same solution to the same underlying model, they may differ in terms of computational performance.
+With our currently implemented variants of FV and DG, FV perform better for solutions with steep gradients or discontinuities, while DG can be much faster for rather smooth solutions.
+For the same number of discrete points, DG will generally be slower but often more accurate.
+
For further information on the choice of discretization methods and their parameters, see Spatial discretization methods.
+
SPATIAL_METHOD
+
+
Spatial discretization method. Optional, defaults to \(\texttt{FV}\)
Number of particle (radial) discretization points for each particle type
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length:\(1\) / \(\texttt{NPARTYPE}\)
+
+
+
+
+
PAR_BOUNDARY_ORDER
+
+
Order of accuracy of outer particle boundary condition. Optional, defaults to \(2\).
+
+
+
Type: int
+
Range:\(\{ 1,2 \}\)
+
Length: 1
+
+
+
+
+
RECONSTRUCTION
+
+
Type of reconstruction method for fluxes
+
+
+
Type: string
+
Range:\(\texttt{WENO}\)
+
Length: 1
+
+
+
+
+
GS_TYPE
+
+
Type of Gram-Schmidt orthogonalization, see IDAS guide Section 4.5.7.3, p. 41f. A value of \(0\) enables classical Gram-Schmidt, a value of 1 uses modified Gram-Schmidt.
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
MAX_KRYLOV
+
+
Defines the size of the Krylov subspace in the iterative linear GMRES solver (0: \(\texttt{MAX_KRYLOV} = \texttt{NCOL} \cdot \texttt{NCOMP} \cdot \texttt{NPARTYPE}\))
Maximum number of restarts in the GMRES algorithm. If lack of memory is not an issue, better use a larger Krylov space than restarts.
+
+
+
Type: int
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
SCHUR_SAFETY
+
+
Schur safety factor; Influences the tradeoff between linear iterations and nonlinear error control; see IDAS guide Section~2.1 and 5.
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: 1
+
+
+
+
+
FIX_ZERO_SURFACE_DIFFUSION
+
+
Determines whether the surface diffusion parameters \(\texttt{PAR_SURFDIFFUSION}\) are fixed if the parameters are zero. If the parameters are fixed to zero (\(\texttt{FIX_ZERO_SURFACE_DIFFUSION} = 1\), \(\texttt{PAR_SURFDIFFUSION} = 0\)), the parameters must not become non-zero during this or subsequent simulation runs. The internal data structures are optimized for a more efficient simulation. This field is optional and defaults to \(0\) (optimization disabled in favor of flexibility).
DG polynomial degree. Optional, defaults to 4 and \(N_d \in \{3, 4, 5\}\) is recommended. The total number of axial discrete points is given by (POLYDEG + 1 ) * NELEM
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
NELEM
+
+
Number of axial column discretization DG cellselements. The total number of axial discrete points is given by (POLYDEG + 1 ) * NELEM
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
NCOL
+
+
Number of axial discrete points. Optional and ignored if NELEM is defined. Otherwise, used to calculate NELEM = \(\lfloor\)NCOL / (POLYDEG + 1 ) \(\rfloor\)
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
EXACT_INTEGRATION
+
+
Specifies the DG integration variant. Optional, defaults to 0
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
PAR_POLYDEG
+
+
DG particle (radial) polynomial degree. Optional, defaults to 3. The total number of particle (radial) discrete points is given by (PARPOLYDEG + 1 ) * PAR_NELEM.
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
PAR_NELEM
+
+
Number of particle (radial) discretization DG elements for each particle type. For the particle discretization, it is usually most performant to fix PAR_NELEM = 1 and to increase the polynomial degree for more accuracy.
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length:\(1\) / \(\texttt{NPARTYPE}\)
+
+
+
+
When using the DG method for the GRM, we recommend specifying USE_MODIFIED_NEWTON=1 in Group /solver/time_integrator, i.e. to use the modified Newton method to solve the linear system within the time integrator.
+For further discretization parameters, see also Nonlinear solver for consistent initialization.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/unit_operations/index.html b/v5.0.1/interface/unit_operations/index.html
new file mode 100644
index 000000000..063322751
--- /dev/null
+++ b/v5.0.1/interface/unit_operations/index.html
@@ -0,0 +1,199 @@
+
+
+
+
+
+
+
+ Unit Operations — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Multiplexing mode of \(\texttt{ADSORPTION_MODEL}\). If set to \(0\), each particle type has a different binding model and the length of \(\texttt{ADSORPTION_MODEL}\) is \(\texttt{NPARTYPE}\). If set to \(1\), all particle types share the same binding model and the length of \(\texttt{ADSORPTION_MODEL}\) is \(1\). This field is optional and inferred from the length of \(\texttt{ADSORPTION_MODEL}\) if left out.
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
+
NBOUND
+
+
Number of bound states for each component in each particle type in type-major ordering
Specifies the type of reaction model of each particle type (or of all particle types if length is \(1\)). The model is configured in the subgroup \(\texttt{reaction_particle}\), or \(\texttt{reaction_particle_XXX}\) in case of disabled multiplexing.
Multiplexing mode of \(\texttt{REACTION_MODEL_PARTICLES}\). If set to \(0\), each particle type has a different reaction model and the length of \(\texttt{REACTION_MODEL_PARTICLES}\) is \(\texttt{NPARTYPE}\). If set to \(1\), all particle types share the same reaction model and the length of \(\texttt{REACTION_MODEL_PARTICLES}\) is \(1\). This field is optional and inferred from the length of \(\texttt{REACTION_MODEL_PARTICLES}\) if left out.
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
INIT_C
Initial concentrations for each component in the bulk mobile phase
Initial concentrations for each component in the bead liquid phase (optional, \(\texttt{INIT_C}\) is used if left out). The length of this field can be \(\texttt{NCOMP}\) (same values for each particle type) or \(\texttt{NPARTYPE} \cdot \texttt{NCOMP}\) Values for each particle type can only be given when \(\texttt{ADSORPTION_MODEL_MULTIPLEX}\) is \(0\). The ordering is type-major.
Initial concentrations for each bound state of each component in the bead solid phase. If \(\texttt{ADSORPTION_MODEL_MULTIPLEX}\) is \(0\), values for each particle type are required in type-component-major ordering (length is \(\texttt{NTOTALBND}\)). If \(\texttt{ADSORPTION_MODEL_MULTIPLEX}\) is \(1\), values for one particle type are required in component-major ordering (length is \(\sum_{i = 0}^{\texttt{NCOMP} - 1} \texttt{NBND}_i\)).
Full state vector for initialization (optional, \(\texttt{INIT_C}\), \(\texttt{INIT_CP}\), and \(\texttt{INIT_Q}\) will be ignored; if length is \(2\texttt{NDOF}\), then the second half is used for time derivatives)
Multiplexing mode of \(\texttt{COL_DISPERSION}\). Determines whether \(\texttt{COL_DISPERSION}\) is treated as component- and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{COL_DISPERSION}\). Valid modes are:
+
+
+
Component-independent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(1\)
+
Component-dependent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP}\)
+
Component-independent, section-dependent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NSEC}\)
+
Component-dependent, section-dependent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
+
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
+
COL_LENGTH
Column length
+
Unit:\(\mathrm{m}\)
+
+
+
Type: double
+
Range:\(> 0\)
+
Length: 1
+
+
+
+
+
+
COL_POROSITY
+
+
Column porosity
+
+
+
Type: double
+
Range:\((0,1]\)
+
Length: 1
+
+
+
+
+
FILM_DIFFUSION
+
+
Film diffusion coefficients for each component of each particle type
+
Unit:\(\mathrm{m}\,\mathrm{s}^{-1}\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: see \(\texttt{FILM_DIFFUSION_MULTIPLEX}\)
+
+
+
+
+
FILM_DIFFUSION_MULTIPLEX
+
+
+
Multiplexing mode of \(\texttt{FILM_DIFFUSION}\). Determines whether \(\texttt{FILM_DIFFUSION}\) is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{FILM_DIFFUSION}\). Valid modes are:
+
+
+
Component-dependent, type-independent, section-independent; length of \(\texttt{FILM_DIFFUSION}\) is \(\texttt{NCOMP}\)
+
Component-dependent, type-independent, section-dependent; length of \(\texttt{FILM_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
+
Component-dependent, type-dependent, section-independent; length of \(\texttt{FILM_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE}\); ordering is type-major
+
Component-dependent, type-dependent, section-dependent; length of \(\texttt{FILM_DIFFUSION}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}\); ordering is section-type-major
+
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
+
PAR_POROSITY
+
+
Particle porosity of all particle types or for each particle type
+
+
+
Type: double
+
Range:\((0,1]\)
+
Length:\(1 / \texttt{NPARTYPE}\)
+
+
+
+
+
PAR_RADIUS
+
+
Particle radius of all particle types or for each particle type
+
Unit:\(\mathrm{m}\)
+
+
+
Type: double
+
Range:\(>0\)
+
Length:\(1 / \texttt{NPARTYPE}\)
+
+
+
+
+
PORE_ACCESSIBILITY
+
+
Pore accessibility factor of each component in each particle type (optional, defaults to \(1\)).
+Note: Should not be used in combination with any binding model!
+
+
+
Type: double
+
Range:\((0, 1]\)
+
Length: see \(\texttt{PORE_ACCESSIBILITY_MULTIPLEX}\)
+
+
+
+
+
+
PORE_ACCESSIBILITY_MULTIPLEX
+
Multiplexing mode of \(\texttt{PORE_ACCESSIBILITY}\). Determines whether \(\texttt{PORE_ACCESSIBILITY}\) is treated as component-, type-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{PORE_ACCESSIBILITY}\). Valid modes are:
+
+
+
Component-dependent, type-independent, section-independent; length of \(\texttt{PORE_ACCESSIBILITY}\) is \(\texttt{NCOMP}\)
+
Component-dependent, type-independent, section-dependent; length of \(\texttt{PORE_ACCESSIBILITY}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
+
Component-dependent, type-dependent, section-independent; length of \(\texttt{PORE_ACCESSIBILITY}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE}\); ordering is type-major
+
Component-dependent, type-dependent, section-dependent; length of \(\texttt{PORE_ACCESSIBILITY}\) is \(\texttt{NCOMP} \cdot \texttt{NPARTYPE} \cdot \texttt{NSEC}\); ordering is section-type-major
Number of particle types. Optional, inferred from the length of \(\texttt{NBOUND}\) if left out.
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
PAR_GEOM
+
+
Specifies the particle geometry for all or each particle type. Valid values are \(\texttt{SPHERE}\), \(\texttt{CYLINDER}\), \(\texttt{SLAB}\). Optional, defaults to \(\texttt{SPHERE}\).
+
+
+
Type: string
+
Length:\(1\) / \(\texttt{NPARTYPE}\)
+
+
+
+
+
PAR_TYPE_VOLFRAC
+
+
Volume fractions of the particle types. The volume fractions can be set for all axial cells together or for each individual axial cell. For each cell, the volume fractions have to sum to \(1\). In case of a spatially inhomogeneous setting, the data is expected in cell-major ordering and the \(\texttt{SENS_SECTION}\) field is used for indexing the axial cell when specifying parameter sensitivities. This field is optional in case of only one particle type.
CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Each method has it’s own set of input fields.
+While both methods approximate the same solution to the same underlying model, they may differ in terms of computational performance.
+With our currently implemented variants of FV and DG, FV perform better for solutions with steep gradients or discontinuities, while DG can be much faster for rather smooth solutions.
+For the same number of discrete points, DG will generally be slower but often more accurate.
+
For further information on the choice of discretization methods and their parameters, see Spatial discretization methods.
+
SPATIAL_METHOD
+
+
Spatial discretization method. Optional, defaults to \(\texttt{FV}\)
Type of Gram-Schmidt orthogonalization, see IDAS guide Section~4.5.7.3, p.~41f. A value of \(0\) enables classical Gram-Schmidt, a value of 1 uses modified Gram-Schmidt.
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
MAX_KRYLOV
+
+
Defines the size of the Krylov subspace in the iterative linear GMRES solver (0: \(\texttt{MAX_KRYLOV} = \texttt{NCOL} \cdot \texttt{NCOMP} \cdot \texttt{NPARTYPE}\))
DG polynomial degree. Optional, defaults to 4 and \(N_d \in \{3, 4, 5\}\) is recommended. The total number of axial discrete points is given by (POLYDEG + 1 ) * NELEM
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
NELEM
+
+
Number of axial column discretization DG cellselements. The total number of axial discrete points is given by (POLYDEG + 1 ) * NELEM
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
NCOL
+
+
Number of axial discrete points. Optional and ignored if NELEM is defined. Otherwise, used to calculate NELEM = \(\lfloor\)NCOL / (POLYDEG + 1 ) \(\rfloor\)
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
EXACT_INTEGRATION
+
+
Specifies the DG integration variant. Optional, defaults to 0
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
When using the DG method for the LRMP, we recommend specifying USE_MODIFIED_NEWTON=1 in Group /solver/time_integrator, i.e. to use the modified Newton method to solve the linear system within the time integrator.
+For further discretization parameters, see also Nonlinear solver for consistent initialization.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/interface/unit_operations/lumped_rate_model_without_pores.html b/v5.0.1/interface/unit_operations/lumped_rate_model_without_pores.html
new file mode 100644
index 000000000..8b8aca541
--- /dev/null
+++ b/v5.0.1/interface/unit_operations/lumped_rate_model_without_pores.html
@@ -0,0 +1,448 @@
+
+
+
+
+
+
+
+ Lumped Rate Model Without Pores — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Full state vector for initialization (optional, \(\texttt{INIT_C}\) and \(\texttt{INIT_Q}\) will be ignored; if length is \(2\texttt{NDOF}\), then the second half is used for time derivatives)
Multiplexing mode of \(\texttt{COL_DISPERSION}\). Determines whether \(\texttt{COL_DISPERSION}\) is treated as component- and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{COL_DISPERSION}\). Valid modes are:
+
+
+
Component-independent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(1\)
+
Component-dependent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP}\)
+
Component-independent, section-dependent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NSEC}\)
+
Component-dependent, section-dependent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
Group /input/model/unit_XXX/discretization - UNIT_TYPE = LUMPED_RATE_MODEL_WITHOUT_PORES¶
+
USE_ANALYTIC_JACOBIAN
+
+
Determines whether analytically computed Jacobian matrix (faster) is used (value is 1) instead of Jacobians generated by algorithmic differentiation (slower, value is 0)
CADET offers two spatial discretization methods: Finite Volumes (FV) and Discontinuous Galerkin (DG). Each method has it’s own set of input fields.
+While both methods approximate the same solution to the same underlying model, they may differ in terms of computational performance.
+With our currently implemented variants of FV and DG, FV perform better for solutions with steep gradients or discontinuities, while DG can be much faster for rather smooth solutions.
+For the same number of discrete points, DG will generally be slower but often more accurate.
+
For further information on the choice of discretization methods and their parameters, see Spatial discretization methods.
+
SPATIAL_METHOD
+
+
Spatial discretization method. Optional, defaults to \(\texttt{FV}\)
DG polynomial degree. Optional, defaults to 4 and \(N_d \in \{3, 4, 5\}\) is recommended. The total number of axial discrete points is given by (POLYDEG + 1 ) * NELEM
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
NELEM
+
+
Number of axial column discretization DG cellselements. The total number of axial discrete points is given by (POLYDEG + 1 ) * NELEM
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
NCOL
+
+
Number of axial discrete points. Optional and ignored if NELEM is defined. Otherwise, used to calculate NELEM = \(\lfloor\)NCOL / (POLYDEG + 1 ) \(\rfloor\)
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
EXACT_INTEGRATION
+
+
Specifies the DG integration variant. Optional, defaults to 0
Initial concentrations for each component in all channels of the bulk mobile phase (length \(\texttt{NCOMP}\)), or for each component in each channel (length \(\texttt{NCOMP} \cdot \texttt{NCHANNEL}\), ordering channel-major)
Full state vector for initialization (optional, \(\texttt{INIT_C}\) will be ignored; if length is \(2\texttt{NDOF}\), then the second half is used for time derivatives)
+
Unit:\(various\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(\texttt{NDOF} / 2\texttt{NDOF}\)
+
+
+
+
+
COL_DISPERSION
+
+
Axial dispersion coefficient. In case of a spatially inhomogeneous setting, the \(\texttt{SENS_PARTYPE}\) field is used for indexing the channel when specifying parameter sensitivities.
+
Unit:\(\mathrm{m}^{2}\,\mathrm{s}^{-1}\)
+
+
+
Type: double
+
Range:\(\geq 0\)
+
Length: see \(\texttt{COL_DISPERSION_MULTIPLEX}\)
+
+
+
+
+
COL_DISPERSION_MULTIPLEX
+
+
+
Multiplexing mode of \(\texttt{COL_DISPERSION}\). Determines whether \(\texttt{COL_DISPERSION}\) is treated as component-, channel-, and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{COL_DISPERSION}\). Valid modes are:
+
+
+
Component-independent, channel-independent, section-independent; length of \(\texttt{COL_DISPERSION}\) is 1
+
Component-independent, channel-dependent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCHANNEL}\)
+
Component-dependent, channel-independent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP}\)
+
Component-dependent, channel-dependent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP} \cdot \texttt{NCHANNEL}\); ordering is channel-major
+
Component-independent, channel-independent, section-dependent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NSEC}\)
+
Component-independent, channel-dependent, section-dependent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCHANNEL} \cdot \texttt{NSEC}\); ordering is section-major
+
Component-dependent, channel-independent, section-independent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP} \cdot \texttt{NSEC}\); ordering is section-major
+
Component-dependent, channel-dependent, section-dependent; length of \(\texttt{COL_DISPERSION}\) is \(\texttt{NCOMP} \cdot \texttt{NCHANNEL} \cdot \texttt{NSEC}\); ordering is section-channel-major
+
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 7 \}\)
+
Length: 1
+
+
+
+
+
+
COL_LENGTH
+
+
Column length
+
Unit:\(\mathrm{m}\)
+
+
+
Type: double
+
Range:\(> 0\)
+
Length: 1
+
+
+
+
+
VELOCITY
+
+
Velocity
+
Unit:\(\mathrm{m}\,\mathrm{s}^{-1}\)
+
Indicates flow direction in each channel (forward if value is positive, backward if value is negative), see Section Specification of flow rate / velocity and direction). In case of a spatially inhomogeneous setting, the \(\texttt{SENS_PARTYPE}\) field is used for indexing the channel when specifying parameter sensitivities.
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length: see \(\texttt{VELOCITY_MULTIPLEX}\)
+
+
+
+
+
VELOCITY_MULTIPLEX
+
+
+
Multiplexing mode of \(\texttt{VELOCITY}\). Determines whether \(\texttt{VELOCITY}\) is treated as channel- and/or section-independent. This field is optional. When left out, multiplexing behavior is inferred from the length of \(\texttt{VELOCITY}\). Valid modes are:
+
+
+
Channel-independent, section-independent; length of \(\texttt{VELOCITY}\) is 1
+
Channel-dependent, section-independent; length of \(\texttt{VELOCITY}\) is \(\texttt{NCHANNEL}\)
+
Section-dependent; length of \(\texttt{VELOCITY}\) is \(\texttt{NSEC}\)
+
Channel-dependent, section-dependent; length of \(\texttt{VELOCITY}\) is \(\texttt{NCHANNEL} \cdot \texttt{NSEC}\); ordering is section-major
+
+
+
+
+
Type: int
+
Range:\(\{0, \dots, 3 \}\)
+
Length: 1
+
+
+
+
+
+
EXCHANGE_MATRIX
+
+
+
Exchange matrix
+
Unit:\(\mathrm{s}^{-1}\)
+
Ordered list containing all exchange rates \(e^k_{ij}\) for component \(k\) from compartment \(i\) to \(j\) based on the exchange matrix \(E^k\). The vector ordering is source channel - destination channel - component (i.e. i-j-k) major.
Group /input/model/unit_XXX/discretization - UNIT_TYPE = MULTI_CHANNEL_TRANSPORT¶
+
USE_ANALYTIC_JACOBIAN
+
+
Determines whether analytically computed Jacobian matrix (faster) is used (value is 1) instead of Jacobians generated by algorithmic differentiation (slower, value is 0)
+
+
+
Type: int
+
Range:\(\{0, 1\}\)
+
Length: 1
+
+
+
+
+
NCOL
+
+
Number of axial column discretization cells
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
LINEAR_SOLVER_BULK
+
+
+
Linear solver used for the sparse column bulk block. This field is optional, the best available method is selected (i.e., sparse direct solver if possible). Valid values are:
+
+
+
\(\texttt{DENSE}\) Converts the sparse matrix into a banded matrix and uses regular LAPACK. Slow and memory intensive, but always available.
+
\(\texttt{UMFPACK}\) Uses the UMFPACK sparse direct solver (LU decomposition) from SuiteSparse. Fast, but has to be enabled when compiling and requires UMFPACK library.
+
\(\texttt{SUPERLU}\) Uses the SuperLU sparse direct solver (LU decomposition). Fast, but has to be enabled when compiling and requires SuperLU library.
Radial flow models are available for the LRM, LRMP and GRM.
+The configurations specified here complement the description for the respective model, i.e. please additionally refer to Lumped Rate Model Without Pores or Lumped rate model with pores or General Rate Model, respectively.
+If input variables are described in both files, then only the description provided here applies for radial flow models.
+
The unit type input must be specified with the prefix \(\texttt{RADIAL_}\) followed by the respective transport model name.
+In this document, we specify the unit type as the radial GRM, but the LRM and LRMP are also available and the changes to input variables are the same for all three models.
+
+
Group /input/model/unit_XXX - UNIT_TYPE - RADIAL_GENERAL_RATE_MODEL¶
In addition to the multiplex specification (e.g. component dependency, see General rate model (GRM)), the dispersion coefficient for radial flow model usually depends on other parameters.
+Parameter dependencies are described here Parameter Dependencies.
+
+
+
COL_RADIUS_INNER
+
+
Inner column radius
+
Unit:\(\mathrm{m}\)
+
+
+
Type: double
+
Range:\(> 0\)
+
Length: 1
+
+
+
+
+
COL_RADIUS_OUTER
+
+
Outer column radius
+
Unit:\(\mathrm{m}\)
+
+
+
Type: double
+
Range:\(> 0\)
+
Length: 1
+
+
+
+
+
CROSS_SECTION_AREA
+
+
Is not explicitly specified. Both the inner and outer cross section areas are implicitly given by the volumetric flow rates and either the velocity coefficient or column length
Interstitial velocity coefficient of the mobile phase (optional \(\texttt{COL_LENGTH}\) is present, see Section Specification of flow rate / velocity and direction).
+This input replaces the VELOCITY field, which is used for axial flow models. The distinction is made to emphasize that radial flow models do not incorporate a global velocity but a variable velocity field that depends on the spatial position, for details see Section Radial flow GRM.
+
Unit:\(\mathrm{m}\,\mathrm{s}^{-1}\)
+
+
+
Type: double
+
Range:\(\mathbb{R}\)
+
Length:\(1 / \texttt{NSEC}\)
+
+
+
+
+
+
+
Group /input/model/unit_XXX/discretization - UNIT_TYPE - RADIAL_GENERAL_RATE_MODEL¶
+
NCOL
+
+
Number of radial column discretization points
+
+
+
Type: int
+
Range:\(\geq 1\)
+
Length: 1
+
+
+
+
+
Currently, there is only a first order FV spatial discretization available. Higher order spatial discretizations are planned for the future.
+Accordingly, the following specifications can be left out for radial flow models.
+
RECONSTRUCTION
+
+
Type of reconstruction method for fluxes
+
+
+
Type: string
+
Range:\(\texttt{NONE}\)
+
Length: 1
+
+
+
+
+
Parameters specified under flux_restruction_methods can also be ignored.
GNU GENERAL PUBLIC LICENSE
+ Version 3, 29 June 2007
+ Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+ Preamble
+ The GNU General Public License is a free, copyleft license for
+software and other kinds of works.
+ The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works. By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users. We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors. You can apply it to
+your programs, too.
+ When we speak of free software, we are referring to freedom, not
+price. Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+ To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights. Therefore, you have
+certain responsibilities if you distribute copies of the software, or if
+you modify it: responsibilities to respect the freedom of others.
+ For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received. You must make sure that they, too, receive
+or can get the source code. And you must show them these terms so they
+know their rights.
+ Developers that use the GNU GPL protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+ For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software. For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+ Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the manufacturer
+can do so. This is fundamentally incompatible with the aim of
+protecting users' freedom to change the software. The systematic
+pattern of such abuse occurs in the area of products for individuals to
+use, which is precisely where it is most unacceptable. Therefore, we
+have designed this version of the GPL to prohibit the practice for those
+products. If such problems arise substantially in other domains, we
+stand ready to extend this provision to those domains in future versions
+of the GPL, as needed to protect the freedom of users.
+ Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary. To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+ The precise terms and conditions for copying, distribution and
+modification follow.
+ TERMS AND CONDITIONS
+ 0. Definitions.
+ "This License" refers to version 3 of the GNU General Public License.
+ "Copyright" also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+ "The Program" refers to any copyrightable work licensed under this
+License. Each licensee is addressed as "you". "Licensees" and
+"recipients" may be individuals or organizations.
+ To "modify" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy. The resulting work is called a "modified version" of the
+earlier work or a work "based on" the earlier work.
+ A "covered work" means either the unmodified Program or a work based
+on the Program.
+ To "propagate" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy. Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+ To "convey" a work means any kind of propagation that enables other
+parties to make or receive copies. Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+ An interactive user interface displays "Appropriate Legal Notices"
+to the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License. If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+ 1. Source Code.
+ The "source code" for a work means the preferred form of the work
+for making modifications to it. "Object code" means any non-source
+form of a work.
+ A "Standard Interface" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+ The "System Libraries" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form. A
+"Major Component", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+ The "Corresponding Source" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities. However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work. For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+ The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+ The Corresponding Source for a work in source code form is that
+same work.
+ 2. Basic Permissions.
+ All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met. This License explicitly affirms your unlimited
+permission to run the unmodified Program. The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work. This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+ You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force. You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright. Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+ Conveying under any other circumstances is permitted solely under
+the conditions stated below. Sublicensing is not allowed; section 10
+makes it unnecessary.
+ 3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+ No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+ When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+ 4. Conveying Verbatim Copies.
+ You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+ You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+ 5. Conveying Modified Source Versions.
+ You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+ a) The work must carry prominent notices stating that you modified
+ it, and giving a relevant date.
+ b) The work must carry prominent notices stating that it is
+ released under this License and any conditions added under section
+ 7. This requirement modifies the requirement in section 4 to
+ "keep intact all notices".
+ c) You must license the entire work, as a whole, under this
+ License to anyone who comes into possession of a copy. This
+ License will therefore apply, along with any applicable section 7
+ additional terms, to the whole of the work, and all its parts,
+ regardless of how they are packaged. This License gives no
+ permission to license the work in any other way, but it does not
+ invalidate such permission if you have separately received it.
+ d) If the work has interactive user interfaces, each must display
+ Appropriate Legal Notices; however, if the Program has interactive
+ interfaces that do not display Appropriate Legal Notices, your
+ work need not make them do so.
+ A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+"aggregate" if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit. Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+ 6. Conveying Non-Source Forms.
+ You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+ a) Convey the object code in, or embodied in, a physical product
+ (including a physical distribution medium), accompanied by the
+ Corresponding Source fixed on a durable physical medium
+ customarily used for software interchange.
+ b) Convey the object code in, or embodied in, a physical product
+ (including a physical distribution medium), accompanied by a
+ written offer, valid for at least three years and valid for as
+ long as you offer spare parts or customer support for that product
+ model, to give anyone who possesses the object code either (1) a
+ copy of the Corresponding Source for all the software in the
+ product that is covered by this License, on a durable physical
+ medium customarily used for software interchange, for a price no
+ more than your reasonable cost of physically performing this
+ conveying of source, or (2) access to copy the
+ Corresponding Source from a network server at no charge.
+ c) Convey individual copies of the object code with a copy of the
+ written offer to provide the Corresponding Source. This
+ alternative is allowed only occasionally and noncommercially, and
+ only if you received the object code with such an offer, in accord
+ with subsection 6b.
+ d) Convey the object code by offering access from a designated
+ place (gratis or for a charge), and offer equivalent access to the
+ Corresponding Source in the same way through the same place at no
+ further charge. You need not require recipients to copy the
+ Corresponding Source along with the object code. If the place to
+ copy the object code is a network server, the Corresponding Source
+ may be on a different server (operated by you or a third party)
+ that supports equivalent copying facilities, provided you maintain
+ clear directions next to the object code saying where to find the
+ Corresponding Source. Regardless of what server hosts the
+ Corresponding Source, you remain obligated to ensure that it is
+ available for as long as needed to satisfy these requirements.
+ e) Convey the object code using peer-to-peer transmission, provided
+ you inform other peers where the object code and Corresponding
+ Source of the work are being offered to the general public at no
+ charge under subsection 6d.
+ A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+ A "User Product" is either (1) a "consumer product", which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or (2) anything designed or sold for incorporation
+into a dwelling. In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage. For a particular
+product received by a particular user, "normally used" refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product. A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+ "Installation Information" for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source. The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+ If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information. But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+ The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed. Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+ Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+ 7. Additional Terms.
+ "Additional permissions" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law. If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+ When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it. (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.) You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+ Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+ a) Disclaiming warranty or limiting liability differently from the
+ terms of sections 15 and 16 of this License; or
+ b) Requiring preservation of specified reasonable legal notices or
+ author attributions in that material or in the Appropriate Legal
+ Notices displayed by works containing it; or
+ c) Prohibiting misrepresentation of the origin of that material, or
+ requiring that modified versions of such material be marked in
+ reasonable ways as different from the original version; or
+ d) Limiting the use for publicity purposes of names of licensors or
+ authors of the material; or
+ e) Declining to grant rights under trademark law for use of some
+ trade names, trademarks, or service marks; or
+ f) Requiring indemnification of licensors and authors of that
+ material by anyone who conveys the material (or modified versions of
+ it) with contractual assumptions of liability to the recipient, for
+ any liability that these contractual assumptions directly impose on
+ those licensors and authors.
+ All other non-permissive additional terms are considered "further
+restrictions" within the meaning of section 10. If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term. If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+ If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+ Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+ 8. Termination.
+ You may not propagate or modify a covered work except as expressly
+provided under this License. Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+ However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated (a)
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and (b) permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+ Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+ Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License. If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+ 9. Acceptance Not Required for Having Copies.
+ You are not required to accept this License in order to receive or
+run a copy of the Program. Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance. However,
+nothing other than this License grants you permission to propagate or
+modify any covered work. These actions infringe copyright if you do
+not accept this License. Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+ 10. Automatic Licensing of Downstream Recipients.
+ Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License. You are not responsible
+for enforcing compliance by third parties with this License.
+ An "entity transaction" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations. If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+ You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License. For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+ 11. Patents.
+ A "contributor" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based. The
+work thus licensed is called the contributor's "contributor version".
+ A contributor's "essential patent claims" are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version. For
+purposes of this definition, "control" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+ Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+ In the following three paragraphs, a "patent license" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement). To "grant" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+ If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients. "Knowingly relying" means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+ If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+ A patent license is "discriminatory" if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License. You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license (a) in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or (b) primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+ Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+ 12. No Surrender of Others' Freedom.
+ If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License. If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all. For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+ 13. Use with the GNU Affero General Public License.
+ Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU Affero General Public License into a single
+combined work, and to convey the resulting work. The terms of this
+License will continue to apply to the part which is the covered work,
+but the special requirements of the GNU Affero General Public License,
+section 13, concerning interaction through a network will apply to the
+combination as such.
+ 14. Revised Versions of this License.
+ The Free Software Foundation may publish revised and/or new versions of
+the GNU General Public License from time to time. Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+ Each version is given a distinguishing version number. If the
+Program specifies that a certain numbered version of the GNU General
+Public License "or any later version" applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation. If the Program does not specify a version number of the
+GNU General Public License, you may choose any version ever published
+by the Free Software Foundation.
+ If the Program specifies that a proxy can decide which future
+versions of the GNU General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+ Later license versions may give you additional or different
+permissions. However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+ 15. Disclaimer of Warranty.
+ THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+ 16. Limitation of Liability.
+ IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+ 17. Interpretation of Sections 15 and 16.
+ If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+ END OF TERMS AND CONDITIONS
+ How to Apply These Terms to Your New Programs
+ If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+ To do so, attach the following notices to the program. It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+ <one line to give the program's name and a brief idea of what it does.>
+ Copyright (C) <year> <name of author>
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>.
+Also add information on how to contact you by electronic and paper mail.
+ If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+ <program> Copyright (C) <year> <name of author>
+ This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+ This is free software, and you are welcome to redistribute it
+ under certain conditions; type `show c' for details.
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License. Of course, your program's commands
+might be different; for a GUI interface, you would use an "about box".
+ You should also get your employer (if you work as a programmer) or school,
+if any, to sign a "copyright disclaimer" for the program, if necessary.
+For more information on this, and how to apply and follow the GNU GPL, see
+<http://www.gnu.org/licenses/>.
+ The GNU General Public License does not permit incorporating your program
+into proprietary programs. If your program is a subroutine library, you
+may consider it more useful to permit linking proprietary applications with
+the library. If this is what you want to do, use the GNU Lesser General
+Public License instead of this License. But first, please read
+<http://www.gnu.org/philosophy/why-not-lgpl.html>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/modelling/binding/bi_steric_mass_action.html b/v5.0.1/modelling/binding/bi_steric_mass_action.html
new file mode 100644
index 000000000..30704aa5a
--- /dev/null
+++ b/v5.0.1/modelling/binding/bi_steric_mass_action.html
@@ -0,0 +1,161 @@
+
+
+
+
+
+
+
+ Bi Steric Mass Action — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Similar to the Bi-Langmuir model (see Section Multi Component Bi-Langmuir), the Bi-SMA model adds \(M - 1\)additional types of binding sites \(q_{i,j}\) (\(0 \leq j \leq M - 1\)) to the SMA model (see Section Steric Mass Action) without allowing an exchange between the different sites \(q_{i,j}\) and \(q_{i,k}\) (\(k \neq j\)).
+Therefore, there are no competitivity effects between the two types of binding sites and they have independent capacities.
where \(c_{p,0}\) and \(q_{0,j}\) (\(0 \leq j \leq M - 1\)) denote the salt concentrations in the liquid and solid phases of the beads respectively.
+The number of available salt ions \(\bar{q}_{0,j}\) for each binding site type \(0 \leq j \leq M - 1\) is given by
Note that all binding components must have exactly the same number of binding site types \(M \geq 1\).
+
The reference concentrations \(c_{\text{ref},j}\) and \(q_{\text{ref},j}\) can be specified for each binding site type \(0 \leq j \leq M - 1\).
+The concept of reference concentrations is explained in the respective paragraph in Section Reference concentrations.
+
Originally, the Bi-SMA model is limited to two different binding site types.
+Here, the model has been extended to arbitrary many binding site types.
+
For more information on model parameters required to define in CADET file format, see Bi Steric Mass Action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/modelling/binding/extended_mobile_phase_modulator_langmuir.html b/v5.0.1/modelling/binding/extended_mobile_phase_modulator_langmuir.html
new file mode 100644
index 000000000..1ad6f1fa4
--- /dev/null
+++ b/v5.0.1/modelling/binding/extended_mobile_phase_modulator_langmuir.html
@@ -0,0 +1,157 @@
+
+
+
+
+
+
+
+ Extended Mobile Phase Modulator Langmuir — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
This model is an extension of the mobile phase modulator Langmuir model (see Section Multi Component Langmuir), which allows linear binding of some selected components.
+A modifier component \(c_{p,\mathrm{mod}}\) is selected and the remaining components are divided into the index sets \(\mathcal{I}_{\mathrm{lin}}\) and \(\mathcal{I}_{\mathrm{lang}}\).
The Freundlich isotherm model is an empirical model that considers changes in the equilibrium constant of the binding process due to the heterogeneity of the surface and the variation of the interaction strength [11, 12].
+This variant of the model is based on the linear driving force approximation (see section Linear Driving Force (LDF)) and is given as
No interaction between the components is considered when the model has multiple components.
+One of the limitation of this isotherm is the first order Jacobian \(\left(\frac{dq^*}{dc_p}\right)\) tends to infinity as \(c_{p} \rightarrow 0\) for \(n>1\).
+To address this issue an approximation of isotherm is considered near the origin.
+This approximation matches the isotherm in such a way that \(q=0\) at \(c_p=0\) and also matches the first derivative of the istotherm at \(c_p = \varepsilon\), where \(\varepsilon\) is a very small number, for example \(1e-14\).
+The form of approximation and its derivative is given below for \(c_p < \varepsilon\) and \(n>1\):
where \(\alpha_0=0\) and \(\alpha_1\) and \(\alpha_2\) are determined from \(\alpha_1 \varepsilon+\alpha_2 \varepsilon^2 = k_f \varepsilon^{1/n}\) and \(\alpha_1 + 2 \alpha_2 \varepsilon = \frac{1}{n}k_f \varepsilon^{\frac{1-n}{n}}\).
This approximation can be used for any pore phase cocentration \(c_p < \varepsilon\) given \(n>1\).
+For the case, when \(n \le 1\) no special treament near the origin is required.
+For more information on model parameters required to define in CADET file format, see Freundlich LDF.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/modelling/binding/generalized_ion_exchange.html b/v5.0.1/modelling/binding/generalized_ion_exchange.html
new file mode 100644
index 000000000..15e3634e2
--- /dev/null
+++ b/v5.0.1/modelling/binding/generalized_ion_exchange.html
@@ -0,0 +1,160 @@
+
+
+
+
+
+
+
+ Generalized Ion Exchange — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The generalized ion exchange model is based on the steric mass action model [13, 14].
+In addition to the first component \(c_{p,0}\), which represents salt, the second component \(c_{p,1}\) represents another non-binding modifier (e.g., pH).
+In comparison to the SMA model, the characteristic charge \(\nu\) and the adsorption and desorption rate constants are modified:
The concept of reference concentrations (\(c_{\text{ref}}\) and \(q_{\text{ref}}\)) is explained in the respective paragraph in Section Reference concentrations.
+
For more information on model parameters required to define in CADET file format, see Generalized Ion Exchange.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/modelling/binding/hic_constant_water_activity.html b/v5.0.1/modelling/binding/hic_constant_water_activity.html
new file mode 100644
index 000000000..4dcc81693
--- /dev/null
+++ b/v5.0.1/modelling/binding/hic_constant_water_activity.html
@@ -0,0 +1,150 @@
+
+
+
+
+
+
+
+ HIC Constant Water Activity — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
This model implements a slightly modified version of the HIC isotherm by Wang et al. based on their 2016 paper [16].
+A naive multicomponent version was added that reduces to the original formulation if only 1 binding species is present.
The following binding models are presented in dynamic binding mode.
+By replacing all occurrences of \(\mathrm{d}q / \mathrm{d}t\) with \(0\), quasi-stationary (rapid-equlibrium) binding mode is achieved.
+In quasi-stationary binding, it is assumed that ad- and desorption take place on a much faster time scale than the other transport processes such that bead liquid phase \(c_{p,i}\) (or bulk liquid phase \(c_i\) for certain unit operation models) are always in equilibrium with the solid phase \(q_i\).
For the quasi-stationary binding mode, adsorption and desorption rate are no longer separate entities.
+Instead, the quotient \(k_{\text{eq}} = k_a / k_d\) of adsorption and desorption coefficient is the relevant parameter as shown for the linear binding model (see Section Linear):
The equilibrium constant \(k_{\text{eq},i}\) is used in CADET by setting \(k_{d,i} = 1\) and \(k_{a,i} = k_{\text{eq},i}\).
+
Note that adsorption rate \(k_{a,i}\) and desorption rate \(k_{d,i}\) are linearly correlated in both binding modes due to the form of the equilibrium constant \(k_{\text{eq}}\):
This correlation can potentially degrade performance of some optimization algorithms.
+While in quasi-stationary binding mode this is prevented by using the technique above, a dynamic binding model has to be reparameterized in order to decouple parameters:
Some authors use the linear driving force (LDF) approximation instead of the native kinetic form of an isotherm.
+All three approaches are equivalent in rapid equilibrium (IS_KINETIC=0) but not equivalent when binding kinetics are considered (IS_KINETIC=1).
+
+
In the native approach, \(\frac{dq}{dt}\) is an explicit funtion of \(c\) and \(q\). For example \(\frac{dq}{dt}=k_a c (q_m - q)-k_d q\) in the Langmuir model.
+
+
2. A linear driving force approximation is based on the equilibrium concentration \(q^*\) for given \(c\).
+For example \(q^*= \frac{q_m k_{eq} c}{1 + k_{eq} c}\) in the Langmuir model.
+Here, \(\frac{dq}{dt}\) is proportional to the actual difference from equilibrium, i.e. \(\frac{dq}{dt} = k_{kin}(q^*-q)\).
+Note that, the sign of \(\frac{dq}{dt}\) causes the resulting flux to act towards the equilibrium.
+In CADET, this approach is denoted by LDF, for example in MULTI_COMPONENT_LANGMUIR_LDF.
+
3. An alterniative linear driving force approximation is based on the equilibrium concentration \(c^*\) for given \(q\).
+For example \(c^*=\frac{q}{k_{eq} \left(q_{m}-q\right)}\) in the Langmuir model.
+Here, \(\frac{dq}{dt}\) is proportional to the actual difference from equilibrium concentrations, i.e. \(\frac{dq}{dt} = k_{kin}(c-c^*)\).
+Note that, the sign of \(\frac{dq}{dt}\) causes the resulting flux to act towards the equilibrium.
+In CADET, this approach is denoted by LDF_LIQUID_PHASE, for example in MULTI_COMPONENT_LANGMUIR_LDF_LIQUID_PHASE.
+
In both LDF examples, the original rate constants \(k_a\) and \(k_d\) are replaced by the equilibrium contant \(k_{eq}=\frac{k_a}{k_d}\).
+The linear driving force approximations are based on a new kinetic constant, \(k_{kin}\).
+
Note that some isotherms, such as the Freundlich model, don’t have a native representation in the above sense.
+LDF versions are availabe for some but not all binding models implemented in CADET.
Some binding models use reference concentrations \(c_{\text{ref}}\) and \(q_{\text{ref}}\) of the mobile phase modulator (e.g., salt) in the particle liquid and solid phase, respectively.
+The reference values are mainly used for normalizing adsorption and desorption rates, but also for other parameters that appear with those concentrations.
+They amount to a simple parameter transformation that is exemplified at one equation of the steric mass action binding model
This transformation serves as a (partial) nondimensionalization of the adsorption and desorption rates and, by properly choosing the reference concentrations \(c_{\text{ref}}\) and \(q_{\text{ref}}\), may improve the optimizer performance.
+
Recommended choices for \(c_{\text{ref}}\) are the average or maximum inlet concentration of the mobile phase modifier \(c_0\), and for \(q_{\text{ref}}\) the ionic capacity \(\Lambda\).
+Note that setting the reference concentrations to \(1.0\) each results in the original binding model.
A binding model may depend on an external function or profile \(T\colon \left[ 0, T_{\text{end}}\right] \times [0, L] \to \mathbb{R}\), where \(L\) denotes the physical length of the unit operation, or \(T\colon \left[0, T_{\text{end}}\right] \to \mathbb{R}\) if the unit operation model has no axial length.
+By using an external profile, it is possible to account for effects that are not directly modeled in CADET (e.g., temperature).
+The dependence of each parameter is modeled by a polynomial of third degree. For example, the adsorption rate \(k_a\) is really given by
While \(k_{a,0}\) is set by the original parameter XXX_KA of the file format (XXX being a placeholder for the binding model), the parameters \(k_{a,3}\), \(k_{a,2}\), and \(k_{a,1}\) are given by XXX_KA_TTT, XXX_KA_TT, and XXX_KA_T, respectively.
+The identifier of the externally dependent binding model is constructed from the original identifier by prepending EXT_ (e.g., MULTI_COMPONENT_LANGMUIR is changed into EXT_MULTI_COMPONENT_LANGMUIR).
+This pattern applies to all parameters and supporting binding models (see Table 3).
+Note that the parameter units have to be adapted to the unit of the external profile by dividing with an appropriate power.
+
Each parameter of the externally dependent binding model can depend on a different external source.
+The 0-based indices of the external source for each parameter is given in the dataset EXTFUN.
+By assigning only one index to EXTFUN, all parameters use the same source.
+The ordering of the parameters in EXTFUN is given by the ordering in the file format specification in Section Binding models.
A short comparison of the most prominent binding model features is given in Table 3.
+The implemented binding models can be divided into two main classes: Single-state and multi-state binding.
+While single-state models only have one bound state per component (or less), multi-state models provide multiple (possibly different) bound states for each component, which may correspond to different binding orientations or binding site types.
+The models also differ in whether a mobile phase modifier (e.g., salt) is supported to modulate the binding behavior.
+
+
Table 3 Supported features of the different binding models¶
This model is a modified Langmuir model (see Section Multi Component Langmuir) which can be used to describe hydrophobic interaction chromatography [17, 18].
+A modulator component (termed “salt”, \(c_{p,0}\) and \(q_0\)) influences ad- and desorption processes:
where \(c_{p,0}\) and \(q_0\) denote the salt concentrations in the liquid and solid phase of the beads respectively.
+Salt is considered to be inert, therefore either
is used if salt has one bound state, or salt can be used without a bound state.
+The parameter \(\gamma\) describes the hydrophobicity and \(\beta\) the ion-exchange characteristics.
The Anti-Langmuir (or generalized Langmuir) binding model extends the Langmuir model (see Section Multi Component Langmuir).
+The factor \(p_j \in \{ -1, 1 \}\) determines the shape of the isotherm.
+For \(p_j = 1\) (standard Langmuir) the chromatograms have sharp fronts and a dispersed tail (isotherm is concave).
+In case of the Anti-Langmuir (\(p_j = -1\)) it is the other way around (isotherm is convex).
The multi component Bi-Langmuir model [3] adds \(M - 1\) additional types of binding sites \(q_{i,j}\) (\(0 \leq j \leq M - 1\)) to the Langmuir model (see Section Multi Component Langmuir) without allowing an exchange between the different sites \(q_{i,j}\) and \(q_{i,k}\) (\(k \neq j\)).
+Therefore, there are no competitivity effects between the different types of binding sites and they have independent capacities.
Note that all binding components must have exactly the same number of binding site types \(M \geq 1\).
+See the Section Multi Component Langmuir.
+
Originally, the Bi-Langmuir model is limited to two different binding site types.
+Here, the model has been extended to arbitrary many binding site types.
+
For more information on model parameters required to define in CADET file format, see Multi Component Bi-Langmuir.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/modelling/binding/multi_component_bi_langmuir_ldf.html b/v5.0.1/modelling/binding/multi_component_bi_langmuir_ldf.html
new file mode 100644
index 000000000..7e530c696
--- /dev/null
+++ b/v5.0.1/modelling/binding/multi_component_bi_langmuir_ldf.html
@@ -0,0 +1,145 @@
+
+
+
+
+
+
+
+ Multi Component Bi-Langmuir LDF — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
This a linear driving force model variant of the Multi Component Bi-Langmuir model.
+It is based on the equilibrium concentration \(q^*\) for a given liquid phase concentration \(c\) (see also Linear Driving Force (LDF)).
+
+\[\begin{aligned}
+ q_{i,j}^*=\frac{q_{m,i,j} k_{eq,i,j} c_i}{1 + \sum_{k=1}^{N_{comp}}{k_{eq,k,j} c_k}} && i = 0, \dots, N_{\text{comp}} - 1, \: j = 0, \dots, M - 1.% (0 \leq i \leq N_{\text{comp}} - 1, \: 0 \leq j \leq M - 1).
+\end{aligned}\]
The colloidal isotherm assumes that adsorbed protein molecules are evenly distributed in a hexagonal arrangement at equilibrium, with the coverage varying via adjustment of the lattice size [19].
+Protein-surface interactions are captured in a parameter \(K_{e}\).
+The surface coverage is modulated at higher coverage, described by a Yukawa potential.
+The Yukawa constant \(b_{pp}\) characterizes protein-protein interactions.
+Since these are long-ranged, they are assumed to be primarily electrostatic for ion-exchange chromatography, with the range of interactions determined by the Debye parameter, \(\kappa\).
where \(n\) is the coordination number describing the two-dimensional lattice agreement of protein molecules on the resin surface (\(n=6\) for hexagonal arrangement).
+\(r_{i}\) is the radius of the protein, and \(K_{kin}\) is the kinetic rate of adsorption.
+
For the surface coverage factor \(R\), the following equation is used:
where \(\phi\) is the phase ratio (surface area/solid phase volume), \(N_{A}\) is Avogadro’s number, and with
+
+\[q_{tot} = \sum q_{i}.\]
+
The screening term \(\kappa\) is a Debye parameter based on the ideal colloidal phase behavior of the protein.
+In the case of ion exchange chromatography, this is the inverse of the Debye length.
+For other interaction mechanisms, this term can also be used to describe protein-protein interactions in general:
\(\kappa_{c}\), \(\kappa_{ef}\), and \(\kappa_{f}\) are fitting constants which can be used to custom define the protein-protein interaction behavior based on additives in the mobile phase.
+\(c_{p,0}\) is the total ionic strength, represented by the first component (non-binding pseudo component).
+
Also the terms for protein-resin interaction, \(K_{e,i}\), and protein-protein interaction, \(b_{pp,i}\), are varied as a function of the ionic strength.
where \(k_{a-e}\), \(b_{a-e}\) are fitting constants.
+
Because the model becomes mathematically singular at zero concentration, the original equation is replaced by its mathematical limit below a threshold concentration \(c_\epsilon > 0\).
The Langmuir binding model includes a saturation term and takes into account the capacity of the resin [3, 20].
+All components compete for the same binding sites.
This a linear driving force model variant of the Multi Component Langmuir model.
+It is based on the equilibrium concentration \(q^*\) for a given liquid phase concentration \(c\) (see also Linear Driving Force (LDF)).
This a linear driving force model variant of the Multi Component Langmuir model.
+It is based on the equilibrium concentration \(c^*\) for a given solid phase concentration \(q\) (see also Linear Driving Force (LDF)).
The multi component spreading model adds a second bound state \(q_{i,2}\) to the Langmuir model (see Section Multi Component Langmuir) and allows the exchange between the two bound states \(q_{i,1}\) and \(q_{i,2}\).
+In the spreading model a second state of the bound molecule (e.g., a different orientation on the surface or a different folding state) is added.
+The exchange of molecules between the two states is allowed and, since the molecules can potentially bind in both states at the same binding site, competitivity effects are present.
+This is different to the Bi-Langmuir model in which another type of binding sites is added and no exchange between the different bound states is considered (see Section Multi Component Bi-Langmuir).
+For all components \(i = 0, \dots, N_{\text{comp}} - 1\) the equations are given by
The multi-state steric mass action model adds \(M_i-1\)additional bound states \(q_{i,j}\) (\(j = 0, \dots, M_i - 1\)) for each component \(i\) to the steric mass action model (see Section Steric Mass Action) and allows the exchange between the different bound states \(q_{i,0}, \dots, q_{i,M-1}\) of each component.
+In the multi-state SMA model a variable number of states of the bound molecule (e.g., different orientations on the surface, binding strength of tentacle adsorbers) is added which are more and more strongly bound, i.e.,
The exchange between the different states of each component is allowed and, since the molecules can potentially bind in all states at the same binding site, competitive effects are present.
where \(c_{p,0}\) and \(q_0\) denote the salt concentrations in the liquid and solid phase of the beads respectively.
+The number of available salt ions \(\bar{q}_0\) is given by
The concept of reference concentrations (\(c_{\text{ref}}\) and \(q_{\text{ref}}\)) is explained in the respective paragraph in Section Reference concentrations.
In this binding model an additional quadratic term is added to the linear model [21].
+The quadratic term allows to take interactions of liquid phase components into account.
This binding model is similar to the steric mass action model (see Section Steric Mass Action) but is also capable of describing dimerization [14, 22].
+The dimerization, which is the immobilization of protein at some already bound protein, is also termed “self-association”.
+It is modeled by adding a quadratic (in \(c_{p,i}\)) term to the adsorption part of the equation.
The concept of reference concentrations (\(c_{\text{ref}}\) and \(q_{\text{ref}}\)) is explained in the respective paragraph in Section Reference concentrations.
+
For more information on model parameters required to define in CADET file format, see Self Association.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/modelling/binding/simplified_multi_state_steric_mass_action.html b/v5.0.1/modelling/binding/simplified_multi_state_steric_mass_action.html
new file mode 100644
index 000000000..f15172bf6
--- /dev/null
+++ b/v5.0.1/modelling/binding/simplified_multi_state_steric_mass_action.html
@@ -0,0 +1,156 @@
+
+
+
+
+
+
+
+ Simplified Multi-State Steric Mass Action — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The simplified multi-state steric mass action is the same as the multi-state SMA model described above (see Section Multi-State Steric Mass Action), but with additional assumptions:
+
+
Molecules are only exchanged between two adjacent states, that is, no transfer from state \(q_{i,1}\) to state \(q_{i,3}\) is allowed.
+
Characteristic charge \(\nu_{i,j}\) and shielding factor \(\sigma_{i,j}\) only depend on the index of the state \(j\).
+
+
Thus, the exchange parameters \(k^{(i)}_{j\ell}\), the characteristic charge \(\nu_{i,j}\), and the shielding \(\sigma_{i,j}\) can be parameterized with few degrees of freedom.
+For all \(i = 1,\dots,N_{\text{comp}} - 1\) and \(j,\ell = 0,\dots,M_i - 1\) let
Note that the characteristic charge \(\nu_{i,j}\) has to be monotonically non-decreasing in the second index \(j\) and all other rates and the steric factor \(\sigma_{i,j}\) have to be non-negative.
The steric mass action model takes charges of the molecules into account [23] and is, thus, often used in ion-exchange chromatography.
+Each component has a characteristic charge \(\nu\) that determines the number of available binding sites \(\Lambda\) (ionic capacity) used up by a molecule.
+Due to the molecule’s shape, some additional binding sites (steric shielding factor \(\sigma\)) may be shielded from other molecules and are not available for binding.
where \(c_{p,0}\) and \(q_0\) denote the salt concentrations in the liquid and solid phase of the beads, respectively.
+The number of free binding sites
is calculated from the number of bound counter ions \(q_0\) by taking steric shielding into account.
+In turn, the number of bound counter ions \(q_0\) (electro-neutrality condition) is given by
which also compensates for the missing equation for \(\frac{\mathrm{d} q_0}{\mathrm{d}t}\).
+
The concept of reference concentrations (\(c_{\text{ref}}\) and \(q_{\text{ref}}\)) is explained in the respective paragraph in Section Reference concentrations.
+
For more information on model parameters required to define in CADET file format, see Steric Mass Action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/modelling/crystallization.html b/v5.0.1/modelling/crystallization.html
new file mode 100644
index 000000000..3f8381496
--- /dev/null
+++ b/v5.0.1/modelling/crystallization.html
@@ -0,0 +1,249 @@
+
+
+
+
+
+
+
+ Population Balance Models — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The population balance model (PBM) is given by a particle-number continuity equation which describes the evolution of the number density \(n\) of the particles over time \(t\) and with respect to a so-called internal coordinate \(x\) and external coordinate \(z\).
+The internal coordinate can be chosen as any characteristic property of the particles such as the particle size or volume.
+The external coordinate can be a characteristic dimension of the reactor itself, including its axial length.
+
In CADET, we chose particle size and axial coordinate as the internal and external coodinate respectively.
+The PBM in CADET is implemented so that it can be used in any unit operation that supports reactions.
+Typical applications consider crystallization in a CSTR or, to model continuous processes, in a Dispersive Plug-Flow Reactor (DPFR), which is described by the LRM without solid phase.
+
In the following, we give a brief overview on the modelling equations, for more information on the PBM as implemented in CADET, please refer to [24].
+
+
+
+
Fig. 8 Nucleation, growth and growth rate dispersion in PBM. Note that dispersion is used to model (random) variance in growth speed, not the reduction of particle size, which is feasible for a convection dominated process.¶
We assume a well-mixed tank and choose the particle size \(x\in (x_c, \infty)\) as the internal coodinate, with \(x_c>0\) being the minimal particle size considered.
+The corresponding PBM is given as
where \(F_{in}, F_{out}\in \mathbb{R}^+\) are the volumetric inflow and outflow rates, \(V\in\mathbb{R}^+\) is the reactor volume,
+\(n(t, x)\colon [0, T_\text{end}] \times (x_c, \infty) \mapsto \mathbb{R}^+\) is the number density distribution,
+\(n_{in}\in\mathbb{R}^+\) is the number density distribution of the inlet feed, \(v_{G}\in\mathbb{R}^+\) is the particle growth rate,
+\(D_g\in\mathbb{R}^+\) is the growth dispersion rate.
+
The boundary conditions are given by the regularity boundary condition
where \(c(t)\colon [0, T_\text{end}] \mapsto \mathbb{R}^+\) is the solute concentration in the bulk phase, \(c_{in}\in\mathbb{R}^+\) is the inlet solute mass concentration, \(\rho > 0\) is the nuclei mass density and \(k_v > 0\) is the volumetric shape factor of the particles.
The PBM can also be formulated for a DPFR to model continuous processes.
+That is, we choose the axial position within a DPFR as the external coordinate \(z\in[0, L]\) and formulate the \(2D\) PBM
where \(n(t, x, z)\colon [0, T_\text{end}] \times (x_c, \infty) \times [0, L] \mapsto \mathbb{R}^+\) is the number density distribution,
+\(v_\text{ax}\in\mathbb{R}^+\) is the axial velocity and \(D_{ax}\in\mathbb{R}^+\) is the axial dispersion coefficient.
+
Boundary conditions for the internal coordinate are again given by Eq. 27 and Eq. 28.
+
For the external coordinate \(z\), Danckwerts boundary conditions are applied:
Which are in turn defined by the following constitutive equations.
+An empirical equation for primary nucleation is given by:
+
+\[\begin{aligned}
+ B_p=k_ps^u,
+\end{aligned}\]
+
where \(k_p\in\mathbb{R}^+\) is the primary nucleation rate constant and \(u\in\mathbb{R}^+\) is a constant.
+An empirical power-law expression is used for the secondary nucleation:
where \(k_b\in\mathbb{R}^+\) is the secondary nucleation rate constant, \(b\in\mathbb{R}^+\) and \(k\in\mathbb{R}^+\) are system-related parameters and \(M\in\mathbb{R}^+\) is the suspension density defined as
where \(k_g\in\mathbb{R}^+\) is the growth rate constant, \(\gamma\in\mathbb{R}^+\) quantifies the size dependence, and \(g, a, p\in\mathbb{R}^+\) are system-related constants.
+
For information on model parameters and how to specify the model interface, see Population balance model.
This section gives complete information about the supported unit operations, binding and reaction models, and creating a network among all the unit operations in CADET. For details on file format specifications related to define each unit operation in CADET, see section Interface specifications.
Unit operation models can be composed into a network or graph, in which a node represents a unit operation and an edge denotes a connection between two unit operations.
+When utilized to full extent, this allows the simulation of complicated setups and processes (e.g., SMB, MCSGP).
+A more simple use case is the addition of plug flows and stirred tanks up- and downstream of a column in order to account for dead volume and additional dispersion from the tubing.
+
In a network, outlet ports of unit operations can be connected to any number of inlet ports of unit operations.
+Even direct cycles, where an outlet port of a unit operation is connected to its own inlet, are possible.
+A unit operation does not have to possess both inlet and outlet, but it has to have at least one of them.
+Pseudo unit operations such as inlet and outlet serve as sources and sinks for the network.
+However, the latter is not strictly required as any terminal node (i.e., a unit operation that possesses an outlet but does not have an outgoing connection) serves as a sink.
+
Each connection between two unit operation ports (i.e., an edge in the graph) is equipped with a volumetric flow rate that determines the mass flow from source to target port.
+These flow rates are used to determine the weight of the different incoming feeds at a unit operation’s inlet port.
+Some unit operations can infer their internal flow rate (e.g., interstitial velocity) from their total incoming volumetric flow rate.
+In general, the mass balance at a unit operation has to be closed, except for unit operations that act as source or sink in the network and variable volume units (e.g., stirred tanks).
+
The network of unit operations uses “connection”-variables \(c_{\text{con}}\) to connect the different unit operation ports with each other.
+The inlet port variables \(c_{\text{in},n,k}\) of unit operation \(n\) are attached to \(c_{\text{con},n}\) via
+
+(25)¶\[\begin{aligned}
+ c_{\text{in},n,k,i} &= c_{\text{con},n,k,i}, \qquad k = 1, \dots, N_{\text{port},\text{in},n},\quad i = 1, \dots, N_{\text{comp},n}.
+\end{aligned}\]
+
While \(N_{\text{port},\text{in},n}\) denotes the number of inlet ports of unit operation \(n\), the number of outlet ports is given by \(N_{\text{port},\text{out},n}\).
+The connection variables \(c_{\text{con},n,k,i}\) collect all inflows of component \(i\) into port \(k\) of unit operation \(n\):
where \(F_{m,\ell}\) denotes the volumetric flow rate from outlet port \(\ell\) of unit operation \(m\), \(S_{(n,k,i),(m,\ell,j)} \in \{0, 1\}\) is a connection matrix indicating whether component \(i\) at outlet port \(k\) of unit operation \(n\) is connected to component \(j\) at inlet port \(\ell\) of unit operation \(m\), and \(\hat{S}_{(n,k),(m,\ell)} \in \{0, 1\}\) is another connection matrix indicating whether outlet port \(k\) of unit operation \(n\) is connected to inlet port \(\ell\) of unit operation \(m\), that is
Note that for each unit operation the number of inlet ports may be different from the number of outlet ports.
+Hence, the mass balance of a single unit operation is taken with respect to all its ports combined.
The connections between the different unit operations in the network are specified by a table.
+There are two table formats:
+
+
The long format includes seven columns.
+The first two columns specify source and destination unit operation id.
+The next two columns give source and destination port indices.
+Source and destination component indices are given by the following two columns.
+Finally, the seventh column specifies the volumetric flow rate of this connection (see Group /input/model/connections/switch_XXX).
+
The short format includes five columns.
+The first two columns specify source and destination unit operation id.
+Source and destination component indices are given by the following two columns.
+Finally, the fifth column specifies the volumetric flow rate of this connection.
+Here, the omitted port indices default to \(-1\), which connects all ports of the source unit operation to the corresponding ports of the target.
+
+
By default, the short format is used (i.e., a table with five columns is expected).
+However, if a unit operation with multiple ports is present, a table with seven columns is required.
+The default format can be overruled by setting a field.
+
With this setup, it is possible to connect single components of unit operations with each other yielding a maximum in flexibility.
+However, the predominant case is to connect all components of the source unit operations with their respective counterparts in the destination unit.
+This can easily be done by setting both component indices to \(-1\) instead of writing a separate row for each component of the connection.
+The same setting (i.e., setting both port indices to \(-1\)) can be used to connect all ports of one unit operation with all corresponding ports of another one.
+
Note that in case of multiple rows for one connection between two unit operation ports (e.g., in case of separate component connections) the flow rate of the first row of that connection is used and all following flow rates are ignored.
+Consequently, there can only be one flow rate for a connection between two unit operations regardless of which components are connected.
+
The connection table is expected in row-major storage format (i.e., the rows are appended to one long array).
The connectivity of the network can only change on a discontinuous section transition.
+Such a transition with changing connectivity is referred to as valve switch and the connectivity itself as valve configuration.
+
A list of valve configurations with at least one entry is required.
+Each valve configuration consists of a network connectivity table as described in Section Specification of network connections and a section index.
+The latter denotes the section in which the connectivity table becomes active.
+Hence, the one required (i.e., the first) entry must have a section index of \(0\) denoting the initial connectivity.
where \(t_s\) is the beginning of the time section that triggers the valve switch.
+
Note that the denominator in Eq. 26 must always be positive.
+That is, the flow rate coefficients have to be chosen such that the flow into every connected inlet port is strictly positive at all times.
Each time step in the simulation requires the solution of a nonlinear system Eq. 29 (see Sec. Time stepping).
+The nonlinear problem is solved by a Newton iteration, which, in turn, requires the solution of a linear system that essentially consists of the Jacobians of the unit operations and some coupling matrices from Eqs. 25 and 26.
+
These linear systems are either solved in parallel or sequentially. The parallel method first solves each unit operation (in parallel) to compute the solution at its outlet.
+Using these values, the inlets are adjusted and the unit operations are solved again.
+This is iterated until the system is fully solved.
+
In contrast, the sequential method first determines an ordering of the unit operations such that each unit only receives inflow from the previous units in the ordering.
+Such an ordering requires an acyclic graph of unit operations.
+Finally, the linear system is solved by solving the unit operations in the ordering determined above.
+Before a unit is solved, its inlet is calculated from the outlets of the previously solved units.
+This means, the system is solved from system inlets to system outlets.
+
The parallel method works regardless of the network topology (i.e., cycles in the graph), but requires to solve each unit operation at least twice.
+The sequential method solvs each unit exactly once, but is restricted to acyclic networks and works best for small graphs.
+By default, CADET uses a heuristic to select an appropriate solution method.
+This default can be overridden by a flag (see Table Group /input/model/solver).
+
The solution method is selected for each valve switch individually.
+If some network configurations contain cycles, the parallel method is chosen for them regardless of the method used for the other configurations.
A reaction model may depend on an external function or profile \(T\colon \left[ 0, T_{\mathrm{end}}\right] \times [0, L] \to \mathbb{R}\), where \(L\) denotes the physical length of the unit operation, or \(T\colon \left[0, T_{\mathrm{end}}\right] \to \mathbb{R}\) if the unit operation model has no axial length.
+By using an external profile, it is possible to account for effects that are not directly modeled in CADET (e.g., temperature).
+The dependence of each parameter is modeled by a polynomial of third degree.
+For example, the forward rate constant \(k_{\mathrm{fwd}}\) is really given by
While \(k_{\mathrm{fwd},0}\) is set by the original parameter XXX_KFWD of the file format (XXX being a placeholder for the reaction model), the parameters \(k_{\mathrm{fwd},3}\), \(k_{\mathrm{fwd},2}\), and \(k_{\mathrm{fwd},1}\) are given by XXX_KFWD_TTT, XXX_KFWD_TT, and XXX_KFWD_T, respectively.
+The identifier of the externally dependent reaction model is constructed from the original identifier by prepending EXT_ (e.g., MASS_ACTION_LAW is changed into EXT_MASS_ACTION_LAW).
+This pattern applies to all parameters and supporting reaction models.
+Note that the parameter units have to be adapted to the unit of the external profile by dividing with an appropriate power.
+
Each parameter of the externally dependent reaction model can depend on a different external source.
+The 0-based indices of the external source for each parameter is given in the dataset EXTFUN.
+By assigning only one index to EXTFUN, all parameters use the same source.
+The ordering of the parameters in EXTFUN is given by the ordering in the file format specification.
+
For the configuration of external function dependence and more information on model parameters required to define in CADET file format, see section Reaction models.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/modelling/reaction/mass_action_law.html b/v5.0.1/modelling/reaction/mass_action_law.html
new file mode 100644
index 000000000..56a1b6c12
--- /dev/null
+++ b/v5.0.1/modelling/reaction/mass_action_law.html
@@ -0,0 +1,193 @@
+
+
+
+
+
+
+
+ Mass action law — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The mass action law reaction model is suitable for most reactions.
+Note that the concentrations are directly used for calculating the fluxes.
+Hence, the model only holds for dilute solutions under the assumption of a well-stirred reaction vessel.
+These assumptions can be weakened by passing to the generalized mass action law, which uses chemical activities instead of concentrations.
+
The mass action law states that the speed of a reaction is proportional to the product of the concentrations of their reactants.
+The net flux for component \(i\) is given by
where \(S^l = (s^l_{i,j}) \in \mathbb{R}^{N_{\mathrm{comp}} \times N_{\mathrm{react}}}\) is the stoichiometric matrix, \(\varphi^l_j(c)\) is the net flux of reaction \(j\), and \(k^l_{\mathrm{fwd},j}\) and \(k^l_{\mathrm{bwd},j}\) are the rate constants.
+The matrices \(E^l_{\mathrm{fwd}} = (e^l_{\mathrm{fwd},\ell,j}) \in \mathbb{R}^{N_{\mathrm{comp}} \times N_{\mathrm{react}}}\) and \(E^l_{\mathrm{bwd}} = (e^l_{\mathrm{bwd},\ell,j}) \in \mathbb{R}^{N_{\mathrm{comp}} \times N_{\mathrm{react}}}\) are usually derived by the order of the reaction, that is,
However, these defaults can be changed by providing those matrices.
+
In situations where both liquid and solid phase are present (e.g., in a bead), the respective other phase may act as a modifier in the net flux equation.
+For example, consider reactions in the liquid phase of a particle given by
The forward and backward rates of the liquid phase particle reactions can be modified by a power of every bound state in the solid phase of the particle.
+The exponents of these powers are given by the matrices \(E^{ps}_{\mathrm{fwd}} = (e^{ps}_{\mathrm{fwd},m,j})\) and \(E^{ps}_{\mathrm{bwd}} = (e^{ps}_{\mathrm{bwd},m,j})\), which are both of size \((\sum_i N_{\mathrm{bnd},i}) \times N_{\mathrm{react}}\).
+Whereas the exponent matrices \(E^{p}_{\mathrm{fwd}}, E^{p}_{\mathrm{bwd}} \in \mathbb{R}^{N_{\mathrm{comp}} \times N_{\mathrm{react}}}\) are initialized based on the stoichiometric matrix \(S^{p} \in \mathbb{R}^{N_{\mathrm{comp}} \times N_{\mathrm{react}}}\), see Eq.?:eq:MRMassActionLawExpMatDefault, the exponent matrices \(E^{ps}_{\mathrm{fwd}}, E^{ps}_{\mathrm{bwd}}\) of the modifier terms default to \(0\).
+
Vice versa, the rates of solid phase reactions can be modified by liquid phase concentrations.
+The corresponding exponent matrices \(E^{sp}_{\mathrm{fwd}} = (e^{sp}_{\mathrm{fwd},\ell,j})\) and \(E^{sp}_{\mathrm{bwd}} = (e^{sp}_{\mathrm{bwd},\ell,j})\) are both of size \(N_{\mathrm{comp}} \times N_{\mathrm{react}}\).
Whereas the exponent matrices \(E^{s}_{\mathrm{fwd}}, E^{s}_{\mathrm{bwd}} \in \mathbb{R}^{(\sum_i N_{\mathrm{bnd},i}) \times N_{\mathrm{react}}}\) are initialized based on the stoichiometric matrix \(S^{s} \in \mathbb{R}^{(\sum_i N_{\mathrm{bnd},i}) \times N_{\mathrm{react}}}\), see Eq.?:eq:MRMassActionLawExpMatDefault, the exponent matrices \(E^{sp}_{\mathrm{fwd}}, E^{sp}_{\mathrm{bwd}}\) of the modifier terms default to \(0\).
+
+
+
Correlation of forward- and backward rate constants¶
+
Note that forward rate constant \(k_{\mathrm{fwd},i}\) and backward
+rate constant \(k_{\mathrm{bwd},i}\) of reaction \(i\) are
+linearly correlated due to the form of the equilibrium constant
+\(k_{\mathrm{eq},i}\):
\(\mu_{\mathrm{max},j}\), is the limiting rate approached by the system at saturation,
+
\(k_{\mathrm{MM},j}\) is the Michaelis constant, which is defined as the concentration of substrate at which the reaction rate is half ov \(\mu_{\mathrm{max},j}\).
+
+
In addition, the reaction might be inhibited by other components.
+In this case, the flux has the form
Here, \(k_{\mathrm{I},j,i}\) is the inhibition constant w.r.t component \(i\) and reaction \(j\).
+If \(k_{\mathrm{I},j,i} <= 0\), component \(i\) does not inhibit the reaction.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/v5.0.1/modelling/unit_operations/2d_general_rate_model.html b/v5.0.1/modelling/unit_operations/2d_general_rate_model.html
new file mode 100644
index 000000000..062f88bed
--- /dev/null
+++ b/v5.0.1/modelling/unit_operations/2d_general_rate_model.html
@@ -0,0 +1,199 @@
+
+
+
+
+
+
+
+ Two Dimensional General rate model (GRM2D) — CADET
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The general rate model as introduced in Section General rate model (GRM) assumes homogeneity in the cross sections of the column.
+This allows to consider transport along the axial dimension only.
+However, due to packing irregularity and inhomogeneous flow at the inlet (i.e., frits), this assumption may be a crude approximation.
+This model can be improved by introducing a radial coordinate \(\rho \in [0, R]\), where \(R\) is the column radius, in the interstitial volume Eq. 1:
depend on \(\rho\).
+Additionally, the porosity \(\varepsilon_c\), axial dispersion coefficient \(D_{\text{ax},i}\), radial dispersion coefficient \(D_{\text{rad},i}\), and interstitial velocity \(u\) may depend on \(\rho\).
+
The dependence of the parameters on \(\rho\) is not arbitrary.
+For simplicity, it is assumed that the parameters are piecewise constant, that is, the range \([0, R]\) is divided into disjoint zones in which all parameters are constant.
+These zones are used for radial discretization and can be supplied to the simulator.
+Continuous dependence of the parameters can be realized by piecewise constant approximation.
+
The Danckwerts boundary conditions at the column in- and outlet, Eq. 3 and 2, are modified to account for the radial coordinate:
While the inner condition Eq.22 represents symmetry at the column center, the outer condition Eq. 23 is a no-flux condition.
+
Using the inlet boundary condition Eq. 20, each radial zone is equipped with its own inlet and outlet port.
+That is, this unit operation has as many inlet and outlet ports as it has radial zones (parameter NRAD in the discretization group).
+This allows each radial zone to have its own inlet profile, which enables modeling of flow distribution in the frits by sending the feed through varying hold-up volumes before injecting it into a radial zone.
+
+
Specification of flow rate / velocity and direction¶
+
Since the column radius \(R\) and the zones \((\rho_k, \rho_{k+1})\), \(k = 0, \dots, N_{\text{rad}} - 1\), are known, the interstitial velocities \(u_k\) are inferred from the volumetric flow rates via
where \(F_{\text{in},k}\) denotes the volumetric flow rate into zone \(k\).
+
The direction of flow inside the radial zone of the unit operation is governed by the sign of the interstitial velocity \(u_k\).
+A positive sign results in (standard) forward flow, whereas a negative sign reverses the flow direction.
+Note that in case of reversed flow, the chromatogram is returned at the unit operation’s inlet port, which may not be returned from simulation by default.
+
Note that, contrary to the standard general rate model as presented in Section General rate model (GRM), the interstitial flow rate is always given by the volumetric flow rate.
+The velocity parameter only determines the flow direction.
The continuous stirred tank reactor model is a basic building block in unit operation networks and often used to model holdup volume.
+When combined with a binding model, it can be used to model batch uptake experiments.
+
Assuming that the fluid inside the tank is well-mixed and that the liquid volume \(V^{\ell}\) can vary, the governing equations are given by
\(c^\ell_i\) concentration of component \(i\) in the liquid phase.
+
\(c^s_{j,i,m_{j,i}}\) concentration of component \(i\) in the solid phase of particle type \(j\) and particle type \(m_{j,i}\).
+
\(V^{\ell}\) liquid volume in the tank.
+
\(V^{s}\) solid volume in the tank.
+
\(F_{\text{in}}\) and \(F_{\text{out}}\) flow rates of liquid into and out of the tank.
+
\(f_{\text{react},i}^l\left( c^\ell \right)\) and \(f_{\text{react},j,i}^s\left( c^\ell, c_j^s \right)\) reaction rates of component \(i\) in the liquid and solid phase.
+
\(d_j\) volume fraction of the different solid volume in the tank.
+
+
Depending on whether quasi-stationary or dynamic binding is used the binding behavior of \(c_i^{\ell}\) and \(c^s_j\) is described by
Removing all bound states by setting \(N_{\text{bnd},j,i} = 0\) for all components \(i\) and particle types \(j\), and applying no binding model results in a simple tank.
+The additional parameter \(F_{\text{filter}}\), which denotes the flow rate of pure liquid (without any components) out of the tank, can be used to model a filtering unit.
+
Note that it is the user’s duty to make sure that the volume of the CSTR does not fall below 0. If it does, the simulation may fail to run or may produce unreasonable (e.g., unphysical) results.
The general rate model is the most comprehensive model of mass transfer in column liquid chromatography, when only the axial coordinate in the column and the radial coordinate in the beads are considered [1, 2, 3, 4].
+
The main assumptions are:
+
+
The cross sections of the column are homogenous in terms of interstitial volume, fluid flow, and distribution of components.
+Thus, only one spatial coordinate in axial direction is needed and radial transport is neglected in the column bulk volume.
+
The bead radii \(r_{p}\) are much smaller than the column radius \(\mathrm{P}\) and the column length \(L\).
+Therefore, the beads can be seen as continuously distributed inside the column (i.e., at each point there is interstitial and bead volume).
The GRM describes transport of solute molecules through the interstitial column volume by convective flow, band broadening caused by axial dispersion, mass transfer resistance through a stagnant film around the beads, pore (and surface) diffusion in the porous beads [5, 6, 7], and adsorption to the inner bead surfaces.
+
Consider a column of length \(L>0\) filled with spherical beads of (possibly) multiple types with radius \(r_{p,j} \ll L\) (see Fig. 2), where \(j\) is the particle type index. The mass balance in the interstitial column volume is described by
Here, \(c^\ell_i\colon \left[0, T_{\text{end}}\right] \times [0, L] \rightarrow \mathbb{R}^{\geq 0}\) denotes the concentration in the interstitial column volume, \(c^p_{j,i}\colon \left[0, T_{\text{end}}\right] \times [0, L] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}\) the liquid phase concentration in the beads, \(k_{f,j,i}\geq 0\) the film diffusion coefficient, \(D_{\text{ax},i}\geq 0\) the dispersion coefficient, \(u\in\mathbb{R}\) the interstitial velocity, \(d_j > 0\) the volume fraction of particle type \(j\), and \(\frac{1}{\beta_c} = (1 - \varepsilon_c) / \varepsilon_c\) the column phase ratio, where \(\varepsilon_c\in (0,1]\) is the column porosity (ratio of interstitial volume to total column volume).
+If reactions are considered, the term \(f_{\text{react},i}^\ell\left(c^\ell\right)\) represents the net change of concentration \(c_i\) due to reactions involving component \(i\).
+
Danckwerts boundary conditions [8] are applied to inlet and outlet of the column:
+
+(2)¶\[\begin{aligned}
+ u c_{\text{in},i}(t) &= u c^\ell_i(t,0) - D_{\text{ax},i} \frac{\partial c^\ell_i}{\partial z}(t, 0) & \forall t > 0,
+\end{aligned}\]
where \(c^s_{j,i,m_{j,i}}\colon \left[0, T_{\text{end}}\right] \times [0,L] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}\) denotes the solid phase concentration of the \(i\)th component’s \(m_{j,i}\)th bound state in the beads of \(j\)th type, \(D_{p,j,i}>0\) the effective diffusion coefficient in the beads, \(D_{s,j,i}\geq 0\) the surface diffusion coefficient, \(F_{\text{acc},j,i}\geq 0 \in [0,1]\) the pore accessibility factor, and \(\varepsilon_{p,j}\in (0,1]\) the particle porosity (ratio of pore volume to total bead volume).
+The inner bead radius \(r_{c,j} \in [0, r_{p,j})\) is assumed to be \(0\) by default, but can be positive in order to account for core-shell particles that have an impermeable core.
+Reaction terms in liquid and solid phase are collected in \(f_{\text{react},j,i}^p( c_j^p, c_j^s)\) and \(f_{\text{react},j,i}^s(c_j^p, c_j^s)\), respectively.
+
The GRM is used with both quasi-stationary (Eq. 5) and dynamic (Eq. 6) binding models.
In the model above, spherical particles are considered.
+Other supported particle forms are cylinders and slabs.
+For cylinders, it is assumed that molecules can only enter through the lateral surface (i.e., the caps are sealed).
+Slabs are assumed to have two large sides such that molecules enter through the two large faces (i.e., the remaining four small faces are sealed).
+
All particle forms support core-shell beads that have an impermeable core.
+The particles are characterized by their (outer) “radius” \(r_{p,j}\) and their (inner) core “radius” \(r_{c,j} \in [0, r_{p,j})\).
+See Fig. 5.
A particle type has its own set of mass transfer parameters \(\varepsilon_{p,j}\), \(D_{p,j}\), \(D_{s,j}\), etc (see Eq. 4) and its own binding model \(f_{\mathrm{ads}}\) (including a possibly differing number of bound states).
+This allows, for example, modeling of particle size distributions or potential applications with differently functionalized beads (e.g., immobilized enzymes).
+
The distribution of the particle types is governed by their volume fractions \(d_j\) in Eq.
+ 1. The volume fractions have to sum to \(1\):
The particle type volume fractions can be spatially constant throughout the column, or depend on the position inside the column bulk volume.
+In the latter case, the user can specify a set of volume fractions for each discretized finite volume cell.
+This allows, for example, the placement of smaller particles near the frits.
The general rate model can be used to simulate size exclusion chromatography (SEC) [2].
+The particle porosity \(\varepsilon_{p,j}\) on the mobile phase side of the transport equations is replaced by a component-dependent accessible porosity
where the pore accessibility factor \(F_{\text{acc},j,i}\) ranges in \((0, 1]\).
+
Small molecules that can enter any pore have \(F_{\text{acc},j,i} = 1\), whereas larger molecules that can enter some, but not small pores, have values \(0 < F_{\text{acc},j,i} < 1\).
+The other extreme is given by molecules so large that they cannot enter any pore and, consequently, \(F_{\text{acc},j,i} = 0\).
+Note that \(F_{\text{acc},j,i} = 0\) is not allowed in a simulation, which can be circumvented by setting \(k_{f,j,i} = 0\).
+
By default, \(F_{\text{acc},j,i} = 1\) for all components \(i\) and all particle types \(j\), which disables size exclusion chromatography.
+
It is important to note that in the presence of size exlusion effects, the saturation capacity (e.g., \(q_{\text{max}}\) of Langmuir-type binding models) will differ for solutes with different accessible porosity values.
+However, this leads to inconsistencies in the equations which account for the full pore volume fraction \(\varepsilon_{p,j}\).
+For this reason, SEC should only be modelled without binding models!
+In order to simulate pure SEC, binding is disabled by setting \(N_{\text{bnd},i} = 0\) for all components \(i\) and applying no binding model.
+
Note that multiple particle types can also be used to aid in modeling size exclusion effects, see Section Multiple particle types.
+
+
+
Specification of flow rate / velocity and direction¶
+
Since volumetric flow rates are specified for each network connection, the unit operation can infer its interstitial velocity via
+
+\[\begin{aligned}
+ u = u_{\text{int}} = \frac{F_{\text{in}}}{A \varepsilon_c},
+\end{aligned}\]
+
where \(F_{\text{in}}\) denotes the volumetric flow rate and \(A\) the cross section area.
+Note that without the bulk porosity \(\varepsilon_c\), the superficial velocity would be obtained.
+
The direction of flow inside the unit operation is governed by the sign of the interstitial velocity \(u\).
+A positive sign results in (standard) forward flow, whereas a negative sign reverses the flow direction.
+Note that in case of reversed flow, the chromatogram is returned at the unit operation’s INLET, which may not be returned from simulation by default.
+
The final behavior for axial flow models is controlled by the interplay of cross section area and interstitial velocity:
+
+
If cross section area \(A\) is given and \(u\) is not, \(u\) is inferred from the volumetric flow rate.
+
If \(u\) is given and \(A\) is not, the volumetric flow rate is ignored and the provided interstitial velocity is used.
+
If both cross section area \(A\) and interstitial velocity \(u\) are given, the magnitude of the actual interstitial velocity \(u\) is inferred from the volumetric flow rate and the flow direction is given by the sign of the provided \(u\).
+
+
The final behavior for radial flow models is controlled by the interplay of column length/height and interstitial velocity coefficient:
+
+
If \(L\) is given, the interstitial velocity field is inferred from the volumetric flow rate.
+
If \(u\) is given and \(L\) is not, the provided interstitial velocity coefficient is used to calculate the interstitial velocity field.
The radial flow GRM describes transport of solute molecules through the interstitial column volume by radial convective flow, band broadening caused by radial dispersion, mass transfer resistance through a stagnant film around the beads, pore (and surface) diffusion in the porous beads [5, 6, 7], and adsorption to the inner bead surfaces.
+
The main assumptions are:
+
+
The cylindrical shells of the column are homogenous in terms of interstitial volume, fluid flow, and distribution of components.
+Thus, only one spatial coordinate in radial direction \(\rho\) is needed and axial transport is neglected in the column bulk volume.
+
The bead radii \(r_{p}\) are much smaller than the column radius \(\mathrm{P}-\mathrm{P}_c\), with \(\mathrm{P}\) and \(\mathrm{P}_c\) being the inner and outer column radius respectively, and the column length \(L\).
+Therefore, the beads can be seen as continuously distributed inside the column (i.e., at each point there is interstitial and bead volume).
+
The fluids are incompressible, i.e. the velocity field \(\mathrm{V} \colon \mathbb{R}^3 \to \mathbb{R}^3\) submits to \(\operatorname{div}\left( \mathrm{V} \right) \equiv 0\).
+That is, the volumetric flow rate at the inner and outer column radius are the same.
+
+
Consider a hollow (double walled) column with inner column diameter \(\mathrm{P}_c>0\) and outer diameter \(\mathrm{P}>\mathrm{P}_c\), filled with spherical beads of (possibly) multiple types with radius \(r_{p,j} \ll L\) (see Fig. 2), where \(j\) is the particle type index. The mass balance in the interstitial column volume is described by
Here, \(c^\ell_i\colon \left[0, T_{\text{end}}\right] \times [\mathrm{P}_c, \mathrm{P}] \rightarrow \mathbb{R}^{\geq 0}\) denotes the concentration in the interstitial column volume, \(c^p_{j,i}\colon \left[0, T_{\text{end}}\right] \times [P_c, P] \times [r_{c,j}, r_{p,j}] \rightarrow \mathbb{R}^{\geq 0}\) the liquid phase concentration in the beads, \(k_{f,j,i}\geq 0\) the film diffusion coefficient, \(D_{\text{rad},i}\geq 0\) the dispersion coefficient, \(u>0\) the interstitial velocity, \(d_j>0\) the volume fraction of particle type \(j\), and \(\beta_c = \varepsilon_c / (1 - \varepsilon_c)\) the column phase ratio, where \(\varepsilon_c\in(0,1)\) is the column porosity (ratio of interstitial volume to total column volume).
+If reactions are considered, the term \(f_{\text{react},i}^\ell\left(c^\ell\right)\) represents the net change of concentration \(c_i\) due to reactions involving component \(i\).
+
Danckwerts boundary conditions [8] are applied to inlet and outlet of the column:
+
+(11)¶\[\begin{aligned}
+ u c_{\text{in},i}(t) &= u c^\ell_i(t,0) - D_{\text{rad},i} \frac{\partial c^\ell_i}{\partial \rho}(t, 0) & \forall t > 0,
+\end{aligned}\]
Note that the outlet boundary condition Eq. 11 is also known as “do nothing” or natural outflow condition.
+
The complementing mass transport and binding equations for the liquid and solid phases of the porous beads are described by the same equations as for the axial GRM.
Moreover, the pseudo unit operations Inlet, and Outlet act as sources and sinks for the system.
+We further note that radial flow model variants are available for the LRM, LRMP and GRM.
A system inlet unit operation is a pseudo unit operation since there is no physical correspondence.
+The inlet serves as a mass source in the network of unit operations.
+Consequently, it only possesses an outlet port and no inlet port.
+Note that an inlet unit operation can provide arbitrary many components and there can be arbitrary many inlet unit operations in a network.
+
An inlet unit operation provides a feed in which the concentration of each component is given by a profile.
+The most common profile is a piecewise cubic polynomial, which can both represent discontinuous signals (e.g., pulse or step) and smooth \(C^2\) signals (cubic spline):
where \(0 \leq t_1 < t_2 < \dots < t_{N_{\text{sect}} + 1} \leq T_{\text{sim}}\) is a decomposition of the simulation time interval \(\left[0, T_{\text{sim}}\right]\) into pieces \(\left[t_k, t_{k+1} \right)\).
+On each piece, the profile is given by a cubic (fourth order) polynomial shifted to the beginning \(t_k\) of the piece.
The lumped rate model with pores [3, 4] deviates from the general rate model (see Section General rate model (GRM)) by neglecting pore diffusion.
+The particle phase \(c^p_j\) is still there, but no mass transfer happens except for binding and film diffusion.
+Hence, the model equations are given by
The radial flow LRMP describes transport of solute molecules through the interstitial column volume by radial convective flow, band broadening caused by radial dispersion, mass transfer resistance through a stagnant film around the beads, and adsorption to the inner bead surfaces.
+
The main assumptions are:
+
+
The shells of the column are homogenous in terms of interstitial volume, fluid flow, and distribution of components.
+Thus, only one spatial coordinate in radial direction \(\rho\) is needed and axial transport is neglected in the column bulk volume.
+
The bead radii \(r_{p}\) are much smaller than the column radius \(\mathrm{P}-\mathrm{P}_c\), with \(\mathrm{P}\) and \(\mathrm{P}_c\) being the inner and outer column radius respectively, and the column length \(L\).
+Therefore, the beads can be seen as continuously distributed inside the column (i.e., at each point there is interstitial and bead volume).
+
The fluids are incompressible, i.e. the velocity field \(\mathrm{V} \colon \mathbb{R}^3 \to \mathbb{R}^3\) submits to \(\operatorname{div}\left( \mathrm{V} \right) \equiv 0\).
+That is, the volumetric flow rate at the inner and outer column radius are the same.
+
+
Consider a hollow (double walled) column with inner column diameter \(\mathrm{P}_c>0\) and outer diameter \(\mathrm{P}>\mathrm{P}_c\), filled with spherical beads of (possibly) multiple types with radius \(r_{p,j} \ll L\) (see Fig. 2), where \(j\) is the particle type index. The mass balance in the interstitial column volume is described by
The lumped rate model without pores [3, 4] deviates from the lumped rate model with pores (see Section Lumped rate model with pores (LRMP)) by neglecting pores completely.
+The particle phase \(c^p\) is removed and the porosity \(\varepsilon_t\) is taken as total porosity
Note that by setting \(\varepsilon_t = 1\), removing all bound states by setting \(N_{\text{bnd},i} = 0\) for all components \(i\), and applying no binding model, a dispersive plug flow reactor (DPFR) is obtained.
+For the specification of flow rate and direction, the same holds as for the general rate model (see Section Specification of flow rate / velocity and direction).
The radial flow LRM describes transport of solute molecules through the interstitial column volume by radial convective flow, band broadening caused by radial dispersion, and adsorption to the bead surfaces.
+
The main assumptions are:
+
+
The shells of the column are homogenous in terms of interstitial volume, fluid flow, and distribution of components.
+Thus, only one spatial coordinate in radial direction \(\rho\) is needed and axial transport is neglected in the column bulk volume.
+
The bead radii \(r_{p}\) are much smaller than the column radius \(\mathrm{P}-\mathrm{P}_c\), with \(\mathrm{P}\) and \(\mathrm{P}_c\) being the inner and outer column radius respectively, and the column length \(L\).
+Therefore, the beads can be seen as continuously distributed inside the column (i.e., at each point there is interstitial and bead volume).
+
The fluids are incompressible, i.e. the velocity field \(\mathrm{V} \colon \mathbb{R}^3 \to \mathbb{R}^3\) submits to \(\operatorname{div}\left( \mathrm{V} \right) \equiv 0\).
+That is, the volumetric flow rate at the inner and outer column radius are the same.
+
+
Consider a hollow (double walled) column with inner column diameter \(\mathrm{P}_c>0\) and outer diameter \(\mathrm{P}>\mathrm{P}_c\), filled with spherical beads. The mass balance in the interstitial column volume is described by
The Multichannel Transport (MCT) model in CADET is based on a class of compartment models introduced by Jonas Bühler et al. [9], which was originally developed in the field of plant sciences.
+There it is used to determine transport and storage parameters of radioactive labelled tracer molecules from positron emission tomography (PET) or magnetic resonance imaging (MRI) based experimental data.
+The model represents main functions of vascular transport pathways: axial transport of the tracer, diffusion in axial direction, lateral exchange between compartments and storage of tracer in compartments. Here, the axial direction represents the length of the stem of the plant and the lateral dimension its cross section. In the MCT context, the compartments of the model class are also referred to as channels.
+
The same model equations arise in describing other biological and technical processes outside of the field of plant sciences, where solutes are transported and exchanged between spatially separated compartments, for example liquid-liquid chromatography (LLC). Here, components in a mixture are separated based on their interactions with two immiscible phases of a biphasic solvent system [10]. The MCT model represents these phases by channels with respective transport and exchange properties. While the current implementation only covers linear driving forces for the exchange processes, the reaction module in CADET allows to add non-linear driving forces for the exchange processes and other chemical reactions in the channels.
+
The MCT model equations are given for all channels \(l \in \{1, \dots, N_k\}\) and components \(i \in \{1, \dots, N_c\}\) by
where \(e^i_{lk}\) denotes the exchange rate of component \(i\) from channel \(l\) to channel \(k\), and \(A_l\) denotes the cross section area of channel \(l\).
+The equations are complemented by Danckwerts boundary conditions [8]
The MCT model describes \(N_k\) one-dimensional spatially parallel channels (see Fig. 6).
+In each channel \(l\), molecules of different species \(i\), represented by a liquid phase concentration \(c^\ell_{i,l}\), can be transported with flux velocities \(v_{i,l}\) while undergoing axial diffusion: \(D_{\text{ax},i,l}\).
+Molecules can be laterally exchanged between any pair of channels \(l\) and \(k\) with rate constant \(e^i_{lk}\).
+We note that the exchange fluxes are computed from the exchange rates w.r.t. the source channel volume, that is, channels with the same exchange rate but different volume will produce differently large exchange fluxes.
+For further elaboration on this, please refer to the second use-case section below.
+If reactions are considered, the term \(f_{\text{react},i,l}\left(c^\ell_l\right)\) represents the net change of concentration \(c^\ell_{il}\) due to reactions in channel \(l\) involving component \(i\).
Fig. 6 Illustration of the Multichannel Transport model class and relevant parameters.
+Figure taken from Jonas Bühler et al. [9].¶
+
+
+
The cross-section area \(A_N\) is individually specified for each channel (see Fig. 7). The MCT is agnostic to the shape of these cross sections, while their ratio determines the distribution of the volumetric flow.
+
+
+
+
Fig. 7 Scheme of exemplary channels with different cross section areas and arbitrary exchange between channels.¶
The MCT can be used to model tracer transport in plants, following Jonas Bühler et al. [9].
+There, the model class is defined by a system of partial differential equations:
\(\boldsymbol{\rho}=({\rho}_1 \dots {\rho}_N)^T\) is the tracer density within each channel \(N\) at position \(x\) and time \(t\).
+
The coupling matrix \(A\) contains exchange rates \(e_{lk}\) describing the lateral tracer transport from channel \(l\) to channel \(k\). All diagonal elements \(e_{ll}\) in the first term are zero indicating there is no tracer exchange of one channel with itself. The second term ensures mass conservation and removes exchanged tracer from each channel respectively, by subtracting the sum of all exchange rates of a row (and therefore channel) from the diagonal. The third term describes the decay of a radioactive tracer at a tracer specific rate \(\lambda\).
All parameters can be zero to exclude the respective mechanism from the model.
+A chart of all resulting valid models of the model family can be found in Bühler et al. [9].
+
+
+
Use-case: Lumped Rate Model without pores and linear kinetic binding¶
+
The MCT can be used to model a LRM with linear binding, if specific parameters are chosen.
+To demonstrate this, we derive the LRM with linear binding equations from the MCT defined above.
+
We consider the MCT with two channels, which are used to represent the liquid and solid phase of the LRM, and only take one component into account, for the sake of brevity.
+The channel volumes \(V_1, V_2 > 0\) and cross section areas \(A_1,A_2>0\) are chosen according to the total column porosity (here \(\varepsilon_t \in (0,1)\) of the LRM, i.e. e.g. \(A_1 = \varepsilon_t A\), with \(A\) being the LRM column cross section area.
+We set the transport parameters of the second channel to zero, change notation for the concentrations, \(c_{0,1}^\ell, c_{0,2}^\ell \rightarrow c^\ell, c^s\), and get
To model the linear binding, we define the exchange rates according to the adsorption and desorption rates and adjust for the channel volumes:
+Since the binding fluxes are computed from the binding rates w.r.t bead surface area (i.e. solid volume), we need to adjust the exchange rate from the first to the second channel accordingly; remember that exchange fluxes are computed based on exchange rates w.r.t channel (in this case liquid) volume.
+That is, we define \(e_{12}^0 = k_a A_2 / A_1 = k_a \frac{1-\varepsilon_t}{\varepsilon_t}\) and \(e_{12}^0 = k_d\) and get
Adding \(\frac{1-\varepsilon_t}{\varepsilon_t}\) times the second channel equation to the first channel equation, we get the standard formulation of the Lumped rate model without pores (LRM) with (kinetic) linear binding:
A system outlet unit operation is a pseudo unit operation since there is no physical correspondence.
+The outlet serves as a sink (terminal node) in the network of unit operations.
+Since any terminal node in the network is a sink (see Section Networks of unit operations), outlet unit operations are not strictly necessary.
+However, in some applications (e.g., SMB) only a certain fraction of a unit operation’s output is taken out of the system and the rest is recycled.
+In this case, outlet unit operations are required in order to avoid unbalanced mass flow in the other unit operations.
+
Outlets can also be of help if the output of multiple unit operations merges together leaving the network.
+Instead of manually adding the streams together in a post-processing step, the unit operations can be connected to the same outlet unit.
+
+
+ You're reading an old version of this documentation.
+ For the latest released version, please have a look at v5.0.0.
+
+
+
+
+
+
General CADET-Core:
+
+
Leweke, S.; von Lieres, E.: ChromatographyAnalysisandDesignToolkit(CADET)<https://doi.org/10.1016/j.compchemeng.2018.02.025>_, Computers and Chemical Engineering 113 (2018), 274?294.
+
von Lieres, E.; Andersson, J.: Afastandaccuratesolverforthegeneralratemodelofcolumnliquidchromatography<https://doi.org/10.1016/j.compchemeng.2010.03.008>_, Computers and Chemical Engineering 34,8 (2010), 1180?1191.
+
+
CADET-Core numerics:
+
+
Breuer, J. M.; Leweke, S.; Schm?lder, J.; Gassner, G.; von Lieres, E.: SpatialdiscontinuousGalerkinspectralelementmethodforafamilyofchromatographymodelsinCADET<https://doi.org/10.1016/j.compchemeng.2023.108340>_, Computers and Chemical Engineering 177 (2023), 108340.
+
Leweke, S.; von Lieres, E.: Fastarbitraryordermomentsandarbitraryprecisionsolutionofthegeneralratemodelofcolumnliquidchromatographywithlinearisotherm<http://dx.doi.org/10.1016/j.compchemeng.2015.09.009>_, Computers and Chemical Engineering 84 (2016), 350?362.
+
P?ttmann, A.; Schnittert, S.; Naumann, U.; von Lieres, E.: Fastandaccurateparametersensitivitiesforthegeneralratemodelofcolumnliquidchromatography<http://dx.doi.org/10.1016/j.compchemeng.2013.04.021>_, Computers and Chemical Engineering 56 (2013), 46?57.
+
+
Selected applications and use-cases of CADET-Core:
+
+
Heymann, W.; Glaser, J.; Schlegel, F.; Johnson, W.; Rolandi, P.; von Lieres, E.: Advancedscoresystemandautomatedsearchstrategiesforparameterestimationinmechanisticchromatographymodeling<https://doi.org/10.1016/j.chroma.2021.462693>_, Journal of Chromatography A 1661 (2022): 462693.
+
He, Q.-L.; Leweke, S.; von Lieres, E.: Efficientnumericalsimulationofsimulatedmovingbedchromatographywithasingle-columnsolver<http://doi.org/10.1016/j.compchemeng.2017.12.022>_, Computers and Chemical Engineering 111 (2018), 183?198.
This chapter gives an overview of the simulation process and the different steps involved.
+
CADET uses a backward-differentiation-formula (BDF) time discretization as implemented by the IDAS solver from SUNDIALS [25].
+Each time step requires the solution of a nonlinear algebraic system of equations is performed by a Newton method.
+Since chromatographic systems can exhibit strong nonlinearity and stiff systems, the Jacobian of the equation system is always updated (i.e., an “exact” Newton method is used).
Time sections are used for various purposes, for example, for defining piecewise polynomials used as inlet profiles or external function, for changing operating conditions such as flow rates, or for changing the connectivity in a network of unit operations.
+A sequence of (one or more) time sections with smooth transitions is called a time slice (see Fig. 10).
+
A transition from one section to the next can either be smooth or discontinuous.
+On smooth transitions, the time integrator can just step over the section transition.
+Contrary to smooth transitions, a discontinuous transition requires some extra work in resetting the time integrator and finding consistent initial conditions for the next time slice.
+
+
+
+
Fig. 10 Time sections, time slices, and transitions between them¶
Time sections are specified by an array (SECTION_TIMES, see Tab. Group /solver/sections) which contains the \(t_i\) that denote the start- and endpoint of a time section \(\left[t_i, t_{i+1}\right]\).
+This means, that the array contains \(n+1\) values if there are \(n\) sections.
+The smoothness of a section transition is indicated by the array SECTION_CONTINUITY, which contains \(n-1\) elements if there are \(n\) sections.
In the setup phase, the model specification is checked and data structures are prepared for the simulation.
+The simulation can be run multiple times with different initial conditions, which also allows to continue a simulation.
+However, the model structure must not change after this point.
+This means, the different model and submodel types (e.g., unit operation model, binding model) as well as their discretization (i.e., number of cells) and structure (i.e., number of components, number of reactions) are fixed. On the contrary, their parameters (e.g., flow rates, porosities, dispersion coefficients) may change on different runs of a prepared simulation.
+
This assumption allows an accelerated simulation as there is no memory allocation performed during time integration.
At the beginning of the simulation and on discontinuous section transitions, consistent initial conditions have to be computed.
+In CADET, the general differential-algebraic equation (DAE)
+
+\[\begin{aligned}
+ F(t, y, \dot{y}, p) = 0
+\end{aligned}\]
+
consists of purely algebraic equations that do not contain \(\dot{y}\) and dynamic equations.
+Let \(\mathcal{I}_d\) be the index set of dynamic equations and \(\mathcal{I}_a\) the index set of algebraic equations.
+The general DAE can be decomposed into
+
+\[\begin{split}\begin{aligned}
+ M \dot{y}_{\mathcal{I}_d} + G_{\mathcal{I}_d}(t, y, p) &= 0, \\
+ G_{\mathcal{I}_a}(t, y, p) &= 0,
+\end{aligned}\end{split}\]
+
where \(M\) is the so called “mass matrix”, which essentially consist of the state time derivative Jacobian \(\partial F / \partial \dot{y}\).
+Furthermore, it is assumed that the Jacobian of the algebraic equations with respect to the algebraic variables \(\partial G_{\mathcal{I}_a} / \partial y_{\mathcal{I}_a}\) is invertible.
+Hence, the original DAE is of differential index 1.
+
Given \(y_{\mathcal{I}_d}\), consistently initialization means finding \(y_{\mathcal{I}_a}\), \(y_{\mathcal{I}_d}\), and \(\dot{y}\) such that the DAE holds at the initial time point \(t_0\) and can be solved for some non-empty time span.
+Thus, consistent initial conditions \(y_0\) and \(\dot{y}_0\) satisfy
+
+\[\begin{split}\begin{aligned}
+ 0 &= M \dot{y}_{\mathcal{I}_d} + G_{\mathcal{I}_d}\left(t_0, y, p\right), \\
+ 0 &= G_{\mathcal{I}_a}\left(t_0, y, p\right), \\
+ 0 &= \frac{\partial G_{\mathcal{I}_a}}{\partial t}\left(t_0, y, p\right) + \frac{\partial G_{\mathcal{I}_a}}{\partial y}\left(t_0, \dot{y}, p\right).
+\end{aligned}\end{split}\]
+
The last equation, which determines \(\dot{y}_{\mathcal{I}_a}\), arises from taking the total derivative with respect to time \(t\) of the second equation.
+
Concluding, a nonlinear algebraic equation system has to be solved in order to compute consistent initial conditions.
+The error in the solution of these systems is controlled by the ALGTOL setting (see Tab. Group /solver/time_integrator).
with consistent initial values \(y_0\) and \(\dot{y}_0\), the BDF discretization uses past time steps \(y\left( t_{\tau - i} \right)\) to compute the current \(\dot{y}\left(t_\tau\right)\) as
where \(t_\tau\) denotes some time step.
+The IDAS time integrator adaptively changes the step size \({\Delta t_\tau = t_\tau-t_{\tau-1}}\) and order \(1 \le q_{\tau} \le 5\) in each time step and automatically determines the corresponding coefficients \(\alpha_{\tau,i}\).
+This ansatz is inserted into the DAE and the resulting nonlinear algebraic equation system is solved for \(y_{\tau} = y\left( t_\tau \right)\) using a Newton method.
The Jacobian of \(H\), which is the linear combination of the partial derivatives \(\partial F / \partial y\) and \(\partial F / \partial \dot{y}\), can be calculated in two ways.
+The fastest way is the analytic computation, which is to be preferred if available.
+However, the implementation of the analytic Jacobian can be time consuming and complicated, especially when quickly testing new models.
+As a remedy, CADET offers to compute the complicated Jacobian \(\partial F / \partial y\) automatically by automatic differentiation (AD).
+The much simpler Jacobian \(\partial F / \partial \dot{y}\) has to be implemented manually.
The BDF order \(q_{\tau}\) and size of the time step \(t_\tau\) are chosen such that the error bounds are satisfied with minimal work.
+Equation 29 is solved with a Newton iteration using very few iterations (MAX_NEWTON_ITER from Table Group /solver/time_integrator) since the starting point is assumed to be close to the solution as the time steps are small.
+If the solution of the Newton iteration does not pass the convergence test, the step size \(t_\tau\) is reduced and the Newton iteration is tried again.
+This may happen at most MAX_CONVTEST_FAIL times, otherwise time integration is aborted with failure.
+Having a solution of the Newton iteration at hand, a local truncation error test is performed which controls the error of the BDF method.
+If this test fails, step size \(t_\tau\) and order \(q_{\tau}\) are adapted and the process restarts with solving the nonlinear system Eq. 29.
+The error test may be failed at most MAX_ERRTEST_FAIL times before time integration is aborted with failure.
+
Error bounds for the local truncation error test are specified by an absolute tolerance (ABSTOL) and a relative tolerance (RELTOL).
+Note that the relative tolerance only works for non-zero values, whereas zero values are accounted for by the absolute tolerance.
+For example, a relative tolerance of \(10^{-4}\) and absolute tolerance of \(10^{-8}\) requests \(3\) significant digits (correct digits after the comma in scientific notation) and considers all numbers with magnitude smaller than \(10^{-8}\) as \(0\).
+
The size of the first time step in a time slice is given by INIT_STEP_SIZE from Table Group /solver/time_integrator.
+If a simulation fails on the first time step, it might help to reduce the initial step size.
+It can also help to increase the error tolerances, at the cost of imprecise results over the whole course of the simulation.
+
It can happen that due to severe stiffness or ill-posed models a simulation may exceed its computational budget given by the maximum number of time steps (per time slice) MAX_STEPS.
+In this case, the formulation of the model should be checked and, if necessary, the error tolerances increased.
+Note that the number of time steps is independent of possible USER_SOLUTION_TIMES and refers to internal steps of the time integrator.
+
On the other extreme, the time integrator might jump over an important change in the solution or not capture some feature of the solution because of too large time steps.
+This can be avoided by specifying the maximum time step size MAX_STEP_SIZE.
+However, such a situation is unlikely to occur and can also be alleviated by placing a discontinuous section transition at the time of the event.
+
Note that while the error in time integration is controlled and can (in theory) be made arbitrarily small, the spatial discretization error is not.
+Hence, it is important and necessary to test different spatial resolutions (number of cells) in order to find a sufficiently accurate (but minimal) number of grid cells.
+This is particularly relevant for problems with steep fronts as a low spatial resolution adds a substantial amount of numerical dispersion to the solution.
Parameter sensitivities \(s = \partial y / \partial p\) of a solution \(y\) to the DAE with respect to some parameter \(p\) are required for various tasks, for example, parameter estimation, process design, and process analysis.
+The CADET simulator implements the forward sensitivity approach which creates a linear companion DAE for each sensitive parameter
+
+\[\begin{split}\begin{aligned}
+ 0 &= \frac{\mathrm{d}}{\mathrm{d}p} F(t, y, \dot{y}, p) = \frac{\partial F}{\partial y}(t, y, \dot{y}, p) \frac{\partial y}{\partial p} + \frac{\partial F}{\partial \dot{y}}(t, y, \dot{y}, p) \frac{\partial \dot{y}}{\partial p} + \frac{\partial F}{\partial p}(t, y, \dot{y}, p) \\
+ &= \frac{\partial F}{\partial y}(t, y, \dot{y}, p) s + \frac{\partial F}{\partial \dot{y}}(t, y, \dot{y}, p) \dot{s} + \frac{\partial F}{\partial p}(t, y, \dot{y}, p).
+\end{aligned}\end{split}\]
+
These linear DAEs depend on the solution \(y\), \(\dot{y}\) of the original DAE system.
+Consequently, the sensitivity systems are solved together with the original DAE system in a staggered approach [26].
+
After the nonlinear Eq. 29 has been successfully solved using Newton iteration (i.e., it has passed the convergence test), each sensitivity is solved using the same Newton iteration.
+If direct linear solvers were used, this iteration would convergence with a single iteration as there is no nonlinearity.
+The Newton method for the sensitivities performs at most MAX_NEWTON_ITER_SENS (see Table Group /solver/time_integrator) iterations.
+Assuming the convergence test has passed for each sensitivity, the local truncation error test is performed for the full set of variables (i.e., original system and sensitivities).
+The sensitivities can be excluded from the local truncation error test by setting ERRORTEST_SENS appropriately.
+Note that time integration step size is always affected by sensitivities due to possible convergence test failures.
+
While the Jacobians \(\partial F / \partial y\) and \(\partial F / \partial \dot{y}\) can be computed either analytically or via AD, the last term \(\partial F / \partial p\) is always computed by AD.
+In fact, the terms \(\partial F / \partial y\) and \(\partial F / \partial p\) can be computed by one AD-enabled evaluation of \(F\) using the vector mode with appropriate seed vectors [27].
+
A parameter sensitivity is specified by identifying the involved parameters, which can be more than one (see below).
+Parameters are identified by name and multiple indices, which may not all be used (see Tab. Group /input/sensitivity/param_XXX). Indices that are not used for identification (e.g., flow rate is independent of bound phase or component) are set to \(-1\). All other indices are zero-based.
+
Note that the sensitivity systems need to be consistently initialized, too.
+However, since only linear systems are involved, no nonlinear equation system has to be solved and the procedure is much simpler computationally.
The use of AD also enables support of meta parameters or joint parameters.
+Consider the situation in which several parameters \(p_1, p_2, \dots, p_n\) depend (linearly) on a single meta parameter \(p\)
+
+\[\begin{aligned}
+ p_i = p_i(p) = \alpha_i p \qquad \text{ for } i = 1, \dots, n
+\end{aligned}\]
+
and some coefficients \(\alpha_i \in \mathbb{R}\).
+Hence, the DAE residual function \(F\) becomes
In order to use this functionality, all parameters involved have to be specified in a single sensitivity instance (param_XXX group, see Tables Group /input/sensitivity and FFSensitivityParam) by using arrays for the name and indices instead of scalar values.
+The coefficients \(\alpha_i\) are provided in the SENS_FACTOR vector.
+
A simple example for a situation, which benefits from having a single meta parameter, would be a chain of unit operations in a network in which the sensitivity with respect to the flow rate is to be computed.
+Instead of computing the sensitivity with respect to each single flow rate and fusing them together in a postprocessing step, a meta parameter that maps to all flow rates can be introduced.
+
Note that nonlinear relationships between original parameter and meta parameters are supported by updating the coefficients \(\alpha_i\) before each simulation:
Georges Guiochon, Attila Felinger, Dean G. Shirazi, and Anita M. Katti. Fundamentals of Preparative and Nonlinear Chromatography. Elsevier Academic Press, Amsterdam, 2nd edition, 2006. ISBN 978-0-12-370537-2.
Thiemo C. Huuk, Tobias Hahn, Katharina Doninger, Jan Griesbach, Stefan Hepbildikler, and Jürgen Hubbuch. Modeling of complex antibody elution behavior under high protein load densities in ion exchange chromatography using an asymmetric activity coefficient. Biotechnology Journal, 12(3):1600336, March 2017. URL: http://doi.wiley.com/10.1002/biot.201600336, doi:10.1002/biot.201600336.
K. Westerberg, E. Broberg Hansen, M. Degerman, T. Budde Hansen, and B. Nilsson. Model-Based Process Challenge of an Industrial Ion-Exchange Chromatography Step. Chemical Engineering & Technology, 35(1):183–190, January 2012. URL: http://doi.wiley.com/10.1002/ceat.201000560, doi:10.1002/ceat.201000560.
Wendi Zhang, Todd Przybycien, Johannes Schmölder, Samuel Leweke, and Eric von Lieres. Solving crystallization/precipitation population balance models in cadet, part i: nucleation growth and growth rate dispersion in batch and continuous modes on nonuniform grids. Computers & Chemical Engineering, pages 108612, 2024. doi:https://doi.org/10.1016/j.compchemeng.2024.108612.
+
+
+[25]
+
Alan C. Hindmarsh, Peter N. Brown, Keith E. Grant, Steven L. Lee, Radu Serban, Dan E. Shumaker, and Carol S. Woodward. SUNDIALS: Suite of nonlinear and differential/algebraic equation solvers. ACM Transactions on Mathematical Software, 31(3):363–396, September 2005. URL: http://portal.acm.org/citation.cfm?doid=1089014.1089020, doi:10.1145/1089014.1089020.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+