link everything to the docs

docs/make.jl

@@ -50,14 +50,10 @@ makedocs(
     modules = [COBREXA],
     sitename = "COBREXA.jl",
     format = Documenter.HTML(
-        # Use clean URLs, unless built as a "local" build
-        prettyurls = !("local" in ARGS),
-        assets = ["assets/favicon.ico"],
-        highlights = ["yaml"],
+        ansicolor = true,
+        canonical = "https://cobrexa.github.io/COBREXA.jl/stable/",
     ),
-    authors = "The developers of COBREXA.jl",
-    linkcheck = !("skiplinks" in ARGS),
-    warnonly = true, # TODO: remove later
+    linkcheck = false,
     pages = [
         "Home" => "index.md",
         "Examples" => [
@@ -72,11 +68,10 @@ makedocs(
             "Contents" => "concepts.md"
             find_mds("concepts")
         ],
-        "Reference" => "reference.md",
-        #[ # TODO re-add this when the reference gets bigger
-        #"Contents" => "reference.md"
-        #find_mds("reference")
-        #],
+        "API reference" => [
+            "Contents" => "reference.md"
+            find_mds("reference")
+        ],
     ],
 )
 

docs/src/concepts/1_screen.md

@@ -5,12 +5,12 @@ A major goal of COBREXA.jl is to make exploring of many model variants easy and
 fast.
 
 One main concept that can be utilized for doing that is implemented in the
-function [`screen`](@ref), which takes your model, a list of model _variants_
+function `screen`, which takes your model, a list of model _variants_
 that you want to explore by some specified _analysis_, and schedules the
 analysis of the model variants parallelly on the available distributed workers.
 
 In its most basic form, the "screening" may use the slightly simplified variant
-of [`screen`](@ref) that is called [`screen_variants`](@ref), which works as
+of `screen` that is called `screen_variants`, which works as
 follows:
 
 ```julia
@@ -128,16 +128,16 @@ This may be easily used for e.g. scrutinizing all possible reaction pairs, to
 find the ones that are redundant and not.
 
 There are many other variant "specifications" to choose from. You may use
-[`with_added_reactions`](@ref), [`with_removed_reactions`](@ref),
-[`with_removed_metabolites`](@ref), and others. Function reference contains a
+`with_added_reactions`, `with_removed_reactions`,
+`with_removed_metabolites`, and others. Function reference contains a
 complete list; as a convention, names of the specifications all start with
 `with_`.
 
 ## Writing custom variant functions
 
 It is actually very easy to create custom specifications that do any
 modification that you can implement, to be later used with
-[`screen_variants`](@ref) and [`screen`](@ref).
+`screen_variants` and `screen`.
 
 Generally, the "specifications" are supposed to return a _function_ that
 creates a modified copy of the model. The copy of the model may be shallow, but
@@ -146,7 +146,7 @@ the functions should always prevent modifying the original model structure --
 prevent unnecessary bulk data transport, and if that is changed in-place, all
 following analyses of the model will work on inconsistent data, usually
 returning wrong results (even randomly changing ones, because of the
-asynchronous nature of [`screen`](@ref) execution).
+asynchronous nature of `screen` execution).
 
 Despite of that, writing a modification is easy. The simplest modification that
 "does nothing" (isomorphic to standard `identity`) can be formatted as follows:
@@ -188,8 +188,8 @@ with_disabled_reaction(reaction_id) = (model::ObjectModel) -> begin
 end
 ```
 
-In turn, these variants can be used in [`screen_variants`](@ref) just as we
-used [`with_changed_bound`](@ref) above:
+In turn, these variants can be used in `screen_variants` just as we
+used `with_changed_bound` above:
 
 ```julia
 screen_variants(
@@ -222,10 +222,10 @@ That should get you the results for all new variants of the model:
 
 Some analysis functions may take additional arguments, which you might want to
 vary for the analysis. `modifications` argument of
-[`flux_balance_dict`](@ref) is one example of such argument, allowing
+`flux_balance_dict` is one example of such argument, allowing
 you to specify details of the optimization procedure.
 
-[`screen`](@ref) function allows you to do precisely that -- apart from
+`screen` function allows you to do precisely that -- apart from
 `variants`, you may also specify an array of `args` of the same shape as
 `variants`, the entries of which will get passed together with the generated
 model variants to your specified analysis function. If either of the arguments

docs/src/distributed/1_functions.md

@@ -14,8 +14,8 @@ You may run your analyses in parallel to gain speed-ups. The usual workflow in
 
 1. Import the `Distributed` package and add worker processes, e.g. using
    `addprocs`.
-2. Pick an analysis function that can be parallelized (such as [`screen`](@ref)
-   or [`flux_variability_analysis`](@ref)) and prepare it to work on your data.
+2. Pick an analysis function that can be parallelized (such as `screen`
+   or `flux_variability_analysis`) and prepare it to work on your data.
 3. Pass the desired set of worker IDs to the function using `workers=` argument,
    in the simplest form using e.g. `screen(...,  workers=workers())`.
 4. Worker communication will be managed automatically, and you will get results
@@ -29,23 +29,21 @@ locally](2_parallel.md) and [running distributed analysis in HPC clusters](3_slu
 As of COBREXA 1.3, the list of functions that accept the `worker` argument is
 as follows:
 
-- [`affine_hit_and_run`](@ref) sampling, together with [`warmup_from_variability`](@ref)
-- [`flux_variability_analysis`](@ref)
-- [`max_min_driving_force`](@ref)
-- [`objective_envelope`](@ref)
-- [`screen`](@ref)
-- [`screen_optmodel_modifications`](@ref)
+- `affine_hit_and_run` sampling, together with `warmup_from_variability`
+- `flux_variability_analysis`
+- `max_min_driving_force`
+- `objective_envelope`
+- `screen`
+- `screen_optmodel_modifications`
 
 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](../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](../examples/11_growth.md) (e.g., metabolite depletion)
+- single and multiple gene deletions (and other genetic modifications)
+- modifications of the reaction spectrum (e.g., disabling reactions)
+- advanced envelope-scanning analyses
+- growth media exploration (e.g., metabolite depletion)
 
 ## Mitigating parallel inefficiencies
 
@@ -57,7 +55,7 @@ that reduce the parallel efficiency, which can be summarized as follows:
   supported (and if it is, it may be inefficient for usual problem sizes). You
   usually want to parallelize the analyzes that comprise multiple independent
   runs of the solvers.
-- Some analysis function, such as [`flux_variability_analysis`](@ref), have
+- Some analysis function, such as `flux_variability_analysis`, have
   serial parts that can not be parallelized by default. Usually, you may avoid
   the inefficiency by precomputing the serial analysis parts without involving
   the cluster of the workers.
@@ -68,9 +66,7 @@ that reduce the parallel efficiency, which can be summarized as follows:
   parallelization for small tasks.
 - Transferring large amounts of data among workers may hamper parallel
   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.
+  transferring many similar models to the workers.
 
 !!! note "Cost of the distribution and parallelization overhead"
     Before allocating extra resources into the distributed execution, always

docs/src/distributed/3_slurm.md

@@ -29,7 +29,7 @@ Adding of the Slurm-provided is done as follows:
 
 After adding the Slurm workers, you may continue as if the workers were added
 using normal `addprocs` --- typically you load the model and (for example) run
-the [`flux_variability_analysis`](@ref) as if you would use the [local
+the `flux_variability_analysis` as if you would use the [local
 workers](2_parallel.md).
 
 The Julia script that does a parallel analysis in a Slurm cluster may look as follows:

docs/src/examples/03-parsimonious-flux-balance.jl

@@ -17,7 +17,7 @@
 # # Parsimonious flux balance analysis
 
 # We will use [`parsimonious_flux_balance_analysis`](@ref) and
-# [`minimize_metabolic_adjustment`](@ref) to find the optimal flux
+# [`minimization_of_metabolic_adjustment`](@ref) to find the optimal flux
 # distribution in the *E. coli* "core" model.
 #
 # TODO pFBA citation

docs/src/examples/08-community-models.jl

@@ -68,7 +68,7 @@ ecoli2.fluxes.ACALD.bound = C.Between(-5.0, 5.0)
 # Because we created the trees with interfaces, we can connect them easily to
 # form a new model with the interface. For simplicity, we use the
 # interface-scaling functionality of [`interface_constraints`](@ref
-# ConstraintTrees.interface_constraints) to bring in cFBA-like community member
+# COBREXA.interface_constraints) to bring in cFBA-like community member
 # abundances:
 
 cc = interface_constraints(

docs/src/reference.md

@@ -1,66 +1,6 @@
 # API reference
 
-## Helper types
-
-```@autodocs
-Modules = [COBREXA]
-Pages = ["src/types.jl"]
-```
-
-## Model loading and saving
-
-```@autodocs
-Modules = [COBREXA]
-Pages = ["src/io.jl"]
-```
-
-## Solver interface
-
-```@autodocs
-Modules = [COBREXA]
-Pages = ["src/solver.jl"]
-```
-
-## Constraint system building
-
-```@autodocs
-Modules = [COBREXA]
-Pages = ["src/builders/core.jl"]
-```
-
-### Genetic constraints
-
-```@autodocs
-Modules = [COBREXA]
-Pages = ["src/builders/genes.jl"]
+```@contents
+Pages = ["reference/core.md", "reference/frontend.md", "reference/builders.md", "reference/analysis.md", "reference/misc.md"]
+Depth = 2
 ```
-
-### Objective function helpers
-
-```@autodocs
-Modules = [COBREXA]
-Pages = ["src/builders/objectives.jl"]
-```
-
-### Bounds&tolerances helpers
-
-```@autodocs
-Modules = [COBREXA]
-Pages = ["src/misc/bounds.jl"]
-```
-
-## Analysis functions
-
-```@autodocs
-Modules = [COBREXA]
-Pages = ["src/analysis/flux_balance.jl", "src/analysis/parsimonious_flux_balance.jl"]
-```
-
-### Analysis modifications
-
-```@autodocs
-Modules = [COBREXA]
-Pages = ["src/analysis/modifications.jl"]
-```
-
-## Distributed analysis

docs/src/reference/analysis.md

@@ -0,0 +1,28 @@
+
+# Specialized analysis functions
+
+```@autodocs
+Modules = [COBREXA]
+Pages = ["src/analysis/solver.jl"]
+```
+
+## Parsimonious analyses
+
+```@autodocs
+Modules = [COBREXA]
+Pages = ["src/analysis/parsimonious.jl"]
+```
+
+## Ensemble solving
+
+```@autodocs
+Modules = [COBREXA]
+Pages = ["src/analysis/screen.jl", "src/analysis/variability.jl", "src/analysis/envelope.jl" ]
+```
+
+## Sampling
+
+```@autodocs
+Modules = [COBREXA]
+Pages = ["src/analysis/sample.jl"]
+```

docs/src/reference/builders.md

@@ -1,21 +1,53 @@
 
-## Constraint system building
+# Constraint system builders
+
+## Generic constraints
+
+### Comparisons
 
 ```@autodocs
 Modules = [COBREXA]
-Pages = ["src/builders/core.jl"]
+Pages = ["src/builders/compare.jl"]
 ```
 
-### Genetic constraints
+### Constraint scaling
 
 ```@autodocs
 Modules = [COBREXA]
-Pages = ["src/builders/genes.jl"]
+Pages = ["src/builders/scale.jl"]
 ```
 
-### Objective function helpers
+### Sign splitting
+
+```@autodocs
+Modules = [COBREXA]
+Pages = ["src/builders/unsigned.jl"]
+```
+
+### Objectives
 
 ```@autodocs
 Modules = [COBREXA]
 Pages = ["src/builders/objectives.jl"]
 ```
+
+## FBC constraint systems
+
+```@autodocs
+Modules = [COBREXA]
+Pages = ["src/builders/fbc.jl"]
+```
+
+## Analysis-specific constriants
+
+```@autodocs
+Modules = [COBREXA]
+Pages = ["src/builders/loopless.jl", "src/builders/knockout.jl", "src/builders/enzymes.jl"]
+```
+
+## Interfacing of constraint systems
+
+```@autodocs
+Modules = [COBREXA]
+Pages = ["src/builders/interface.jl"]
+```

docs/src/reference/core.md

@@ -0,0 +1,37 @@
+
+# Core functionality
+
+## Model I/O
+
+```@autodocs
+Modules = [COBREXA]
+Pages = ["src/io.jl"]
+```
+
+## Types
+
+```@autodocs
+Modules = [COBREXA]
+Pages = ["src/types.jl"]
+```
+
+## Configuration
+
+```@autodocs
+Modules = [COBREXA]
+Pages = ["src/config.jl"]
+```
+
+## Solver interface
+
+```@autodocs
+Modules = [COBREXA]
+Pages = ["src/solver.jl"]
+```
+
+## Task distribution support
+
+```@autodocs
+Modules = [COBREXA]
+Pages = ["src/worker_data.jl"]
+```