Some editing

docs/contribute/core.qmd

@@ -4,15 +4,15 @@ title: "Julia core development"
 
 # Julia core overview
 
-The computational core is one of the components of Ribasim as illustrated in the [component overview](index.qmd##sec-components).
+The computational core is one of the components of Ribasim as illustrated in the [component overview](../index.qmd#sec-components).
 
 The computational process can be divided in three phases:
 
 - Model initialization
 - Running the simulation loop
 - Writing the output files
 
-A more detailed sequence diagram of the simulation loop is available at the [Core](./index.qmd#sec-simulationloop) home page.
+A more detailed sequence diagram of the simulation loop is available at the [core](index.qmd#sec-simulationloop) home page.
 
 # Set up the developer environment
 
@@ -46,7 +46,7 @@ Make sure to have the correct environment when opening your IDE by running `pixi
 You will want to run the testsuite on a regular basis to check if your changes had unexpected side effects.
 It is also a good way to find out if your development environment is set up correctly.
 
-Before the tests can run, you need to [prepare model input](./python.qmd#prepare-model-input).
+Before the tests can run, you need to [prepare model input](python.qmd#prepare-model-input).
 
 With the root of the repository as your working directory you can start the REPL with activated `Ribasim` environment by running the following:
 

docs/contribute/qgis.qmd

@@ -39,7 +39,7 @@ Then simply call `pixi run test-ribasim-qgis`.
 After installing the plugins via `pixi run install-qgis-plugins`.
 Extra debugging tools are also installed in QGIS that is installed within your pixi environment.
 
-After you have started `pixi run qgis`, you can make alterations to the python code and use the [Plugin Reloader](https://github.com/borysiasty/plugin_reloader) to reload the plugin without restarting QGIS.
+After you have started `pixi run qgis`, you can make alterations to the Python code and use the [Plugin Reloader](https://github.com/borysiasty/plugin_reloader) to reload the plugin without restarting QGIS.
 The shortcut in QGIS is `CTRL+F5`.
 
 It is also possible to connect the debugger of Visual Studio Code.

docs/core/index.qmd

@@ -5,15 +5,15 @@ title: "Julia core"
 With the term "core", we mean the computational engine of Ribasim. As detailed in the
 [usage](usage.qmd) documentation, it is generally used as a command line tool.
 
-A quick overview of the model concept is available at the [Home](../index.qmd#sec-conceptualization) page, while a more indepth discussion is available on the [model concept](modelconcept.qmd) page.
+A quick overview of the model concept is available at the [home page](../index.qmd#sec-concept), while a more in depth discussion is available on the [model concept](modelconcept.qmd) page.
 The theory is described on the [equations](equations.qmd) page, and more in-depth numerical considerations are described on the [numerical considerations](numerics.qmd) page. As allocation is a large and self-contained part of the Ribasim core, it is described on the separate [allocation](allocation.qmd) page. Input validation is described on the [validation](validation.qmd) page.
 
 The core is implemented in the [Julia programming language](https://julialang.org/), and
 can be found in the [Ribasim repository](https://github.com/Deltares/Ribasim) under the
 `core/` folder. For developers we also advise to read the
 [developer documentation](../contribute/core.qmd).
 
-An overview of all components is given on the [Home page](../index.qmd#sec-components)
+An overview of all components is given on the [home page](../index.qmd#sec-components)
 
 # The simulation loop {#sec-simulationloop}
 
@@ -80,9 +80,9 @@ sequenceDiagram
   end
 ```
 
-**Nested allocation** {#sec-nestedallocation}
+# Nested allocation {#sec-nested-allocation}
 
-Since water systems may be extensive, like in the Netherlands, Ribasim models may become massive networks with multiple 10,000’s of nodes.
+Since water systems may be extensive, like in the Netherlands, Ribasim models may become large networks with over ten thousand nodes.
 To keep a proper functioning allocation concept under these circumstances, the modeller can decompose the network domain into a main network and multiple sub-networks.
 The allocation will then be conducted in three steps:
 
@@ -120,7 +120,6 @@ allocation_subNetwork->>user: allocated
 user->>basin: abstracted
 ```
 
-
 # Coupling
 
 Ribasim can also be coupled to other kernels with the help of iMOD Coupler.

docs/core/modelconcept.qmd

@@ -1,14 +1,15 @@
 ---
 title: Model concept
 ---
-A brief summary of the conceptualization is given on the documentation [home page](../index.qmd#sec-conceptualization)
+A brief summary of the concept is given on the documentation [home page](../index.qmd#sec-concept).
 As indicated, the model concept is organized in three layers:
 
 - a physical layer representing water bodies and associated infrastructure,
 - a rule-based control layer to manage the infrastructure, and
 - a priority-based allocation layer to take centralized decisions on user abstractions.
 
-# The physical layer
+# Physical layer
+
 ## Water balance equations
 
 The water balance equation for a drainage basin [@enwiki:1099736933] can be defined by a first-order ordinary differential equation (ODE), where the change of the storage $S$ over time is determined by the inflow fluxes minus the outflow fluxes.
@@ -109,28 +110,17 @@ In addition to free flowing waterbodies, a watersystem typically has structures
 free flowing conditions or structures.
 The following type of connector nodes are available for this purpose:
 
-- [TabulatedRatingCurve](.\usage.qmd#sec-tabulatedratingcurve): one-directional flow based on upstream head. Node type typically used for gravity flow conditions either free flowing open water channels
+- [TabulatedRatingCurve](.\usage.qmd#sec-tabulated-rating-curve): one-directional flow based on upstream head. Node type typically used for gravity flow conditions either free flowing open water channels
 or over a fixed structure.
-- [LinearResistance](.\usage.qmd#sec-linearresistance): bi-directional flow based on head difference and linear resistance. Node type typically used for bi-directional flow
+- [LinearResistance](.\usage.qmd#sec-linear-resistance): bi-directional flow based on head difference and linear resistance. Node type typically used for bi-directional flow
 situations or situations where head difference over a structure determines its actual flow capacity.
-- [ManningResistance](.\usage.qmd#sec-manningresistance): bi-directional flow based on head difference and resistance using Manning-Gauckler formula. Same usage as LinearResistance,
+- [ManningResistance](.\usage.qmd#sec-manning-resistance): bi-directional flow based on head difference and resistance using Manning-Gauckler formula. Same usage as LinearResistance,
 providing a better hydrological meaning to the resistance parameterization.
 - [Pump](.\usage.qmd#sec-pump): one-directional structure with a set flow rate. Node type typically used in combination with control to force water over the edge.
 - [Outlet](.\usage.qmd#sec-outlet): one-directional gravity structure with a set flow rate. Node type typically used in combination with control to force water over the edge, even if
 their is a mismatch in actual hydraulic capacity. The node type has an automated mechanism to stop the flow when the head difference is zero.
-- [FractionalFlow](.\usage.qmd#sec-fractionalflow): to split an outflow over multiple edges based on a flow fraction. Node type is typically used for diversions or bifurcations with a known and fixed ratio.
+- [FractionalFlow](.\usage.qmd#sec-fractional-flow): to split an outflow over multiple edges based on a flow fraction. Node type is typically used for diversions or bifurcations with a known and fixed ratio.
 
 The control layer can activate or deactivate nodes, set flow rates for the Pump and Outlet, or choose different parameterizations for TabulatedRatingCurve, LinearResistance, ManningResistance or FractionalFlow.
 
 Connector nodes are required within a Ribasim network to determine the flow exchange between basins.
-
-# The control layer
-## Discrete Control
-To do:
-
-## Pid Control
-To do.
-
-
-# Example situations
-To do: take example situations from the real world  and explain how they can be modelled, if possible with pro's and cons.

docs/core/usage.qmd

@@ -23,7 +23,7 @@ Usage: ribasim 'path/to/model/ribasim.toml'
 
 Ribasim has a single configuration file, which is written in the [TOML](https://toml.io/)
 format. It contains settings, as well as paths to other input and output files.
-Ribasim expects the geo-package database [database.gpkg](./usage.qmd#sec-geopackage) as well as any (optional) arrow input files to be available in the input_dir.
+Ribasim expects the GeoPackage database [database.gpkg](usage.qmd#sec-geopackage) as well as optional Arrow input files to be available in the input_dir.
 
 ```{.toml include="../../core/test/docs.toml"}
 ```
@@ -144,7 +144,7 @@ objects such as weirs might have specific identification codes. Additional colum
 added to tables. The column names should be prefixed with `meta_`. They will not be used in
 computations or validated by the Julia core.
 
-The ribasim-python library will automatically add the `meta_` prefix to non-standard columns.
+The Ribasim Python library will automatically add the `meta_` prefix to non-standard columns.
 Column names already prefixed with `meta_` will not be updated.
 
 # Node {#sec-node}
@@ -226,7 +226,7 @@ There are currently 2 possible edge types:
   way.
 2. "control": The control edges define which nodes are controlled by a particular control node.
   Control edges should always point away from the control node.
-  The edges between the control node and the nodes it *listens* to are *not* present in `Edge \ static`, these are defined in [Control / condition](usage.qmd#sec-condition)
+  The edges between the control node and the nodes it *listens* to are *not* present in `Edge`, these are defined in [`DiscreteControl / condition`](usage.qmd#sec-discrete-control)
 
 column                | type     | restriction
 --------------------- | -------- | -----------
@@ -373,7 +373,7 @@ The table is sorted by time, and per time the same `edge_id` order is used, thou
 Flows that are added to the model at a node, have a missing `edge_id`, and identical `from_node_id` and `to_node_id`.
 Flows out of the model always have a negative sign, and additions a positive sign.
 
-# FractionalFlow {#sec-fractionalflow}
+# FractionalFlow {#sec-fractional-flow}
 
 Lets a fraction (in [0,1]) of the incoming flow trough.
 
@@ -383,7 +383,7 @@ node_id       | Int     | -            | sorted
 control_state | String  | -            | (optional) sorted per node_id
 fraction      | Float64 | -            | in the interval [0,1]
 
-# TabulatedRatingCurve {#sec-tabulatedratingcurve}
+# TabulatedRatingCurve {#sec-tabulated-rating-curve}
 
 This table is similar in structure to the Basin profile. The TabulatedRatingCurve gives a
 relation between the storage of a connected Basin (via the outlet level) and its outflow.
@@ -510,7 +510,7 @@ abstracted            | Float64
 Currently the stored demand and abstraction rate are those at the allocation timepoint (and the abstraction rate is based on the previous allocation optimization). In the future these will be an average over the previous allocation timestep.
 :::
 
-# LevelBoundary {#sec-levelboundary}
+# LevelBoundary {#sec-level-boundary}
 
 Acts like an infinitely large basin where the level does not change by flow.
 This can be connected to a basin via a `LinearResistance`.
@@ -539,7 +539,7 @@ node_id   | Int      | -            | sorted
 time      | DateTime | -            | sorted per node_id
 level     | Float64  | $m$          | -
 
-# FlowBoundary {#sec-flowboundary}
+# FlowBoundary {#sec-flow-boundary}
 
 Pump water to a destination node.
 We require that the edge connecting the flow boundary to the Basin should point towards the basin,
@@ -570,7 +570,7 @@ node_id   | Int      | -            | sorted
 time      | DateTime | -            | sorted per node_id
 flow_rate | Float64  | $m^3 s^{-1}$ | non-negative
 
-# LinearResistance {#sec-linearresistance}
+# LinearResistance {#sec-linear-resistance}
 
 Flow proportional to the level difference between the connected basins.
 
@@ -581,7 +581,7 @@ control_state | String  | -            | (optional) sorted per node_id
 active        | Bool    | -            | (optional, default true)
 resistance    | Float64 | $sm^{-2}$    | -
 
-# ManningResistance {#sec-manningresistance}
+# ManningResistance {#sec-manning-resistance}
 
 Flow through this connection is estimated by conservation of energy and the Manning-Gauckler formula to estimate friction losses.
 
@@ -606,11 +606,11 @@ column                | type    | unit         | restriction
 ---------             | ------- | ------------ | -----------
 node_id               | Int     | -            | sorted
 
-# DisceteControl {#sec-discretecontrol}
+# DisceteControl {#sec-discrete-control}
 
 DiscreteControl is implemented based on [VectorContinuousCallback](https://docs.sciml.ai/DiffEqDocs/stable/features/callback_functions/#VectorContinuousCallback).
 
-## DiscreteControl / condition {#sec-condition}
+## DiscreteControl / condition
 
 The condition schema defines conditions of the form 'the discrete_control node with this node id listens to whether the given variable of the node with the given listen feature id is grater than the given value'. If the condition variable comes from a time-series, a look ahead $\Delta t$ can be supplied.
 
@@ -622,7 +622,7 @@ variable          | String   | -       | must be "level" or "flow_rate", sorted
 greater_than      | Float64  | various | sorted per variable
 look_ahead        | Float64  | $s$     | Only on transient boundary conditions, non-negative (optional, default 0)
 
-## DiscreteControl / logic {#sec-logic}
+## DiscreteControl / logic
 
 The logic schema defines which control states are triggered based on the truth of the conditions a discrete_control node listens to.
 DiscreteControl is applied in the Julia core as follows:
@@ -652,7 +652,7 @@ control_node_id | Int
 truth_state     | String
 control_state   | String
 
-# PidControl {#sec-pidcontrol}
+# PidControl {#sec-pid-control}
 
 The PidControl node controls the level in a basin by continuously controlling the flow rate of a connected pump or outlet. See also [PID controller](https://en.wikipedia.org/wiki/PID_controller). When A PidControl node is made inactive, the node under its control retains the last flow rate value, and the error integral is reset to 0.