From 661d9114472d4892abdfaeb4da9b103e7d38c762 Mon Sep 17 00:00:00 2001 From: "Documenter.jl" Date: Fri, 22 Nov 2024 09:46:40 +0000 Subject: [PATCH] build based on 9e4be24 --- dev/.documenter-siteinfo.json | 2 +- dev/distributed/1_functions/index.html | 2 +- dev/distributed/2_parallel/index.html | 2 +- dev/distributed/3_slurm/index.html | 2 +- dev/distributed/index.html | 2 +- dev/examples/01-loading-and-saving/index.html | 2 +- .../02a-flux-balance-analysis/index.html | 2 +- dev/examples/02b-optimizer-parameters.ipynb | 2 +- .../02b-optimizer-parameters/index.html | 2 +- .../02c-model-modifications/index.html | 2 +- .../02d-constraint-modifications/index.html | 2 +- .../03a-flux-variability-analysis/index.html | 2 +- .../03b-parsimonious-flux-balance/index.html | 2 +- dev/examples/03c-envelopes/index.html | 2 +- dev/examples/03d-unidirectional/index.html | 2 +- dev/examples/04-community-models/index.html | 2 +- .../index.html | 2 +- .../05b-enzyme-constrained-models/index.html | 2 +- dev/examples/05c-mmdf/index.html | 2 +- dev/examples/05d-loopless-models/index.html | 2 +- dev/examples/05e-knockouts/index.html | 2 +- dev/examples/05f-cyclefree/index.html | 2 +- dev/examples/05g-gapfilling/index.html | 2 +- dev/examples/06a-sampling.ipynb | 4 +- dev/examples/06a-sampling/index.html | 76 +++++++++---------- dev/examples/06b-screening/index.html | 2 +- dev/examples/index.html | 2 +- dev/index.html | 2 +- dev/reference/analysis/index.html | 24 +++--- dev/reference/builders/index.html | 56 +++++++------- dev/reference/core/index.html | 38 +++++----- dev/reference/frontend/index.html | 66 ++++++++-------- dev/reference/index.html | 2 +- dev/reference/misc/index.html | 22 +++--- dev/structure/index.html | 2 +- 35 files changed, 171 insertions(+), 171 deletions(-) diff --git a/dev/.documenter-siteinfo.json b/dev/.documenter-siteinfo.json index e62098c1..98bae00d 100644 --- a/dev/.documenter-siteinfo.json +++ b/dev/.documenter-siteinfo.json @@ -1 +1 @@ -{"documenter":{"julia_version":"1.9.4","generation_timestamp":"2024-11-21T19:07:05","documenter_version":"1.8.0"}} \ No newline at end of file +{"documenter":{"julia_version":"1.9.4","generation_timestamp":"2024-11-22T09:46:34","documenter_version":"1.8.0"}} \ No newline at end of file diff --git a/dev/distributed/1_functions/index.html b/dev/distributed/1_functions/index.html index 470273ea..e621cd81 100644 --- a/dev/distributed/1_functions/index.html +++ b/dev/distributed/1_functions/index.html @@ -1,2 +1,2 @@ -Parallel processing overview · COBREXA.jl
GitHub

Parallel processing overview

Distributed processing in Julia is represented mainly by the package Distributed.jl.

COBREXA.jl is able to utilize this existing system to almost transparently run the large parallelizable analyses on multiple CPU cores and multiple computers connected through the network. Ultimately, the approach scales to thousands of computing nodes in large HPC facilities.

Users may run the analyses in parallel to gain speed-ups. The usual workflow in COBREXA.jl is quite straightforward:

  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 or flux_variability_analysis) and prepare it to work on the 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 the results will be computed "as usual", just appropriately faster.

Specific documentation is available about running parallel analysis locally and running distributed analysis in HPC clusters.

Functions that support parallelization

The functions that support parallel execution include:

Notably, the screening functions can be reused to run many other kinds of analyses which, in turn, inherit the parallelizability. This includes a wide range of use-cases that can thus be parallelized very easily:

  • single and multiple gene deletions (and other genetic modifications)
  • multiple reaction knockouts
  • envelope-like production profiles (e.g., enzyme-constrained growth profiles)
  • growth media explorations (such as explorations of metabolite depletion)

Mitigating parallel inefficiencies

Ideally, the speedup gained by parallel processing should be proportional to the amount of hardware one add as the workers. To reach that, it is beneficial to be aware of factors that reduce the parallel efficiency, which can be summarized as follows:

  • Parallelization within single runs of the linear solver is typically not supported (and if it is, it may be inefficient for common problem sizes). Normally, we want to parallelize the analyzes that comprise multiple independent runs of the solvers.
  • Some analysis function, such as flux_variability_analysis, have serial parts that can not be parallelized by default. Usually, pipelines may avoid the inefficiency by precomputing the serial analysis parts without involving the cluster of the workers.
  • Frequent worker communication may vastly reduce the efficiency of parallel processing; typically this happens if the time required for individual analysis steps is smaller than the network round-trip-time to the worker processes. Do not use parallelization for very small tasks.
  • Transferring large amounts of data among workers may hamper parallel efficiency too. Use a single loaded model data object and apply any required small modifications directly on the workers to avoid this kind of inefficiency.
Cost of the distribution and parallelization overhead

Before allocating extra resources into the distributed execution, always check that the tasks are properly parallelizable and sufficiently large to saturate the computation resources, so that the invested energy is not wasted. Amdahl's and Gustafson's laws give a better overview of the sources and consequences of the parallelization inefficiencies, and the costs of the resulting overhead.

+Parallel processing overview · COBREXA.jl
GitHub

Parallel processing overview

Distributed processing in Julia is represented mainly by the package Distributed.jl.

COBREXA.jl is able to utilize this existing system to almost transparently run the large parallelizable analyses on multiple CPU cores and multiple computers connected through the network. Ultimately, the approach scales to thousands of computing nodes in large HPC facilities.

Users may run the analyses in parallel to gain speed-ups. The usual workflow in COBREXA.jl is quite straightforward:

  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 or flux_variability_analysis) and prepare it to work on the 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 the results will be computed "as usual", just appropriately faster.

Specific documentation is available about running parallel analysis locally and running distributed analysis in HPC clusters.

Functions that support parallelization

The functions that support parallel execution include:

Notably, the screening functions can be reused to run many other kinds of analyses which, in turn, inherit the parallelizability. This includes a wide range of use-cases that can thus be parallelized very easily:

  • single and multiple gene deletions (and other genetic modifications)
  • multiple reaction knockouts
  • envelope-like production profiles (e.g., enzyme-constrained growth profiles)
  • growth media explorations (such as explorations of metabolite depletion)

Mitigating parallel inefficiencies

Ideally, the speedup gained by parallel processing should be proportional to the amount of hardware one add as the workers. To reach that, it is beneficial to be aware of factors that reduce the parallel efficiency, which can be summarized as follows:

  • Parallelization within single runs of the linear solver is typically not supported (and if it is, it may be inefficient for common problem sizes). Normally, we want to parallelize the analyzes that comprise multiple independent runs of the solvers.
  • Some analysis function, such as flux_variability_analysis, have serial parts that can not be parallelized by default. Usually, pipelines may avoid the inefficiency by precomputing the serial analysis parts without involving the cluster of the workers.
  • Frequent worker communication may vastly reduce the efficiency of parallel processing; typically this happens if the time required for individual analysis steps is smaller than the network round-trip-time to the worker processes. Do not use parallelization for very small tasks.
  • Transferring large amounts of data among workers may hamper parallel efficiency too. Use a single loaded model data object and apply any required small modifications directly on the workers to avoid this kind of inefficiency.
Cost of the distribution and parallelization overhead

Before allocating extra resources into the distributed execution, always check that the tasks are properly parallelizable and sufficiently large to saturate the computation resources, so that the invested energy is not wasted. Amdahl's and Gustafson's laws give a better overview of the sources and consequences of the parallelization inefficiencies, and the costs of the resulting overhead.

diff --git a/dev/distributed/2_parallel/index.html b/dev/distributed/2_parallel/index.html index 4ba9801d..68141148 100644 --- a/dev/distributed/2_parallel/index.html +++ b/dev/distributed/2_parallel/index.html @@ -5,4 +5,4 @@ model, optimizer = HiGHS.Optimizer, workers = workers() -) +) diff --git a/dev/distributed/3_slurm/index.html b/dev/distributed/3_slurm/index.html index 13175765..3b6e9ade 100644 --- a/dev/distributed/3_slurm/index.html +++ b/dev/distributed/3_slurm/index.html @@ -17,4 +17,4 @@ module load lang/Julia # add Julia to the environment (this may differ on different clusters and installations!) -julia myJob.jl

To run the computation, run sbatch myJob.sbatch on the cluster access node. The job will be scheduled and eventually executed. It is possible to watch the output of commands sacct and squeue in the meantime, to see the progress.

Remember that it is necessary to explicitly save the result of the Julia script computation to files, to be able to retrieve them later. Standard outputs of the jobs are often mangled and/or discarded. If we would still want to collect the standard output of the Julia script, we might need to change the last line of the batch script as follows:

julia myJob.jl > myJob.log

...and collect the output from myJob.log later. This is convenient especially if the script prints out various computation details using @info and similar macros.

+julia myJob.jl

To run the computation, run sbatch myJob.sbatch on the cluster access node. The job will be scheduled and eventually executed. It is possible to watch the output of commands sacct and squeue in the meantime, to see the progress.

Remember that it is necessary to explicitly save the result of the Julia script computation to files, to be able to retrieve them later. Standard outputs of the jobs are often mangled and/or discarded. If we would still want to collect the standard output of the Julia script, we might need to change the last line of the batch script as follows:

julia myJob.jl > myJob.log

...and collect the output from myJob.log later. This is convenient especially if the script prints out various computation details using @info and similar macros.

diff --git a/dev/distributed/index.html b/dev/distributed/index.html index c06ce10a..3a6b4380 100644 --- a/dev/distributed/index.html +++ b/dev/distributed/index.html @@ -1,2 +1,2 @@ -Contents · COBREXA.jl
GitHub
+Contents · COBREXA.jl
GitHub
diff --git a/dev/examples/01-loading-and-saving/index.html b/dev/examples/01-loading-and-saving/index.html index 5c546b2e..563eeeca 100644 --- a/dev/examples/01-loading-and-saving/index.html +++ b/dev/examples/01-loading-and-saving/index.html @@ -54,4 +54,4 @@ end |> String, "...")
7JL5Model|)&i!@=OZAbstractFBCModelsCanonicalModelD5DictND!Reaction...

The above code has saved the CanonicalModel in the way specified by the CanonicalModel structure – which is, in this case, a binary dump of the Julia objects, instead of the expected JSON. To prevent this, you can either specify the output type yourself:

save_model(model_in_julia_structures, "e_coli_saved_right.json", JSONFBCModel)

...or use save_converted_model to guess the model type automatically from the extension:

save_converted_model(model_in_julia_structures, "e_coli_saved_automatically_right.json")
 println(open("e_coli_saved_automatically_right.json") do f
     read(f, 100)
-end |> String, "...")
{"metabolites":[{"compartment":"c","name":"3-Phospho-D-glyceroyl phosphate","formula":"C3H4O10P2","i...

As with load_model, there is some overhead and uncertainty associated with save_converted_model guessing the model type from extension. For that reason, it is adviseable to rely on the guessing functionality only in interactive use in REPL, and avoid it in automated scriptage altogether.

This page was generated using Literate.jl.

+end |> String, "...")
{"metabolites":[{"compartment":"c","name":"3-Phospho-D-glyceroyl phosphate","formula":"C3H4O10P2","i...

As with load_model, there is some overhead and uncertainty associated with save_converted_model guessing the model type from extension. For that reason, it is adviseable to rely on the guessing functionality only in interactive use in REPL, and avoid it in automated scriptage altogether.

This page was generated using Literate.jl.

diff --git a/dev/examples/02a-flux-balance-analysis/index.html b/dev/examples/02a-flux-balance-analysis/index.html index 943292e2..658057d2 100644 --- a/dev/examples/02a-flux-balance-analysis/index.html +++ b/dev/examples/02a-flux-balance-analysis/index.html @@ -32,4 +32,4 @@ :THD2 => 0.0 :TKT1 => 1.496983757261565 :TKT2 => 1.1814980932459616 - :TPI => 7.477381962160285

This page was generated using Literate.jl.

+ :TPI => 7.477381962160285

This page was generated using Literate.jl.

diff --git a/dev/examples/02b-optimizer-parameters.ipynb b/dev/examples/02b-optimizer-parameters.ipynb index 7838f0b9..eafb2cff 100644 --- a/dev/examples/02b-optimizer-parameters.ipynb +++ b/dev/examples/02b-optimizer-parameters.ipynb @@ -162,7 +162,7 @@ " System : Augmented system (K2)\n", "\n", " Itn PObj DObj PFeas DFeas GFeas Mu Time\n", - " 0 -0.0000000e+00 +1.7686535e+05 1.16e+04 8.59e-02 1.77e+05 1.0e+00 0.86\n", + " 0 -0.0000000e+00 +1.7686535e+05 1.16e+04 8.59e-02 1.77e+05 1.0e+00 0.87\n", "Solver exited with status Trm_TimeLimit\n" ] } diff --git a/dev/examples/02b-optimizer-parameters/index.html b/dev/examples/02b-optimizer-parameters/index.html index f7a4b427..3025eced 100644 --- a/dev/examples/02b-optimizer-parameters/index.html +++ b/dev/examples/02b-optimizer-parameters/index.html @@ -59,4 +59,4 @@ 0 -0.0000000e+00 +1.7686535e+05 1.16e+04 8.59e-02 1.77e+05 1.0e+00 0.00 1 -5.3305641e-02 +1.7675067e+05 7.98e+03 5.26e-02 1.21e+05 6.9e-01 0.00 2 -8.5532053e-02 +1.7615681e+05 2.06e+03 1.69e-02 3.13e+04 1.8e-01 0.00 -Solver exited with status Trm_IterationLimit

Applicable optimizer attributes are documented in the documentations of the respective optimizers. To browse the possibilities, one might want to see the JuMP documentation page that summarizes the references to the available optimizers.

Default solver settings can be examined and changed via Configuration.

This page was generated using Literate.jl.

+Solver exited with status Trm_IterationLimit

Applicable optimizer attributes are documented in the documentations of the respective optimizers. To browse the possibilities, one might want to see the JuMP documentation page that summarizes the references to the available optimizers.

Default solver settings can be examined and changed via Configuration.

This page was generated using Literate.jl.

diff --git a/dev/examples/02c-model-modifications/index.html b/dev/examples/02c-model-modifications/index.html index d3b92ed4..3645acd2 100644 --- a/dev/examples/02c-model-modifications/index.html +++ b/dev/examples/02c-model-modifications/index.html @@ -157,4 +157,4 @@ )

The values of any coupling constraints can be inspected directly in the solved model:

solution_with_coupling = flux_balance_analysis(model, optimizer = HiGHS.Optimizer)
 
-solution_with_coupling.coupling.total_energy_intake
5.0

This page was generated using Literate.jl.

+solution_with_coupling.coupling.total_energy_intake
5.0

This page was generated using Literate.jl.

diff --git a/dev/examples/02d-constraint-modifications/index.html b/dev/examples/02d-constraint-modifications/index.html index 7c5c5bb6..7f1b7f8a 100644 --- a/dev/examples/02d-constraint-modifications/index.html +++ b/dev/examples/02d-constraint-modifications/index.html @@ -73,4 +73,4 @@ solution = optimized_values(ct, objective = ct.objective.value, optimizer = HiGHS.Optimizer) -print(solution)
nothing

Several functions exist to simplify the construction of more complicated constraints. See the reference documentation for generic constraint builders for details.

This page was generated using Literate.jl.

+print(solution)
nothing

Several functions exist to simplify the construction of more complicated constraints. See the reference documentation for generic constraint builders for details.

This page was generated using Literate.jl.

diff --git a/dev/examples/03a-flux-variability-analysis/index.html b/dev/examples/03a-flux-variability-analysis/index.html index af4bfb1b..6092f92f 100644 --- a/dev/examples/03a-flux-variability-analysis/index.html +++ b/dev/examples/03a-flux-variability-analysis/index.html @@ -77,4 +77,4 @@ :D_LACt2 => (-0.214512, 0.0) :ENO => (13.4361, 16.1819) :ETOHt2r => (-0.221432, 0.0) - ⋮ => ⋮
Speed up FVA with parallel processing

By default, FVA is parallelized on all workers that are available in the worker pool of the Distributed package, which may speed up the computation considerably. See the parallel processing documentation for more details.

This page was generated using Literate.jl.

+ ⋮ => ⋮
Speed up FVA with parallel processing

By default, FVA is parallelized on all workers that are available in the worker pool of the Distributed package, which may speed up the computation considerably. See the parallel processing documentation for more details.

This page was generated using Literate.jl.

diff --git a/dev/examples/03b-parsimonious-flux-balance/index.html b/dev/examples/03b-parsimonious-flux-balance/index.html index 0f04ba5e..6c5b82b3 100644 --- a/dev/examples/03b-parsimonious-flux-balance/index.html +++ b/dev/examples/03b-parsimonious-flux-balance/index.html @@ -72,4 +72,4 @@ :D_LACt2 => 0.0 :ENO => 14.7161 :ETOHt2r => 0.0 - ⋮ => ⋮

This page was generated using Literate.jl.

+ ⋮ => ⋮

This page was generated using Literate.jl.

diff --git a/dev/examples/03c-envelopes/index.html b/dev/examples/03c-envelopes/index.html index 89ce2d5d..3336a358 100644 --- a/dev/examples/03c-envelopes/index.html +++ b/dev/examples/03c-envelopes/index.html @@ -15,4 +15,4 @@ ["EX_o2_e", "EX_co2_e"]; breaks = 5, optimizer = HiGHS.Optimizer, -)
(breaks = Pair{String, StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}}["EX_o2_e" => -60.0:15.0:0.0, "EX_co2_e" => -11.104242424242429:17.776060606060632:60.0000000000001], objective_values = Union{Nothing, Float64}[nothing nothing … nothing 1.4356622286820861e-15; nothing nothing … 0.2724440832478481 nothing; … ; nothing 0.6046187247413645 … nothing nothing; 0.0 0.2019262880721721 … nothing nothing])

Documentation of the function describes ways to set custom bounds for the examined reaction flux ranges and several other customizations.

This page was generated using Literate.jl.

+)
(breaks = Pair{String, StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}}["EX_o2_e" => -60.0:15.0:0.0, "EX_co2_e" => -11.104242424242429:17.776060606060632:60.0000000000001], objective_values = Union{Nothing, Float64}[nothing nothing … nothing 1.4356622286820861e-15; nothing nothing … 0.2724440832478481 nothing; … ; nothing 0.6046187247413645 … nothing nothing; 0.0 0.2019262880721721 … nothing nothing])

Documentation of the function describes ways to set custom bounds for the examined reaction flux ranges and several other customizations.

This page was generated using Literate.jl.

diff --git a/dev/examples/03d-unidirectional/index.html b/dev/examples/03d-unidirectional/index.html index 53ed9c77..19a48729 100644 --- a/dev/examples/03d-unidirectional/index.html +++ b/dev/examples/03d-unidirectional/index.html @@ -133,4 +133,4 @@ :D_LACt2 => 0.0 :ENO => 14.7161 :ETOHt2r => 0.0 - ⋮ => ⋮

This page was generated using Literate.jl.

+ ⋮ => ⋮

This page was generated using Literate.jl.

diff --git a/dev/examples/04-community-models/index.html b/dev/examples/04-community-models/index.html index 783d4ebf..f69d33c0 100644 --- a/dev/examples/04-community-models/index.html +++ b/dev/examples/04-community-models/index.html @@ -153,4 +153,4 @@ objective = custom_community.community_biomass.value, output = custom_community.community_biomass, optimizer = HiGHS.Optimizer, -)
0.5237157737585176

This page was generated using Literate.jl.

+)
0.5237157737585176

This page was generated using Literate.jl.

diff --git a/dev/examples/05a-minimization-of-metabolic-adjustment/index.html b/dev/examples/05a-minimization-of-metabolic-adjustment/index.html index 9bfcf3cf..c34449d0 100644 --- a/dev/examples/05a-minimization-of-metabolic-adjustment/index.html +++ b/dev/examples/05a-minimization-of-metabolic-adjustment/index.html @@ -135,4 +135,4 @@ :PGM => 2.184138541733045 :PGK => 2.2174214742776375 :FRD7 => 2.982501375979094 - :SUCDi => 4.073918836637732

This page was generated using Literate.jl.

+ :SUCDi => 4.073918836637732

This page was generated using Literate.jl.

diff --git a/dev/examples/05b-enzyme-constrained-models/index.html b/dev/examples/05b-enzyme-constrained-models/index.html index a7602bb9..242cb364 100644 --- a/dev/examples/05b-enzyme-constrained-models/index.html +++ b/dev/examples/05b-enzyme-constrained-models/index.html @@ -478,4 +478,4 @@ :b0728 => (-0.0, 0.00800682) :b0729 => (-0.0, 0.00800682) :b0733 => (-0.0, 0.0541366) - ⋮ => ⋮

This page was generated using Literate.jl.

+ ⋮ => ⋮

This page was generated using Literate.jl.

diff --git a/dev/examples/05c-mmdf/index.html b/dev/examples/05c-mmdf/index.html index 8423bdc9..e9cc8157 100644 --- a/dev/examples/05c-mmdf/index.html +++ b/dev/examples/05c-mmdf/index.html @@ -115,4 +115,4 @@ :nadh_c => (-11.7753, -2.30259) :pep_c => (-13.8155, -3.12524) :pi_c => (-3.06118, -2.30259) - :pyr_c => (-13.8155, -2.30259)

This page was generated using Literate.jl.

+ :pyr_c => (-13.8155, -2.30259)

This page was generated using Literate.jl.

diff --git a/dev/examples/05d-loopless-models/index.html b/dev/examples/05d-loopless-models/index.html index 352aecb8..cfc03e46 100644 --- a/dev/examples/05d-loopless-models/index.html +++ b/dev/examples/05d-loopless-models/index.html @@ -15,4 +15,4 @@ :loopless_constraints => ConstraintTrees.Tree{Float64}(#= 5 elements =#) :loopless_directions => ConstraintTrees.Tree{Float64}(#= 75 elements =#) :loopless_driving_forces => ConstraintTrees.Tree{Float64}(#= 75 elements =#) - :objective => 0.873922

Loopless constraints can also be added to any model (e.g. enzyme constrained models). Refer to the source code of loopless_flux_balance_constraints for guidance.

This page was generated using Literate.jl.

+ :objective => 0.873922

Loopless constraints can also be added to any model (e.g. enzyme constrained models). Refer to the source code of loopless_flux_balance_constraints for guidance.

This page was generated using Literate.jl.

diff --git a/dev/examples/05e-knockouts/index.html b/dev/examples/05e-knockouts/index.html index fc8321fc..012a679e 100644 --- a/dev/examples/05e-knockouts/index.html +++ b/dev/examples/05e-knockouts/index.html @@ -44,4 +44,4 @@ ("b1276", "b3919") => 0.7040369478590238 ("b4153", "b3919") => 0.7040369478590238 ("b2279", "b3919") => nothing - ("b0726", "b3919") => 0.7040369478590238

Now, how many genes are critical given b3919 is already missing?

critical_without_b3919 = count(isnothing, last.(knockouts_with_b3919))
23

This page was generated using Literate.jl.

+ ("b0726", "b3919") => 0.7040369478590238

Now, how many genes are critical given b3919 is already missing?

critical_without_b3919 = count(isnothing, last.(knockouts_with_b3919))
23

This page was generated using Literate.jl.

diff --git a/dev/examples/05f-cyclefree/index.html b/dev/examples/05f-cyclefree/index.html index 520b919c..05c87fe7 100644 --- a/dev/examples/05f-cyclefree/index.html +++ b/dev/examples/05f-cyclefree/index.html @@ -167,4 +167,4 @@ -21.811205956007473 -21.813364572555663 -21.80963333194993 - -21.81300524702459

This page was generated using Literate.jl.

+ -21.81300524702459

This page was generated using Literate.jl.

diff --git a/dev/examples/05g-gapfilling/index.html b/dev/examples/05g-gapfilling/index.html index 32c86674..9962757c 100644 --- a/dev/examples/05g-gapfilling/index.html +++ b/dev/examples/05g-gapfilling/index.html @@ -70,4 +70,4 @@ end

Gapfilling now points to the metabolites that need to be somehow taken care of by the modeller in order for the model to become feasible:

xm = gap_filling_analysis(infeasible_model, magic_model, 0.05, optimizer = HiGHS.Optimizer)
 
 blocking_metabolites = [k for (k, v) in xm.fill_flags if v != 0]
1-element Vector{Symbol}:
- :e4p_c

We can also have a look at how much of a given metabolite was used to make the model feasible again:

xm.universal_fluxes[first(blocking_metabolites)]
0.6866985638297876

This page was generated using Literate.jl.

+ :e4p_c

We can also have a look at how much of a given metabolite was used to make the model feasible again:

xm.universal_fluxes[first(blocking_metabolites)]
0.6866985638297876

This page was generated using Literate.jl.

diff --git a/dev/examples/06a-sampling.ipynb b/dev/examples/06a-sampling.ipynb index 600973fe..77d0a8b5 100644 --- a/dev/examples/06a-sampling.ipynb +++ b/dev/examples/06a-sampling.ipynb @@ -68,7 +68,7 @@ { "output_type": "execute_result", "data": { - "text/plain": "ConstraintTrees.Tree{Vector{Float64}} with 95 elements:\n :ACALD => [-0.0339393, -0.0183041, -0.0244384, -0.0171156,…\n :ACALDt => [-0.0238711, -0.0089021, -0.0171858, -0.00481697…\n :ACKr => [-0.0175626, -0.0183591, -0.0174642, -0.0161155,…\n :ACONTa => [6.04839, 6.05919, 6.06307, 6.32011, 6.06423, 6.…\n :ACONTb => [6.04839, 6.05919, 6.06307, 6.32011, 6.06423, 6.…\n :ACt2r => [-0.0175626, -0.0183591, -0.0174642, -0.0161155,…\n :ADK1 => [0.0255307, 0.0236547, 0.0225911, 0.0407002, 0.0…\n :AKGDH => [4.52188, 4.49318, 4.54835, 5.21185, 4.49936, 4.…\n :AKGt2r => [-0.00203689, -0.00337451, -0.00235789, -0.00355…\n :ALCD2x => [-0.0100682, -0.00940199, -0.00725264, -0.012298…\n :ATPM => [8.43191, 8.44349, 8.43552, 8.48344, 8.43995, 8.…\n :ATPS4r => [45.1864, 45.2007, 45.1518, 44.7883, 45.2077, 45…\n :BIOMASS_Ecoli_core_w_GAM => [0.865418, 0.865393, 0.865401, 0.865439, 0.86545…\n :CO2t => [-22.9085, -22.937, -22.9264, -22.8857, -22.9285…\n :CS => [6.04839, 6.05919, 6.06307, 6.32011, 6.06423, 6.…\n :CYTBD => [43.8423, 43.9028, 43.8974, 43.8438, 43.9033, 43…\n :D_LACt2 => [-0.0105959, -0.0128465, -0.00905381, -0.0111468…\n :ENO => [14.7477, 14.7492, 14.7511, 15.005, 14.7476, 14.…\n :ETOHt2r => [-0.0100682, -0.00940199, -0.00725264, -0.012298…\n ⋮ => ⋮" + "text/plain": "ConstraintTrees.Tree{Vector{Float64}} with 95 elements:\n :ACALD => [-0.0151235, -0.016959, -0.029273, -0.0132804, -…\n :ACALDt => [-0.00380377, -0.00328341, -0.00836245, -0.00306…\n :ACKr => [-0.0226167, -0.0246119, -0.0296686, -0.0220629,…\n :ACONTa => [6.09871, 6.12508, 6.21874, 5.89783, 6.14237, 5.…\n :ACONTb => [6.09871, 6.12508, 6.21874, 5.89783, 6.14237, 5.…\n :ACt2r => [-0.0226167, -0.0246119, -0.0296686, -0.0220629,…\n :ADK1 => [0.0387393, 0.0346144, 0.0094285, 0.0401418, 0.0…\n :AKGDH => [4.53272, 4.70363, 4.94867, 4.15118, 4.61469, 4.…\n :AKGt2r => [-0.00161543, -0.00253266, -0.00378415, -0.00238…\n :ALCD2x => [-0.0113197, -0.0136756, -0.0209106, -0.0102125,…\n :ATPM => [8.42732, 8.42983, 8.44163, 8.42365, 8.43029, 8.…\n :ATPS4r => [45.1228, 45.0502, 44.8095, 45.4555, 45.0738, 45…\n :BIOMASS_Ecoli_core_w_GAM => [0.865472, 0.865572, 0.865721, 0.865487, 0.86554…\n :CO2t => [-22.9322, -22.9129, -22.858, -22.9559, -22.9455…\n :CS => [6.09871, 6.12508, 6.21874, 5.89783, 6.14237, 5.…\n :CYTBD => [43.914, 43.8665, 43.7661, 43.9448, 43.9399, 43.…\n :D_LACt2 => [-0.0094216, -0.00990907, -0.0114174, -0.0076256…\n :ENO => [14.7834, 14.8156, 14.9268, 14.5789, 14.8152, 14…\n :ETOHt2r => [-0.0113197, -0.0136756, -0.0209106, -0.0102125,…\n ⋮ => ⋮" }, "metadata": {}, "execution_count": 2 @@ -101,7 +101,7 @@ { "output_type": "execute_result", "data": { - "text/plain": "380×2 Matrix{Float64}:\n 21.9212 -22.9085\n 21.9514 -22.937\n 21.9487 -22.9264\n 21.9219 -22.8857\n 21.9516 -22.9285\n 21.9564 -22.9158\n 21.981 -22.9703\n 21.9509 -22.9107\n 21.9446 -22.9208\n 22.0146 -22.9864\n ⋮ \n 21.9645 -22.9424\n 21.9823 -22.9598\n 21.9726 -22.9707\n 21.9745 -22.9473\n 21.9857 -22.9637\n 21.988 -22.9794\n 21.9565 -22.9391\n 21.9748 -22.9534\n 22.0033 -22.9813" + "text/plain": "380×2 Matrix{Float64}:\n 21.957 -22.9322\n 21.9333 -22.9129\n 21.883 -22.858\n 21.9724 -22.9559\n 21.97 -22.9455\n 21.9333 -22.944\n 21.879 -22.8562\n 21.9478 -22.9265\n 21.9761 -22.9475\n 21.9298 -22.9111\n ⋮ \n 21.9592 -22.9362\n 21.9415 -22.921\n 21.9395 -22.9146\n 21.8988 -22.8755\n 21.9457 -22.9191\n 21.9808 -22.9534\n 21.9259 -22.8916\n 21.9539 -22.9359\n 21.8757 -22.8378" }, "metadata": {}, "execution_count": 3 diff --git a/dev/examples/06a-sampling/index.html b/dev/examples/06a-sampling/index.html index 5e7c0309..4b6347f4 100644 --- a/dev/examples/06a-sampling/index.html +++ b/dev/examples/06a-sampling/index.html @@ -16,43 +16,43 @@ n_chains = 2, collect_iterations = [10], )
ConstraintTrees.Tree{Vector{Float64}} with 95 elements:
-  :ACALD                    => [-0.047168, -0.0121551, -0.0161673, -0.00834307,…
-  :ACALDt                   => [-0.0391003, -0.00333216, -0.00185464, -0.000743…
-  :ACKr                     => [-0.0189725, -0.01571, -0.020084, -0.012282, -0.…
-  :ACONTa                   => [6.06594, 6.10498, 6.03611, 6.05815, 6.02655, 5.…
-  :ACONTb                   => [6.06594, 6.10498, 6.03611, 6.05815, 6.02655, 5.…
-  :ACt2r                    => [-0.0189725, -0.01571, -0.020084, -0.012282, -0.…
-  :ADK1                     => [0.0165227, 0.0348701, 0.0421537, 0.0537109, 0.0…
-  :AKGDH                    => [4.53344, 4.55089, 4.49959, 4.3967, 4.50947, 3.8…
-  :AKGt2r                   => [-0.000780867, -0.00189532, -0.00162626, -0.0020…
-  :ALCD2x                   => [-0.00806768, -0.00882299, -0.0143127, -0.007599…
-  :ATPM                     => [8.41381, 8.43629, 8.42351, 8.43248, 8.42018, 8.…
-  :ATPS4r                   => [45.0544, 45.1498, 45.3242, 45.3231, 45.0074, 45…
-  :BIOMASS_Ecoli_core_w_GAM => [0.865332, 0.865498, 0.865548, 0.865613, 0.86533…
-  :CO2t                     => [-22.9105, -22.9405, -22.9484, -22.9829, -22.860…
-  :CS                       => [6.06594, 6.10498, 6.03611, 6.05815, 6.02655, 5.…
-  :CYTBD                    => [43.8363, 43.9427, 43.939, 44.0031, 43.7649, 44.…
-  :D_LACt2                  => [-0.00678971, -0.0109083, -0.00497423, -0.008240…
-  :ENO                      => [14.7707, 14.7824, 14.7157, 14.7286, 14.765, 14.…
-  :ETOHt2r                  => [-0.00806768, -0.00882299, -0.0143127, -0.007599…
+  :ACALD                    => [-0.0184756, -0.019148, -0.0865059, -0.0147449, …
+  :ACALDt                   => [-0.00929189, -0.00653271, -0.080044, -0.0060144…
+  :ACKr                     => [-0.0151406, -0.0163737, -0.0126386, -0.0169413,…
+  :ACONTa                   => [6.07579, 6.02101, 6.02629, 6.10877, 6.10348, 6.…
+  :ACONTb                   => [6.07579, 6.02101, 6.02629, 6.10877, 6.10348, 6.…
+  :ACt2r                    => [-0.0151406, -0.0163737, -0.0126386, -0.0169413,…
+  :ADK1                     => [0.0265303, 0.0205372, 0.0205225, 0.0270841, 0.0…
+  :AKGDH                    => [4.56117, 4.33202, 4.6606, 4.60826, 4.56153, 4.6…
+  :AKGt2r                   => [-0.00230913, -0.00226784, -0.00153662, -0.00209…
+  :ALCD2x                   => [-0.00918374, -0.0126153, -0.00646192, -0.008730…
+  :ATPM                     => [8.4322, 8.43416, 8.41978, 8.43126, 8.43101, 8.4…
+  :ATPS4r                   => [45.1796, 45.2471, 45.1076, 45.1126, 45.1193, 45…
+  :BIOMASS_Ecoli_core_w_GAM => [0.865488, 0.865414, 0.865345, 0.865456, 0.86550…
+  :CO2t                     => [-22.9408, -22.9631, -22.8662, -22.9492, -22.936…
+  :CS                       => [6.07579, 6.02101, 6.02629, 6.10877, 6.10348, 6.…
+  :CYTBD                    => [43.9136, 43.9493, 43.6881, 43.939, 43.8962, 43.…
+  :D_LACt2                  => [-0.0112033, -0.00935899, -0.00557739, -0.010214…
+  :ENO                      => [14.7628, 14.706, 14.7652, 14.791, 14.7903, 14.8…
+  :ETOHt2r                  => [-0.00918374, -0.0126153, -0.00646192, -0.008730…
   ⋮                         => ⋮

The result is a tree of vectors of sampled states for each value; the order of the values in these vectors is fixed. You can thus e.g. create a good matrix for plotting the sample as 2D scatterplot:

[s.O2t s.CO2t]
380×2 Matrix{Float64}:
- 21.9182  -22.9105
- 21.9713  -22.9405
- 21.9695  -22.9484
- 22.0015  -22.9829
- 21.8825  -22.8606
- 22.0276  -23.007
- 21.997   -22.9761
- 21.9937  -22.9743
- 22.0517  -23.0283
- 21.9969  -22.9774
+ 21.9568  -22.9408
+ 21.9746  -22.9631
+ 21.8441  -22.8662
+ 21.9695  -22.9492
+ 21.9481  -22.9369
+ 21.9551  -22.9376
+ 21.9624  -22.9446
+ 21.9121  -22.8881
+ 21.9984  -22.9817
+ 21.9173  -22.9012
   ⋮       
- 21.9775  -22.954
- 21.968   -22.9414
- 21.9722  -22.9473
- 21.9956  -22.9733
- 21.9827  -22.9577
- 21.9904  -22.968
- 22.0163  -22.9905
- 21.9275  -22.8928
- 21.9848  -22.9593

This page was generated using Literate.jl.

+ 21.8671 -22.8138 + 21.9522 -22.9247 + 21.9283 -22.8902 + 21.9817 -22.9416 + 21.9529 -22.9196 + 21.9353 -22.8964 + 21.9852 -22.963 + 21.9218 -22.869 + 21.9445 -22.9094

This page was generated using Literate.jl.

diff --git a/dev/examples/06b-screening/index.html b/dev/examples/06b-screening/index.html index c4419363..306a8217 100644 --- a/dev/examples/06b-screening/index.html +++ b/dev/examples/06b-screening/index.html @@ -100,4 +100,4 @@ (:H2Ot, :EX_h2o_e, 1.0)=>0.454097 … (:H2Ot, :EX_nh4_e, 1.0)=>0.494176 (:CO2t, :EX_h2o_e, 1.0)=>0.454097 (:CO2t, :EX_nh4_e, 1.0)=>0.550176 (:O2t, :EX_h2o_e, 1.0)=>0.391648 (:O2t, :EX_nh4_e, 1.0)=>0.391648 - (:NH4t, :EX_h2o_e, 1.0)=>0.454097 (:NH4t, :EX_nh4_e, 1.0)=>0.550176

Notably, this approach makes various indexing and ordering errors quite improbable.

This page was generated using Literate.jl.

+ (:NH4t, :EX_h2o_e, 1.0)=>0.454097 (:NH4t, :EX_nh4_e, 1.0)=>0.550176

Notably, this approach makes various indexing and ordering errors quite improbable.

This page was generated using Literate.jl.

diff --git a/dev/examples/index.html b/dev/examples/index.html index 3af4a98c..777e224f 100644 --- a/dev/examples/index.html +++ b/dev/examples/index.html @@ -1,2 +1,2 @@ -Contents · COBREXA.jl
GitHub

Examples

+Contents · COBREXA.jl
GitHub

Examples

diff --git a/dev/index.html b/dev/index.html index 1da5325e..9d01464d 100644 --- a/dev/index.html +++ b/dev/index.html @@ -1,2 +1,2 @@ -Home · COBREXA.jl
GitHub

COBREXA.jl

COBREXA.COBREXA — Module
module COBREXA

COnstraint Based Reconstruction and EXascale Analysis. COBREXA provides functions for construction, modification, simulation and analysis of constraint-based metabolic models that follows the COBRA methodology.

COBREXA is built as a front-end for the combination of AbstractFBCModels.jl (provides the model I/O), ConstraintTrees.jl (provides the constraint system organization), Distributed.jl (provides HPC execution capability), and JuMP.jl (provides the solvers).

See the online documentation for a complete description of functionality aided by copy-pastable examples.

To start quickly, load your favorite JuMP-compatible solver, use load_model to read a metabolic model from the disk, and solve it with flux_balance_analysis.

source
+Home · COBREXA.jl
GitHub

COBREXA.jl

COBREXA.COBREXA — Module
module COBREXA

COnstraint Based Reconstruction and EXascale Analysis. COBREXA provides functions for construction, modification, simulation and analysis of constraint-based metabolic models that follows the COBRA methodology.

COBREXA is built as a front-end for the combination of AbstractFBCModels.jl (provides the model I/O), ConstraintTrees.jl (provides the constraint system organization), Distributed.jl (provides HPC execution capability), and JuMP.jl (provides the solvers).

See the online documentation for a complete description of functionality aided by copy-pastable examples.

To start quickly, load your favorite JuMP-compatible solver, use load_model to read a metabolic model from the disk, and solve it with flux_balance_analysis.

source
diff --git a/dev/reference/analysis/index.html b/dev/reference/analysis/index.html index 63f763fd..8b9824f7 100644 --- a/dev/reference/analysis/index.html +++ b/dev/reference/analysis/index.html @@ -5,7 +5,7 @@ output, kwargs... ) -

Make an JuMP model out of constraints using optimization_model (most arguments are forwarded there), then apply the settings, optimize the model, and return either nothing if the optimization failed, or output substituted with the solved values (output defaults to constraints.

For a "nice" version for simpler finding of metabolic model optima, use flux_balance_analysis.

source

Parsimonious analyses

COBREXA.parsimonious_optimized_values — Method
parsimonious_optimized_values(
+

Make an JuMP model out of constraints using optimization_model (most arguments are forwarded there), then apply the settings, optimize the model, and return either nothing if the optimization failed, or output substituted with the solved values (output defaults to constraints.

For a "nice" version for simpler finding of metabolic model optima, use flux_balance_analysis.

source

Parsimonious analyses

COBREXA.parsimonious_optimized_values — Method
parsimonious_optimized_values(
     constraints::Union{ConstraintTrees.Constraint, ConstraintTrees.Tree{ConstraintTrees.Constraint}};
     objective,
     objective_value,
@@ -18,8 +18,8 @@
     output,
     kwargs...
 )
-

Optimize the system of constraints to get the optimal objective value. Then try to find a "parsimonious" solution with the same objective value, which optimizes the parsimonious_objective (possibly also switching optimization sense, optimizer, and adding more settings).

For efficiency, everything is performed on a single instance of JuMP model.

A simpler version suitable for direct work with metabolic models is available in parsimonious_flux_balance_analysis.

source

Ensemble solving

COBREXA.screen — Method
screen(f, args...; workers) -> Any
-

Execute a function with arguments given by args on workers.

This is merely a nice shortcut for Distributed.pmap running over a Distributed.CachingPool of the given workers.

source
COBREXA.screen_optimization_model — Method
screen_optimization_model(
+

Optimize the system of constraints to get the optimal objective value. Then try to find a "parsimonious" solution with the same objective value, which optimizes the parsimonious_objective (possibly also switching optimization sense, optimizer, and adding more settings).

For efficiency, everything is performed on a single instance of JuMP model.

A simpler version suitable for direct work with metabolic models is available in parsimonious_flux_balance_analysis.

source

Ensemble solving

COBREXA.screen — Method
screen(f, args...; workers) -> Any
+

Execute a function with arguments given by args on workers.

This is merely a nice shortcut for Distributed.pmap running over a Distributed.CachingPool of the given workers.

source
COBREXA.screen_optimization_model — Method
screen_optimization_model(
     f,
     constraints::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     args...;
@@ -29,19 +29,19 @@
     settings,
     workers
 )
-

Execute a function arguments from arrays args on workers, with a pre-cached JuMP optimization model created from constraints, objective and optimizer using optimization_model. settings are applied to the optimization model before first execution of f.

Since the model is cached and never re-created, this may be faster than just plain screen in many use cases.

The function f is supposed to take length(args)+1 arguments, the first argument is the JuMP model, and the other arguments are taken from args as with Distributed.pmap. While the model may be modified in place, one should take care to avoid modifications that change results of subsequent invocations of f, as that almost always results in data races and irreproducible executions. Ideally, all modifications of the model should be either manually reverted in the invocation of f, or the future invocations of f must be able to overwrite them.

f may use optimized_model to extract results easily w.r.t. some given ConstraintTree.

source
COBREXA.constraints_variability — Method
constraints_variability(
+

Execute a function arguments from arrays args on workers, with a pre-cached JuMP optimization model created from constraints, objective and optimizer using optimization_model. settings are applied to the optimization model before first execution of f.

Since the model is cached and never re-created, this may be faster than just plain screen in many use cases.

The function f is supposed to take length(args)+1 arguments, the first argument is the JuMP model, and the other arguments are taken from args as with Distributed.pmap. While the model may be modified in place, one should take care to avoid modifications that change results of subsequent invocations of f, as that almost always results in data races and irreproducible executions. Ideally, all modifications of the model should be either manually reverted in the invocation of f, or the future invocations of f must be able to overwrite them.

f may use optimized_model to extract results easily w.r.t. some given ConstraintTree.

source
COBREXA.constraints_variability — Method
constraints_variability(
     constraints::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     targets::ConstraintTrees.Tree{ConstraintTrees.Constraint};
     kwargs...
 )
-

Simplified variant of constraints_variability that computes the variability of all values in tree targets, and returns a new tree of the same shape as targets that contains tuples for minima and maxima.

All other arguments are forwarded to the matrix-returning overload of constraints_variability.

source
COBREXA.constraints_variability — Method
constraints_variability(
+

Simplified variant of constraints_variability that computes the variability of all values in tree targets, and returns a new tree of the same shape as targets that contains tuples for minima and maxima.

All other arguments are forwarded to the matrix-returning overload of constraints_variability.

source
COBREXA.constraints_variability — Method
constraints_variability(
     constraints::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     targets::Vector{<:ConstraintTrees.Value};
     output,
     output_type,
     kwargs...
 )
-

In a feasible space specified by constraints, compute the feasible range of individual targets values. The output is a matrix with one column for minima and second column for maxima of the individual target's values.

This is used e.g. to compute the flux_variability_analysis, and can be viewed as a more generalized version thereof.

output and output_type can be used to customize the information reported from the solved models.

Extra arguments are passed to screen_optimization_model.

source
COBREXA.constraints_objective_envelope — Method
constraints_objective_envelope(
+

In a feasible space specified by constraints, compute the feasible range of individual targets values. The output is a matrix with one column for minima and second column for maxima of the individual target's values.

This is used e.g. to compute the flux_variability_analysis, and can be viewed as a more generalized version thereof.

output and output_type can be used to customize the information reported from the solved models.

Extra arguments are passed to screen_optimization_model.

source
COBREXA.constraints_objective_envelope — Method
constraints_objective_envelope(
     constraints::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     dims...;
     objective,
@@ -50,7 +50,7 @@
     settings,
     workers
 )
-

Optimize the system given by constraints and objective with optimizer (with custom settings) for all combination of constriants given by dims.

dims should be compatible with pairs that assign a sequence of breaks to a ConstraintTrees.Value: For example, organism.fluxes.PFK => 1:3 will compute optima of the model with the flux through PFK constrained to be equal to 1, 2 and 3.

In turn, all dims are converted to groups of equality constraints, and the model is solved for all combinations. Shape of the output matrix corresponds to Iterators.product(last.(dims)...).

Operation is parallelized by distribution over workers; by default all Distributed.workers() are used.

source

Sampling

COBREXA.sample_chain_achr — Method
sample_chain_achr(
+

Optimize the system given by constraints and objective with optimizer (with custom settings) for all combination of constriants given by dims.

dims should be compatible with pairs that assign a sequence of breaks to a ConstraintTrees.Value: For example, organism.fluxes.PFK => 1:3 will compute optima of the model with the flux through PFK constrained to be equal to 1, 2 and 3.

In turn, all dims are converted to groups of equality constraints, and the model is solved for all combinations. Shape of the output matrix corresponds to Iterators.product(last.(dims)...).

Operation is parallelized by distribution over workers; by default all Distributed.workers() are used.

source

Sampling

COBREXA.sample_chain_achr — Method
sample_chain_achr(
     sample_c::AbstractArray{F<:Real, 2};
     variable_lower_bounds,
     variable_upper_bounds,
@@ -61,7 +61,7 @@
     collect_iterations,
     generator
 )
-

Implementation of a single chain run for the Artificially-Centered Hit and Run algorithm (ACHR).

To use this on a model, use flux_sample or sample_constraints; most parameters are filled in correctly by these functions.

epsilon is defaulted from configuration.

source
COBREXA.sample_constraint_variables — Method
sample_constraint_variables(
+

Implementation of a single chain run for the Artificially-Centered Hit and Run algorithm (ACHR).

To use this on a model, use flux_sample or sample_constraints; most parameters are filled in correctly by these functions.

epsilon is defaulted from configuration.

source
COBREXA.sample_constraint_variables — Method
sample_constraint_variables(
     sampler::Function,
     constraints::ConstraintTrees.Tree{ConstraintTrees.Constraint};
     start_variables,
@@ -70,7 +70,7 @@
     n_chains,
     kwargs...
 )
-

Sample the feasible space constrained by constraints by sampling algorithm sampler, using the start_variables as a "warm-up" for the sampling runs. Random values are derived from the seed. Computation of individual n_chains chains by sampler is parallelized over workers using screen. Extra arguments are passed to sampler.

This function returns a matrix of the samples (one sample per row). To nicely aggregate the statistics in the constraint tree, use sample_constraints.

source
COBREXA.sample_constraints — Method
sample_constraints(
+

Sample the feasible space constrained by constraints by sampling algorithm sampler, using the start_variables as a "warm-up" for the sampling runs. Random values are derived from the seed. Computation of individual n_chains chains by sampler is parallelized over workers using screen. Extra arguments are passed to sampler.

This function returns a matrix of the samples (one sample per row). To nicely aggregate the statistics in the constraint tree, use sample_constraints.

source
COBREXA.sample_constraints — Method
sample_constraints(
     sampler::Function,
     constraints::ConstraintTrees.Tree{ConstraintTrees.Constraint};
     output,
@@ -78,7 +78,7 @@
     aggregate_type,
     kwargs...
 )
-

A front-end for sample_constraint_variables that saves the sampling results in a constraint tree of the same shape as output. Additionally, aggregate function and aggregate_type can be specified to customize the output.

All other parameters are forwarded to sample_constraint_variables.

source

Analysis front-end API helpers

COBREXA.frontend_optimized_values — Method
frontend_optimized_values(
+

A front-end for sample_constraint_variables that saves the sampling results in a constraint tree of the same shape as output. Additionally, aggregate function and aggregate_type can be specified to customize the output.

All other parameters are forwarded to sample_constraint_variables.

source

Analysis front-end API helpers

COBREXA.frontend_optimized_values — Method
frontend_optimized_values(
     builder,
     args...;
     builder_kwargs,
@@ -89,7 +89,7 @@
     settings,
     kwargs...
 )
-

A helper that converts a front-end constraint builder function (the output of which would normally be just passed through optimized_values) to front-end analysis function.

source
COBREXA.frontend_parsimonious_optimized_values — Method
frontend_parsimonious_optimized_values(
+

A helper that converts a front-end constraint builder function (the output of which would normally be just passed through optimized_values) to front-end analysis function.

source
COBREXA.frontend_parsimonious_optimized_values — Method
frontend_parsimonious_optimized_values(
     builder,
     args...;
     builder_kwargs,
@@ -106,4 +106,4 @@
     tolerances,
     kwargs...
 )
-

A helper that converts a parsimonious-style front-end constraint builder function to front-end analysis function.

Like frontend_optimized_values, but internally calls parsimonious_optimized_values.

source
+

A helper that converts a parsimonious-style front-end constraint builder function to front-end analysis function.

Like frontend_optimized_values, but internally calls parsimonious_optimized_values.

source diff --git a/dev/reference/builders/index.html b/dev/reference/builders/index.html index 9b592413..720759ef 100644 --- a/dev/reference/builders/index.html +++ b/dev/reference/builders/index.html @@ -3,59 +3,59 @@ a, tree::ConstraintTrees.Tree{ConstraintTrees.Constraint} ) -> Any -

A constriant tree that makes sure that all values in tree are the same as the value of a.

Names in the output ConstraintTree match the names in the tree.

source
COBREXA.difference_constraint — Method
difference_constraint(
+

A constriant tree that makes sure that all values in tree are the same as the value of a.

Names in the output ConstraintTree match the names in the tree.

source
COBREXA.difference_constraint — Method
difference_constraint(
     a,
     b,
     difference_bound
 ) -> ConstraintTrees.Constraint
-

A constraint that makes sure that the difference from a to b is within the difference_bound. For example, difference_constraint(-1, 1, 2) will always be valid. Any type of ConstraintTree.Bound can be supplied.

source
COBREXA.equal_value_constraint — Method
equal_value_constraint(a, b) -> ConstraintTrees.Constraint
-

A constraint that makes sure that the values of a and b are the same.

source
COBREXA.greater_or_equal_constraint — Method
greater_or_equal_constraint(
+

A constraint that makes sure that the difference from a to b is within the difference_bound. For example, difference_constraint(-1, 1, 2) will always be valid. Any type of ConstraintTree.Bound can be supplied.

source
COBREXA.equal_value_constraint — Method
equal_value_constraint(a, b) -> ConstraintTrees.Constraint
+

A constraint that makes sure that the values of a and b are the same.

source
COBREXA.greater_or_equal_constraint — Method
greater_or_equal_constraint(
     a,
     b
 ) -> ConstraintTrees.Constraint
-

A constraint that makes sure that the value of a is greater than or equal to the the value of b.

source
COBREXA.less_or_equal_constraint — Method
less_or_equal_constraint(a, b) -> ConstraintTrees.Constraint
-

A constraint that makes sure that the value of a is less than or equal to the the value of b.

source

Constraint scaling

COBREXA.scale_bounds — Method
scale_bounds(
+

A constraint that makes sure that the value of a is greater than or equal to the the value of b.

source
COBREXA.less_or_equal_constraint — Method
less_or_equal_constraint(a, b) -> ConstraintTrees.Constraint
+

A constraint that makes sure that the value of a is less than or equal to the the value of b.

source

Constraint scaling

COBREXA.scale_bounds — Method
scale_bounds(
     tree::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     factor
 ) -> Any
-

Linearly scale all bounds in a constraint tree by the factor. This actually changes the model semantics, and may not work in surprising/improper ways with some constraint systems, esp. the MILP and QP ones.

See also scale_constraints.

source
COBREXA.scale_constraints — Method
scale_constraints(
+

Linearly scale all bounds in a constraint tree by the factor. This actually changes the model semantics, and may not work in surprising/improper ways with some constraint systems, esp. the MILP and QP ones.

See also scale_constraints.

source
COBREXA.scale_constraints — Method
scale_constraints(
     tree::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     factor
 ) -> Any
-

Linearly scale all constraints in a constraint tree by the factor.

See also scale_bounds.

source

Sign splitting

COBREXA.positive_bound_contribution — Method
positive_bound_contribution(
+

Linearly scale all constraints in a constraint tree by the factor.

See also scale_bounds.

source

Sign splitting

COBREXA.positive_bound_contribution — Method
positive_bound_contribution(
     b::ConstraintTrees.EqualTo
 ) -> ConstraintTrees.EqualTo
-

Clamp all negative values in the bound to zero, leaving only the "positive contribution" to the overall value of the constraint. Used in unsigned_positive_contribution_variables and unsigned_negative_contribution_variables to allocate unidirectional variables.

source
COBREXA.sign_split_constraints — Method
sign_split_constraints(; positive, negative, signed)
-

A constraint tree that bound the values present in signed to be sums of pairs of positive and negative contributions to the individual values.

Keys in the result are the same as the keys of signed constraints.

Typically, this can be used to create "unidirectional" fluxes together with unsigned_negative_contribution_variables and unsigned_positive_contribution_variables.

Use sign_split_variables to allocate the variables easily.

source
COBREXA.sign_split_variables — Method
sign_split_variables(
+

Clamp all negative values in the bound to zero, leaving only the "positive contribution" to the overall value of the constraint. Used in unsigned_positive_contribution_variables and unsigned_negative_contribution_variables to allocate unidirectional variables.

source
COBREXA.sign_split_constraints — Method
sign_split_constraints(; positive, negative, signed)
+

A constraint tree that bound the values present in signed to be sums of pairs of positive and negative contributions to the individual values.

Keys in the result are the same as the keys of signed constraints.

Typically, this can be used to create "unidirectional" fluxes together with unsigned_negative_contribution_variables and unsigned_positive_contribution_variables.

Use sign_split_variables to allocate the variables easily.

source
COBREXA.sign_split_variables — Method
sign_split_variables(
     constraints::ConstraintTrees.Tree{ConstraintTrees.Constraint};
     positive,
     negative
 ) -> ConstraintTrees.Tree{ConstraintTrees.Constraint}
-

Shortcut for making a pair of named variable groups created by unsigned_positive_contribution_variables and unsigned_negative_contribution_variables, in subtrees named by positive and negative.

Use sign_split_constraints to bind the new variables to existing values.

source
COBREXA.unsigned_negative_contribution_constraints — Method
unsigned_negative_contribution_constraints(
+

Shortcut for making a pair of named variable groups created by unsigned_positive_contribution_variables and unsigned_negative_contribution_variables, in subtrees named by positive and negative.

Use sign_split_constraints to bind the new variables to existing values.

source
COBREXA.unsigned_negative_contribution_constraints — Method
unsigned_negative_contribution_constraints(
     cs::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     positive::ConstraintTrees.Tree{ConstraintTrees.Constraint}
 ) -> Any
-

A constraint tree that connects positive unsigned variable contributions to signed ones, while acting as negative contributions.

source
COBREXA.unsigned_negative_contribution_variables — Method
unsigned_negative_contribution_variables(
+

A constraint tree that connects positive unsigned variable contributions to signed ones, while acting as negative contributions.

source
COBREXA.unsigned_negative_contribution_variables — Method
unsigned_negative_contribution_variables(
     cs::ConstraintTrees.Tree{ConstraintTrees.Constraint}
 ) -> Any
-

A constraint tree of variables with negative contributions to the values in cs.

source
COBREXA.unsigned_positive_contribution_constraints — Method
unsigned_positive_contribution_constraints(
+

A constraint tree of variables with negative contributions to the values in cs.

source
COBREXA.unsigned_positive_contribution_constraints — Method
unsigned_positive_contribution_constraints(
     cs::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     negative::ConstraintTrees.Tree{ConstraintTrees.Constraint}
 ) -> Any
-

A constraint tree that connects negative unsigned variable contributions to signed ones, while acting as positive contributions.

source
COBREXA.unsigned_positive_contribution_variables — Method
unsigned_positive_contribution_variables(
+

A constraint tree that connects negative unsigned variable contributions to signed ones, while acting as positive contributions.

source
COBREXA.unsigned_positive_contribution_variables — Method
unsigned_positive_contribution_variables(
     cs::ConstraintTrees.Tree{ConstraintTrees.Constraint}
 ) -> Any
-

A constraint tree of variables with positive contributions to the values in cs.

source

Objectives

COBREXA.squared_sum_error_value — Method
squared_sum_error_value(
+

A constraint tree of variables with positive contributions to the values in cs.

source

Objectives

COBREXA.squared_sum_error_value — Method
squared_sum_error_value(
     constraints::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     target
 ) -> Any
-

Construct a ConstraintTrees.Value out of squared error (in the RMSE-like squared-error sense) between the values in the constraint tree and the reference target.

target is a function that takes a symbol (key) and returns either a Float64 reference value, or nothing if the error of given key should not be considered.

source
COBREXA.squared_sum_value — Method
squared_sum_value(
+

Construct a ConstraintTrees.Value out of squared error (in the RMSE-like squared-error sense) between the values in the constraint tree and the reference target.

target is a function that takes a symbol (key) and returns either a Float64 reference value, or nothing if the error of given key should not be considered.

source
COBREXA.squared_sum_value — Method
squared_sum_value(
     x::ConstraintTrees.Tree{ConstraintTrees.Constraint}
 ) -> Any
-

Construct a ConstraintTrees.Value out of squared sum of all values directly present in a given constraint tree.

source
COBREXA.sum_value — Method
sum_value(
+

Construct a ConstraintTrees.Value out of squared sum of all values directly present in a given constraint tree.

source
COBREXA.sum_value — Method
sum_value(
     x...
 ) -> Union{ConstraintTrees.LinearValue, ConstraintTrees.QuadraticValue}
-

Construct a ConstraintTrees.Value out of a sum of all values directly present in a given constraint tree.

source

Analysis-specific constriants

COBREXA.loopless_constraints — Method
loopless_constraints(
+

Construct a ConstraintTrees.Value out of a sum of all values directly present in a given constraint tree.

source

Analysis-specific constriants

COBREXA.loopless_constraints — Method
loopless_constraints(
 ;
     fluxes,
     loopless_direction_indicators,
@@ -66,11 +66,11 @@
     driving_force_nonzero_bound,
     driving_force_infinity_bound
 )
-

Construct the loopless constraint system that binds fluxes of all internal_reactions to direction of loopless_direction_indicators and connects them to loopless_driving_forces. The solution is bounded to lie in internal_nullspace (which is a sufficient algebraic condition for loop-less-ness).

The indicators must be discrete variables, valued 1 if the reaction flux goes forward, or 0 if the reaction flux is reversed.

The simplest (but by no means the fastest) way to obtain a good internal_nullspace is to use LinearAlgebra.nullspace with the internal reactions' stoichiometry matrix. Rows of internal_nullspace must correspond to internal_reactions.

flux_infinity_bound is used as the maximal bound for fluxes (for constraints that connect them to indicator variables); it should optimally be greater than the maximum possible absolute value of any flux in the original model.

driving_force_nonzero_bound and driving_force_infinity_bound are similarly used to limit the individual reaction's driving forces.

source
COBREXA.knockout_constraints — Method
knockout_constraints(
+

Construct the loopless constraint system that binds fluxes of all internal_reactions to direction of loopless_direction_indicators and connects them to loopless_driving_forces. The solution is bounded to lie in internal_nullspace (which is a sufficient algebraic condition for loop-less-ness).

The indicators must be discrete variables, valued 1 if the reaction flux goes forward, or 0 if the reaction flux is reversed.

The simplest (but by no means the fastest) way to obtain a good internal_nullspace is to use LinearAlgebra.nullspace with the internal reactions' stoichiometry matrix. Rows of internal_nullspace must correspond to internal_reactions.

flux_infinity_bound is used as the maximal bound for fluxes (for constraints that connect them to indicator variables); it should optimally be greater than the maximum possible absolute value of any flux in the original model.

driving_force_nonzero_bound and driving_force_infinity_bound are similarly used to limit the individual reaction's driving forces.

source
COBREXA.knockout_constraints — Method
knockout_constraints(
     knockout_test::Function,
     fluxes::ConstraintTrees.Tree{ConstraintTrees.Constraint}
 ) -> ConstraintTrees.Tree{ConstraintTrees.Constraint}
-

Make a ConstraintTree that knocks out fluxes given by the predicate knockout_test. The predicate function is called with a single parameter (the key of the flux in tree fluxes) and must return a boolean. Returning true means that the corresponding flux (usually a reaction flux) will be knocked out.

source
COBREXA.enzyme_constraints — Method
enzyme_constraints(
+

Make a ConstraintTree that knocks out fluxes given by the predicate knockout_test. The predicate function is called with a single parameter (the key of the flux in tree fluxes) and must return a boolean. Returning true means that the corresponding flux (usually a reaction flux) will be knocked out.

source
COBREXA.enzyme_constraints — Method
enzyme_constraints(
 ;
     fluxes_forward,
     fluxes_reverse,
@@ -86,7 +86,7 @@
     gene_product_amounts_name,
     gene_product_capacity_name
 )
-

Connect variables returned by enzyme_variables to unidirectional fluxes. This is used to construct the contraint system for enzyme_constrained_flux_balance_constraints.

Parameters fluxes_forward, fluxes_reverse, isozyme_forward_amounts, isozyme_reverse_amounts and gene_product_amounts should correspond to parameters and results of enzyme_variables.

Further, parameter functions kcat_forward and kcat_reverse specify the turnover numbers for reaction and isozyme IDs given in parameters; isozyme_gene_product_stoichiometry specifies the composition of the reaction-isozyme IDs given in parameter by returning an interable mapping of gene product IDs to numbers (such as Dict{Symbol, Float64}), and gene_product_molar_mass specifies a numeric mass for a given gene product ID. All parameter functions may return nothing, at which point the given object is considered nonexistent and is omitted from constraints.

capacity_limits is an interable container of triples (limit_id, gene_product_ids, capacity_bound) which are converted to a constraint identified by the limit_id that limits the total mass of gene_product_ids (which is any iterable container) by capacity_bound.

source
COBREXA.enzyme_variables — Method
enzyme_variables(
+

Connect variables returned by enzyme_variables to unidirectional fluxes. This is used to construct the contraint system for enzyme_constrained_flux_balance_constraints.

Parameters fluxes_forward, fluxes_reverse, isozyme_forward_amounts, isozyme_reverse_amounts and gene_product_amounts should correspond to parameters and results of enzyme_variables.

Further, parameter functions kcat_forward and kcat_reverse specify the turnover numbers for reaction and isozyme IDs given in parameters; isozyme_gene_product_stoichiometry specifies the composition of the reaction-isozyme IDs given in parameter by returning an interable mapping of gene product IDs to numbers (such as Dict{Symbol, Float64}), and gene_product_molar_mass specifies a numeric mass for a given gene product ID. All parameter functions may return nothing, at which point the given object is considered nonexistent and is omitted from constraints.

capacity_limits is an interable container of triples (limit_id, gene_product_ids, capacity_bound) which are converted to a constraint identified by the limit_id that limits the total mass of gene_product_ids (which is any iterable container) by capacity_bound.

source
COBREXA.enzyme_variables — Method
enzyme_variables(
 ;
     fluxes_forward,
     fluxes_reverse,
@@ -96,20 +96,20 @@
     isozyme_forward_amounts_name,
     isozyme_reverse_amounts_name
 )
-

Returns a constraint tree with enzyme capacity constraints, added for reactions in fluxes_forward and fluxes_reverse. This is used to construct the constraint system in enzyme_constrained_flux_balance_constraints.

Parameter function isozyme_ids takes a reaction ID and returns nothing if the reaction does not have isozymes associated with it, or an iterable container of all the isozyme IDs for that reaction (as Symbols).

Parameters isozyme_forward_ids and isozyme_reverse_ids can be used to fine-tune the generated isozymes in either direction; both default to isozyme_ids.

The keys in the output constraint tree can be customized by setting isozyme_forward_amounts_name, isozyme_reverse_amounts_name and gene_product_amounts_name.

source
COBREXA.isozyme_amount_variables — Method
isozyme_amount_variables(
+

Returns a constraint tree with enzyme capacity constraints, added for reactions in fluxes_forward and fluxes_reverse. This is used to construct the constraint system in enzyme_constrained_flux_balance_constraints.

Parameter function isozyme_ids takes a reaction ID and returns nothing if the reaction does not have isozymes associated with it, or an iterable container of all the isozyme IDs for that reaction (as Symbols).

Parameters isozyme_forward_ids and isozyme_reverse_ids can be used to fine-tune the generated isozymes in either direction; both default to isozyme_ids.

The keys in the output constraint tree can be customized by setting isozyme_forward_amounts_name, isozyme_reverse_amounts_name and gene_product_amounts_name.

source
COBREXA.isozyme_amount_variables — Method
isozyme_amount_variables(
     fluxes,
     flux_isozymes
 ) -> ConstraintTrees.Tree{ConstraintTrees.Constraint}
-

Create a ConstraintTree with variables for isozyme contributions to reaction fluxes. The tree has 2 levels: the first contains all reaction flux IDs that have isozymes, the second contains the isozyme IDs for each reaction flux.

fluxes should be anything that can be iterated to give reaction flux IDs.

flux_isozymes is a function that, for a given reaction flux ID, returns anything iterable that contains the isozyme IDs for the given reaction flux. Returning an empty iterable prevents allocating the subtree for the given flux.

source
COBREXA.isozyme_flux_constraints — Method
isozyme_flux_constraints(
+

Create a ConstraintTree with variables for isozyme contributions to reaction fluxes. The tree has 2 levels: the first contains all reaction flux IDs that have isozymes, the second contains the isozyme IDs for each reaction flux.

fluxes should be anything that can be iterated to give reaction flux IDs.

flux_isozymes is a function that, for a given reaction flux ID, returns anything iterable that contains the isozyme IDs for the given reaction flux. Returning an empty iterable prevents allocating the subtree for the given flux.

source
COBREXA.isozyme_flux_constraints — Method
isozyme_flux_constraints(
     isozyme_amounts::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     fluxes::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     kcat
 ) -> ConstraintTrees.Tree{ConstraintTrees.Constraint}
-

A constraint tree that sums up partial contributions of reaction isozymes to the fluxes of reactions.

For practical purposes, both fluxes and isozymes are here considered to be unidirectional, i.e., one would typically apply this twice to constraint both "forward" and "reverse" fluxes.

Function kcat should return the kcat value for a given reaction and isozyme (IDs of which respectively form the 2 parameters for each call).

source
COBREXA.isozyme_gene_product_amount_constraints — Method
isozyme_gene_product_amount_constraints(
+

A constraint tree that sums up partial contributions of reaction isozymes to the fluxes of reactions.

For practical purposes, both fluxes and isozymes are here considered to be unidirectional, i.e., one would typically apply this twice to constraint both "forward" and "reverse" fluxes.

Function kcat should return the kcat value for a given reaction and isozyme (IDs of which respectively form the 2 parameters for each call).

source
COBREXA.isozyme_gene_product_amount_constraints — Method
isozyme_gene_product_amount_constraints(
     isozyme_amounts,
     isozyme_stoichiometry
 ) -> ConstraintTrees.Tree{ConstraintTrees.Constraint}
-

A constraint tree that computes the gene product amounts from given isozyme amounts their multiplicities (aka. stoichiometries, protein units, ...) given by isozyme_stoichiometry.

Values in ConstraintTree gene_product_amounts should describe the gene product allocations. Allocation for the isozyme is ignored if the gene product is missing in gene_product_amounts.

isozyme_amounts is an iterable that contains several ConstraintTrees that describe the allocated isozyme amounts (typically these would be created by isozyme_amount_variables. The multiple trees may describe several different kinds of isozyme use, e.g., you can use it to pass in both forward- and reverse-direction amounts at once. To only use a single tree, use an uni-tuple: isozyme_amounts = tuple(my_tree).

Parameter function isozyme_stoichiometry gets called with a reaction and isozyme IDs as given by the isozyme amount trees. It should return nothing in case there's no information – in such case, the isozyme is not going to be included in the calculation of gene product mass.

source
COBREXA.simplified_enzyme_constraints — Method
simplified_enzyme_constraints(
+

A constraint tree that computes the gene product amounts from given isozyme amounts their multiplicities (aka. stoichiometries, protein units, ...) given by isozyme_stoichiometry.

Values in ConstraintTree gene_product_amounts should describe the gene product allocations. Allocation for the isozyme is ignored if the gene product is missing in gene_product_amounts.

isozyme_amounts is an iterable that contains several ConstraintTrees that describe the allocated isozyme amounts (typically these would be created by isozyme_amount_variables. The multiple trees may describe several different kinds of isozyme use, e.g., you can use it to pass in both forward- and reverse-direction amounts at once. To only use a single tree, use an uni-tuple: isozyme_amounts = tuple(my_tree).

Parameter function isozyme_stoichiometry gets called with a reaction and isozyme IDs as given by the isozyme amount trees. It should return nothing in case there's no information – in such case, the isozyme is not going to be included in the calculation of gene product mass.

source
COBREXA.simplified_enzyme_constraints — Method
simplified_enzyme_constraints(
 ;
     fluxes_forward,
     fluxes_reverse,
@@ -117,14 +117,14 @@
     mass_cost_reverse,
     capacity_limits
 )
-

Build a constraint system that bounds fluxes according to their enzyme mass requirements, with respect to per-reaction enzyme mass costs.

Parameter functions mass_cost_forward and mass_cost_reverse take a flux ID (corresponding to a flux in fluxes_forward and fluxes_reverse) and return the enzyme mass required to catalyze one "unit" of reaction in the forward or reverse direction, respectively. Returning nothing ignores the mass cost.

capacity_limits is an iterable container of triples (limit_id, flux_ids, bound), which creates the capacity bounds over groups of fluxes (in the same manner as for gene products in enzyme_constraints).

source
COBREXA.simplified_isozyme_gene_product_amount_constraints — Method
simplified_isozyme_gene_product_amount_constraints(
+

Build a constraint system that bounds fluxes according to their enzyme mass requirements, with respect to per-reaction enzyme mass costs.

Parameter functions mass_cost_forward and mass_cost_reverse take a flux ID (corresponding to a flux in fluxes_forward and fluxes_reverse) and return the enzyme mass required to catalyze one "unit" of reaction in the forward or reverse direction, respectively. Returning nothing ignores the mass cost.

capacity_limits is an iterable container of triples (limit_id, flux_ids, bound), which creates the capacity bounds over groups of fluxes (in the same manner as for gene products in enzyme_constraints).

source
COBREXA.simplified_isozyme_gene_product_amount_constraints — Method
simplified_isozyme_gene_product_amount_constraints(
     x...
 ) -> ConstraintTrees.Tree{ConstraintTrees.Constraint}
-

Like isozyme_gene_product_amount_constraints, but works with the "simplified" view where each reaction has an uniquely determined catalytic isozyme, as with simplified_enzyme_constraints.

As the main difference, the arguments are tuples that contain first the constraint tree without the "isozyme" layer (i.e., fluxes), and second a function that returns the gene product stoichiometry and the turnover number (again in a tuple) for the given flux identifier.

source

Interfacing of constraint systems

COBREXA.interface_constraints — Method
interface_constraints(
+

Like isozyme_gene_product_amount_constraints, but works with the "simplified" view where each reaction has an uniquely determined catalytic isozyme, as with simplified_enzyme_constraints.

As the main difference, the arguments are tuples that contain first the constraint tree without the "isozyme" layer (i.e., fluxes), and second a function that returns the gene product stoichiometry and the turnover number (again in a tuple) for the given flux identifier.

source

Interfacing of constraint systems

COBREXA.interface_constraints — Method
interface_constraints(
     kv;
     kwargs...
 ) -> ConstraintTrees.Tree{ConstraintTrees.Constraint}
-

Overload of interface_constraints for general key-value containers.

source
COBREXA.interface_constraints — Method
interface_constraints(
+

Overload of interface_constraints for general key-value containers.

source
COBREXA.interface_constraints — Method
interface_constraints(
     ps::Pair...;
     default_interface,
     out_interface,
@@ -132,4 +132,4 @@
     ignore,
     bound
 ) -> ConstraintTrees.Tree{ConstraintTrees.Constraint}
-

Join multiple constraint tree modules with interfaces into a bigger module with an interface.

Modules are like usual constraint trees, but contain an explicitly declared interface part, marked properly in arguments using e.g. a tuple (the parameters should form a dictionary constructor that would generally look such as :module_name => (module, module.interface); the second tuple member may also be specified just by name as e.g. :interface, or omitted while relying on default_interface).

Interface parts get merged and constrained to create a new interface; networks are intact with disjoint variable sets.

Compatible modules with ready-made interfaces may be created e.g. by flux_balance_constraints.

ignore may be used to selectively ignore parts of interfaces given the "module name" identifier and constraint path in the interface (these form 2 parameters passed to ignore). Similarly, bound may be used to specify bounds for the new interface, if required.

source
+

Join multiple constraint tree modules with interfaces into a bigger module with an interface.

Modules are like usual constraint trees, but contain an explicitly declared interface part, marked properly in arguments using e.g. a tuple (the parameters should form a dictionary constructor that would generally look such as :module_name => (module, module.interface); the second tuple member may also be specified just by name as e.g. :interface, or omitted while relying on default_interface).

Interface parts get merged and constrained to create a new interface; networks are intact with disjoint variable sets.

Compatible modules with ready-made interfaces may be created e.g. by flux_balance_constraints.

ignore may be used to selectively ignore parts of interfaces given the "module name" identifier and constraint path in the interface (these form 2 parameters passed to ignore). Similarly, bound may be used to specify bounds for the new interface, if required.

source diff --git a/dev/reference/core/index.html b/dev/reference/core/index.html index 9d97b465..b2592286 100644 --- a/dev/reference/core/index.html +++ b/dev/reference/core/index.html @@ -1,66 +1,66 @@ Core functionality · COBREXA.jl
GitHub

Core functionality

Model I/O

COBREXA.download_model — Method
download_model(args...; kwargs...) -> Any
-

Safely download a model with a known hash. All arguments are forwarded to AbstractFBCModels.download_data_file – see the documentation in the AbstractFBCModels package for details.

source
COBREXA.load_model — Method
load_model(path::String) -> Any
-

Load a FBC model representation while guessing the correct model type to load. Uses AbstractFBCModels.load.

This overload almost always involves a search over types; do not use it in environments where performance is critical.

source
COBREXA.load_model — Method
load_model(
+

Safely download a model with a known hash. All arguments are forwarded to AbstractFBCModels.download_data_file – see the documentation in the AbstractFBCModels package for details.

source
COBREXA.load_model — Method
load_model(path::String) -> Any
+

Load a FBC model representation while guessing the correct model type to load. Uses AbstractFBCModels.load.

This overload almost always involves a search over types; do not use it in environments where performance is critical.

source
COBREXA.load_model — Method
load_model(
     model_type::Type{I<:AbstractFBCModels.AbstractFBCModel},
     path::String
 ) -> Any
-

Load a FBC model representation from a known model_type. Uses AbstractFBCModels.load.

source
COBREXA.load_model — Method
load_model(
+

Load a FBC model representation from a known model_type. Uses AbstractFBCModels.load.

source
COBREXA.load_model — Method
load_model(
     model_type::Type{I<:AbstractFBCModels.AbstractFBCModel},
     path::String,
     convert_to::Type{O<:AbstractFBCModels.AbstractFBCModel}
 ) -> Any
-

Overload of load_model that explicitly specifies the known input type, and immediately converts to another model type given by argument convert_to.

source
COBREXA.load_model — Method
load_model(
+

Overload of load_model that explicitly specifies the known input type, and immediately converts to another model type given by argument convert_to.

source
COBREXA.load_model — Method
load_model(
     path::String,
     convert_to::Type{O<:AbstractFBCModels.AbstractFBCModel}
 ) -> Any
-

Overload of load_model that guesses the input type, but immediately converts to the model type given by argument convert_to.

source
COBREXA.save_converted_model — Method
save_converted_model(
     model::AbstractFBCModels.AbstractFBCModel,
     path::String
 ) -> Any
-

Like save_model but tries to convert the model to a type that matches the extension of the path. For example, this will convert the model to a JSON model type in case the path ends with .json.

This is an utility shortcut – if possible, it is always better to specify the output model type explicitly.

source
COBREXA.save_model — Method
save_model(
+

Like save_model but tries to convert the model to a type that matches the extension of the path. For example, this will convert the model to a JSON model type in case the path ends with .json.

This is an utility shortcut – if possible, it is always better to specify the output model type explicitly.

source
COBREXA.save_model — Method
save_model(
     model::AbstractFBCModels.AbstractFBCModel,
     path::String,
     convert_to::Type{O<:AbstractFBCModels.AbstractFBCModel}
 ) -> Any
-

Overload of save_model that converts the model type to convert_to before saving.

source
COBREXA.save_model — Method
save_model(
     model::AbstractFBCModels.AbstractFBCModel,
     path::String
 ) -> Any
-

Save a FBC model representation. Uses AbstractFBCModels.save.

Use the 3-parameter overload if you need to convert the model to another representation (e.g., if you want to save a canonical model type as JSON or SBML).

source

Types

Configuration

COBREXA.configuration — Constant
const configuration

The configuration object. You can change the contents of configuration to override the default behavior of some of the functions.

The available options are described by struct Configuration.

source
COBREXA.Configuration — Type
mutable struct Configuration

Global configuration options for various COBREXA functions, mainly for various non-interesting function parameters that are too inconvenient to be passed around manually.

Changing the configuration values at runtime is possible via the global configuration variable.

Fields

  • exchange_id_prefixes::Vector{String}: Prefixes that flux_balance_constraints uses for guessing which reactions are exchanges.
  • biomass_id_prefixes::Vector{String}: Prefixes that flux_balance_constraints uses for guessing which reactions are biomass reactions.
  • atp_maintenance_ids::Vector{String}: Reaction identifiers that flux_balance_constraints considers to be ATP maintenance reactions.
  • sampler_tolerance::Any: Default numerical tolerance for sampling functions.
  • default_solver_settings::Any: Default settings first applied to all JuMP Models.
source

Solver interface

COBREXA.Feasible — Constant
Maximal

Objective sense for finding the any feasible value of the objective.

Same as JuMP.FEASIBILITY_SENSE.

source
COBREXA.Maximal — Constant
Maximal

Objective sense for finding the maximal value of the objective.

Same as JuMP.MAX_SENSE.

source
COBREXA.Minimal — Constant
Minimal

Objective sense for finding the minimal value of the objective.

Same as JuMP.MIN_SENSE.

source
COBREXA.Switch — Type
mutable struct Switch <: ConstraintTrees.Bound

Representation of a "binary switch" bound for ConstraintTrees. The value is constrained to be either the value of field a or of field b; both fields are Float64s. Upon translation to JuMP, the switches create an extra boolean variable, and the value is constrained to equal a + boolean_var * (b-a).

Switches can be offset by adding real numbers, negated, and multiplied and divided by scalar constraints. For optimizing some special cases, multiplying by exact zero returns an equality bound to zero.

Fields

  • a::Float64: One choice

  • b::Float64: The other choice

source
COBREXA.constraint_jump! — Method
constraint_jump!(
+

Save a FBC model representation. Uses AbstractFBCModels.save.

Use the 3-parameter overload if you need to convert the model to another representation (e.g., if you want to save a canonical model type as JSON or SBML).

source

Types

Configuration

COBREXA.configuration — Constant
const configuration

The configuration object. You can change the contents of configuration to override the default behavior of some of the functions.

The available options are described by struct Configuration.

source
COBREXA.Configuration — Type
mutable struct Configuration

Global configuration options for various COBREXA functions, mainly for various non-interesting function parameters that are too inconvenient to be passed around manually.

Changing the configuration values at runtime is possible via the global configuration variable.

Fields

  • exchange_id_prefixes::Vector{String}: Prefixes that flux_balance_constraints uses for guessing which reactions are exchanges.
  • biomass_id_prefixes::Vector{String}: Prefixes that flux_balance_constraints uses for guessing which reactions are biomass reactions.
  • atp_maintenance_ids::Vector{String}: Reaction identifiers that flux_balance_constraints considers to be ATP maintenance reactions.
  • sampler_tolerance::Any: Default numerical tolerance for sampling functions.
  • default_solver_settings::Any: Default settings first applied to all JuMP Models.
source

Solver interface

COBREXA.Feasible — Constant
Maximal

Objective sense for finding the any feasible value of the objective.

Same as JuMP.FEASIBILITY_SENSE.

source
COBREXA.Maximal — Constant
Maximal

Objective sense for finding the maximal value of the objective.

Same as JuMP.MAX_SENSE.

source
COBREXA.Minimal — Constant
Minimal

Objective sense for finding the minimal value of the objective.

Same as JuMP.MIN_SENSE.

source
COBREXA.Switch — Type
mutable struct Switch <: ConstraintTrees.Bound

Representation of a "binary switch" bound for ConstraintTrees. The value is constrained to be either the value of field a or of field b; both fields are Float64s. Upon translation to JuMP, the switches create an extra boolean variable, and the value is constrained to equal a + boolean_var * (b-a).

Switches can be offset by adding real numbers, negated, and multiplied and divided by scalar constraints. For optimizing some special cases, multiplying by exact zero returns an equality bound to zero.

Fields

  • a::Float64: One choice

  • b::Float64: The other choice

source
COBREXA.constraint_jump! — Method
constraint_jump!(
     model,
     expr,
     b::ConstraintTrees.Between
 ) -> Union{Bool, JuMP.ConstraintRef}
-

Add an interval constraint to a JuMP model.

source
COBREXA.constraint_jump! — Method
constraint_jump!(
     model,
     expr,
     b::ConstraintTrees.EqualTo
 ) -> JuMP.ConstraintRef
-

Add an equality constraint to a JuMP model.

source
COBREXA.is_solved — Method
is_solved(opt_model::JuMP.Model) -> Bool
-

true if opt_model solved successfully (solution is optimal or locally optimal). false if any other termination status is reached.

source
COBREXA.is_solved — Method
is_solved(opt_model::JuMP.Model) -> Bool
+

true if opt_model solved successfully (solution is optimal or locally optimal). false if any other termination status is reached.

source
COBREXA.optimization_model — Method
optimization_model(
     cs::Union{ConstraintTrees.Constraint, ConstraintTrees.Tree{ConstraintTrees.Constraint}};
     objective,
     optimizer,
     sense
 )
-

Construct a JuMP Model that describes the precise constraint system into the JuMP Model created for solving in optimizer, with a given optional objective and optimization sense chosen from Maximal, Minimal and Feasible.

All types of values in the constraint tree must have an overload for substitute_jump.

source
COBREXA.optimized_model — Method
optimized_model(om; output)
-

Like optimized_values, but works directly with a given JuMP model om without applying any settings or creating the optimization model.

To run the process manually, you can use optimization_model to convert the constraints into a suitable JuMP optimization model.

source
COBREXA.optimized_objective — Method
optimized_objective(
+

Construct a JuMP Model that describes the precise constraint system into the JuMP Model created for solving in optimizer, with a given optional objective and optimization sense chosen from Maximal, Minimal and Feasible.

All types of values in the constraint tree must have an overload for substitute_jump.

source
COBREXA.optimized_model — Method
optimized_model(om; output)
+

Like optimized_values, but works directly with a given JuMP model om without applying any settings or creating the optimization model.

To run the process manually, you can use optimization_model to convert the constraints into a suitable JuMP optimization model.

source
COBREXA.substitute_jump — Method
substitute_jump(
     val::ConstraintTrees.LinearValue,
     vars
 ) -> JuMP.AffExpr
-

Very efficiently substitute a ConstraintTrees' LinearValue into a JuMP expression of type AffExpr.

source
COBREXA.substitute_jump — Method
substitute_jump(
+

Very efficiently substitute a ConstraintTrees' LinearValue into a JuMP expression of type AffExpr.

source
COBREXA.substitute_jump — Method
substitute_jump(
     val::ConstraintTrees.QuadraticValue,
     vars
 ) -> JuMP.QuadExpr
-

Very efficiently substitute a ConstraintTrees' QuadraticValue into a JuMP expression of type QuadExpr.

source

Task distribution support

COBREXA.worker_local_data — Type
mutable struct worker_local_data

Helper struct that provides access to local data that are unboxed and cached directly on distributed workers.

Use with get_worker_local_data and Distributed.CachingPool.

Fields

  • transfer_data::Any: The data that is transferred to the remote worker

  • local_data::Union{Nothing, Some}: The data that is cached on the remote worker

  • transform::Function: The function that converts the transferred data to locally-cached data on the remote worker

source
COBREXA.get_worker_local_data — Method
get_worker_local_data(x::COBREXA.worker_local_data) -> Any
-

"Unwrap" the worker_local_data on a remote worker to get the local_data out. If required, executes the transform function.

Local copies of transfer_data are forgotten after the function executes.

source
+

Very efficiently substitute a ConstraintTrees' QuadraticValue into a JuMP expression of type QuadExpr.

source
COBREXA.variable_vector — Method
variable_vector(opt_model::JuMP.Model) -> Any
+

Retrieve the variable vector from a JuMP model created by optimization_model.

source

Task distribution support

COBREXA.worker_local_data — Type
mutable struct worker_local_data

Helper struct that provides access to local data that are unboxed and cached directly on distributed workers.

Use with get_worker_local_data and Distributed.CachingPool.

Fields

  • transfer_data::Any: The data that is transferred to the remote worker

  • local_data::Union{Nothing, Some}: The data that is cached on the remote worker

  • transform::Function: The function that converts the transferred data to locally-cached data on the remote worker

source
COBREXA.get_worker_local_data — Method
get_worker_local_data(x::COBREXA.worker_local_data) -> Any
+

"Unwrap" the worker_local_data on a remote worker to get the local_data out. If required, executes the transform function.

Local copies of transfer_data are forgotten after the function executes.

source
diff --git a/dev/reference/frontend/index.html b/dev/reference/frontend/index.html index 9e153a4c..b687ceb2 100644 --- a/dev/reference/frontend/index.html +++ b/dev/reference/frontend/index.html @@ -3,12 +3,12 @@ model::AbstractFBCModels.AbstractFBCModel; kwargs... ) -

Compute an optimal objective-optimizing solution of the given model.

Most arguments are forwarded to optimized_values.

Returns a tree with the optimization solution of the same shape as given by flux_balance_constraints.

source
COBREXA.flux_balance_constraints — Method
flux_balance_constraints(
+

Compute an optimal objective-optimizing solution of the given model.

Most arguments are forwarded to optimized_values.

Returns a tree with the optimization solution of the same shape as given by flux_balance_constraints.

source
COBREXA.flux_balance_constraints — Method
flux_balance_constraints(
     model::AbstractFBCModels.AbstractFBCModel;
     interface,
     interface_name
 ) -> Any
-

A constraint tree that models the content of the given instance of AbstractFBCModel.

The constructed tree contains subtrees fluxes (with the reaction-defining "variables") and flux_stoichiometry (with the metabolite-balance-defining constraints), and a single constraint objective thad describes the objective function of the model.

Optionally if interface is specified, an "interface block" will be created within the constraint tree for later use as a "module" in creating bigger models (such as communities) using interface_constraints. The possible parameter values include:

  • nothing – default, no interface is created
  • :sbo – the interface gets created from model's SBO annotations)
  • :identifier_prefixes – the interface is guesstimated from commonly occurring adhoc reaction ID prefixes used in contemporary models
  • :boundary – the interface is created from all reactions that either only consume or only produce metabolites

Output interface name can be set via interface_name.

See Configuration for fine-tuning the default interface creation.

source

Flux variability analysis

COBREXA.flux_variability_analysis — Method
flux_variability_analysis(
+

A constraint tree that models the content of the given instance of AbstractFBCModel.

The constructed tree contains subtrees fluxes (with the reaction-defining "variables") and flux_stoichiometry (with the metabolite-balance-defining constraints), and a single constraint objective thad describes the objective function of the model.

Optionally if interface is specified, an "interface block" will be created within the constraint tree for later use as a "module" in creating bigger models (such as communities) using interface_constraints. The possible parameter values include:

  • nothing – default, no interface is created
  • :sbo – the interface gets created from model's SBO annotations)
  • :identifier_prefixes – the interface is guesstimated from commonly occurring adhoc reaction ID prefixes used in contemporary models
  • :boundary – the interface is created from all reactions that either only consume or only produce metabolites

Output interface name can be set via interface_name.

See Configuration for fine-tuning the default interface creation.

source

Flux variability analysis

COBREXA.flux_variability_analysis — Method
flux_variability_analysis(
     model::AbstractFBCModels.AbstractFBCModel;
     objective_bound,
     reactions,
@@ -16,25 +16,25 @@
     settings,
     workers
 )
-

Perform a Flux Variability Analysis (FVA) on the model, and return a dictionary of flux ranges where the model is able to perform optimally.

The constraint system is constructed using flux_balance_constraints, and the variability is examined on all reaction's fluxes, or on the subset given optionally in reaction_subset (e.g., reaction_subset = ["PFK", "ACALD"]). The optimality tolerance can be specified with objective_bound using e.g. relative_tolerance_bound or absolute_tolerance_bound; the default is 99% relative tolerance.

Parameter workers may be used to enable parallel or distributed processing; the execution defaults to all available workers. Other parameters (esp. optimizer) are internally forwarded to optimized_values.

Use constraints_variability to customize the FVA execution.

source

Parsimonious flux balance analysis

COBREXA.linear_parsimonious_flux_balance_analysis — Method
linear_parsimonious_flux_balance_analysis(
+

Perform a Flux Variability Analysis (FVA) on the model, and return a dictionary of flux ranges where the model is able to perform optimally.

The constraint system is constructed using flux_balance_constraints, and the variability is examined on all reaction's fluxes, or on the subset given optionally in reaction_subset (e.g., reaction_subset = ["PFK", "ACALD"]). The optimality tolerance can be specified with objective_bound using e.g. relative_tolerance_bound or absolute_tolerance_bound; the default is 99% relative tolerance.

Parameter workers may be used to enable parallel or distributed processing; the execution defaults to all available workers. Other parameters (esp. optimizer) are internally forwarded to optimized_values.

Use constraints_variability to customize the FVA execution.

source

Parsimonious flux balance analysis

COBREXA.linear_parsimonious_flux_balance_analysis — Method
linear_parsimonious_flux_balance_analysis(
     model::AbstractFBCModels.AbstractFBCModel;
     tolerances,
     kwargs...
 )
-

Like parsimonious_flux_balance_analysis, but uses the L1-metric parsimonious system given by linear_parsimonious_flux_balance_constraints.

In turn, the solution is often faster, does not require a solver capable of quadratic objectives, and has many beneficial properties of the usual parsimonious solutions (such as the general lack of unnecessary loops). On the other hand, like with plain flux balance analysis there is no strong guarantee of uniqueness of the solution.

Solver configuration arguments are forwarded to parsimonious_optimized_values.

source
COBREXA.linear_parsimonious_flux_balance_constraints — Method
linear_parsimonious_flux_balance_constraints(
+

Like parsimonious_flux_balance_analysis, but uses the L1-metric parsimonious system given by linear_parsimonious_flux_balance_constraints.

In turn, the solution is often faster, does not require a solver capable of quadratic objectives, and has many beneficial properties of the usual parsimonious solutions (such as the general lack of unnecessary loops). On the other hand, like with plain flux balance analysis there is no strong guarantee of uniqueness of the solution.

Solver configuration arguments are forwarded to parsimonious_optimized_values.

source
COBREXA.linear_parsimonious_flux_balance_constraints — Method
linear_parsimonious_flux_balance_constraints(
     model::AbstractFBCModels.AbstractFBCModel;
     kwargs...
 ) -> ConstraintTrees.Tree
-

Like parsimonious_flux_balance_constraints, but uses a L1 metric for solving the parsimonious problem. The parsimonious_objective constraint is thus linear.

Keyword arguments are forwarded to flux_balance_constraints.

source
COBREXA.parsimonious_flux_balance_analysis — Method
parsimonious_flux_balance_analysis(
+

Like parsimonious_flux_balance_constraints, but uses a L1 metric for solving the parsimonious problem. The parsimonious_objective constraint is thus linear.

Keyword arguments are forwarded to flux_balance_constraints.

source
COBREXA.parsimonious_flux_balance_analysis — Method
parsimonious_flux_balance_analysis(
     model::AbstractFBCModels.AbstractFBCModel;
     tolerances,
     kwargs...
 )
-

Compute a parsimonious flux solution for the model, using the constraints given by parsimonious_flux_balance_constraints.

In short, the objective value of the parsimonious solution should be the same as the one from flux_balance_analysis, except the squared sum of reaction fluxes is minimized. If there are multiple possible fluxes that achieve a given objective value, parsimonious flux thus represents the "minimum energy" one, which is arguably more realistic.

Solver configuration arguments are forwarded to parsimonious_optimized_values.

source
COBREXA.parsimonious_flux_balance_constraints — Method
parsimonious_flux_balance_constraints(
+

Compute a parsimonious flux solution for the model, using the constraints given by parsimonious_flux_balance_constraints.

In short, the objective value of the parsimonious solution should be the same as the one from flux_balance_analysis, except the squared sum of reaction fluxes is minimized. If there are multiple possible fluxes that achieve a given objective value, parsimonious flux thus represents the "minimum energy" one, which is arguably more realistic.

Solver configuration arguments are forwarded to parsimonious_optimized_values.

source
COBREXA.parsimonious_flux_balance_constraints — Method
parsimonious_flux_balance_constraints(
     model::AbstractFBCModels.AbstractFBCModel;
     kwargs...
 ) -> Any
-

A constraint system like from flux_balance_constraints, but with the parsimonious objective present under key parsimonious_objective. Best used via parsimonious_flux_balance_analysis.

Keyword arguments are forwarded to flux_balance_constraints.

source

Minimization of metabolic adjustment

COBREXA.linear_metabolic_adjustment_minimization_analysis — Method
linear_metabolic_adjustment_minimization_analysis(
+

A constraint system like from flux_balance_constraints, but with the parsimonious objective present under key parsimonious_objective. Best used via parsimonious_flux_balance_analysis.

Keyword arguments are forwarded to flux_balance_constraints.

source

Minimization of metabolic adjustment

COBREXA.linear_metabolic_adjustment_minimization_analysis — Method
linear_metabolic_adjustment_minimization_analysis(
     model::AbstractFBCModels.AbstractFBCModel,
     args...;
     optimizer,
@@ -45,17 +45,17 @@
     reference_settings,
     kwargs...
 )
-

Perform a linear minimization of metabolic adjustment analysis (l-MOMA) on model. The reference is given by the second argument, which is either a reference_flux or a reference_model (the second argument is forwarded to linear_metabolic_adjustment_minimization_constraints).

While the solution is "less uniquely defined" than with fully quadratic metabolic_adjustment_minimization_analysis, the linear variant typically produces a sufficiently good result with much less resources. See documentation of linear_parsimonious_flux_balance_analysis for some of the considerations.

source
COBREXA.linear_metabolic_adjustment_minimization_constraints — Method
linear_metabolic_adjustment_minimization_constraints(
+

Perform a linear minimization of metabolic adjustment analysis (l-MOMA) on model. The reference is given by the second argument, which is either a reference_flux or a reference_model (the second argument is forwarded to linear_metabolic_adjustment_minimization_constraints).

While the solution is "less uniquely defined" than with fully quadratic metabolic_adjustment_minimization_analysis, the linear variant typically produces a sufficiently good result with much less resources. See documentation of linear_parsimonious_flux_balance_analysis for some of the considerations.

source
COBREXA.linear_metabolic_adjustment_minimization_constraints — Method
linear_metabolic_adjustment_minimization_constraints(
     model::AbstractFBCModels.AbstractFBCModel,
     reference_model::AbstractFBCModels.AbstractFBCModel;
     kwargs...
 ) -> Union{Nothing, ConstraintTrees.Tree}
-

Like metabolic_adjustment_minimization_constraints but the output constraints optimize the L1 distance from the linear-parsimonious solution of the reference_model.

source
COBREXA.linear_metabolic_adjustment_minimization_constraints — Method
linear_metabolic_adjustment_minimization_constraints(
+

Like metabolic_adjustment_minimization_constraints but the output constraints optimize the L1 distance from the linear-parsimonious solution of the reference_model.

source
COBREXA.linear_metabolic_adjustment_minimization_constraints — Method
linear_metabolic_adjustment_minimization_constraints(
     model::AbstractFBCModels.AbstractFBCModel,
     reference_fluxes::ConstraintTrees.Tree;
     _...
 ) -> ConstraintTrees.Tree
-

Like metabolic_adjustment_minimization_constraints but optimizes the L1 distance from reference_fluxes.

Keyword arguments are discarded for compatibility with the other overload.

source
COBREXA.metabolic_adjustment_minimization_analysis — Method
metabolic_adjustment_minimization_analysis(
+

Like metabolic_adjustment_minimization_constraints but optimizes the L1 distance from reference_fluxes.

Keyword arguments are discarded for compatibility with the other overload.

source
COBREXA.metabolic_adjustment_minimization_analysis — Method
metabolic_adjustment_minimization_analysis(
     model::AbstractFBCModels.AbstractFBCModel,
     args...;
     optimizer,
@@ -66,28 +66,28 @@
     reference_settings,
     kwargs...
 )
-

Find a solution of the "minimization of metabolic adjustment" (MOMA) analysis for the model, which is the "closest" feasible solution to the solution given in the second argument, which is either reference_fluxes or reference_model (see documentation of metabolic_adjustment_minimization_constraints), in the sense of squared-sum distance. The minimized squared distance (the objective) is present in the result tree as minimal_adjustment_objective.

If the second argument is a reference model, it is solved using a parsimonious_flux_balance_analysis with the optimizer and settings parameters for the 2 steps set by keyword arguments prefixed by reference_.

This is often used for models with smaller feasible region than the reference models (typically handicapped by a knockout, a nutritional deficiency or a similar perturbation). MOMA solution then gives an expectable "easiest" adjustment of the organism towards a somewhat working state.

Reference fluxes that do not exist in the model are ignored (internally, the objective is constructed via squared_sum_error_value).

source
COBREXA.metabolic_adjustment_minimization_constraints — Method
metabolic_adjustment_minimization_constraints(
+

Find a solution of the "minimization of metabolic adjustment" (MOMA) analysis for the model, which is the "closest" feasible solution to the solution given in the second argument, which is either reference_fluxes or reference_model (see documentation of metabolic_adjustment_minimization_constraints), in the sense of squared-sum distance. The minimized squared distance (the objective) is present in the result tree as minimal_adjustment_objective.

If the second argument is a reference model, it is solved using a parsimonious_flux_balance_analysis with the optimizer and settings parameters for the 2 steps set by keyword arguments prefixed by reference_.

This is often used for models with smaller feasible region than the reference models (typically handicapped by a knockout, a nutritional deficiency or a similar perturbation). MOMA solution then gives an expectable "easiest" adjustment of the organism towards a somewhat working state.

Reference fluxes that do not exist in the model are ignored (internally, the objective is constructed via squared_sum_error_value).

source
COBREXA.metabolic_adjustment_minimization_constraints — Method
metabolic_adjustment_minimization_constraints(
     model::AbstractFBCModels.AbstractFBCModel,
     reference_model::AbstractFBCModels.AbstractFBCModel;
     kwargs...
 ) -> Any
-

A slightly easier-to-use version of metabolic_adjustment_minimization_constraints that computes the reference flux as the parsimonious optimal solution of the reference_model. The reference flux is calculated using reference_optimizer and reference_modifications, which default to the optimizer and settings.

Other arguments are forwarded to the internal call of parsimonious_optimized_values.

Returns nothing if no feasible solution is found.

source
COBREXA.metabolic_adjustment_minimization_constraints — Method
metabolic_adjustment_minimization_constraints(
+

A slightly easier-to-use version of metabolic_adjustment_minimization_constraints that computes the reference flux as the parsimonious optimal solution of the reference_model. The reference flux is calculated using reference_optimizer and reference_modifications, which default to the optimizer and settings.

Other arguments are forwarded to the internal call of parsimonious_optimized_values.

Returns nothing if no feasible solution is found.

source
COBREXA.metabolic_adjustment_minimization_constraints — Method
metabolic_adjustment_minimization_constraints(
     model::AbstractFBCModels.AbstractFBCModel,
     reference_fluxes::ConstraintTrees.Tree;
     _...
 ) -> Any
-

Keyword arguments are discarded for compatibility with the other overload.

source

Constraint systems for metabolite concentrations

COBREXA.log_concentration_constraints — Method
log_concentration_constraints(
+

Keyword arguments are discarded for compatibility with the other overload.

source

Constraint systems for metabolite concentrations

COBREXA.log_concentration_constraints — Method
log_concentration_constraints(
     model::AbstractFBCModels.AbstractFBCModel;
     reactions,
     metabolites,
     metabolite_concentration_bound,
     reaction_concentration_bound
 ) -> ConstraintTrees.Tree{ConstraintTrees.Constraint}
-

Build log-concentration-stoichiometry constraints for the model, as used e.g. by max_min_driving_force_analysis.

The output constraint tree contains a log-concentration variable for each metabolite from model, in subtree log_concentrations. The total reactant log-concentrations for each reaction are constrained in subtree log_concentration_stoichiometry. By default, all reactions and metabolites in model are included.

A concentration bound is given by parameter function concentration_bound for each metabolite ID (the string ID is the single argument of the function); by default the function returns nothing and no bounds are installed. The same is used for reactions with reaction_concentration_bound.

source

Enzyme-mass-constrained models

COBREXA.Isozyme — Type
mutable struct Isozyme

A simple struct storing information about the isozyme composition, including subunit stoichiometry and turnover numbers. Use with enzyme_constrained_flux_balance_analysis.

Fields

  • gene_product_stoichiometry::Dict{String, Float64}: Mapping of gene product identifiers ("genes" in FBC model nomenclature) to their relative amount required to construct one unit of the isozyme.

  • kcat_forward::Union{Nothing, Float64}: Turnover number for this isozyme catalyzing the forward direction of the reaction.

  • kcat_reverse::Union{Nothing, Float64}: Turnover number for this isozyme catalyzing the reverse direction of the reaction.

source
COBREXA.enzyme_constrained_flux_balance_analysis — Method
enzyme_constrained_flux_balance_analysis(
+

Build log-concentration-stoichiometry constraints for the model, as used e.g. by max_min_driving_force_analysis.

The output constraint tree contains a log-concentration variable for each metabolite from model, in subtree log_concentrations. The total reactant log-concentrations for each reaction are constrained in subtree log_concentration_stoichiometry. By default, all reactions and metabolites in model are included.

A concentration bound is given by parameter function concentration_bound for each metabolite ID (the string ID is the single argument of the function); by default the function returns nothing and no bounds are installed. The same is used for reactions with reaction_concentration_bound.

source

Enzyme-mass-constrained models

COBREXA.Isozyme — Type
mutable struct Isozyme

A simple struct storing information about the isozyme composition, including subunit stoichiometry and turnover numbers. Use with enzyme_constrained_flux_balance_analysis.

Fields

  • gene_product_stoichiometry::Dict{String, Float64}: Mapping of gene product identifiers ("genes" in FBC model nomenclature) to their relative amount required to construct one unit of the isozyme.

  • kcat_forward::Union{Nothing, Float64}: Turnover number for this isozyme catalyzing the forward direction of the reaction.

  • kcat_reverse::Union{Nothing, Float64}: Turnover number for this isozyme catalyzing the reverse direction of the reaction.

source
COBREXA.enzyme_constrained_flux_balance_analysis — Method
enzyme_constrained_flux_balance_analysis(
     model::AbstractFBCModels.AbstractFBCModel;
     kwargs...
 )
-

Perform the enzyme-constrained flux balance analysis on the model and return the solved constraint system.

Arguments are forwarded to enzyme_constrained_flux_balance_constraints; solver configuration arguments are forwarded to optimized_values.

source
COBREXA.enzyme_constrained_flux_balance_constraints — Method
enzyme_constrained_flux_balance_constraints(
+

Perform the enzyme-constrained flux balance analysis on the model and return the solved constraint system.

Arguments are forwarded to enzyme_constrained_flux_balance_constraints; solver configuration arguments are forwarded to optimized_values.

source
COBREXA.enzyme_constrained_flux_balance_constraints — Method
enzyme_constrained_flux_balance_constraints(
     model::AbstractFBCModels.AbstractFBCModel;
     reaction_isozymes,
     gene_product_molar_masses,
@@ -95,11 +95,11 @@
     interface,
     interface_name
 )
-

Construct a enzyme-constrained flux-balance constraint system, following the method in GECKO algorithm (refer to: Sánchez, Benjamín J., et al. "Improving the phenotype predictions of a yeast genome‐scale metabolic model by incorporating enzymatic constraints." Molecular systems biology 13.8 (2017): 935).

The enzyme mass constraints depend primarily on the available isozymes, given in parameter reaction_isozymes, which is a mapping of reaction identifiers to descriptions of Isozymes that may catalyze the particular reactions. The isozymes are built from gene products, the mass of which is specified by gene_product_molar_masses. In total, the amount of gene product building material is limited by capacity.

capacity may be a single number, which sets the mass limit for "all described enzymes". Alternatively, capacity may be a vector of identifier-genes-limit triples that together form a constraint (identified by the given identifier) that limits the total sum of the listed genes to the given limit.

interface and interface_name are forwarded to flux_balance_constraints.

source
COBREXA.simplified_enzyme_constrained_flux_balance_analysis — Method
simplified_enzyme_constrained_flux_balance_analysis(
+

Construct a enzyme-constrained flux-balance constraint system, following the method in GECKO algorithm (refer to: Sánchez, Benjamín J., et al. "Improving the phenotype predictions of a yeast genome‐scale metabolic model by incorporating enzymatic constraints." Molecular systems biology 13.8 (2017): 935).

The enzyme mass constraints depend primarily on the available isozymes, given in parameter reaction_isozymes, which is a mapping of reaction identifiers to descriptions of Isozymes that may catalyze the particular reactions. The isozymes are built from gene products, the mass of which is specified by gene_product_molar_masses. In total, the amount of gene product building material is limited by capacity.

capacity may be a single number, which sets the mass limit for "all described enzymes". Alternatively, capacity may be a vector of identifier-genes-limit triples that together form a constraint (identified by the given identifier) that limits the total sum of the listed genes to the given limit.

interface and interface_name are forwarded to flux_balance_constraints.

source
COBREXA.simplified_enzyme_constrained_flux_balance_analysis — Method
simplified_enzyme_constrained_flux_balance_analysis(
     model::AbstractFBCModels.AbstractFBCModel;
     kwargs...
 )
-

Perform the enzyme-constrained flux balance analysis on the model and return the solved constraint system.

Arguments are forwarded to simplified_enzyme_constrained_flux_balance_constraints; solver configuration arguments are forwarded to optimized_values.

source
COBREXA.simplified_enzyme_constrained_flux_balance_constraints — Method
simplified_enzyme_constrained_flux_balance_constraints(
+

Perform the enzyme-constrained flux balance analysis on the model and return the solved constraint system.

Arguments are forwarded to simplified_enzyme_constrained_flux_balance_constraints; solver configuration arguments are forwarded to optimized_values.

source
COBREXA.simplified_enzyme_constrained_flux_balance_constraints — Method
simplified_enzyme_constrained_flux_balance_constraints(
     model;
     reaction_isozymes,
     gene_product_molar_masses,
@@ -107,8 +107,8 @@
     interface,
     interface_name
 )
-

Like enzyme_constrained_flux_balance_constraints, but automatically selects a single "fastest" isozyme for each reaction direction. In turn, the system requires much less variables in the constraint system description, and usually solves more efficiently, for the price of possibly finding suboptimal solutions. The method follows the SMOMENT algorithm described in Bekiaris, P.S., Klamt, S. Automatic construction of metabolic models with enzyme constraints. BMC Bioinformatics 21, 19 (2020). https://doi.org/10.1186/s12859-019-3329-9.

Arguments are as with enzyme_constrained_flux_balance_constraints, with a major difference in capacity handling: the identifier lists (2nd elements of the triples given in the list) are not identifiers of gene products, but identifiers of reactions.

source

Community models

COBREXA.community_flux_balance_analysis — Method
community_flux_balance_analysis(args...; kwargs...)
-

Run the Community Flux Balance Analysis on several models. All arguments are forwarded to community_flux_balance_constraints which constructs the model; this function returns the solved model.

source
COBREXA.community_flux_balance_constraints — Method
community_flux_balance_constraints(
+

Like enzyme_constrained_flux_balance_constraints, but automatically selects a single "fastest" isozyme for each reaction direction. In turn, the system requires much less variables in the constraint system description, and usually solves more efficiently, for the price of possibly finding suboptimal solutions. The method follows the SMOMENT algorithm described in Bekiaris, P.S., Klamt, S. Automatic construction of metabolic models with enzyme constraints. BMC Bioinformatics 21, 19 (2020). https://doi.org/10.1186/s12859-019-3329-9.

Arguments are as with enzyme_constrained_flux_balance_constraints, with a major difference in capacity handling: the identifier lists (2nd elements of the triples given in the list) are not identifiers of gene products, but identifiers of reactions.

source

Community models

COBREXA.community_flux_balance_analysis — Method
community_flux_balance_analysis(args...; kwargs...)
+

Run the Community Flux Balance Analysis on several models. All arguments are forwarded to community_flux_balance_constraints which constructs the model; this function returns the solved model.

source
COBREXA.community_flux_balance_constraints — Method
community_flux_balance_constraints(
     model_abundances,
     community_exchange_bounds;
     interface,
@@ -116,7 +116,7 @@
     interface_biomass,
     default_community_exchange_bound
 ) -> Any
-

Construct an instance of a linear community Flux Balance Analysis (cFBA) model. The relative abundances of the organisms are known in advance; this function predicts the maximum achievable community growth rate.

model_abundances is a dictionary-like object that maps model identifiers to tuples of models (usually subtypes of AbstractFBCModel) and their abundances (such as: "bug1" => (bug1, 0.5), ...). community_exchange_bounds is a dictionary-like object that can be additionally used to restrict selected community exchange reactions (keys should be reaction IDs, the values are converted to ConstraintTrees-like bounds). Bounds otherwise default to parameter default_community_exchange_bound, which itself defaults to nothing (i.e., unbounded).

If required, constraint trees may be supplied instead of AbstracFBCModels in model_abundances. These must provide an interface compatible with interface_exchanges and interface_biomass.

interface is forwarded to flux_balance_constraints. interface_exchanges and interface_biomass are used to pick up the correct interface part to contribute to the community exchanges and community biomass.

source

Production envelopes

COBREXA.objective_production_envelope — Method
objective_production_envelope(
+

Construct an instance of a linear community Flux Balance Analysis (cFBA) model. The relative abundances of the organisms are known in advance; this function predicts the maximum achievable community growth rate.

model_abundances is a dictionary-like object that maps model identifiers to tuples of models (usually subtypes of AbstractFBCModel) and their abundances (such as: "bug1" => (bug1, 0.5), ...). community_exchange_bounds is a dictionary-like object that can be additionally used to restrict selected community exchange reactions (keys should be reaction IDs, the values are converted to ConstraintTrees-like bounds). Bounds otherwise default to parameter default_community_exchange_bound, which itself defaults to nothing (i.e., unbounded).

If required, constraint trees may be supplied instead of AbstracFBCModels in model_abundances. These must provide an interface compatible with interface_exchanges and interface_biomass.

interface is forwarded to flux_balance_constraints. interface_exchanges and interface_biomass are used to pick up the correct interface part to contribute to the community exchanges and community biomass.

source

Production envelopes

COBREXA.objective_production_envelope — Method
objective_production_envelope(
     model::AbstractFBCModels.AbstractFBCModel,
     reactions::Vector{String};
     breaks,
@@ -124,8 +124,8 @@
     settings,
     workers
 )
-

Find the objective production envelope of the model in the dimensions given by reactions.

This runs a variability analysis of the fluxes given by flux_balance_constraints to determine an applicable range for the dimensions, then splits the dimensions to equal-sized breaks (of count breaks for each dimension, i.e. total breaks ^ length(reactions) individual "multidimensional breaks") thus forming a grid, and returns an array of fluxes through the model objective with the individual reactions fixed to flux as given by the grid.

optimizer and settings are used to construct the optimization models.

The computation is distributed to the specified workers, defaulting to all available workers.

source

Gap-filling

COBREXA.gap_filling_analysis — Method
gap_filling_analysis(args...; kwargs...)
-

Run the gap-filling analysis on a constraint system specified by gap_filling_constraints.

source
COBREXA.gap_filling_constraints — Method
gap_filling_constraints(
+

Find the objective production envelope of the model in the dimensions given by reactions.

This runs a variability analysis of the fluxes given by flux_balance_constraints to determine an applicable range for the dimensions, then splits the dimensions to equal-sized breaks (of count breaks for each dimension, i.e. total breaks ^ length(reactions) individual "multidimensional breaks") thus forming a grid, and returns an array of fluxes through the model objective with the individual reactions fixed to flux as given by the grid.

optimizer and settings are used to construct the optimization models.

The computation is distributed to the specified workers, defaulting to all available workers.

source

Gap-filling

COBREXA.gap_filling_analysis — Method
gap_filling_analysis(args...; kwargs...)
+

Run the gap-filling analysis on a constraint system specified by gap_filling_constraints.

source
COBREXA.gap_filling_constraints — Method
gap_filling_constraints(
     model::AbstractFBCModels.AbstractFBCModel,
     universal_model::AbstractFBCModels.AbstractFBCModel,
     objective_target::Float64;
@@ -134,7 +134,7 @@
     known_fills,
     kwargs...
 ) -> ConstraintTrees.Tree{ConstraintTrees.Constraint}
-

Make a gap-filling system from a FBC model with gaps and an universal FBC model that contains reactions to be added into the original model.

The output system will be constrainted to reach at least objective_target flux through the objective function. Generally, this should be set to an arbitrary small value such as 0.05.

universal_reaction_cost should assign a numeric cost of inclusion of each of the reactions in the universal_model; by default all are assigned equal weight of 1. max_cost puts an optional maximum limit on the cost, which may help the solver to avoid exploring unnecessarily complex solutions. known_fills may contain previous solutions of the same system; these will be made infeasible in the output constraint system in order to allow discovery of other ones.

Additional arguments are forwarded to flux_balance_constraints that converts model to constraints.

source
COBREXA.gap_filling_constraints — Method
gap_filling_constraints(
+

Make a gap-filling system from a FBC model with gaps and an universal FBC model that contains reactions to be added into the original model.

The output system will be constrainted to reach at least objective_target flux through the objective function. Generally, this should be set to an arbitrary small value such as 0.05.

universal_reaction_cost should assign a numeric cost of inclusion of each of the reactions in the universal_model; by default all are assigned equal weight of 1. max_cost puts an optional maximum limit on the cost, which may help the solver to avoid exploring unnecessarily complex solutions. known_fills may contain previous solutions of the same system; these will be made infeasible in the output constraint system in order to allow discovery of other ones.

Additional arguments are forwarded to flux_balance_constraints that converts model to constraints.

source
COBREXA.gap_filling_constraints — Method
gap_filling_constraints(
 ;
     system,
     stoichiometry,
@@ -144,41 +144,41 @@
     max_cost,
     known_fills
 )
-

Make a gap-fillign system from a non-solving system with a separated stoichiometry, filling in possible fluxes from universal_fluxes that are balanced with universal_stoichiometry

flux_cost can be used to assign a weight to each given universal flux; the total cost is bounded by max_cost.

known_fills may contain previous solutions to be avoided; these are processed by gap_filling_known_fill_constraint and attached to the system.

stoichiometry needs to be extended to construct the final constraints, thus it should not be present in the original system.

source
COBREXA.gap_filling_known_fill_constraint — Method
gap_filling_known_fill_constraint(
+

Make a gap-fillign system from a non-solving system with a separated stoichiometry, filling in possible fluxes from universal_fluxes that are balanced with universal_stoichiometry

flux_cost can be used to assign a weight to each given universal flux; the total cost is bounded by max_cost.

known_fills may contain previous solutions to be avoided; these are processed by gap_filling_known_fill_constraint and attached to the system.

stoichiometry needs to be extended to construct the final constraints, thus it should not be present in the original system.

source
COBREXA.gap_filling_known_fill_constraint — Method
gap_filling_known_fill_constraint(
     fill_flags::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     known_flags::ConstraintTrees.Tree{Float64}
 ) -> ConstraintTrees.Constraint
-

Produce a constraint that can be added to the system made by gap_filling_constraints to avoid repeating of a solution that includes reactions already generated by another solution, as represented by the solved fill_flags.

Parameter fill_flags are the gapfilling flags of the given constraint system, parameter known_flags is expected to contain the solved fill_flags for the solution that is to be avoided.

source

Knockout models

COBREXA.gene_knockout_constraints — Method
gene_knockout_constraints(
+

Produce a constraint that can be added to the system made by gap_filling_constraints to avoid repeating of a solution that includes reactions already generated by another solution, as represented by the solved fill_flags.

Parameter fill_flags are the gapfilling flags of the given constraint system, parameter known_flags is expected to contain the solved fill_flags for the solution that is to be avoided.

source

Knockout models

COBREXA.gene_knockout_constraints — Method
gene_knockout_constraints(
     fluxes::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     knockout_genes,
     model::AbstractFBCModels.AbstractFBCModel
 ) -> ConstraintTrees.Tree{ConstraintTrees.Constraint}
-

Make a ConstraintTree that simulates a gene knockout of knockout_genes in the model and disables corresponding fluxes accordingly.

Keys of the fluxes must correspond to the reaction identifiers in the model.

knockout_genes may be any collection that support element tests using in. Since the test is done many times, a Set is a preferred contained for longer lists of genes.

All constraints are equality constraints returned in a single flat ConstraintTree.

source
COBREXA.gene_knockout_constraints — Method
gene_knockout_constraints(
+

Make a ConstraintTree that simulates a gene knockout of knockout_genes in the model and disables corresponding fluxes accordingly.

Keys of the fluxes must correspond to the reaction identifiers in the model.

knockout_genes may be any collection that support element tests using in. Since the test is done many times, a Set is a preferred contained for longer lists of genes.

All constraints are equality constraints returned in a single flat ConstraintTree.

source
COBREXA.gene_knockout_constraints — Method
gene_knockout_constraints(
     fluxes::ConstraintTrees.Tree{ConstraintTrees.Constraint},
     knockout_gene::String,
     model::AbstractFBCModels.AbstractFBCModel
 ) -> ConstraintTrees.Tree{ConstraintTrees.Constraint}
-

Convenience overload of gene_knockout_constraints for knocking out a single gene (without the necessity to store the gene identifier in a singleton container).

source
COBREXA.gene_knockouts — Function
gene_knockouts(model::AbstractFBCModels.AbstractFBCModel)
+

Convenience overload of gene_knockout_constraints for knocking out a single gene (without the necessity to store the gene identifier in a singleton container).

source
COBREXA.gene_knockouts — Function
gene_knockouts(model::AbstractFBCModels.AbstractFBCModel)
 gene_knockouts(
     model::AbstractFBCModels.AbstractFBCModel,
     gene_combinations::Vector{<:Union{String, Tuple{Vararg{String, N}} where N}};
     kwargs...
 )
-

Compute the objective value of the model for all knockouts specified by gene_combinations, which is a vector of gene IDs or tuples of gene IDs that are knocked out in groups.

Returns a vector in the same order as gene_combinations.

Extra arguments (mainly, the optimizer) are forwarded to screen_optimization_model.

source

Loopless flux balance analysis

COBREXA.loopless_flux_balance_analysis — Method
loopless_flux_balance_analysis(
+

Compute the objective value of the model for all knockouts specified by gene_combinations, which is a vector of gene IDs or tuples of gene IDs that are knocked out in groups.

Returns a vector in the same order as gene_combinations.

Extra arguments (mainly, the optimizer) are forwarded to screen_optimization_model.

source

Loopless flux balance analysis

COBREXA.loopless_flux_balance_analysis — Method
loopless_flux_balance_analysis(
     model::AbstractFBCModels.AbstractFBCModel;
     kwargs...
 )
-

Perform the loopless flux balance analysis on the model, returning the solved constraint system.

Arguments are forwarded to loopless_flux_balance_constraints (see the documentation for the description of the constraint system); solver configuration arguments are forwarded to optimized_values.

source
COBREXA.loopless_flux_balance_constraints — Method
loopless_flux_balance_constraints(
+

Perform the loopless flux balance analysis on the model, returning the solved constraint system.

Arguments are forwarded to loopless_flux_balance_constraints (see the documentation for the description of the constraint system); solver configuration arguments are forwarded to optimized_values.

source
COBREXA.loopless_flux_balance_constraints — Method
loopless_flux_balance_constraints(
     model::AbstractFBCModels.AbstractFBCModel;
     flux_infinity_bound,
     driving_force_nonzero_bound,
     driving_force_infinity_bound
 ) -> ConstraintTrees.Tree{ConstraintTrees.Constraint}
-

Construct a flux-balance constraint system from model with added quasi-thermodynamic constraints that ensure that thermodynamically infeasible internal cycles can not occur. The method is closer described by: Schellenberger, Lewis, and, Palsson. "Elimination of thermodynamically infeasible loops in steady-state metabolic models.", Biophysical journal, 2011`.

The loopless condition comes with a performance overhead: the computation needs to find the null space of the stoichiometry matrix (essentially inverting it); and the subsequently created optimization problem contains binary variables for each internal reaction, thus requiring a MILP solver and a potentially exponential solving time.

Internally, the system is constructed by combining flux_balance_constraints and loopless_constraints.

The arguments driving_force_max_bound and driving_force_nonzero_bound set the bounds (possibly negated ones) on the virtual "driving forces" (G_i in the paper).

source

Max-Min Driving Force analysis

COBREXA.max_min_driving_force_analysis — Method
max_min_driving_force_analysis(
+

Construct a flux-balance constraint system from model with added quasi-thermodynamic constraints that ensure that thermodynamically infeasible internal cycles can not occur. The method is closer described by: Schellenberger, Lewis, and, Palsson. "Elimination of thermodynamically infeasible loops in steady-state metabolic models.", Biophysical journal, 2011`.

The loopless condition comes with a performance overhead: the computation needs to find the null space of the stoichiometry matrix (essentially inverting it); and the subsequently created optimization problem contains binary variables for each internal reaction, thus requiring a MILP solver and a potentially exponential solving time.

Internally, the system is constructed by combining flux_balance_constraints and loopless_constraints.

The arguments driving_force_max_bound and driving_force_nonzero_bound set the bounds (possibly negated ones) on the virtual "driving forces" (G_i in the paper).

source

Max-Min Driving Force analysis

COBREXA.max_min_driving_force_analysis — Method
max_min_driving_force_analysis(
     model::AbstractFBCModels.AbstractFBCModel;
     kwargs...
 )
-

Perform the max-min driving force analysis on the model, returning the solved constraint system.

Arguments are forwarded to max_min_driving_force_constraints (see the documentation for the description of the constraint system); solver configuration arguments are forwarded to optimized_values.

source
COBREXA.max_min_driving_force_constraints — Method
max_min_driving_force_constraints(
+

Perform the max-min driving force analysis on the model, returning the solved constraint system.

Arguments are forwarded to max_min_driving_force_constraints (see the documentation for the description of the constraint system); solver configuration arguments are forwarded to optimized_values.

source
COBREXA.max_min_driving_force_constraints — Method
max_min_driving_force_constraints(
     model::AbstractFBCModels.AbstractFBCModel;
     reaction_standard_gibbs_free_energies,
     reference_flux,
@@ -193,7 +193,7 @@
     R,
     reference_flux_atol
 )
-

Create max-min driving force constraint system from model, using the supplied reaction standard Gibbs free energies in reaction_standard_gibbs_free_energies.

The method is described by: Noor, et al., "Pathway thermodynamics highlights kinetic obstacles in central metabolism.", PLoS computational biology, 2014.

reference_flux sets the directions of each reaction in model. The scale of the values is not important, only the direction is examined (w.r.t. reference_flux_atol tolerance). Ideally, the supplied reference_flux should be completely free of internal cycles, which enables the thermodynamic consistency. To get the cycle-free flux, you can use loopless_flux_balance_analysis (computationally demanding, but gives thermodynamically consistent solutions), parsimonious_flux_balance_analysis or linear_parsimonious_flux_balance_analysis (which is computationally simple, but the consistency is not guaranteed).

Internally, log_concentration_constraints is used to lay out the base structure of the problem.

Following arguments are set optionally:

  • water_metabolites, proton_metabolites and ignored_metabolites allow to completely ignore constraints on a part of the metabolite set, which is explicitly recommended especially for water and protons (since the analyses generally assume aqueous environment of constant pH)
  • constant_concentrations can be used to fix the concentrations of the metabolites
  • concentration_lower_bound and concentration_upper_bound set the default concentration bounds for all other metabolites
  • concentration ratios is a dictionary that assigns a tuple of metabolite-metabolite-concentration ratio constraint names; e.g. ATP/ADP ratio can be fixed to five-times-more-ATP by setting concentration_ratios = Dict("adenosin_ratio" => ("atp", "adp", 5.0))
  • T and R default to the usual required thermodynamic constraints in the expected units (the defaults assume the "usual" units, valuing 298.15 K and ~0.008314 kJ/K/mol, respectively). These multiply the log-concentrations to obtain the actual Gibbs energies, and thus driving forces.
source

Sampling

COBREXA.flux_sample — Method
flux_sample(
+

Create max-min driving force constraint system from model, using the supplied reaction standard Gibbs free energies in reaction_standard_gibbs_free_energies.

The method is described by: Noor, et al., "Pathway thermodynamics highlights kinetic obstacles in central metabolism.", PLoS computational biology, 2014.

reference_flux sets the directions of each reaction in model. The scale of the values is not important, only the direction is examined (w.r.t. reference_flux_atol tolerance). Ideally, the supplied reference_flux should be completely free of internal cycles, which enables the thermodynamic consistency. To get the cycle-free flux, you can use loopless_flux_balance_analysis (computationally demanding, but gives thermodynamically consistent solutions), parsimonious_flux_balance_analysis or linear_parsimonious_flux_balance_analysis (which is computationally simple, but the consistency is not guaranteed).

Internally, log_concentration_constraints is used to lay out the base structure of the problem.

Following arguments are set optionally:

  • water_metabolites, proton_metabolites and ignored_metabolites allow to completely ignore constraints on a part of the metabolite set, which is explicitly recommended especially for water and protons (since the analyses generally assume aqueous environment of constant pH)
  • constant_concentrations can be used to fix the concentrations of the metabolites
  • concentration_lower_bound and concentration_upper_bound set the default concentration bounds for all other metabolites
  • concentration ratios is a dictionary that assigns a tuple of metabolite-metabolite-concentration ratio constraint names; e.g. ATP/ADP ratio can be fixed to five-times-more-ATP by setting concentration_ratios = Dict("adenosin_ratio" => ("atp", "adp", 5.0))
  • T and R default to the usual required thermodynamic constraints in the expected units (the defaults assume the "usual" units, valuing 298.15 K and ~0.008314 kJ/K/mol, respectively). These multiply the log-concentrations to obtain the actual Gibbs energies, and thus driving forces.
source

Sampling

COBREXA.flux_sample — Method
flux_sample(
     model::AbstractFBCModels.AbstractFBCModel;
     seed,
     objective_bound,
@@ -205,4 +205,4 @@
     workers,
     kwargs...
 )
-

Run a sampling algorithm on the near-optimal feasible space of the model (as specified by objective_bound). By default, the sampling algorithm is ACHR (the method parameter is defaulted to sample_chain_achr). The sampling algorithm is ran for n_chains and the iterations for collecting the sampled values are specified by collect_iterations.

optimizer is used to generate the warmup (with settings) for the sampler using the usual unidimensional maximum-variability fluxes (as from flux_variability_analysis). All computations are parallelized across workers.

Extra arguments are forwarded to sample_constraints. Eventually the arguments will reach the method function, so extra arguments can be also used to customize the methods (e.g., by setting the epsilon for the ACHR sampler).

source
+

Run a sampling algorithm on the near-optimal feasible space of the model (as specified by objective_bound). By default, the sampling algorithm is ACHR (the method parameter is defaulted to sample_chain_achr). The sampling algorithm is ran for n_chains and the iterations for collecting the sampled values are specified by collect_iterations.

optimizer is used to generate the warmup (with settings) for the sampler using the usual unidimensional maximum-variability fluxes (as from flux_variability_analysis). All computations are parallelized across workers.

Extra arguments are forwarded to sample_constraints. Eventually the arguments will reach the method function, so extra arguments can be also used to customize the methods (e.g., by setting the epsilon for the ACHR sampler).

source diff --git a/dev/reference/index.html b/dev/reference/index.html index 5e529186..519fd168 100644 --- a/dev/reference/index.html +++ b/dev/reference/index.html @@ -1,2 +1,2 @@ -Contents · COBREXA.jl
GitHub

API reference

+Contents · COBREXA.jl
GitHub

API reference

diff --git a/dev/reference/misc/index.html b/dev/reference/misc/index.html index 7bf044a6..c88e28b4 100644 --- a/dev/reference/misc/index.html +++ b/dev/reference/misc/index.html @@ -1,29 +1,29 @@ Miscellaneous functions · COBREXA.jl
GitHub

Miscellaneous functions

COBREXA.absolute_tolerance_bound — Method
absolute_tolerance_bound(tolerance) -> COBREXA.var"#404#405"
-

Make a function that returns absolute tolerance bounds, i.e. value - tolerance and value + tolerance in a tuple, in the increasing order.

source
COBREXA.relative_tolerance_bound — Method
relative_tolerance_bound(tolerance) -> COBREXA.var"#406#407"
-

Make a function that returns relative tolerance bounds, i.e. value / tolerance and value * tolerance in a tuple, in the increasing order.

source
COBREXA.remove_bounds — Method
remove_bounds(
+

Make a function that returns absolute tolerance bounds, i.e. value - tolerance and value + tolerance in a tuple, in the increasing order.

source
COBREXA.relative_tolerance_bound — Method
relative_tolerance_bound(tolerance) -> COBREXA.var"#406#407"
+

Make a function that returns relative tolerance bounds, i.e. value / tolerance and value * tolerance in a tuple, in the increasing order.

source
COBREXA.remove_bounds — Method
remove_bounds(
     cs::ConstraintTrees.Tree{ConstraintTrees.Constraint}
 ) -> Any
-

Make a copy of a constraint tree with all bounds removed. This is helpful when creating large trees only for for value representation purposes, which should not directly constraint anything (and thus should not put additional stress on the constraint solver).

source
COBREXA.maybemap — Function
maybemap(f, ::Nothing)
+

Make a copy of a constraint tree with all bounds removed. This is helpful when creating large trees only for for value representation purposes, which should not directly constraint anything (and thus should not put additional stress on the constraint solver).

source
COBREXA.maybemap — Function
maybemap(f, ::Nothing)
 maybemap(f, ::Nothing, def) -> Any
-

Helper for applying functions to stuff that might be nothing.

source
COBREXA.set_optimizer — Method
set_optimizer(optimizer) -> COBREXA.var"#412#413"
-

Change the JuMP optimizer used to run the optimization.

source
COBREXA.set_optimizer — Method
set_optimizer(optimizer) -> COBREXA.var"#412#413"
+

Change the JuMP optimizer used to run the optimization.

source
COBREXA.set_optimizer_attribute — Method
set_optimizer_attribute(
     attribute_key,
     value
 ) -> COBREXA.var"#414#415"
-

Change a named JuMP optimizer attribute. The attribute names are optimizer-specific, refer to the JuMP documentation and the documentation of the specific optimizer for usable keys and values.

source
COBREXA.set_time_limit — Method
set_time_limit(limit::Real) -> COBREXA.var"#416#417"
-

Set a time limit in seconds for the optimizer computation (shortcut for set_time_limit_sec from JuMP).

source
COBREXA.silence — Method
silence

Disable all output from the JuMP optimizer (shortcut for set_silent from JuMP).

source
COBREXA.unsilence — Method
unsilence

Enable output from the JuMP optimizer (shortcut for unset_silent from JuMP).

source
COBREXA.tree_deflate — Method
tree_deflate(f, x::ConstraintTrees.Tree{T}) -> Vector
+

Change a named JuMP optimizer attribute. The attribute names are optimizer-specific, refer to the JuMP documentation and the documentation of the specific optimizer for usable keys and values.

source
COBREXA.set_time_limit — Method
set_time_limit(limit::Real) -> COBREXA.var"#416#417"
+

Set a time limit in seconds for the optimizer computation (shortcut for set_time_limit_sec from JuMP).

source
COBREXA.silence — Method
silence

Disable all output from the JuMP optimizer (shortcut for set_silent from JuMP).

source
COBREXA.unsilence — Method
unsilence

Enable output from the JuMP optimizer (shortcut for unset_silent from JuMP).

source
COBREXA.tree_deflate — Method
tree_deflate(f, x::ConstraintTrees.Tree{T}) -> Vector
 tree_deflate(
     f,
     x::ConstraintTrees.Tree{T},
     ::Type{U}
 ) -> Vector
-

Extract all elements of a ConstraintTrees.Tree in order and return them in a Vector transformed by f. If the order is not modified, one can re-insert a vector of modified elements into the same-shaped tree using tree_reinflate.

source
COBREXA.tree_reinflate — Method
tree_reinflate(
+

Extract all elements of a ConstraintTrees.Tree in order and return them in a Vector transformed by f. If the order is not modified, one can re-insert a vector of modified elements into the same-shaped tree using tree_reinflate.

source
COBREXA.tree_reinflate — Method
tree_reinflate(
     x::ConstraintTrees.Tree,
     elems::Array{T, 1}
 ) -> ConstraintTrees.Tree
-

Insert a Vector of elements into the "values" of a ConstraintTrees.Tree. The order of elements is given by tree_deflate.

source
+

Insert a Vector of elements into the "values" of a ConstraintTrees.Tree. The order of elements is given by tree_deflate.

source diff --git a/dev/structure/index.html b/dev/structure/index.html index 5456a249..97bc9748 100644 --- a/dev/structure/index.html +++ b/dev/structure/index.html @@ -1,2 +1,2 @@ -Core concepts and structure · COBREXA.jl
GitHub

Logical structure of COBREXA

COBREXA uses ConstraintTrees.jl for internal representation of all metabolic modeling problems. In short, constraint trees are "tidy" representations of the constraint-based modeling problems, which store information about the variables' participation in named constraints. They provide several main benefits:

  • User is freed from having to allocate variables – all variables are present only implicitly, are described by their "semantics" by participation in constraints, and are allocated automatically whenever the user connects the constraint trees.
  • There is no need for complicated index manipulation (as with linear-algebraic "matrixy" model representations) nor for various identifier mangling schemes – constraint trees provide named interface for everything, and identifiers can be organized into directories to prevent name clashes in various multi-compartment and community models.
  • Contrary to the fixed model representations (such as SBML or JSON models), ConstraintTrees do not possess a semantic of a "single flux-based model" and are thus infinitely extensible, allowing easy creation, manipulation and storage of even very complicated constraint systems.

With ConstraintTrees, the typical workflow in COBREXA is as follows:

  1. "Raw" data and base model data are loaded from semantically organized models (such as SBML, or lab measurements in CSV or other tabular format)
  2. COBREXA functions are used to convert these to a constraint tree that properly describes the problem at hand
    • possibly, multiple types and groups of raw data can be soaked into the constraint tree
  3. Analysis functionality of COBREXA is used to solve the system described by the constraint tree, and extract useful information from the solutions.

COBREXA mainly provides functionality to make this workflow easy to use for many various purposes:

Exploring and customizing the front-end analysis functions

To know which builder function is used to create or modify some kind of constraint tree in COBREXA, use the "link to source code" feature in the front-end function's individual documentation. The source code of front-end functions is written to be as easily re-usable as possible – one can simply copy-paste it into the program, and immediately start building specialized and customized front-end functions.

Technical description of the constraint tree functionality, together with examples of basic functionality and many useful utility functions is available in dedicated documentation of ConstraintTrees.jl.

+Core concepts and structure · COBREXA.jl
GitHub

Logical structure of COBREXA

COBREXA uses ConstraintTrees.jl for internal representation of all metabolic modeling problems. In short, constraint trees are "tidy" representations of the constraint-based modeling problems, which store information about the variables' participation in named constraints. They provide several main benefits:

  • User is freed from having to allocate variables – all variables are present only implicitly, are described by their "semantics" by participation in constraints, and are allocated automatically whenever the user connects the constraint trees.
  • There is no need for complicated index manipulation (as with linear-algebraic "matrixy" model representations) nor for various identifier mangling schemes – constraint trees provide named interface for everything, and identifiers can be organized into directories to prevent name clashes in various multi-compartment and community models.
  • Contrary to the fixed model representations (such as SBML or JSON models), ConstraintTrees do not possess a semantic of a "single flux-based model" and are thus infinitely extensible, allowing easy creation, manipulation and storage of even very complicated constraint systems.

With ConstraintTrees, the typical workflow in COBREXA is as follows:

  1. "Raw" data and base model data are loaded from semantically organized models (such as SBML, or lab measurements in CSV or other tabular format)
  2. COBREXA functions are used to convert these to a constraint tree that properly describes the problem at hand
    • possibly, multiple types and groups of raw data can be soaked into the constraint tree
  3. Analysis functionality of COBREXA is used to solve the system described by the constraint tree, and extract useful information from the solutions.

COBREXA mainly provides functionality to make this workflow easy to use for many various purposes:

Exploring and customizing the front-end analysis functions

To know which builder function is used to create or modify some kind of constraint tree in COBREXA, use the "link to source code" feature in the front-end function's individual documentation. The source code of front-end functions is written to be as easily re-usable as possible – one can simply copy-paste it into the program, and immediately start building specialized and customized front-end functions.

Technical description of the constraint tree functionality, together with examples of basic functionality and many useful utility functions is available in dedicated documentation of ConstraintTrees.jl.