fill in cross-links, check TODOs

docs/src/concepts/2_modifications.md

@@ -23,7 +23,7 @@ the semantics of the model or erase the previous changes by carelessly adding
 the modifications.
 
 Here, we show how to construct the modifications. Their semantics is similar to
-hte [variant-generating functions](TODO), which receive a model (of type
+the [variant-generating functions](1_screen.md), which receive a model (of type
 [`MetabolicModel`](@ref)), and are expected to create another (modified) model.
 Contrary to that, modifications receive both the [`MetabolicModel`](@ref) and a
 JuMP model structure, and are expected to cause a side effect on the latter.

docs/src/distributed/1_functions.md

@@ -22,7 +22,7 @@ You may run your analyses in parallel to gain speed-ups. The usual workflow in
    "as usual".
 
 Specific documentation is available about [running parallel analysis
-locally](TODO) and [running distributed analysis in HPC clusters](TODO).
+locally](2_parallel.md) and [running distributed analysis in HPC clusters](3_slurm.md).
 
 ## Functions that support parallelization
 
@@ -40,10 +40,12 @@ Notably, the screening functions are reused to run many other kinds of analyses
 which, in turn, inherit the parallelizability. This includes a wide range of
 functionality, including analyses such as:
 
-- [single and multiple gene deletions](TODO) (and other genetic modifications),
-- [modifications of the reaction spectrum](TODO) (e.g., disabling reactions)
+- [single and multiple gene deletions](../examples/07_gene_deletion.md) (and other
+  genetic modifications),
+- [modifications of the reaction
+  spectrum](../examples/07_restricting_reactions.md) (e.g., disabling reactions)
 - advanced envelope-scanning analyses,
-- [growth media exploration](TODO) (e.g., metabolite depletion)
+- [growth media exploration](../examples/11_growth.md) (e.g., metabolite depletion)
 
 ## Mitigating parallel inefficiencies
 
@@ -65,9 +67,10 @@ that reduce the parallel efficiency, which can be summarized as follows:
   round-trip-time to the worker processes. Do not use unnecessary
   parallelization for small tasks.
 - Transferring large amounts of data among workers may hamper parallel
-  efficiency. Use [the system of model variants](TODO) to avoid transferring
-  many similar models to the workers, and [model serialization
-  functionality](TODO) to quickly distribute share large models to the workers.
+  efficiency. Use [the system of model variants](../concepts/1_screen.md) to avoid
+  transferring many similar models to the workers, and [model serialization
+  functionality](4_serialized.md) to quickly distribute share large models to the
+  workers.
 
 !!! note "Cost of the distribution and parallelization overhead"
     Before allocating extra resources into the distributed execution, always

docs/src/examples/01_loading.jl

@@ -64,10 +64,10 @@ reactions(mat_model)[1:5]
 
 reactions(json_model)[1:5]
 
-# You can use the [generic accessors](TODO) to gather more information about
-# the model contents, [convert the models](TODO) into formats more suitable for
-# hands-on processing, and [export them](TODO) back to disk after the
+# You can use the [generic accessors](03_exploring.md) to gather more information about
+# the model contents, [convert the models](02_convert_save.md) into formats more suitable for
+# hands-on processing, and export them back to disk after the
 # modification.
 #
-# All model types can be directly [used in analysis functions](TODO), such as
+# All model types can be directly [used in analysis functions](05a_fba.md), such as
 # [`flux_balance_analysis`](@ref).

docs/src/examples/02_convert_save.jl

@@ -53,8 +53,8 @@ t = @elapsed deserialize("myModel.stdmodel")
 
 # ## Converting and saving a modified model
 
-# To modify the models easily, it is useful to convert them to [a format that
-# simplifies this modification](TODO), such as [`CoreModel`](@ref) or
+# To modify the models easily, it is useful to convert them to a format that
+# simplifies this modification, such as [`CoreModel`](@ref) or
 # [`StandardModel`](@ref):
 
 sm = convert(StandardModel, sbml_model)
@@ -68,7 +68,7 @@ sm = load_model(StandardModel, "e_coli_core.json")
 
 sm.reactions["PFK"].ub = 10.0
 
-# After [possibly applying more modifications](TODO), you can again save the
+# After [possibly applying more modifications](04_standardmodel.md), you can again save the
 # modified model in a desirable exchange format:
 
 save_model(sm, "modified_e_coli.json")

docs/src/examples/05a_fba.jl

@@ -47,6 +47,3 @@ flux_balance_analysis_dict(model, Tulip.Optimizer)
 
 using GLPK
 flux_balance_analysis_dict(model, GLPK.Optimizer)
-
-# An overview of solver properties relevant for COBREXA.jl can be [found
-# here](TODO).

docs/src/examples/05b_fba_mods.jl

@@ -14,12 +14,12 @@ using COBREXA, GLPK, Tulip
 
 model = load_model("e_coli_core.xml")
 
-# `COBREXA.jl` supports [many modifications](TODO), which include changing
-# objective sense, optimizer attributes, flux constraints, optimization
-# objective, reaction and gene knockouts, and others. These modifications are
-# applied to the optimization built within the supplied optimizer (in this case
-# GLPK) in order as they are specified. User needs to manually ensure that the
-# modification ordering is sensible.
+# `COBREXA.jl` supports [many modifications](../concepts/2_modifications.md),
+# which include changing objective sense, optimizer attributes, flux
+# constraints, optimization objective, reaction and gene knockouts, and others.
+# These modifications are applied to the optimization built within the supplied
+# optimizer (in this case GLPK) in order as they are specified. User needs to
+# manually ensure that the modification ordering is sensible.
 
 # The following example applies multiple different (although partially
 # nonsential) modifications to the *E.  Coli* core model:

docs/src/examples/06_fva.jl

@@ -4,7 +4,7 @@
 # core model.
 
 # As usual, it is not already present, download the model and load the required
-# packages. We picked the GLPK solver, but [others may work as well](TODO):
+# packages. We picked the GLPK solver, but others may work as well:
 
 !isfile("e_coli_core.xml") &&
     download("http://bigg.ucsd.edu/static/models/e_coli_core.xml", "e_coli_core.xml")
@@ -25,7 +25,8 @@ flux_variability_analysis(model, GLPK.Optimizer; bounds = objective_bounds(0.99)
 #
 # A dictionary-returning variant in [`flux_variability_analysis_dict`](@ref),
 # returns the result in a slightly more structured way. At the same time, we
-# can specify additional [modifications](TODO) to be applied to the model:
+# can specify additional [modifications](../concepts/2_modifications.md) to be
+# applied to the model:
 
 min_fluxes, max_fluxes = flux_variability_analysis_dict(
     model,

docs/src/examples/07_restricting_reactions.jl

@@ -71,7 +71,8 @@ original_flux["BIOMASS_Ecoli_core_w_GAM"], restricted_flux["BIOMASS_Ecoli_core_w
 
 running_reactions = [(rid, x) for (rid, x) in original_flux if abs(x) > 1e-3]
 
-# ...and choke these reactions to half that flux, computing the relative loss of the biomass production::
+# ...and choke these reactions to half that flux, computing the relative loss
+# of the biomass production::
 
 screen(
     model,
@@ -136,5 +137,5 @@ ax.yticklabelalign = (:right, :center)
 f
 
 # Remember that [`screen`](@ref) can be parallelized just [by supplying worker
-# IDs](TODO). Use that to gain significant speedup with analyses of larger
-# models.
+# IDs](../distributed/1_functions.md). Use that to gain significant speedup
+# with analyses of larger models.

docs/src/examples/08_pfba.jl

@@ -30,11 +30,11 @@ model = load_model("e_coli_core.xml")
 #md #       you use. Commercial solvers like `Gurobi`, `Mosek`, `CPLEX`, etc.
 #md #       require less user engagement.
 
-# Running of basic pFBA is perfectly analogous to running of [FBA](TODO) and
-# other analyses. We add several modifications that improve the solution (using
-# functions [`silence`](@ref), and [`change_optimizer_attribute`](@ref)), and
-# fix the glucose exchange (using [`change_constraint`](@ref)) in order to get
-# a more reasonable result:
+# Running of basic pFBA is perfectly analogous to running of [FBA](05a_fba.md)
+# and other analyses. We add several modifications that improve the solution
+# (using functions [`silence`](@ref), and
+# [`change_optimizer_attribute`](@ref)), and fix the glucose exchange (using
+# [`change_constraint`](@ref)) in order to get a more reasonable result:
 
 fluxes = parsimonious_flux_balance_analysis_dict(
     model,

docs/src/examples/12_mmdf.jl

@@ -113,7 +113,7 @@ reaction_standard_gibbs_free_energies = Dict(
 # solution that is used as a reference.
 #
 # We can generate a well-suited reference solution using e.g. the [loopless
-# FBA](TODO):
+# FBA](09_loopless.md):
 
 flux_solution = flux_balance_analysis_dict(
     model,

docs/src/examples/14_smoment.jl

@@ -89,11 +89,12 @@ flux_balance_analysis_dict(smoment_model, GLPK.Optimizer)
 # reactions are indeed split in the model! The underlying mechanism is provided
 # by [`reaction_flux`](@ref) accessor.)
 
-# [Variability](TODO) of the sMOMENT model can be explored as such:
+# [Variability](06_fva.md) of the sMOMENT model can be explored as such:
 
 flux_variability_analysis(smoment_model, GLPK.Optimizer, bounds = gamma_bounds(0.95))
 
-# ...and a sMOMENT model sample can be obtained [as usual with sampling](TODO):
+# ...and a sMOMENT model sample can be obtained [as usual with
+# sampling](16_hit_and_run.md):
 
 (
     affine_hit_and_run(

docs/src/examples/16_hit_and_run.jl

@@ -3,7 +3,7 @@
 # Sampling the feasible space of the model allows you to gain a realistic
 # insight into the distribution of the flow and its probabilistic nature, often
 # better describing the variance and correlations of the possible fluxes better
-# (but more approximately) than e.g. [flux variability analysis](TODO).
+# (but more approximately) than e.g. [flux variability analysis](06_fva.md).
 
 # COBREXA supports a variant of hit-and-run sampling adjusted to the
 # complexities of metabolic models; in particular, it implements a version
@@ -53,8 +53,8 @@ samples = affine_hit_and_run(model, warmup_points, sample_iters = 201:210, chain
 #md # !!! tip "Parallelization"
 #md #     Both procedures used for sampling in this example
 #md #     ([`warmup_from_variability`](@ref), [`affine_hit_and_run`](@ref)) can be
-#md #     effectively parallelized by adding `workers=` parameter, as demonstrated
-#md #     in [other examples](TODO). Due to the nature of the algorithm, parallelization
+#md #     effectively parallelized by adding `workers=` parameter, as summarized
+#md #     in [the documentation](../distributed/1_functions.md). Due to the nature of the algorithm, parallelization
 #md #     of the sampling requires at least 1 chain per worker.
 
 # ## Visualizing the samples