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:
- "Raw" data and base model data are loaded from semantically organized models (such as SBML, or lab measurements in CSV or other tabular format)
- 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
- 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:
- Front-end functions help to run the 3 above steps easily without any intermediate steps. These include:
community_flux_balance_analysis
enzyme_constrained_flux_balance_analysis
flux_balance_analysis
flux_sample
gene_knockouts
linear_metabolic_adjustment_minimization_analysis
loopless_flux_balance_analysis
max_min_driving_force_analysis
metabolic_adjustment_minimization_analysis
objective_production_envelope
simplified_enzyme_constrained_flux_balance_analysis
- Front-end functions call various Front-end constraint tree builders which translate various kinds of raw data to the constraint trees, such as:
community_flux_balance_constraints
enzyme_constrained_flux_balance_constraints
flux_balance_constraints
flux_variability_analysis
gene_knockout_constraints
linear_metabolic_adjustment_minimization_constraints
log_concentration_constraints
loopless_flux_balance_constraints
max_min_driving_force_constraints
metabolic_adjustment_minimization_constraints
simplified_enzyme_constrained_flux_balance_constraints
- Additional constraint builders are provided to decorate the "raw" model representations with various additional semantics and limits:
- Some functions are provided to join the constraint trees via interfaces, simplifying e.g. the creation of community or multi-organ models,
flux_balance_constraints
can automatically generate interfaces suitable for community-style and multi-compartment-style metabolic modeling from the annotations in the FBC modelsinterface_constraints
joins the "modules" with prepared interfaces together
- Finally, the analysis functions simulate the model in the constraint tree mechanistically and extract analysis results:
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.