memote - the genome-scale metabolic model test suite¶

Our goal in promoting this tool is to achieve two major shifts in the metabolic model building community:

Models should be version-controlled such that changes can be tracked and if necessary reverted. Ideally, they should be available through a public repository such as GitHub that will allow other researchers to inspect, share, and contribute to the model.
Models should, for the benefit of the community and for research gain, live up to certain standards and minimal functionality.

The MEMOTE tool therefore performs four subfunctions:

Create a skeleton git repository for the model.
Run the current model through a test suite that represents the community standard.
Generate an informative report which details the results of the test suite in a visually appealing manner.
(Re-)compute test statistics for an existing version controlled history of a metabolic model.

And in order to make this process as easy as possible the generated repository can easily be integrated with continuous integration testing providers such as Travis CI, which means that anytime you push a model change to GitHub, the test suite will be run automatically and a report will be available for you to look at via GitHub pages for your repository.

Contact¶

For comments and questions get in touch via

our gitter chatroom
or open a GitHub issue.

Are you excited about this project? Consider contributing by adding novel tests, reporting or fixing bugs, and generally help us make this a better software for everyone.

Copyright¶

Copyright (c) 2017, Novo Nordisk Foundation Center for Biosustainability, Technical University of Denmark.
Free software: Apache Software License 2.0

Contents¶

Installation¶

Please Note: With its retirement on the horizon we decided to stop testing against Python 2.7, and like many others, want to focus entirely on Python 3. Hence, we cannot guarantee that memote will still function as expected

Before installing memote, make sure that you have correctly installed the latest version of git.

We highly recommend creating a Python virtualenv for your model testing purposes.

Stable release¶

To install memote, run this command in your terminal:

$ pip install memote

This is the preferred method to install memote, as it will always install the most recent stable release.

If you don’t have pip installed, this Python installation guide can guide you through the process.

From sources¶

The sources for memote can be downloaded from the Github repo.

You can either clone the public repository:

$ git clone https://github.com/opencobra/memote.git

Or download the tarball or zip archive:

$ curl  -OL https://github.com/opencobra/memote/archive/master.zip

Once you have a copy of the source files, you can install it with:

$ pip install .

Getting Started¶

After installation, memote can be employed in three different ways:

As a benchmarking tool for ad hoc model assessment. When using memote to benchmark a model, the tests are run once and a report is generated which describes the status-quo.
Similarly, multiple models can be tested and a report comparing the differences is generated.
As an automated testing suite, memote facilitates tracking incremental model changes in a version controlled repository and can enable continuous testing and reporting if desired.

Here, we explain step-by-step the basic commands to pursue either workflow. Users that have already followed these steps once may want to refer to the cheat-sheet flowchart to refresh their memory. For a more comprehensive insight into all optional parameters of the CLI please refer to the corresponding API reference.

If you only want to benchmark a model, using the memote webservice hosted at memote.io instead may be more convenient.

Benchmark¶

Snapshot¶

To benchmark the performance of a single model, run this command in your terminal:

$ memote report snapshot path/to/model.xml

This will generate the performance report as index.html.

The output filename can be changed by adding the following option. To illustrate here it is changed to report.html.

$ memote report snapshot --filename "report.html" path/to/model.xml

In both cases the generated report will look something like this:

While we recommend using the html report, frequent users may want to skip the generation of the html report, and only use the raw console output to get a quick overview.

$ memote run path/to/model.xml

In the console you’ll first see a list of all the tests and their pytest status reading either PASSED, FAILED, SKIPPED or ERRORED, followed by a short traceback showing why certain tests failed:

Here, it is possible to tweak the console output by passing additional arguments directly to pytest through the --pytest-args or simply -a option. This can be done by writing the pytest arguments as one continuous string.

For a more detailed traceback, for instance, try:

$ memote run -a "--tb long" path/to/model.xml

or to disable them completely use --tb no. For a full list of possible arguments please refer to the pytest documentation.

Diff¶

To compare the performance of two (or more) models, run this command in your terminal:

$ memote report diff path/to/model1.xml path/to/model2.xml [path/to/model3.xml ...]

This will generate a comparative report as index.html showing the snapshot performance of two models side-by-side:

Reconstruction¶

When starting a memote repository, users need to provide an SBMLv3-FBC2 formatted file. Automatic draft reconstruction tools such as Pathway Tools, Model SEED, The RAVEN Toolbox and others are able to output files in this format. Model repositories such as BiGG or BioModels further serve as a great resource for models in the correct format.

With this in mind, starting a local, version-controlled model repository is as simple as running the following command:

$ memote new

After this, the user will be prompted with a few questions regarding details of the project. If the project is to be kept strictly locally, the user does not need to supply GitHub (or GitLab - not implemented yet) credentials. However, these are a requirement if the project is to use the full benefits of distributed version control such as cloud-based development, remote collaboration and community feedback. It is important to note that furthermore a public repository is needed to set up automatic testing through continuous integration, one of the key features of memote.

CI tested, online and public workflow:¶

Once all the questions following memote new have been answered, a local git repository is created with the model file and configuration files. The tests are also run for the initial commit and a first history report is generated. The results and report are stored on the deployment branch (typically the gh-pages branch).

In order to make your local git repository available online and enable continuous integration via Travis CI, you can run:

$ memote online

This will use require your GitHub password to create the repository, connect it with Travis CI, and generate a GitHub token to be used for continuous integration of the history report.

Now, after each edit to the model in the repository, the user can generate an update to the continuous model report shown at the project’s gh-pages branch. That means each commit should be pushed to Travis individually.

The continuous report will look like this:

Since memote uses git for version control in memote repositories, regular git commands can be used. For instance:

git status lists all new or modified files.
git branch lists all local branches of the current repository.

To make a new version execute the following commands in sequence:

All files that have been changed since the last version are staged with git add .
Using git commit -m "<Short Description of Change Here>" a user creates a new version with a specific short description and a unique hash.
Finally git push applies that new version to the central repository in the cloud.

Please refer to the git documentation for more information on these and more advanced commands to interact with memote repositories.

Offline, local or private workflow:¶

Users that have decided to not to use GitHub (or GitLab Not implemented yet), or those that have decided to set up a private model repository, will need to manually execute the commands that would otherwise be carried out by the continuous integration server after each modification of the model:

In sequence, these are:

On the desired branch make a change to the model and commit that change.
```
$ git add .
$ git commit -m <Some Description>
```
After committing your changes initiate the test suite with
```
$ memote run
```
which will commit the results to your deployment branch.

Switch to the deployment branch and generate the history report.

$ git checkout gh-pages
$ memote report history
$ git add .
$ git commit -m <Some Description>

This will generate the same type of report that would be shown automatically with continuous integration. If you do not want to maintain an up-to-date history report in your repository, you can run memote report history from any branch at any time to generate it.

We highly recommend the public workflow not only to promote open, collaborative science but also to benefit from the full functionality of memote.

Flowchart¶

This cheat-sheet flowchart servers as a visual guide on how to get up and running with memote. It is essentially the pictographic form of the section Getting Started.

Understanding the reports¶

Memote will return one of four possible outputs. If your preferred workflow is to benchmark one or several genome-scale metabolic models (GSM) memote generates either a snapshot or a diff report, respectively. For the reconstruction workflow the primary output is a history report. This will only work if the provided input models are formatted correctly in the systems biology markup language (SBML). However, if a provided model is not a valid SBML file, memote composes a report enumerating errors and warnings from the SBML validator in order of appearance. To better understand the output of the error report we refer the reader to this section of the SBML documentation. In this section we will focus on how to understand the snapshot, diff and history reports.

Orientation¶

Main Body¶

The main body of the reports is divided into an independent section to the left and a specific section to the right.

The tests in the independent section are agnostic of the type of modeled organism, preferred modeling paradigms, the complexity of a genome-scale metabolic model (GSM) or the types of identifiers that are used to describe its components. The tests in this section focus on testing adherence to fundamental principles of constraint-based modeling: mass, charge and stoichiometric balance as well as the presence of annotations. The results in this section can be normalized, and thus enable a comparison of GSMs. The Score_ at the bottom of the page summarises the results to further simplify comparison.

The specific section on the right provides model specific statistics and covers aspects of a metabolic network that can not be normalized without introducing bias. For instance, dedicated quality control of the biomass equation only applies to GSMs which are used to investigate cell growth, i.e., those for which a biomass equation has been generated. Some tests in this section are also influenced by whether the tested GSM represents a prokaryote or a eukaryote. Therefore the results cannot be generalized and direct comparisons ought to take bias into account.

Test Results¶

Test results are arranged in rows with the title visible to the left and the result on the right. The result is displayed as white text in a coloured rectangle detailed in Color_.

By default only the minimum information is visible as indicated by an arrow pointing down right of the result. Clicking anywhere in the row will expand the result revealing a description of the concept behind the test, its implementation and a brief summary of the result. In addition, there is a text field which contains plaintext representations of Python objects which can be copy/pasted into Python code for follow up procedures.

Some tests carry out one operation on several parameters and therefore deviate slightly from the descriptions above. Expanding the title row reveals only the description, while rows of the individual parameters reveal the text fields.

In the history report, instead of text fields scatterplots show how the respective metrics developed over the commit history for each branch of a repository. By clicking an entry in the legend, it is possible to toggle its visibility in the plot.

Interpretation¶

The variety of constraints-based modeling approaches and differences between various organisms compound the assessment of GSMs. While memote facilitates model assessment it can only do so within limitations. Please bear in mind the diversity of Paradigms that challenge some of memote’s results.

Color¶

Snapshot Report

Results without highlights are kept in the main blue color of the memote color scheme. Scored results will be marked with a gradient ranging from red to green denoting a low or a high score respectively:

100%

Diff Report

The colour in the Diff Report depends on the ratio of the sample minimum to the sample maxium. Result sets where the sample minimum and the sample maximum are identical will be coloured in the main blue colour of the memote colour scheme. Result sets where the sample minimum is very small relative to the sample maximum will appear red . This ratio is calculated using $1 - (Min / Max)) * 100$.

This is then mapped to the following gradient:

Identical

Different

Score¶

Each test in the independent section provides a relative measure of completeness with regard to the tested property. The final score is the weighted sum of all individual test results normalized by the maximally achievable score, i.e., all individual results at 100%. Individual tests can be weighted, but it is also possible to apply weighting to entire test categories. Hence the final score is calculated:

Weights for sections and individual tests are indicated by a white number inside a magenta badge. No badge means that the weight defaults to 1.

Paradigms¶

“Reconstructions” and “Models”¶

Some authors may publish metabolic networks which are parameterized, ready to run flux balance analysis (FBA), these are referred to simply as ‘models’. Alternatively, others may publish unconstrained metabolic knowledgebases (referred to as ‘reconstructions’), from which several models can be derived by applying different constraints. Both can be encoded in SBML. With having an independent test section, we attempt to make both ‘models’ and ‘reconstructions’ comparable, although a user should be aware that this difference exists and is subject to some discussion. Please note, that some tests in the specific section may error for a reconstruction as they require initialization.

“Lumped” and “Split” Biomass Reaction¶

There are two basic ways of specifying the biomass composition. The most common is a single lumped reaction containing all biomass precursors. Alternatively, the biomass equation can be split into several reactions each focusing on a different macromolecular component for instance a (1 gDW ash) + b (1 gDW phospholipids) + c (free fatty acids)+ d (1 gDW carbs) + e (1 gDW protein) + f (1 gDW RNA) + g (1 gDW DNA) + h (vitamins/cofactors) + xATP + xH2O-> 1 gDCW biomass + xADP + xH + xPi. The benefit of either approach depends very much on the use cases which are discussed by the community. Memote employs heuristics to identify the type of biomass which may fail to distinguish edge cases.

“Average” and “Unique” Metabolites¶

A metabolite consisting of a fixed core with variable branches such as a membrane lipid are sometimes implemented by averaging over the distribution of individual lipid species. The resulting pseudo-metabolite is assigned an average chemical formula, which requires scaling of stoichiometries of associated reactions to avoid floating point numbers in the chemical formulae. An alternative approach is to implement each species as a distinct metabolite in the model, which increases the total count of reactions. Memote cannot yet distinguish between these paradigms, which means that results in the specific sections that rely on the total number of reactions or scaling of stochiometric parameters may be biased.

Experimental Data¶

Sections

Configuration
- Minimal growth rate
Media
- Format
Growth
- Format
Essentiality
- Format

At the moment it is possible to include the following types of experimental data with your model tests.

Growth data, for example, processed Biolog data, that lists whether growth was possible in different media.
Gene essentiality data that lists for a single gene identifier whether it is essential, i.e., a knock-out is lethal, or not.

In order for memote to make proper use of your data, you should add them to the repository. If you use memote new to generate the repository structure, take a look at the files under data. It should look like this:

data
├── essentiality
├── experiments.yml
├── growth
└── media

Configuration ¶

In order for anything to happen you have to edit the experiments.yml configuration file. The provided file contains a minimal setup but does not actually define any experiments.

version: "0.1"
medium:
  path: "media/"
essentiality:
  path: "essentiality/"
growth:
  path: "growth/"

The file simply states that files relating to media, essentiality, and growth experiments can be found at directories stated under path: relative to the location of the file.

Minimal growth rate ¶

Both growth and essentiality experiments require a minimal biomass function value to determine if the model predicts viability. This value can be set via the minimal_growth_rate option in the experiments.yml file. For instance:

version: "0.1"
medium:
  path: "media/"
essentiality:
  path: "essentiality/"
growth:
  path: "growth/"
minimal_growth_rate: 0.05

By default, minimal_growth_rate is set to 10% of the biomass function value under the default constraints in the model.

Media ¶

You can fill the configuration with life by adding medium definitions and experiments. So you could add:

medium:
  path: "media/"
  definitions:
    m9_minimal:

which by default would look for a medium file media/m9_minimal.csv. Definition keys need to be valid YAML keys. In addition to CSV, other data formats such as TSV, XLS or XLSX are also allowed. You can specify the filename which also allows you to use a different name, although that would probably be confusing.

medium:
  path: "media/"
  definitions:
    m9_minimal:
        filename: "minimal.xls"

Additionally, you can add a convenient label.

medium:
  path: "media/"
  definitions:
    m9_minimal:
        filename: "minimal.xls"
        label: "M9 minimal medium"

Format ¶

A medium is defined by a tabular format with the following columns. A ‘comment’ column is allowed for your own convenience but no entry is required.

exchange	uptake	comment
EX_glc_e	10

Each row must include the exchange reaction identifier and an uptake rate between 0 and 1000.

Growth ¶

Growth data are included under the key experiments:. It works similarly to media but allows a few extra definitions.

growth:
  path: "growth/"
  experiments:
    my_growth:
      filename: "my_growth.csv"
      medium: m9_minimal
      objective: Biomass
      label: "Exhaustive carbon growth"

Again, each experiment should have a unique key. By default, memote will look for a relative CSV file of the same name. The specified medium refers to a medium key. The objective, for the moment, should refer to a reaction identifier such as that of the biomass reaction or ATP formation. Again, a more expressive label can be given.

Only the experiment key is really required as the default filename, medium, and objective may be used. However, growth data typically vary the carbon source which is not reflected by the default medium. This will become more clear when looking at the format.

Format ¶

exchange	uptake	growth	comment
EX_glc_e	10	yes
EX_glc_e	0	no

For the tabular growth data, each row represents one data point with a binary outcome. In order to take full advantage of this format it makes sense to define a minimal medium without any carbon source. That medium will be used as the basis and the exchange specified in each row of a growth experiment will be set in addition to the base medium. That means if you rely on the default medium you will likely end up with multiple carbon sources. The binary outcome in the ‘growth’ column will be compared to the model predictions. Any one of the following values is recognized: “true”, “True”, “TRUE”, “1”, “yes”, “Yes”, “YES” and “false”, “False”, “FALSE”, “0”, “no”, “No”, “NO”.

Essentiality ¶

Essentiality experiments can be defined in the same way as growth experiments but the medium entry is interpreted differently.

essentiality:
  path: "essentiality/"
  experiments:
    knockouts:
      filename: "knockouts.xls"
      medium: glucose
      objective: Biomass
      label: "knock-out library"

Unlike for growth experiments, in the case of essentiality experiments the same medium is used in each individual gene deletion experiment. If you have knock-out experiments performed in different media, simply define the media and define one essentiality experiment for each medium.

Format ¶

gene	essential	comment
b0025	yes

An essentiality table should define unique gene identifiers as they are specified in the model. At the moment, only single gene deletion experiments are supported. The binary column ‘essential’ allows the same values as the ‘growth’ column above. Again, in silico deletion outcomes are compared to the provided ones.

Custom Tests¶

Memote can be configured to include custom test modules from any other directory in addition to the tests that are included in the package.

Custom Test Setup¶

All custom test modules and the tests defined inside of them have to adhere to the same standard design for the results to be generated and displayed correctly. Optionally, a user may specify a configuration file which can be used to change how individual tests are displayed in the snapshot report.

A Custom Test Module¶

At its core, a memote test module is a collection of specific python code in a text file with the file ending .py. Since, memote uses pytest for discovery and execution of model tests, the conditions for memote test modules and pytest test modules are identical.

The module name has to match either test_*.py or *_test.py:

your_custom_directory/
    test_module1.py
    module2_test.py
    ...

Minimal Test Module & Simple Test Function Template¶

The minimal content of a custom test module should look like this:

import pytest
from memote.utils import annotate, wrapper, truncate

import path.to.your_support_module as your_support_module


@annotate(
    title="Some human-readable descriptive title for the report",
    format_type="Single keyword describing how the data ought to be displayed."
)
def test_your_custom_case(read_only_model):
"""
Docstring that briefly outlines the test function.

A more elaborate explanation of why this test is important, how it works,
and the assumptions/ theory behind it. This can be more than one line.
"""
ann = test_your_custom_case.annotation
ann["data"] = list(your_support_module.specific_model_quality(read_only_model))
ann["metric"] = len(ann["data"]) / len(read_only_model.total_model_quality)
ann["message"] = wrapper.fill(
    """A concise message that displays and explains the test results.
    For instance, if data is a list of items the amount: {} and
    percentage ({:.2%}) values can be recorded here, as well as an
    excerpt of the list itself: {}""".format(
    len(ann["data"]), ann['metric'], truncate(ann['data'])
    ))
)
assert len(ann["data"]) == 0, ann["message"]

This is a minimal test module template containing a test function called test_your_custom_case. There can be additional lines of code, but you should keep in mind that any logic is best put into a separate support module, which is imported above as your_support_module. The functions of this support module are called by the test function. This will simplify debugging, error handling and allows for dedicated unit testing on the code in the support module.

The following components are requirements of test_your_custom_case:

Each test has to be decorated with the annotate() decorator, which collects:
- The data that the test is run on. Can be of the following type: list, set, tuple, string, float, integer and boolean. It can be of type dictionary, but this is only supported for parametrized tests (see example below).
- The format_type of data. This is not the actual python type of data but it correlates closely with it. If data is a set, tuple or list format_type="count" configures the report to display its length. If data is an integer or float use format_type="number". If data is a single string, then choose format_type="raw". This format_type also works for any other data type. In case, you’d rather display the metric as opposed to the contents of data use format_type="percent". It is important that the custom test case does not return nan, None or null as this will lead to errors on the report.
- A human-readable, descriptive title that will be displayed in the report as opposed to the test function name test_your_custom_case which will only serve as the test’s ID internally.
- metric can be any fraction relating to the quality that is tested. In memote’s core tests the metrics of each scored tests are used to calculate the overall score.
- The message is a brief summary of the results displayed only on the command line. There are no restrictions on what it should include. We’ve generally tried to keep this short and concise to avoid spamming the command line.
The prefix ‘test_’ is required by pytest for automatic test discovery. Every function with this prefix will be executed when later running memote with the configuration to find custom tests.
read_only_model is the required parameter to access the loaded metabolic model at runtime.
In the report the docstring is taken as a tooltip for each test. It should generally adhere to the conventions of the NumPy/SciPy documentation. It suffices to write a brief one-sentence outline of the test function optionally followed by a more elaborate explanation that helps the user to understand the test’s purpose and function.
The assert statement works just like the assert statement in pytest.

Parametrized Test Function Template¶

Pytest allows us to run one test function with multiple sets of arguments by simply using the pytest.mark.paremtrize decorator. This is quite useful when the same underlying assertion logic can be applied to several parameters. In the following example taken from memote.suite.tests.test_annotation we test that there are no metabolites that lack annotations from any of the databases listed in annotation.METABOLITE_ANNOTATIONS. Without parametrization we would have had to copy the entire test function below to specifically check the metabolite annotations for each database.

@pytest.mark.parametrize("db", list(annotation.METABOLITE_ANNOTATIONS))
@annotate(title="Missing Metabolite Annotations Per Database",
          format_type="count", message=dict(), data=dict(), metric=dict())
def test_metabolite_annotation_overview(read_only_model, db):
    """
    Expect all metabolites to have annotations from common databases.

    The required databases are outlined in `annotation.py`.
    """
    ann = test_metabolite_annotation_overview.annotation
    ann["data"][db] = get_ids(annotation.generate_component_annotation_overview(
        read_only_model.metabolites, db))
    ann["metric"][db] = len(ann["data"][db]) / len(read_only_model.metabolites)
    ann["message"][db] = wrapper.fill(
        """The following {} metabolites ({:.2%}) lack annotation for {}:
        {}""".format(len(ann["data"][db]), ann["metric"][db], db,
                     truncate(ann["data"][db])))
    assert len(ann["data"][db]) == 0, ann["message"][db]

Custom Test Configuration¶

Finally, there are two ways of configuring memote to find custom tests. The first involves the --custom-* options of the memote CLI and requires the user to provide a corresponding config file with the custom test modules, while the second involves passing arguments directly to pytest through the use of the --pytest-args option, which can be abbreviated to -a. This option only requires the user to set up the custom test module. No config file is needed here.

The Custom Option¶

When invoking the memote run, memote report snapshot or memote report diff commands in the terminal, it is possible to add the --custom-* options:

--custom-tests takes the absolute path to any directory in which pytest is to check for custom tests modules. By default test discovery is recursive. More information is provided here.
--custom-config The absolute path to a valid configuration file.

To simply insert custom tests into the test suite, it suffices to use the first option --custom-tests. Providing the custom configuration file with --custom-config further gives you the means to weigh, categorise and layout where on the report your results will be displayed.

$ memote report snapshot --custom-tests path/to/dir/ --custom-config path/to/config.yml --filename "report.html" path/to/model.xml

The Pytest Option¶

In addition, it is possible to pass any number of absolute paths to custom test directories directly to pytest, as long as they are placed behind any other parameters that you might want to pass in. For instance here we want to get a list of the ten slowest running tests while including two custom test module directories:

$ memote run -a "--durations=10 path/to/dir1/ path/to/dir2/" --filename "report.html" path/to/model.xml

Guidelines¶

Please consider the following guidelines which reflect some of the considerations behind the core tests in memote. Adhering to these guidelines will allow other researchers to easily adopt your custom tests and ensure that they are applicable to a wide array of modeling practises.

1. Be namespace agnostic. Use the METANETX_SHORTLIST and COMPARTMENT_SHORTLIST (both in memote/support/helpers.py) mapping tables from memote or consider creating your own if your custom test needs to identify a specific metabolite in a specific compartment. You can generate a custom metabolite shortlist by adapting shortlist.tsv and then executing the script annotate_mnx_shortlists.py found in memote/scripts.

2. Be paradigm agnostic. Use the functions provided in memote/support for routine operations i.e. identifying a model’s biomass reaction(s) or finding all purely metabolic reactions. We have been intent on making memote as robust as possible with regards to the range of modeling paradigms we have encountered so far. In addition, support functions are rigidly unit tested.

3. Be organism agnostic. Unless you target a specific class of organism, consider how your test performs on a model of a different organism. Will the results be biased by that in anyway? If so, consider emphasizing that bias in the docstring.

4. Be reproducible. Provide a requirements.txt or setup.cfg with your custom test module if you rely on packages or specific version that differ from those memote relies on.

5. Write readable code. Lint your code with respect to PEP8, annotate it consistently and make use of logging.

6. Share the love. Let us know about your custom tests! We are considering to build a registry and knowing that people use this feature is the first step towards that.

Test Suite¶

Core Tests¶

Annotation¶

Basic¶

Biomass¶

Consistency¶

Matrix¶

SBO¶

Thermodynamics¶

Experimental Tests¶

Essentiality¶

Growth¶

Contributing¶

Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.

You can contribute in many ways:

Report Bugs¶

Report bugs at https://github.com/opencobra/memote/issues.

If you are reporting a bug, please follow the template guidelines. The more detailed your report, the easier and thus faster we can help you.

Fix Bugs¶

Look through the GitHub issues for bugs. Anything tagged with “bug” and “help wanted” is open to whoever wants to implement it.

Implement Features¶

Look through the GitHub issues for features. Anything tagged with “enhancement” and “help wanted” is open to whoever wants to implement it.

Write Documentation¶

memote could always use more documentation, whether as part of the official documentation, in docstrings, or even on the web in blog posts, articles, and such.

Submit Feedback¶

The best way to send feedback is to file an issue at https://github.com/opencobra/memote/issues.

If you are proposing a feature:

Explain in detail how it would work.
Keep the scope as narrow as possible, to make it easier to implement.
Remember that this is a volunteer-driven project, and that contributions are welcome :)

Get Started!¶

Ready to contribute? Here’s how to set up memote for local development.

Fork the https://github.com/opencobra/memote repository on GitHub.

Clone your fork locally

git clone git@github.com:your_name_here/memote.git

Install your local copy into a a Python virtual environment. You can read this guide to learn more about them and how to create one. Alternatively, particularly if you are a Windows or Mac user, you can also use Anaconda. Assuming you have virtualenvwrapper installed, this is how you set up your fork for local development
```
mkvirtualenv my-env
cd memote/
pip install -e .[development]
```
Create a branch for local development using the devel branch as a starting point. Use fix or feat as a prefix
```
git checkout devel
git checkout -b fix-name-of-your-bugfix
```
Now you can make your changes locally.
When you’re done making changes, apply the quality assurance tools and check that your changes pass our test suite. This is all included with tox
```
make qa
tox
```

Commit your changes and push your branch to GitHub. Please use semantic commit messages.

git add .
git commit -m "fix: Your summary of changes"
git push origin fix-name-of-your-bugfix

Open the link displayed in the message when pushing your new branch in order to submit a pull request.

Pull Request Guidelines¶

Before you submit a pull request, check that it meets these guidelines:

The pull request should include tests.
If the pull request adds functionality, the docs should be updated. Put your new functionality into a function with a docstring.

Credits¶

Development Leads¶

Contributors¶

History¶

Next Release¶

0.14.0 (2023-09-13)¶

Fix problems with the deprecated API of importlib_resources. Update to either use standard library or newer version of the package.

0.13.0 (2021-06-12)¶

Fix logic errors with orphan and dead-end metabolite detection. This problem could occur with irreversible reactions whose bounds constrain flux to the reverse direction.

0.12.1 (2021-06-12)¶

Fix problems with spreadsheet parser. Now supports .xls, .xlsx, and .ods.
Fix a bug with models whose biomass optimization is infeasible.

0.12.0 (2020-10-20)¶

Fix bug caused from upstream changes -> cobrapy -> pandas.
Refactor stoichiometric consistency test into 3 separate ones.

0.11.1 (2020-08-10)¶

Change the logic for identifying biomass reactions to be less eager.
Fix failing excel reader.

0.11.0 (2020-06-26)¶

Fix an issue where experimental growth was incorrectly not reported.
Allow the user to set a threshold value for growth in experimental data.
Fix and enable the consistency test for minimal unconservable sets.

0.10.2 (2020-03-24)¶

Correct the names of parametrized experiments.

0.10.1 (2020-03-24)¶

Make the confusion matrix computation more robust.

0.10.0 (2020-03-24)¶

Fix an issue where experimental data was not loaded.
Enable command line options for solver timeouts.
Setting the log level to DEBUG now also enables the solver log output.

0.9.13 (2019-12-04)¶

Improve the biomass reaction finding logic.
Explicitly register custom markers biomass, essentiality and growth used for custom test parametrization in pytest.
Fix logic for consistency tests of production and consumption of metabolites with open bounds. It allows multiprocessing, currently relying on cobra.Configuration to select the number of processors.

0.9.11 (2019-04-23)¶

Pin cobrapy version to <= 0.14.2 (because cobra==0.15.1,0.15.2 SBML parsing is broken).

0.9.10 (2019-04-23)¶

Pin cobrapy version to 0.14.2 (because cobra==0.15.1,0.15.2 SBML parsing is broken).

0.9.9 (2019-04-17)¶

Include memote’s requirement for git on installation instructions.
Check for the presence of git in CLI commands that require it.
Replace vega with taucharts in all reports.
Fix plots to be large enough.
Fix responsive behaviour.
Add clear axis labels and understandable titles.
Add an option to save all plots to png, json and csv.
Color code the category plots just like the results buttons on the snapshot report.
Fix the data that is displayed in the independent an specific sections of the history report.
Invert metrices and display as percentages.
Add hover-over tooltips for all plots.
Implement lazy loading for all the reports, meaning that the content of an expansion panel in any of the reports is only rendered when it is open.
Fix the reactions with identical genes test case to not group all reactions without any GPR together.
Enable CI on Appveyor (unit tests on Windows as opposed to linux which we do on Travis).
Replace any commit operations through gitpython with direct subprocess invocations of git.
Regenerate the mock repo we use in some tests so that filemode changes are ignored by default.

0.9.8 (2019-04-01)¶

Repair memote online which would not get the most up-to-date status when checking whether a repo had already been activate for testing on Travis CI.
Pin travis-encode due to conflicts in dependency on click with goodtables and jsonschema.

0.9.7 (2019-03-29)¶

Repair the experimental testing and add a test case for the runner with experimental data.
Update docstring of test_find_duplicate_reactions.
Add a guide explaining the structure of and how to interpret the memote reports.
Add guidelines on writing custom tests to the documentation.
Add unit tests to the CLI workflow.
Remove dependency on GitHub and Travis API wrappers, make calls through python requests.
Fix bugs in memote

0.9.6 (2019-03-06)¶

The number of duplicated reactions is now reported uniquely rather than all duplicate pairs.

0.9.5 (2019-02-21)¶

Add missing parametrized metric on test_biomass_open_production.

0.9.4 (2019-02-20)¶

Add metrics, i.e., model-size independent test outcomes to almost all test cases.
Repair auto generation of API docs and update section on test suite.
Remove our dependecy on PyGithub and TravisPy by reimplementing all the necessary steps with requests
Add unit and integration tests for runner.py and reports.py, except for memote online.
Debug memote online - could only be tested manually, CI is impossible without a secure way of storing github credentials.
Add logging statements to all CLI functions to facilitate future debugging.

0.9.3 (2019-01-30)¶

Enhance the function for finding unique metabolites and make it more robust.
Improve logging output when there is a problem with serializing a result to JSON.
Fix some test cases that got broken by cobrapy’s new boundary identification.

0.9.2 (2019-01-28)¶

Fix bug that would lead to biomass SBO annotations not being reported.

0.9.1 (2019-01-28)¶

Add seed.reaction namespace to the reaction annotation databases.

0.9.0 (2019-01-28)¶

Change SBO annotation tests to check for multiple terms until we can properly handle the ontology.
Remove ‘Steady-state flux solution vectors’ test case.
Improve the descriptions of stoichiometric matrix test cases.
Fix the discovery or orphan and dead-end metabolites.
Improve detection of metabolites that are not consumed or not produced by only opening exchange reactions not other boundary reactions.
Thematically reorganize the test cases in the config.
Instead of min/max bounds consider the median bounds for testing (un-)bounded fluxes.
Use a model context for every test case.
Fix bug which involved find_transport_reactions to ignore compartments.
Internal change to use model context rather than copy.
Internal changes to JSON structure.
Remove tests for metabolite inconsistency with closed bounds. The results are a subset only of the unconserved metabolites.
Make the consistency tests account better for numeric instability.
Add the GLPK exact solver as a possible option.
Update memote-report-app from Angular 5.1.0 to 7.2.0.
Reduce the prominence of the total score in the reports.
Provide partial calculations for each section.
Show overall formula of how the total score is calculated.
Clearly indicate weights/ multipliers by introducing margenta badges next to each test in the report.
In the reports, improve the descriptions of the ‘Help’ section and rename this section to ‘Readme’.
Rename the principal sections and include a brief explanation for each.
Fix bug that would show a test as ‘Errored’ although it only failed. Fixed by making condition in errorFailsafe in test-result.model.ts more specific for cases where data is undefined or null.
Fix bug that would make parametrized tests disappear from the report if they had errored or if for some reason their ‘data’ attribute was undefined.
Unpin pytest (require >= 4.0) and adjust some internal mechanics accordingly.
Display an alternative message if some biomass components do not contain a formula.
Extend the annotations tests by a check for full length InChI strings.
Fix a bug in Unrealistic Growth Rate In Default Medium which reported the opposite of what was the case.
Extend the description of each test by a description of how it is implemented.
Refactor test that identifies duplicate reactions to take into metabolites, reaction directionality and compartments into account.
Add additional tests that identify reactions having identical annotations and identical genes.
Refactor test that identifies duplicate metabolites to use for inchi strings in addition to inchikeys.
Round score to and display a single decimal value.
Fix bug that would show a test as errored whenever it was marked as skipped.
Read SBML files with modified parser that can collect the level, version and whether the FBC package is used.
Validate the SBML structure with the libSBML python API if the parser errors and produce a simple SBML validation report.
Add test cases that report on the level and version, and FBC availability through the memote reports.

0.8.11 (2019-01-07)¶

Temporarily pin pytest to <4.1 in order to avoid a breaking API change on their part.

0.8.10 (2018-12-21)¶

Refactor the test for enzyme complexes to only return an estimated size.

0.8.9 (2018-12-11)¶

Compress JSON and SQLite storage of results using gzip by default. JSON continues to work either compressed or uncompressed. At the moment we offer no database migration, please contact us if you need help in migrating a large existing SQLite database rather than just re-computing it.

0.8.8 (2018-12-10)¶

Adjust the reversibility index test to not use name matching and increase the threshold slightly. Also adjust the description of the test.
Adjust tests to the change in the add_boundary interface.
Identify blocked reactions using the cobrapy built-in function.

0.8.7 (2018-11-21)¶

Add a feature to allow suppling a commit range to memote history.
Add a test that checks if reactions are annotated with reactome identifiers.
Add a feature that allows identifying specific metabolites by matching annotation information against the metabolite shortlist for a given MNX ID.
Change every usage of SBO key to lower case to conform to the identifiers.org namespace for the Systems Biology Ontology.
Remove that metabolite SBO terms are used when identifying transport reactions as this may lead to false positives.
Return metabolite IDs when finding duplicate metabolites to avoid serialization errors.
Identify transport reactions first by formula then by annotation.
For the diff report, run pytest in different processes to avoid accidentally overwriting the results of the former with the results of the later runs.
In the diff report, fix a typo that allowed the diff button to depart the defined colour scheme (blue -> red) to cyan.
Fix the snapshot report not showing environment information.
Allow memote run to skip commits where the model was not changed, if the flag --skip-unchanged is provided.
Fix the default value of the overall score to be zero instead of one and make sure that the calculation is ensured with unit tests.
Fix medium and experiment loading
Add a test to check reaction directionality with thermodynamic estimation from eQuilibrator API.

0.8.6 (2018-09-13)¶

Fix test titles and descriptions.

0.8.5 (2018-08-20)¶

Unpin cobra dependency and set it to >0.13.3.
Set ruamel.yaml to >=0.15 to keep up with cobra.

0.8.4 (2018-07-18)¶

Handle various pytest verbosity options better.
Improve memote new behavior.

0.8.3 (2018-07-16)¶

memote run in a repository now immediately commits the result to the deployment branch.

0.8.2 (2018-07-16)¶

Allow running of memote history from any branch.
Let the history report only use commits where the model actually changed.
Proofread and update all docstrings and comments inside the memote subfolder.
Reworded all test titles to be a) shorter and b) as neutral as was sensibly possible.
Reordered tests in the test-config.yaml such that results belonging to a category are grouped logically.
Updated the documentation to include a newer flowchart, up-to-date getting started and custom test sections.
Update code to account for breaking changes in the most recent version of cobrapy (0.13.0) and subsequently unpin cobrapy dependency (set to >=0.13.0).

0.8.1 (2018-06-27)¶

Allow users to selective recompute the history of results.
Skip commits in the history that did not change the model file.
Change format_type on experimental tests from count to percent
Fix typo in test_basic.py that lead to tests returning null which breaks the diff report frontend.
Update the diff report to properly show errored and skipped tests
Fix issues with asynchronicity on the diff report.
Change format_type on experimental tests from count to percent
Fix typo in test_basic.py that lead to tests returning null which breaks the diff report frontend.
Update the diff report to properly show errored and skipped tests

0.8.0 (2018-06-22)¶

Finalize testing comparing with experimental data (growth and esentiality).
Temporarily disable test_find_inconsistent_min_stoichiometry.
Update the nullspace function.
Improve optlang compatibility.
Add test find_medium_metabolites to detect and display all substrates capable of being taken up by model
Display the score on History and Snapshot reports.
Invert the colour coding.
Display results as percentages.
Add ability to generate a diff report which compares two or more models.
Annotation of metabolite shortlist simplified.

0.7.6 (2018-05-28)¶

Refactor internal API and JSON object creation.

0.7.5 (2018-05-25)¶

Expose more of the internal API to the top level.
Also, remember to carry a towel!

0.7.4 (2018-05-23)¶

Add test find_duplicate_reactions to detect duplicate reactions in model
Add dynamic upper and lower bounds. They are based on the most extreme bound values given in a model (if none exist -1000 and 1000 are chosen as defaults)
Fix logic in find_bounds function in helpers.py

0.7.3 (2018-05-23)¶

Make the report type variable a string in the index.html.

0.7.2 (2018-05-22)¶

Distribute the missing tests.

0.7.1 (2018-05-16)¶

Fix a problem with the report caused by previous refactoring.

0.7.0 (2018-05-15)¶

Remove the pip dependency in show_versions.
Update the CI to use stages and tox-travis.
Modify some editor and other configuration.
Expose testing of experimental essentiality and growth data in memote.
Create a configuration system for media that is extensible to further experimental data types.
Add test for identifying purely metabolic reactions with fixed constraints in models
Add test for identifying transport reactions with fixed constraints in models
Add test for identifying reversible oxygen-containing reactions in models
Add division import from __future__ to test_biomass and test_consistency where it was missing.
Add O2 to MetaNetX shortlist, allowing for easier identification
Allow tests and test module to be skipped or run exclusively when creating a snapshot report.
Fix some typos
Add history report view and connect it to memote report history call.
find_direct_metabolites detects and removes false positives.
find_transport_reactions detects reactions using forumlae and annotations
Add tests for detecting gene annotations (and verifying they are in MIRIAM style)
Add unit tests for matrix.py in file test_for_matrix.py.
Add tests find_metabolites_not_produced_with_open_bounds and find_metabolites_not_consumed_with_open_bounds
Add test find_duplicate_metabolites_in_compartments to detect duplicate metabolites in identical compartments
Cache heavily used support functions in helpers.py and consistency_helpers.py

0.6.2 (2018-03-12)¶

Test summary only displays extended narrative summary describing test, and not one-line summary describing expected function behavior/output
Fix the following bugs:
- Fix type annotation on the test for Biomass Production in Complete Medium
- Fix TypeError when running memote new which was associated with unicode and string formatting in py2.7
- Sort existing test results from misc into the respective categories (by editing test_config.yml)
- Move Matrix statistics category to unscored side into their own card
- Add a tuple of (number of reactions, number of genes) to the data annotation of the metabolic coverage test.
Add filter in report_data_service that changed the test result status to “error” when the data attribute is null, thus avoiding that the report interface breaks when trying to access data.
Add test for identifying stoichiometrically balanced cycles in models
Correct the arguments used for repositories such that memote run and memote history work as expected inside of a repository.

0.6.1 (2018-03-01)¶

Emergency fix for distributing required JSON file.

0.6.0 (2018-02-27)¶

Let Travis re-package the snapshot report with every release.
Add new module to test for the presence of SBO term annotations.
Add a test for Biomass production in complete medium.
Clarify extend of mass- and charge-imbalance testing.
Remove much of the boilerplate code of the report template as a preparation for the history and diff report.
Fix bug with test_blocked_reactions
Update the testData.json with data from the previous release
Fix a small bug with the metrics of mass/charge unbalanced reactions.
Correctly invert the found identifiers in wrong annotations and namespace consistency in order to report the correct results.
Add a cross-reference shortlist using MetaNetX flatfiles
Add a script that can be used to add more metabolites and then to re-generate the shortlist
Add helper function find_met_in_model which looks up a query metabolite ID using the MNX namespace in the shortlist and:
- If no compartment is provided, returns a list of all possible candidates metabolites.
- If a compartment is provided, tries to return a list containing only ONE corresponding metabolite.
Add helper function find_compartment_id_in_model to identify compartments using an internal shortlist of possible compartment names.
Provide tests for each function
Refactor code to use these functions specifically:
- find_ngam
- find_biomass_reaction
- detect_energy_generating_cycles
- find_exchange_rxns
- find_demand_rxns
- find_sink_rxns
- gam_in_biomass
- find_biomass_precursors
Improve find_ngam in addition to agnostically looking for ATP hydrolysis reactions, the test now also looks for a range of possible “buzzwords” in the reaction NAME: [‘maintenance’, ‘atpm’, ‘requirement’, ‘ngam’, ‘non-growth’, ‘associated’]. One match suffices as a classification.
Improve find_biomass_reaction to look for three attributes in a biomass reaction, one of which is sufficient to classify it as a biomass reaction:
1. “Buzzwords” in the reaction ID: [‘biomass’, ‘growth’, ‘bof’]
2. An annotation matching the SBO-Term SBO:0000630 specifically!
3. Containing a metabolite matching the regex: ^biomass(_[a-zA-Z]+?)*?$ (case-insensitive)
Add function bundle_biomass_components to identify whether a given biomass reaction is ‘split’ or ‘lumped’. This function looks simply at the size of the biomass reaction. Based on a guess-timated cut-off the reaction is then classified. If it is ‘lumped’ it is returned without changes, if it is ‘split’ the reactions of any non-energy precursor metabolite are returned as well. This is based on the assumption that a ‘split’ biomass reaction has the following structure: a (1 gDW ash) + b (1 gDW phospholipids) + c (free fatty acids) + d (1 gDW carbs) + e (1 gDW protein) + f (1 gDW RNA) + g (1 gDW DNA) + h (vitamins/cofactors)-> 1 gDCW biomass. We’re supposing that for each macromolecule precursor metabolite there is a single reaction defining its composition i.e. e = protein would have the reaction: alanine + asparagine + ... + valine --> e
Add function, test and model test to identify missing essential precursors to the biomass reaction. The function is essential_precursors_not_in_biomass
Record the score of individual test cases and sections in the result output.
Correct the import of module ‘annotation’ with ‘sbo’ in test_sbo.py
Refactor sink_react_list to sink_reactions for improved readability
Allow test_sink_specific_sbo_presence to be skipped when no sink reactions are present with a metric of 1.0
Fix a bug that compared the length of a float to generate a metric in test_basic.py and generated a TypeError.
Fix a bug that prevented find_biomass_precursors in memote/support/biomass.py from functioning due to a malformed set
In CONTRIBUTING.rst replace link to semantic commit guide by seesparkbox with link to guide by karma, due to error with sphinx linkcheck.
Fix a bug that prevented find_biomass_precursors from correctly identifying atp and h2o metabolites in cobra model reactions
Fix improperly labeled sbo terms for biomass production in biomass.py and test_for_helpers.py.
Add matrix conditioning functions in matrix.py which are used for model stoichiometric matrix testing in test_matrix.py
Add missing rank and nullspace_basis functions in consistency_helpers.py
Fix issue with improper string/dict formatting in test_biomass.py tests
Re-organize the architecture to read in external configurations and add custom tests.
Add an argument --location which replaces --directory which can be used to set the directory or database where results should be stored.

0.5.0 (2018-01-16)¶

Enable test result and meta-data collection.
Allow command line option and configuration of exclusive test cases and modules skipping all others (--exclusive test_biomass).
Allow command line option and configuration to skip test cases and modules (--skip test_model_id_presence).
Introduce a dummy configuration file for the report organization and test scoring weights.
Sort unconfigured tests into the card ‘Misc. Tests’ in the snapshot report.
Handle skipped tests better in the snapshot report.
Bundle the Angular report javascript libraries in the snapshot template
Pass results into the report as JSON
Fixed/ changed a lot of visuals on the angular report:
- Indent the rows of the parametrized test results
- Color the header text of the parametrized test results in pure black
- Remove the horizontal lines in the parametrized test results
- Display all results regardless of scored/ unscored inside of buttons to force a uniform line height and a more consistent look
- Add logic to correctly display errored tests
- Give skipped and errored test results a distinct look
- Explicitly handle boolean results, and add boolean as an option for the ‘type’ attribute.
- Fix the raw data output in the textboxes so that they are formatted python code.
Allow command line option to enable the definition of a custom test directory in combination with a corresponding config file.
Extend test descriptions to make it more clear how a user can satisfy the test conditions.
Remove duplicate test for the presence of transport reactions.
Implement a test for unbounded flux through reactions in the default condition.
Implement a test for detecting metabolites that can either be produced or removed from the model when all system boundaries are closed.
Implement a test for ‘direct’ metabolites, i.e. the detection of biomass precursors that are not involved in any metabolic reactions; only in exchange reactions, transporters and the biomass reaction itself.
Implement a test that checks for a low ratio of transport reactions without GPR relative to the total amount of transport reactions.
Fix UnicodeDecodeError when memote tries to open the html template for the snapshot report.

0.4.6 (2017-10-31)¶

Improve the automated release pipeline. It now creates pumpkins.
Provide a new decorator @register_with that can be used in all test_for* modules and replaces the model_builder function.
Temporarily change the links to readthedocs to point to latest instead of stable.
Provide angular2 app for the snapshot report instead of the jinja template

0.4.5 (2017-10-09)¶

Correctly account for reversibility when testing for dead-end and orphan metabolites.

0.4.4 (2017-09-26)¶

Fix a bunch of bugs:
- Remove false positive detection of Biocyc annotation
- Allow memote to identify CTP or GTP driven transport reactions
- Refactor how memote detects GAM in the biomass reaction
Add tests to find deadend, orphan and disconnected metabolites.
Extend and improve algorithm to find energy-generating cycles
Remove the print statement from memote.support.annotation .generate_component_annotation_miriam_match.
Fix the bug in the assertion output of memote.memote.suite.tests.test_basic .test_gene_protein_reaction_rule_presence.
Split mass-charge-balance test into two separate tests for more clarity
Fix a bug in memote.support.consistency_helpers.get_internals that did not exclude the (by definition) imbalanced biomass reactions.

0.4.3 (2017-09-25)¶

Fix documentation building and add auto-generation of docs.
Make the command line output of pytest more verbose until the report is up to speed.
Temporarily skip test_find_stoichiometrically_balanced_cycles
Catch errors when testing for compartments and loops.

0.4.2 (2017-08-22)¶

Push all branches with memote online.

0.4.1 (2017-08-22)¶

Fix JSON serialization of test results.

0.4.0 (2017-08-21)¶

Add a programmatic API in module memote.suite.api (#162).
Reorganize the structure and build process for auto-documenting memote (#172).
Add a new command memote online (#95, #153).
Add more basic tests.

0.3.6 (2017-08-15)¶

Improve GitHub support.
Update the readthedocs and gitter badge.
Add a function memote.show_versions() for easy dependency checking.

0.3.4 (2017-08-12)¶

Properly configure Travis deployment.

0.3.3 (2017-08-12)¶

Build tags.

0.3.2 (2017-08-12)¶

Enable automatic deployment to PyPi.

0.3.0 (2017-08-12)¶

Greatly extend the core test modules: * basic * consistency * biomass * annotation * syntax
Add an Angular-material based report with plotly.
Add documentation on readthedocs.io.
Make the first release on PyPi.

0.2.0 (2017-02-09)¶

Yet another package structure for supporting functions, their tests, and the model test suite.

0.1.0 (2017-01-30)¶

New package structure and start of joint development

API Reference¶

This page contains auto-generated API reference documentation [1].

`memote`¶

(me)tabolic (mo)del (te)sts.

The memote Python package is a community-driven effort towards a standardized genome-scale metabolic model test suite.

Subpackages¶

`memote.experimental`¶

Modules related to reading and writing experimental files.

Subpackages¶

memote.experimental.schemata¶

Provide different schemata for goodtables validation.

Submodules¶

memote.experimental.checks¶

Custom checks for goodtables.

Module Contents¶

Classes¶

UnknownIdentifier Validate data identifiers against a known set.

class memote.experimental.checks.UnknownIdentifier(column, identifiers, **_)[source]¶

Validate data identifiers against a known set.

Attributes:	column : str The header of the data column to check. identifiers : iterable of str The known set of identifiers.

check_row(self, cells)[source]¶: Check each row in the data table.

memote.experimental.config¶

Provide a YAML parser for experiment configuration files.

Module Contents¶

Classes¶

ExperimentConfiguration Represent an experimental configuration.

class memote.experimental.config.ExperimentConfiguration(filename, **kwargs)[source]¶

Bases: object

Represent an experimental configuration.

load(self, model)[source]¶

Load all information from an experimental configuration file.

Parameters:	model : cobra.Model The metabolic model under investigation.

validate(self)[source]¶: Validate the configuration file.

load_medium(self, model)[source]¶: Load and validate all media.

load_essentiality(self, model)[source]¶: Load and validate all data files.

load_growth(self, model)[source]¶: Load and validate all data files.

get_path(self, obj, default)[source]¶: Return a relative or absolute path to experimental data.

get_minimal_growth_rate(self, model, threshold=0.1)[source]¶

Calculate min growth default value or return input value.

This value is used to determine if a model is capable of growth under certain experimental conditions.

Parameters:	model : cobra.Model threshold : float, optional If no input is provided by the user the default value is set to a coefficient threshold times the growth under default constraints (default: 0.1).

memote.experimental.essentiality¶

Provide an interface for essentiality experiments.

Module Contents¶

Classes¶

EssentialityExperiment Represent an essentiality experiment.

class memote.experimental.essentiality.EssentialityExperiment(**kwargs)[source]¶

Bases: memote.experimental.experiment.Experiment

Represent an essentiality experiment.

SCHEMA = essentiality.json[source]¶

load(self, dtype_conversion=None)[source]¶

Load the data table and corresponding validation schema.

Parameters:	dtype_conversion : dict Column names as keys and corresponding type for loading the data. Please take a look at the pandas documentation for detailed explanations.

validate(self, model, checks=None)[source]¶: Use a defined schema to validate the medium table format.

evaluate(self, model)[source]¶: Use the defined parameters to predict single gene essentiality.

memote.experimental.experiment¶

Provide a base class for experiment definitions.

Module Contents¶

Classes¶

Experiment Base class for experimental data.

class memote.experimental.experiment.Experiment(obj, minimal_growth_rate, **kwargs)[source]¶

Bases: memote.experimental.experimental_base.ExperimentalBase

Base class for experimental data.

evaluate(self, model)[source]¶: Abstract base method for evaluating experimental data.

memote.experimental.experimental_base¶

Provide a class for medium definitions.

Module Contents¶

Classes¶

ExperimentalBase Represent a specific medium condition.

class memote.experimental.experimental_base.ExperimentalBase(identifier, obj, filename, **kwargs)[source]¶

Bases: object

Represent a specific medium condition.

SCHEMA[source]¶

TRUTHY[source]¶

load(self, dtype_conversion=None)[source]¶

Load the data table and corresponding validation schema.

Parameters:	dtype_conversion : dict Column names as keys and corresponding type for loading the data. Please take a look at the pandas documentation for detailed explanations.

validate(self, model, checks=None)[source]¶: Use a defined schema to validate the given table.

static evaluate_report(report)[source]¶: Iterate over validation errors.

memote.experimental.growth¶

Provide an interface for growth experiments.

Module Contents¶

Classes¶

GrowthExperiment Represent a growth experiment.

class memote.experimental.growth.GrowthExperiment(**kwargs)[source]¶

Bases: memote.experimental.experiment.Experiment

Represent a growth experiment.

SCHEMA = growth.json[source]¶

load(self, dtype_conversion=None)[source]¶

Load the data table and corresponding validation schema.

Parameters:	dtype_conversion : dict Column names as keys and corresponding type for loading the data. Please take a look at the pandas documentation for detailed explanations.

evaluate(self, model)[source]¶: Evaluate in silico growth rates.

memote.experimental.medium¶

Provide a class for medium definitions.

Module Contents¶

Classes¶

Medium Represent a specific medium condition.

class memote.experimental.medium.Medium(**kwargs)[source]¶

Bases: memote.experimental.experimental_base.ExperimentalBase

Represent a specific medium condition.

SCHEMA = medium.json[source]¶

validate(self, model, checks=None)[source]¶: Use a defined schema to validate the medium table format.

apply(self, model)[source]¶: Set the defined medium on the given model.

memote.experimental.tabular¶

Modules related to reading and writing files.

Module Contents¶

Functions¶

read_tabular(filename, dtype_conversion=None) Read a tabular data file which can be CSV, TSV, XLS or XLSX.

memote.experimental.tabular.read_tabular(filename, dtype_conversion=None)[source]¶

Read a tabular data file which can be CSV, TSV, XLS or XLSX.

Parameters:	filename : str or pathlib.Path The full file path. May be a compressed file. dtype_conversion : dict Column names as keys and corresponding type for loading the data. Please take a look at the pandas documentation for detailed explanations.
Returns:	pandas.DataFrame The data table.

Package Contents¶

Classes¶

ExperimentConfiguration Represent an experimental configuration.

class memote.experimental.ExperimentConfiguration(filename, **kwargs)[source]¶

Bases: object

Represent an experimental configuration.

load(self, model)¶

Load all information from an experimental configuration file.

Parameters:	model : cobra.Model The metabolic model under investigation.

validate(self)¶: Validate the configuration file.

load_medium(self, model)¶: Load and validate all media.

load_essentiality(self, model)¶: Load and validate all data files.

load_growth(self, model)¶: Load and validate all data files.

get_path(self, obj, default)¶: Return a relative or absolute path to experimental data.

get_minimal_growth_rate(self, model, threshold=0.1)¶

Calculate min growth default value or return input value.

This value is used to determine if a model is capable of growth under certain experimental conditions.

Parameters:	model : cobra.Model threshold : float, optional If no input is provided by the user the default value is set to a coefficient threshold times the growth under default constraints (default: 0.1).

`memote.suite`¶

(Me)tabolic (Mo)del (Te)st Suite.

Test suite for an instance of cobra.Model.

Subpackages¶

memote.suite.cli¶

memote command line interface.

Submodules¶

memote.suite.cli.callbacks¶

Callbacks for command line parameters.

Module Contents¶

Functions¶

`validate_collect`(context, param, value)	Handle the report collection flag.
`validate_experimental`(context, param, value)	Load and validate an experimental data configuration.
`validate_pytest_args`(context, param, value)	Handle additional arguments to pytest.
`validate_repository`(context, param, value)	Load repository slug from different locations.
`validate_username`(context, param, value)	Load username from different locations.
`probe_git`()	Return a git repository instance if it exists.
`abort_if_false`(ctx, param, value)	Require confirmation.
`git_installed`()	Interrupt execution of memote if git has not been installed.

memote.suite.cli.callbacks.LOGGER[source]¶

memote.suite.cli.callbacks.validate_collect(context, param, value)[source]¶: Handle the report collection flag.

memote.suite.cli.callbacks.validate_experimental(context, param, value)[source]¶: Load and validate an experimental data configuration.

memote.suite.cli.callbacks.validate_pytest_args(context, param, value)[source]¶: Handle additional arguments to pytest.

memote.suite.cli.callbacks.validate_repository(context, param, value)[source]¶: Load repository slug from different locations.

memote.suite.cli.callbacks.validate_username(context, param, value)[source]¶: Load username from different locations.

memote.suite.cli.callbacks.probe_git()[source]¶: Return a git repository instance if it exists.

memote.suite.cli.callbacks.abort_if_false(ctx, param, value)[source]¶: Require confirmation.

memote.suite.cli.callbacks.git_installed()[source]¶: Interrupt execution of memote if git has not been installed.

memote.suite.cli.config¶

Define and make parseable the memote configuration file.

Module Contents¶

Classes¶

`ConfigSectionSchema`	Describes all sections of the memote configuration file.
`ConfigFileProcessor`	Determine which files to look for and what sections.

class memote.suite.cli.config.ConfigSectionSchema[source]¶

Bases: object

Describes all sections of the memote configuration file.

class Memote[source]¶

Bases: click_configfile.SectionSchema

Describes the memote configuration keys and values.

Memote configuration should be carried out either in ‘setup.cfg’ or a dedicated ‘memote.ini’ file.

collect[source]¶

git[source]¶

addargs[source]¶

model[source]¶

deployment[source]¶

location[source]¶

github_repository[source]¶

github_username[source]¶

exclusive[source]¶

skip[source]¶

solver[source]¶

solver_timeout[source]¶

experimental[source]¶

class memote.suite.cli.config.ConfigFileProcessor[source]¶

Bases: click_configfile.ConfigFileReader

Determine which files to look for and what sections.

config_files = ['memote.ini', 'setup.cfg'][source]¶

config_section_schemas[source]¶

memote.suite.cli.reports¶

Provide commands for generating report files.

Module Contents¶

Functions¶

`report`()	Generate one of three different types of reports.
`snapshot`(model, filename, pytest_args, exclusive, skip, solver, solver_timeout, experimental, custom_tests, custom_config)	Take a snapshot of a model’s state and generate a report.
`history`(location, model, filename, deployment, custom_config)	Generate a report over a model’s git commit history.
`_test_diff`(model_and_model_ver_tuple, pytest_args, skip, exclusive, experimental, solver_timeout)
`diff`(models, filename, pytest_args, exclusive, skip, solver, solver_timeout, experimental, custom_tests, custom_config)	Take a snapshot of all the supplied models and generate a diff report.

memote.suite.cli.reports.LOGGER[source]¶

memote.suite.cli.reports.report()[source]¶: Generate one of three different types of reports.

memote.suite.cli.reports.snapshot(model, filename, pytest_args, exclusive, skip, solver, solver_timeout, experimental, custom_tests, custom_config)[source]¶

Take a snapshot of a model’s state and generate a report.

MODEL: Path to model file. Can also be supplied via the environment variable MEMOTE_MODEL or configured in ‘setup.cfg’ or ‘memote.ini’.

memote.suite.cli.reports.history(location, model, filename, deployment, custom_config)[source]¶: Generate a report over a model’s git commit history.

memote.suite.cli.reports._test_diff(model_and_model_ver_tuple, pytest_args, skip, exclusive, experimental, solver_timeout)[source]¶

memote.suite.cli.reports.diff(models, filename, pytest_args, exclusive, skip, solver, solver_timeout, experimental, custom_tests, custom_config)[source]¶

Take a snapshot of all the supplied models and generate a diff report.

MODELS: List of paths to two or more model files.

memote.suite.cli.runner¶

Provide commands for running the test suite on a metabolic model.

Module Contents¶

Functions¶

`cli`()	Metabolic model testing command line tool.
`run`(model, collect, filename, location, ignore_git, pytest_args, exclusive, skip, solver, solver_timeout, experimental, custom_tests, deployment, skip_unchanged)	Run the test suite on a single model and collect results.
`new`(directory, replay)	Create a suitable model repository structure from a template.
`_model_from_stream`(stream, filename)
`_test_history`(model, sbml_ver, solver, solver_timeout, manager, commit, pytest_args, skip, exclusive, experimental)
`history`(model, message, rewrite, solver, solver_timeout, location, pytest_args, deployment, commits, skip, exclusive, experimental=None)	Re-compute test results for the git branch history.
`_setup_gh_repo`(github_repository, github_username, note)
`_setup_travis_ci`(gh_repo_name, auth_token, repo_access_token)
`online`(note, github_repository, github_username)	Upload the repository to GitHub and enable testing on Travis CI.

memote.suite.cli.runner.LOGGER[source]¶

memote.suite.cli.runner.cli()[source]¶

Metabolic model testing command line tool.

In its basic invocation memote runs a test suite on a metabolic model. Through various subcommands it can further generate three types of pretty HTML reports (snapshot, diff and history), generate a model repository structure for starting a new project, and recreate the test result history.

memote.suite.cli.runner.run(model, collect, filename, location, ignore_git, pytest_args, exclusive, skip, solver, solver_timeout, experimental, custom_tests, deployment, skip_unchanged)[source]¶

Run the test suite on a single model and collect results.

MODEL: Path to model file. Can also be supplied via the environment variable MEMOTE_MODEL or configured in ‘setup.cfg’ or ‘memote.ini’.

memote.suite.cli.runner.new(directory, replay)[source]¶

Create a suitable model repository structure from a template.

By using a cookiecutter template, memote will ask you a couple of questions and set up a new directory structure that will make your life easier. The new directory will be placed in the current directory or respect the given –directory option.

memote.suite.cli.runner._model_from_stream(stream, filename)[source]¶

memote.suite.cli.runner._test_history(model, sbml_ver, solver, solver_timeout, manager, commit, pytest_args, skip, exclusive, experimental)[source]¶

memote.suite.cli.runner.history(model, message, rewrite, solver, solver_timeout, location, pytest_args, deployment, commits, skip, exclusive, experimental=None)[source]¶

Re-compute test results for the git branch history.

MODEL is the path to the model file.

MESSAGE is a commit message in case results were modified or added.

[COMMIT] … It is possible to list out individual commits that should be re-computed or supply a range <oldest commit>..<newest commit>, for example,

memote history model.xml “chore: re-compute history” 6b84d05..cd49c85

There are two distinct modes:

1. Completely re-compute test results for each commit in the git history.

This should only be necessary when memote is first used with existing model repositories.

By giving memote specific commit hashes, it will re-compute test results for those only. This can also be achieved by supplying a commit range.

memote.suite.cli.runner._setup_gh_repo(github_repository, github_username, note)[source]¶

memote.suite.cli.runner._setup_travis_ci(gh_repo_name, auth_token, repo_access_token)[source]¶

memote.suite.cli.runner.online(note, github_repository, github_username)[source]¶: Upload the repository to GitHub and enable testing on Travis CI.

Package Contents¶

Classes¶

ConfigFileProcessor Determine which files to look for and what sections.

class memote.suite.cli.ConfigFileProcessor[source]¶

Bases: click_configfile.ConfigFileReader

Determine which files to look for and what sections.

config_files = ['memote.ini', 'setup.cfg']¶

config_section_schemas¶

memote.suite.cli.LOGGER[source]¶

memote.suite.cli.CONTEXT_SETTINGS[source]¶

memote.suite.reporting¶

Subpackage for creating visually pleasing reports of test results.

There are three types of reports that we support:

1. Snapshot Report: A one-time report of a model giving a good insight into its current state. 2. History Report: A more elaborate report that makes use of the model development over time (aka git history). 3. Diff Report: A comparison report between two different versions of the same model or across different models (similar to a diff).

Submodules¶

memote.suite.reporting.config¶

Configure the layout and scoring of test reports.

Module Contents¶

Classes¶

ReportConfiguration Collect the metabolic model test suite results.

class memote.suite.reporting.config.ReportConfiguration(*args, **kwargs)[source]¶

Bases: dict

Collect the metabolic model test suite results.

classmethod load(cls, filename=None)[source]¶: Load a test report configuration.

merge(self, other)[source]¶: Merge a custom configuration.

memote.suite.reporting.diff¶

Compare two or more models with one another side-by-side.

Module Contents¶

Classes¶

DiffReport Render a report displaying the results of two or more models side-by-side.

class memote.suite.reporting.diff.DiffReport(diff_results, configuration, **kwargs)[source]¶

Bases: memote.suite.reporting.report.Report

Render a report displaying the results of two or more models side-by-side.

Attributes:	diff_results : python.Dictionary The dictionary structure of memote.MemoteResult objects. configuration : memote.MemoteConfiguration A memote configuration structure.

format_and_score_diff_data(self, diff_results)[source]¶: Reformat the api results to work with the front-end.

memote.suite.reporting.history¶

Render results into pretty HTML.

Module Contents¶

Classes¶

HistoryReport Render a rich report using the git repository history.

memote.suite.reporting.history.LOGGER[source]¶

class memote.suite.reporting.history.HistoryReport(history, configuration, **kwargs)[source]¶

Bases: memote.suite.reporting.report.Report

Render a rich report using the git repository history.

Attributes:	configuration : memote.MemoteConfiguration A memote configuration structure.

collect_history(self)[source]¶: Build the structure of results in terms of a commit history.

memote.suite.reporting.report¶

Provide an abstract report base class that sets the interface.

Module Contents¶

Classes¶

Report Determine the abstract report interface.

memote.suite.reporting.report.LOGGER[source]¶

class memote.suite.reporting.report.Report(result, configuration, **kwargs)[source]¶

Bases: object

Determine the abstract report interface.

Attributes:	result : memote.MemoteResult The dictionary structure of results. configuration : memote.MemoteConfiguration A memote configuration structure.

render_json(self, pretty=False)[source]¶

Render the report results as JSON.

Parameters:	pretty : bool, optional Whether to format the resulting JSON in a more legible way ( default False).

render_html(self)[source]¶: Render an HTML report.

get_configured_tests(self)[source]¶: Get tests explicitly configured.

determine_miscellaneous_tests(self)[source]¶

Identify tests not explicitly configured in test organization.

List them as an additional card called Misc, which is where they will now appear in the report.

compute_score(self)[source]¶: Calculate the overall test score using the configuration.

memote.suite.reporting.snapshot¶

Render a one-time model report.

Module Contents¶

Classes¶

SnapshotReport Render a one-time report from the given model results.

memote.suite.reporting.snapshot.LOGGER[source]¶

class memote.suite.reporting.snapshot.SnapshotReport(**kwargs)[source]¶

Bases: memote.suite.reporting.report.Report

Render a one-time report from the given model results.

Attributes:	result : memote.MemoteResult The dictionary structure of results. configuration : memote.MemoteConfiguration A memote configuration structure.

Package Contents¶

Classes¶

`ReportConfiguration`	Collect the metabolic model test suite results.
`Report`	Determine the abstract report interface.
`SnapshotReport`	Render a one-time report from the given model results.
`Report`	Determine the abstract report interface.
`HistoryReport`	Render a rich report using the git repository history.
`Report`	Determine the abstract report interface.
`DiffReport`	Render a report displaying the results of two or more models side-by-side.

class memote.suite.reporting.ReportConfiguration(*args, **kwargs)[source]¶

Bases: dict

Collect the metabolic model test suite results.

classmethod load(cls, filename=None)¶: Load a test report configuration.

merge(self, other)¶: Merge a custom configuration.

class memote.suite.reporting.Report(result, configuration, **kwargs)¶

Bases: object

Determine the abstract report interface.

Attributes:	result : memote.MemoteResult The dictionary structure of results. configuration : memote.MemoteConfiguration A memote configuration structure.

render_json(self, pretty=False)¶

Render the report results as JSON.

Parameters:	pretty : bool, optional Whether to format the resulting JSON in a more legible way ( default False).

render_html(self)¶: Render an HTML report.

get_configured_tests(self)¶: Get tests explicitly configured.

determine_miscellaneous_tests(self)¶

Identify tests not explicitly configured in test organization.

List them as an additional card called Misc, which is where they will now appear in the report.

compute_score(self)¶: Calculate the overall test score using the configuration.

memote.suite.reporting.LOGGER[source]¶

class memote.suite.reporting.SnapshotReport(**kwargs)[source]¶

Bases: memote.suite.reporting.report.Report

Render a one-time report from the given model results.

Attributes:	result : memote.MemoteResult The dictionary structure of results. configuration : memote.MemoteConfiguration A memote configuration structure.

class memote.suite.reporting.Report(result, configuration, **kwargs)

Bases: object

Determine the abstract report interface.

Attributes:	result : memote.MemoteResult The dictionary structure of results. configuration : memote.MemoteConfiguration A memote configuration structure.

render_json(self, pretty=False)

Render the report results as JSON.

Parameters:	pretty : bool, optional Whether to format the resulting JSON in a more legible way ( default False).

render_html(self): Render an HTML report.

get_configured_tests(self): Get tests explicitly configured.

determine_miscellaneous_tests(self)

Identify tests not explicitly configured in test organization.

List them as an additional card called Misc, which is where they will now appear in the report.

compute_score(self): Calculate the overall test score using the configuration.

memote.suite.reporting.LOGGER[source]

class memote.suite.reporting.HistoryReport(history, configuration, **kwargs)[source]¶

Bases: memote.suite.reporting.report.Report

Render a rich report using the git repository history.

Attributes:	configuration : memote.MemoteConfiguration A memote configuration structure.

collect_history(self)¶: Build the structure of results in terms of a commit history.

class memote.suite.reporting.Report(result, configuration, **kwargs)

Bases: object

Determine the abstract report interface.

Attributes:	result : memote.MemoteResult The dictionary structure of results. configuration : memote.MemoteConfiguration A memote configuration structure.

render_json(self, pretty=False)

Render the report results as JSON.

Parameters:	pretty : bool, optional Whether to format the resulting JSON in a more legible way ( default False).

render_html(self): Render an HTML report.

get_configured_tests(self): Get tests explicitly configured.

determine_miscellaneous_tests(self)

Identify tests not explicitly configured in test organization.

List them as an additional card called Misc, which is where they will now appear in the report.

compute_score(self): Calculate the overall test score using the configuration.

class memote.suite.reporting.DiffReport(diff_results, configuration, **kwargs)[source]¶

Bases: memote.suite.reporting.report.Report

Render a report displaying the results of two or more models side-by-side.

Attributes:	diff_results : python.Dictionary The dictionary structure of memote.MemoteResult objects. configuration : memote.MemoteConfiguration A memote configuration structure.

format_and_score_diff_data(self, diff_results)¶: Reformat the api results to work with the front-end.

memote.suite.results¶

Provide the memote result object and managers for various situations.

The MemoteResult represents the collective result of running the metabolic model test suite on a given model at a certain point in time.
The ResultManager and its subclasses knows how to store a MemoteResult in various data backends (file, SQL, NoSQL).
The ResultHistoryManager uses the different ResultManagers to iterate over and collect a model’s test result history.

Submodules¶

memote.suite.results.history_manager¶

Provide a history manager that integrates with a git repository.

Module Contents¶

Classes¶

HistoryManager Manage access to results in the commit history of a git repository.

class memote.suite.results.history_manager.HistoryManager(repository, manager, **kwargs)[source]¶

Bases: object

Manage access to results in the commit history of a git repository.

Attributes:	manager : memote.RepoResultManager The manager for accessing individual results. current : str The name of the currently active branch.

build_branch_structure(self, model, skip)[source]¶: Inspect and record the repo’s branches and their history.

iter_branches(self)[source]¶: Iterate over branch names and their commit histories.

iter_commits(self)[source]¶: Iterate over all commit hashes in the repository.

load_history(self, model, skip=('gh-pages', ))[source]¶

Load the entire results history into memory.

Could be a bad idea in a far future.

get_result(self, commit, default=None)[source]¶: Return an individual result from the history if it exists.

__contains__(self, commit)[source]¶: Test for the existence of a result for a commit.

memote.suite.results.models¶

Persist the memote test suite results in a database.

Module Contents¶

Classes¶

Result Model a git based result for storage in a database.

class memote.suite.results.models.Result[source]¶

Bases: Base

Model a git based result for storage in a database.

The class attributes correspond both to the columns in the database table and to instance attributes.

__tablename__ = results[source]¶

id[source]¶

hexsha[source]¶

author[source]¶

email[source]¶

authored_on[source]¶

memote_result[source]¶

memote.suite.results.repo_result_manager¶

Provide a memote result manager that integrates with a git repository.

Module Contents¶

Classes¶

RepoResultManager Manage storage of results to JSON files.

class memote.suite.results.repo_result_manager.RepoResultManager(repository, location, **kwargs)[source]¶

Bases: memote.suite.results.result_manager.ResultManager

Manage storage of results to JSON files.

Results are stored to and loaded from a specific location (directory) and enriched with git commit meta information.

record_git_info(self, commit=None)[source]¶

Record git meta information.

Parameters:	commit : str, optional Unique hexsha of the desired commit.
Returns:	GitInfo Git commit meta information.

get_filename(self, git_info)[source]¶

Create a filename from the storage directory and the commit hash.

Parameters:	git_info : GitInfo A named tuple with git meta information.
Returns:	str The path to the file where the result of the current commit is stored.

static add_git(meta, git_info)[source]¶: Enrich the result meta information with commit data.

store(self, result, commit=None, **kwargs)[source]¶

Store a result in a JSON file attaching git meta information.

Parameters:	result : memote.MemoteResult The dictionary structure of results. commit : str, optional Unique hexsha of the desired commit. kwargs Passed to parent function.

load(self, commit=None)[source]¶: Load a result from the storage directory.

memote.suite.results.result¶

Provide a collective access to a test suite result..

Module Contents¶

Classes¶

MemoteResult Collect the metabolic model test suite results.

class memote.suite.results.result.MemoteResult(*args, **kwargs)[source]¶

Bases: dict

Collect the metabolic model test suite results.

static add_environment_information(meta)[source]¶: Record environment information.

memote.suite.results.result_manager¶

Provide the memote result managers for various storage backends.

Module Contents¶

Classes¶

ResultManager Manage storage of results to JSON files.

class memote.suite.results.result_manager.ResultManager(**kwargs)[source]¶

Bases: object

Manage storage of results to JSON files.

store(self, result, filename, pretty=True)[source]¶

Write a result to the given file.

Parameters:	result : memote.MemoteResult The dictionary structure of results. filename : str or pathlib.Path Store results directly to the given filename. pretty : bool, optional Whether (default) or not to write JSON in a more legible format.

load(self, filename)[source]¶: Load a result from the given JSON file.

memote.suite.results.sql_result_manager¶

Provide a memote result manager that is git aware and uses a SQL database.

Module Contents¶

Classes¶

SQLResultManager Manage storage of results to a database.

class memote.suite.results.sql_result_manager.SQLResultManager(**kwargs)[source]¶

Bases: memote.suite.results.repo_result_manager.RepoResultManager

Manage storage of results to a database.

store(self, result, commit=None, **kwargs)[source]¶

Store a result in a JSON file attaching git meta information.

Parameters:	result : memote.MemoteResult The dictionary structure of results. commit : str, optional Unique hexsha of the desired commit. kwargs Passed to parent function.

load(self, commit=None)[source]¶: Load a result from the database.

Package Contents¶

Classes¶

`MemoteResult`	Collect the metabolic model test suite results.
`ResultManager`	Manage storage of results to JSON files.
`RepoResultManager`	Manage storage of results to JSON files.
`SQLResultManager`	Manage storage of results to a database.
`HistoryManager`	Manage access to results in the commit history of a git repository.

class memote.suite.results.MemoteResult(*args, **kwargs)[source]¶

Bases: dict

Collect the metabolic model test suite results.

static add_environment_information(meta)¶: Record environment information.

class memote.suite.results.ResultManager(**kwargs)[source]¶

Bases: object

Manage storage of results to JSON files.

store(self, result, filename, pretty=True)¶

Write a result to the given file.

Parameters:	result : memote.MemoteResult The dictionary structure of results. filename : str or pathlib.Path Store results directly to the given filename. pretty : bool, optional Whether (default) or not to write JSON in a more legible format.

load(self, filename)¶: Load a result from the given JSON file.

class memote.suite.results.RepoResultManager(repository, location, **kwargs)[source]¶

Bases: memote.suite.results.result_manager.ResultManager

Manage storage of results to JSON files.

Results are stored to and loaded from a specific location (directory) and enriched with git commit meta information.

record_git_info(self, commit=None)¶

Record git meta information.

Parameters:	commit : str, optional Unique hexsha of the desired commit.
Returns:	GitInfo Git commit meta information.

get_filename(self, git_info)¶

Create a filename from the storage directory and the commit hash.

Parameters:	git_info : GitInfo A named tuple with git meta information.
Returns:	str The path to the file where the result of the current commit is stored.

static add_git(meta, git_info)¶: Enrich the result meta information with commit data.

store(self, result, commit=None, **kwargs)¶

Store a result in a JSON file attaching git meta information.

Parameters:	result : memote.MemoteResult The dictionary structure of results. commit : str, optional Unique hexsha of the desired commit. kwargs Passed to parent function.

load(self, commit=None)¶: Load a result from the storage directory.

class memote.suite.results.SQLResultManager(**kwargs)[source]¶

Bases: memote.suite.results.repo_result_manager.RepoResultManager

Manage storage of results to a database.

store(self, result, commit=None, **kwargs)¶

Store a result in a JSON file attaching git meta information.

Parameters:	result : memote.MemoteResult The dictionary structure of results. commit : str, optional Unique hexsha of the desired commit. kwargs Passed to parent function.

load(self, commit=None)¶: Load a result from the database.

class memote.suite.results.HistoryManager(repository, manager, **kwargs)[source]¶

Bases: object

Manage access to results in the commit history of a git repository.

Attributes:	manager : memote.RepoResultManager The manager for accessing individual results. current : str The name of the currently active branch.

build_branch_structure(self, model, skip)¶: Inspect and record the repo’s branches and their history.

iter_branches(self)¶: Iterate over branch names and their commit histories.

iter_commits(self)¶: Iterate over all commit hashes in the repository.

load_history(self, model, skip=('gh-pages', ))¶

Load the entire results history into memory.

Could be a bad idea in a far future.

get_result(self, commit, default=None)¶: Return an individual result from the history if it exists.

__contains__(self, commit)¶: Test for the existence of a result for a commit.

memote.suite.templates¶

Provide templates and configuration files for memote reports.

Submodules¶

memote.suite.api¶

Programmatically interact with the memote test suite.

Module Contents¶

Functions¶

`validate_model`(path)	Validate a model structurally and optionally store results as JSON.
`test_model`(model, sbml_version=None, results=False, pytest_args=None, exclusive=None, skip=None, experimental=None, solver_timeout=10)	Test a model and optionally store results as JSON.
`snapshot_report`(result, config=None, html=True)	Generate a snapshot report from a result set and configuration.
`history_report`(history, config=None, html=True)	Test a model and save a history report.
`diff_report`(diff_results, config=None, html=True)	Generate a diff report from a result set and configuration.

memote.suite.api.validate_model(path)[source]¶

Validate a model structurally and optionally store results as JSON.

Parameters:	path Path to model file.
Returns:	tuple cobra.Model The metabolic model under investigation. tuple A tuple reporting on the SBML level, version, and FBC package version used (if any) in the SBML document. dict A simple dictionary containing a list of errors and warnings.

memote.suite.api.test_model(model, sbml_version=None, results=False, pytest_args=None, exclusive=None, skip=None, experimental=None, solver_timeout=10)[source]¶

Test a model and optionally store results as JSON.

Parameters:

model : cobra.Model: The metabolic model under investigation.
sbml_version: tuple, optional: A tuple reporting on the level, version, and FBC use of the SBML file.
results : bool, optional: Whether to return the results in addition to the return code.
pytest_args : list, optional: Additional arguments for the pytest suite.
exclusive : iterable, optional: Names of test cases or modules to run and exclude all others. Takes precedence over skip.
skip : iterable, optional: Names of test cases or modules to skip.
solver_timeout: int, optional: Timeout in seconds to set on the mathematical optimization solver (default 10).

Returns:

int: The return code of the pytest suite.
memote.Result, optional: A nested dictionary structure that contains the complete test results.

memote.suite.api.snapshot_report(result, config=None, html=True)[source]¶

Generate a snapshot report from a result set and configuration.

Parameters:	result : memote.MemoteResult Nested dictionary structure as returned from the test suite. config : dict, optional The final test report configuration (default None). html : bool, optional Whether to render the report as full HTML or JSON (default True).

memote.suite.api.history_report(history, config=None, html=True)[source]¶

Test a model and save a history report.

Parameters:	history : memote.HistoryManager The manager grants access to previous results. config : dict, optional The final test report configuration. html : bool, optional Whether to render the report as full HTML or JSON (default True).

memote.suite.api.diff_report(diff_results, config=None, html=True)[source]¶

Generate a diff report from a result set and configuration.

Parameters:	diff_results : iterable of memote.MemoteResult Nested dictionary structure as returned from the test suite. config : dict, optional The final test report configuration (default None). html : bool, optional Whether to render the report as full HTML or JSON (default True).

memote.suite.collect¶

Collect results for reporting model quality.

Module Contents¶

Classes¶

ResultCollectionPlugin Provide functionality for complex test result collection.

memote.suite.collect.LOGGER[source]¶

class memote.suite.collect.ResultCollectionPlugin(model, sbml_version=None, experimental_config=None, exclusive=None, skip=None, **kwargs)[source]¶

Bases: object

Provide functionality for complex test result collection.

The plugin exposes the fixture store which can be used in test functions to store values in a dictionary. The dictionary is namespaced to the module so within a module the same keys should not be re-used (unless intended).

_param[source]¶

pytest_generate_tests(self, metafunc)[source]¶: Parametrize marked functions at runtime.

pytest_runtest_call(self, item)[source]¶: Either run a test exclusively or skip it.

pytest_runtest_teardown(self, item)[source]¶: Collect the annotation from each test case and store it.

pytest_report_teststatus(self, report)[source]¶

Log pytest results for each test.

The categories are passed, failed, error, skipped and marked to fail.

Parameters:	report : TestReport A test report object from pytest with test case result.

model(self)[source]¶: Provide each test case with a pristine model.

sbml_version(self)[source]¶: Provide SBML level, version, and FBC use.

pytest_configure(self, config)[source]¶: Register custom markers at runtime.

Package Contents¶

memote.suite.TEST_DIRECTORY[source]¶

`memote.support`¶

Helper functions for the metabolic model test suite.

Subpackages¶

memote.support.data¶

Provide data files to the memote support functions.

Submodules¶

memote.support.annotation¶

Supporting functions for annotation checks performed on the model object.

Module Contents¶

Functions¶

`find_components_without_annotation`(model, components)	Find model components with empty annotation attributes.
`generate_component_annotation_overview`(elements, db)	Tabulate which MIRIAM databases the component’s annotation match.
`generate_component_annotation_miriam_match`(elements, component, db)	Tabulate which MIRIAM databases the element’s annotation match.
`generate_component_id_namespace_overview`(model, components)	Tabulate which MIRIAM databases the component’s identifier matches.

memote.support.annotation.LOGGER[source]¶

memote.support.annotation.GENE_PRODUCT_ANNOTATIONS[source]¶

memote.support.annotation.REACTION_ANNOTATIONS[source]¶

memote.support.annotation.METABOLITE_ANNOTATIONS[source]¶

memote.support.annotation.find_components_without_annotation(model, components)[source]¶

Find model components with empty annotation attributes.

Parameters:	model : cobra.Model A cobrapy metabolic model. components : {“metabolites”, “reactions”, “genes”} A string denoting cobra.Model components.
Returns:	list The components without any annotation.

memote.support.annotation.generate_component_annotation_overview(elements, db)[source]¶

Tabulate which MIRIAM databases the component’s annotation match.

Parameters:	elements : list Elements of a model, either metabolites, reactions, or genes. db : str One of the MIRIAM database identifiers.
Returns:	list The components that are not annotated with the specified MIRIAM database.

memote.support.annotation.generate_component_annotation_miriam_match(elements, component, db)[source]¶

Tabulate which MIRIAM databases the element’s annotation match.

If the relevant MIRIAM identifier is not in an element’s annotation it is ignored.

Parameters:	elements : list Elements of a model, either metabolites or reactions. component : {“metabolites”, “reactions”} A string denoting a type of `cobra.Model` component. db : str One of the MIRIAM database identifiers.
Returns:	list The components whose annotation does not match the pattern for the MIRIAM database.

memote.support.annotation.generate_component_id_namespace_overview(model, components)[source]¶

Tabulate which MIRIAM databases the component’s identifier matches.

Parameters:	model : cobra.Model A cobrapy metabolic model. components : {“metabolites”, “reactions”, “genes”} A string denoting cobra.Model components.
Returns:	pandas.DataFrame The index of the table is given by the component identifiers. Each column corresponds to one MIRIAM database and a Boolean entry determines whether the annotation matches.

memote.support.basic¶

Supporting functions for basic checks performed on the model object.

Module Contents¶

Functions¶

check_metabolites_formula_presence(model) Return the list of model metabolites that have no associated formula.

memote.support.basic.check_metabolites_formula_presence(model)[source]¶: Return the list of model metabolites that have no associated formula.

memote.support.biomass¶

Supporting functions for biomass consistency checks.

Module Contents¶

Functions¶

`sum_biomass_weight`(reaction)	Compute the sum of all reaction compounds.
`find_biomass_precursors`(model, reaction)	Return a list of all biomass precursors excluding ATP and H2O.
`find_blocked_biomass_precursors`(reaction, model)	Return a list of all biomass precursors that cannot be produced.

memote.support.biomass.sum_biomass_weight(reaction)[source]¶

Compute the sum of all reaction compounds.

This function expects all metabolites of the biomass reaction to have formula information assigned.

Parameters:	reaction : cobra.core.reaction.Reaction The biomass reaction of the model under investigation.
Returns:	float The molecular weight of the biomass reaction in units of g/mmol.

memote.support.biomass.find_biomass_precursors(model, reaction)[source]¶

Return a list of all biomass precursors excluding ATP and H2O.

Parameters:	reaction : cobra.core.reaction.Reaction The biomass reaction of the model under investigation. model : cobra.Model The metabolic model under investigation.
Returns:	list Metabolite objects that are reactants of the biomass reaction excluding ATP and H2O.

memote.support.biomass.find_blocked_biomass_precursors(reaction, model)[source]¶

Return a list of all biomass precursors that cannot be produced.

Parameters:	reaction : cobra.core.reaction.Reaction The biomass reaction of the model under investigation. model : cobra.Model The metabolic model under investigation.
Returns:	list Metabolite objects that are reactants of the biomass reaction excluding ATP and H2O that cannot be produced by flux balance analysis.

memote.support.consistency¶

Supporting functions for stoichiometric consistency checks.

Module Contents¶

Functions¶

`check_stoichiometric_consistency`(model)	Verify the consistency of the model’s stoichiometry.
`find_unconserved_metabolites`(model)	Detect unconserved metabolites.
`find_inconsistent_min_stoichiometry`(model, atol=1e-13, max_mets_computed=10)	Detect inconsistent minimal net stoichiometries.
`find_elementary_leakage_modes`(model, atol=1e-13)	Detect elementary leakage modes.
`detect_energy_generating_cycles`(model, metabolite_id)	Detect erroneous energy-generating cycles for a a single metabolite.
`find_mass_unbalanced_reactions`(reactions)	Find metabolic reactions that are not mass balanced.
`find_charge_unbalanced_reactions`(reactions)	Find metabolic reactions that are not charge balanced.
`find_stoichiometrically_balanced_cycles`(model)	Find metabolic reactions in stoichiometrically balanced cycles (SBCs).
`find_orphans`(model)	Return metabolites that are only consumed in reactions.
`find_deadends`(model)	Return metabolites that are only produced in reactions.
`find_disconnected`(model)	Return metabolites that are not in any of the reactions.
`_init_worker`(model, variable_name, coefficient)	Initialize a global model object for multiprocessing.
`_solve_metabolite_exchange`(metabolite_id)	Solve for a metabolite’s exchange flux.
`find_blocked_metabolites`(model, coefficient, processes=None)	Return metabolite identifiers that cannot be produced or consumed.
`find_metabolites_not_produced_with_open_bounds`(model, processes=None)	Return metabolite identifiers that cannot be produced with open exchanges.
`find_metabolites_not_consumed_with_open_bounds`(model, processes=None)	Return metabolite identifiers that cannot be consumed with open exchanges.
`find_reactions_with_unbounded_flux_default_condition`(model)	Return list of reactions whose flux is unbounded in the default condition.

memote.support.consistency.LOGGER[source]¶

memote.support.consistency.ENERGY_COUPLES[source]¶

memote.support.consistency.TOLERANCE_THRESHOLD = 1e-07[source]¶

memote.support.consistency.cobra_configuration[source]¶

memote.support.consistency.check_stoichiometric_consistency(model)[source]¶

Verify the consistency of the model’s stoichiometry.

Parameters:	model : cobra.Model The metabolic model under investigation.

Notes

See [1] section 3.1 for a complete description of the algorithm.

[1]	Gevorgyan, A., M. G Poolman, and D. A Fell. “Detection of Stoichiometric Inconsistencies in Biomolecular Models.” Bioinformatics 24, no. 19 (2008): 2245.

memote.support.consistency.find_unconserved_metabolites(model)[source]¶

Detect unconserved metabolites.

Parameters:	model : cobra.Model The metabolic model under investigation.

Notes

See [1] section 3.2 for a complete description of the algorithm.

[1]	Gevorgyan, A., M. G Poolman, and D. A Fell. “Detection of Stoichiometric Inconsistencies in Biomolecular Models.” Bioinformatics 24, no. 19 (2008): 2245.

memote.support.consistency.find_inconsistent_min_stoichiometry(model, atol=1e-13, max_mets_computed=10)[source]¶

Detect inconsistent minimal net stoichiometries.

Parameters:	model : cobra.Model The metabolic model under investigation. atol : float, optional Values below the absolute tolerance are treated as zero. Expected to be very small but larger than zero. max_mets_computed: int, optional To avoid computing for too long, a soft cap is added to the number of computed unconserved metabolites (trivial cases are ignored).

Notes

See [1] section 3.3 for a complete description of the algorithm.

References

[1]	(1, 2) Gevorgyan, A., M. G Poolman, and D. A Fell. “Detection of Stoichiometric Inconsistencies in Biomolecular Models.” Bioinformatics 24, no. 19 (2008): 2245.

memote.support.consistency.find_elementary_leakage_modes(model, atol=1e-13)[source]¶

Detect elementary leakage modes.

Parameters:	model : cobra.Model The metabolic model under investigation. atol : float, optional Values below the absolute tolerance are treated as zero. Expected to be very small but larger than zero.

Notes

See [1] section 3.4 for a complete description of the algorithm.

References

[1]	(1, 2) Gevorgyan, A., M. G Poolman, and D. A Fell. “Detection of Stoichiometric Inconsistencies in Biomolecular Models.” Bioinformatics 24, no. 19 (2008): 2245.

memote.support.consistency.detect_energy_generating_cycles(model, metabolite_id)[source]¶

Detect erroneous energy-generating cycles for a a single metabolite.

The function will first build a dissipation reaction corresponding to the input metabolite. This reaction is then set as the objective for optimization, after closing all exchanges. If the reaction was able to carry flux, an erroneous energy-generating cycle must be present. In this case a list of reactions with a flux greater than zero is returned. Otherwise, the function returns False.

Parameters:	model : cobra.Model The metabolic model under investigation. metabolite_id : str The identifier of an energy metabolite.

Notes

“[…] energy generating cycles (EGC) […] charge energy metabolites without a source of energy. […] To efficiently identify the existence of diverse EGCs, we first add a dissipation reaction to the metabolic network for each metabolite used to transmit cellular energy; e.g., for ATP, the irreversible reaction ATP + H2O → ADP + P + H+ is added. These dissipation reactions close any existing energy-generating cycles, thereby converting them to type-III pathways. Fluxes through any of the dissipation reactions at steady state indicate the generation of energy through the metabolic network. Second, all uptake reactions are constrained to zero. The sum of the fluxes through the energy dissipation reactions is now maximized using FBA. For a model without EGCs, these reactions cannot carry any flux without the uptake of nutrients. [1].”

References

[1]	(1, 2) Fritzemeier, C. J., Hartleb, D., Szappanos, B., Papp, B., & Lercher, M. J. (2017). Erroneous energy-generating cycles in published genome scale metabolic networks: Identification and removal. PLoS Computational Biology, 13(4), 1–14. http://doi.org/10.1371/journal.pcbi.1005494

memote.support.consistency.find_mass_unbalanced_reactions(reactions)[source]¶

Find metabolic reactions that are not mass balanced.

Parameters:	reactions : iterable An iterable of cobra.Reaction’s.

memote.support.consistency.find_charge_unbalanced_reactions(reactions)[source]¶

Find metabolic reactions that are not charge balanced.

Parameters:	reactions : iterable An iterable of cobra.Reaction’s.

memote.support.consistency.find_stoichiometrically_balanced_cycles(model)[source]¶

Find metabolic reactions in stoichiometrically balanced cycles (SBCs).

Identify forward and reverse cycles by closing all exchanges and using FVA.

Parameters:	model : cobra.Model The metabolic model under investigation.

Notes

“SBCs are artifacts of metabolic reconstructions due to insufficient constraints (e.g., thermodynamic constraints and regulatory constraints) [1].” They are defined by internal reactions that carry flux in spite of closed exchange reactions.

References

[1]	(1, 2) Thiele, I., & Palsson, B. Ø. (2010, January). A protocol for generating a high-quality genome-scale metabolic reconstruction. Nature protocols. Nature Publishing Group. http://doi.org/10.1038/nprot.2009.203

memote.support.consistency.find_orphans(model)[source]¶

Return metabolites that are only consumed in reactions.

Metabolites that are involved in an exchange reaction are never considered to be orphaned.

Parameters:	model : cobra.Model The metabolic model under investigation.

memote.support.consistency.find_deadends(model)[source]¶

Return metabolites that are only produced in reactions.

Metabolites that are involved in an exchange reaction are never considered to be dead ends.

Parameters:	model : cobra.Model The metabolic model under investigation.

memote.support.consistency.find_disconnected(model)[source]¶

Return metabolites that are not in any of the reactions.

Parameters:	model : cobra.Model The metabolic model under investigation.

memote.support.consistency._init_worker(model, variable_name, coefficient)[source]¶

Initialize a global model object for multiprocessing.

Parameters:	model : cobra.Model The metabolic model under investigation. variable_name: str The name of the variable representing the metabolite exchange. coefficient: int The value of the metabolite’s stoichiometric coefficient: -1 to test if the model can produce the metabolite and 1 to test if it can be consumed.

memote.support.consistency._solve_metabolite_exchange(metabolite_id)[source]¶

Solve for a metabolite’s exchange flux.

By adding the exchange variable to the metabolite constraint, the solution tests whether the metabolic model produce or consume the metabolite.

Parameters:	metabolite_id: str The exchange will be added to this metabolite as a linear coefficient.
Returns:	float The numeric value of the solution of the flux-balance problem; NaN if infeasible. str The identifier of the considered metabolite.

Notes

The model, exchange variable, and stoichiometric coefficient are globals.

memote.support.consistency.find_blocked_metabolites(model, coefficient, processes=None)[source]¶

Return metabolite identifiers that cannot be produced or consumed.

Parameters:	model : cobra.Model The metabolic model under investigation. coefficient: int Test if production is possible with -1 and consumption with 1. processes: int, optional Number of processes to be used (the default is taken from cobra.Configuration.processes).
Returns:	list The identifiers of blocked metabolites.

memote.support.consistency.find_metabolites_not_produced_with_open_bounds(model, processes=None)[source]¶

Return metabolite identifiers that cannot be produced with open exchanges.

A perfect model should be able to produce each and every metabolite when all medium components are available.

Parameters:	model : cobra.Model The metabolic model under investigation. processes: int, optional Number of processes to be used (the default is taken from cobra.Configuration.processes).
Returns:	list The metabolite identifiers that could not be produced.

memote.support.consistency.find_metabolites_not_consumed_with_open_bounds(model, processes=None)[source]¶

Return metabolite identifiers that cannot be consumed with open exchanges.

When all metabolites can be secreted, it should be possible for each and every metabolite to be consumed in some form.

Parameters:	model : cobra.Model The metabolic model under investigation. processes: int, optional Number of processes to be used (the default is taken from cobra.Configuration.processes).
Returns:	list The metabolite identifiers that could not be consumed.

memote.support.consistency.find_reactions_with_unbounded_flux_default_condition(model)[source]¶

Return list of reactions whose flux is unbounded in the default condition.

Parameters:	model : cobra.Model The metabolic model under investigation.
Returns:	tuple list A list of reactions that in default modeling conditions are able to carry flux as high/low as the systems maximal and minimal bounds. float The fraction of the amount of unbounded reactions to the amount of non-blocked reactions. list A list of reactions that in default modeling conditions are not able to carry flux at all.

memote.support.consistency_helpers¶

Helper functions for stoichiometric consistency checks.

Module Contents¶

Functions¶

`stoichiometry_matrix`(metabolites, reactions)	Return the stoichiometry matrix representation of a set of reactions.
`nullspace`(matrix, atol=1e-13, rtol=0.0)	Compute an approximate basis for the null space (kernel) of a matrix.

memote.support.consistency_helpers.stoichiometry_matrix(metabolites, reactions)[source]¶

Return the stoichiometry matrix representation of a set of reactions.

The reactions and metabolites order is respected. All metabolites are expected to be contained and complete in terms of the reactions.

Parameters:	reactions : iterable A somehow ordered list of unique reactions. metabolites : iterable A somehow ordered list of unique metabolites.
Returns:	numpy.array The 2D array that represents the stoichiometry matrix. dict A dictionary mapping metabolites to row indexes. dict A dictionary mapping reactions to column indexes.

memote.support.consistency_helpers.nullspace(matrix, atol=1e-13, rtol=0.0)[source]¶

Compute an approximate basis for the null space (kernel) of a matrix.

The algorithm used by this function is based on the singular value decomposition of the given matrix.

Parameters:

matrix : ndarray: The matrix should be at most 2-D. A 1-D array with length k will be treated as a 2-D with shape (1, k)
atol : float: The absolute tolerance for a zero singular value. Singular values smaller than atol are considered to be zero.
rtol : float: The relative tolerance for a zero singular value. Singular values less than the relative tolerance times the largest singular value are considered to be zero.

Returns:

ndarray: If matrix is an array with shape (m, k), then the returned nullspace will be an array with shape (k, n), where n is the estimated dimension of the nullspace.

Notes

If both atol and rtol are positive, the combined tolerance is the maximum of the two; that is:

tol = max(atol, rtol * smax)

Singular values smaller than tol are considered to be zero.

References

Adapted from: https://scipy.github.io/old-wiki/pages/Cookbook/RankNullspace.html

memote.support.essentiality¶

Supporting functions for stoichiometric consistency checks.

Module Contents¶

Functions¶

confusion_matrix(predicted_essential, expected_essential, predicted_nonessential, expected_nonessential) Compute a representation of the confusion matrix.

memote.support.essentiality.LOGGER[source]¶

memote.support.essentiality.confusion_matrix(predicted_essential, expected_essential, predicted_nonessential, expected_nonessential)[source]¶

Compute a representation of the confusion matrix.

Parameters:	predicted_essential : set expected_essential : set predicted_nonessential : set expected_nonessential : set
Returns:	dict Confusion matrix as different keys of a dictionary. The abbreviated keys correspond to the ones used in [1].

References

[1]	(1, 2) Wikipedia entry for the Confusion matrix

memote.support.gpr_helpers¶

Helper classes and functions for analyzing GPR associations.

Module Contents¶

Functions¶

find_top_level_complex(gpr) Find unique elements of both branches of the top level logical AND.

memote.support.gpr_helpers.find_top_level_complex(gpr)[source]¶

Find unique elements of both branches of the top level logical AND.

Parameters:	gpr : str The gene-protein-reaction association as a string.
Returns:	int The size of the symmetric difference between the set of elements to the left of the top level logical AND and the right set.

memote.support.helpers¶

Helper functions that are used all over the memote package.

Module Contents¶

Functions¶

`find_transported_elements`(rxn)	Return a dictionary showing the amount of transported elements of a rxn.
`find_transport_reactions`(model)	Return a list of all transport reactions.
`is_transport_reaction_formulae`(rxn)	Return boolean if a reaction is a transport reaction (from formulae).
`is_transport_reaction_annotations`(rxn)	Return boolean if a reaction is a transport reaction (from annotations).
`find_converting_reactions`(model, pair)	Find all reactions which convert a given metabolite pair.
`filter_sbo_term`(component, sbo_term)	Return true if the component is annotated with the given SBO term.
`filter_match_name`(component, buzzwords)	Return whether the component’s name matches a biomass description.
`filter_identifier`(component, buzzwords)	Return whether the component’s identifier contains a biomass description.
`find_biomass_reaction`(model)	Return a list of the biomass reaction(s) of the model.
`find_demand_reactions`(model)	Return a list of demand reactions.
`find_sink_reactions`(model)	Return a list of sink reactions.
`find_exchange_rxns`(model)	Return a list of exchange reactions.
`find_interchange_biomass_reactions`(model, biomass=None)	Return the set of all transport, boundary, and biomass reactions.
`run_fba`(model, rxn_id, direction=’max’, single_value=True)	Return the solution of an FBA to a set objective function.
`get_biomass_flux`(model: cobra.Model, rxn_id: str) → float	Compute the maximal objective value.
`close_boundaries_sensibly`(model)	Return a cobra model with all boundaries closed and changed constraints.
`open_exchanges`(model)	Open all exchange reactions.
`open_boundaries`(model)	Open all boundary reactions.
`metabolites_per_compartment`(model, compartment_id)	Identify all metabolites that belong to a given compartment.
`largest_compartment_id_met`(model)	Return the ID of the compartment with the most metabolites.
`find_compartment_id_in_model`(model, compartment_id)	Identify a model compartment by looking up names in COMPARTMENT_SHORTLIST.
`find_met_in_model`(model, mnx_id, compartment_id=None)	Return specific metabolites by looking up IDs in METANETX_SHORTLIST.
`find_objective_function`(model)	Return reactions that are part of the objective function.
`find_bounds`(model)	Return the median upper and lower bound of the metabolic model.

memote.support.helpers.LOGGER[source]¶

memote.support.helpers.TRANSPORT_RXN_SBO_TERMS = ['SBO:0000185', 'SBO:0000588', 'SBO:0000587', 'SBO:0000655', 'SBO:0000654', 'SBO:0000660', 'SBO:0000659', 'SBO:0000657', 'SBO:0000658'][source]¶

memote.support.helpers.METANETX_SHORTLIST[source]¶

memote.support.helpers.COMPARTMENT_SHORTLIST[source]¶

memote.support.helpers.find_transported_elements(rxn)[source]¶

Return a dictionary showing the amount of transported elements of a rxn.

Collects the elements for each metabolite participating in a reaction, multiplies the amount by the metabolite’s stoichiometry in the reaction and bins the result according to the compartment that metabolite is in. This produces a dictionary of dictionaries such as this {'p': {'C': -1, 'H': -4}, c: {'C': 1, 'H': 4}} which shows the transported entities. This dictionary is then simplified to only include the non-zero elements of one single compartment i.e. showing the precise elements that are transported.

Parameters:	rxn : cobra.Reaction Any cobra.Reaction containing metabolites.

memote.support.helpers.find_transport_reactions(model)[source]¶

Return a list of all transport reactions.

Parameters:	model : cobra.Model The metabolic model under investigation.

Notes

A transport reaction is defined as follows: 1. It contains metabolites from at least 2 compartments and 2. at least 1 metabolite undergoes no chemical reaction, i.e., the formula and/or annotation stays the same on both sides of the equation.

A notable exception is transport via PTS, which also contains the following restriction: 3. The transported metabolite(s) are transported into a compartment through the exchange of a phosphate group.

An example of transport via PTS would be pep(c) + glucose(e) -> glucose-6-phosphate(c) + pyr(c)

Reactions similar to transport via PTS (referred to as “modified transport reactions”) follow a similar pattern: A(x) + B-R(y) -> A-R(y) + B(y)

Such modified transport reactions can be detected, but only when a formula field exists for all metabolites in a particular reaction. If this is not the case, transport reactions are identified through annotations, which cannot detect modified transport reactions.

memote.support.helpers.is_transport_reaction_formulae(rxn)[source]¶

Return boolean if a reaction is a transport reaction (from formulae).

Parameters:	rxn: cobra.Reaction The metabolic reaction under investigation.

memote.support.helpers.is_transport_reaction_annotations(rxn)[source]¶

Return boolean if a reaction is a transport reaction (from annotations).

Parameters:	rxn: cobra.Reaction The metabolic reaction under investigation.

memote.support.helpers.find_converting_reactions(model, pair)[source]¶

Find all reactions which convert a given metabolite pair.

Parameters:	model : cobra.Model The metabolic model under investigation. pair: tuple or list A pair of metabolite identifiers without compartment suffix.
Returns:	frozenset The set of reactions that have one of the pair on their left-hand side and the other on the right-hand side.

memote.support.helpers.filter_sbo_term(component, sbo_term)[source]¶

Return true if the component is annotated with the given SBO term.

Parameters:	component : cobra.Reaction or cobra.Metabolite Either a reaction or a metabolite instance. sbo_term : str The term for either biomass production or biomass.

memote.support.helpers.filter_match_name(component, buzzwords)[source]¶

Return whether the component’s name matches a biomass description.

Parameters:	component : cobra.Reaction or cobra.Metabolite Either a reaction or a metabolite instance. buzzwords : collection of regex patterns One or more regular expression patterns to match against the name of the component.
Returns:	bool True if there was any match at all.

Notes

Regex patterns are necessary here to prevent, for example, ‘non-growth’ from matching.

memote.support.helpers.filter_identifier(component, buzzwords)[source]¶

Return whether the component’s identifier contains a biomass description.

Parameters:	component : cobra.Reaction or cobra.Metabolite Either a reaction or a metabolite instance. buzzwords : iterable of str One or more buzzwords that the identifier should contain.
Returns:	bool True if there was any match at all.

Notes

We check substring presence here because identifiers are often prefixed with M_ or R_.

memote.support.helpers.find_biomass_reaction(model)[source]¶

Return a list of the biomass reaction(s) of the model.

Identifiy possible biomass reactions using multiple steps: 1. Look for candidate reactions that include the SBO term SBO:0000629 for biomass production, 2. the ‘buzzwords’ biomass, growth, and bof in reaction names and identifiers, 3. reactions that involve a metabolite with the SBO term SBO:0000649 for biomass, 4. or reactions that involve a metabolite whose name or identifier contains the ‘buzzword’ biomass. Return identified reactions excluding any boundary reactions.

Parameters:	model : cobra.Model The metabolic model under investigation.
Returns:	list Identified biomass reactions (if any).

memote.support.helpers.find_demand_reactions(model)[source]¶

Return a list of demand reactions.

Parameters:	model : cobra.Model The metabolic model under investigation.

Notes

[1] defines demand reactions as: – ‘unbalanced network reactions that allow the accumulation of a compound’ – reactions that are chiefly added during the gap-filling process – as a means of dealing with ‘compounds that are known to be produced by the organism [..] (i) for which no information is available about their fractional distribution to the biomass or (ii) which may only be produced in some environmental conditions – reactions with a formula such as: ‘met_c -> ‘

Demand reactions differ from exchange reactions in that the metabolites are not removed from the extracellular environment, but from any of the organism’s compartments.

References

[1]	Thiele, I., & Palsson, B. Ø. (2010, January). A protocol for generating a high-quality genome-scale metabolic reconstruction. Nature protocols. Nature Publishing Group. http://doi.org/10.1038/nprot.2009.203

memote.support.helpers.find_sink_reactions(model)[source]¶

Return a list of sink reactions.

Parameters:	model : cobra.Model The metabolic model under investigation.

Notes

[1] defines sink reactions as: – ‘similar to demand reactions’ but reversible, thus able to supply the model with metabolites – reactions that are chiefly added during the gap-filling process – as a means of dealing with ‘compounds that are produced by nonmetabolic cellular processes but that need to be metabolized’ – reactions with a formula such as: ‘met_c <-> ‘

Sink reactions differ from exchange reactions in that the metabolites are not removed from the extracellular environment, but from any of the organism’s compartments.

References

[1]	Thiele, I., & Palsson, B. Ø. (2010, January). A protocol for generating a high-quality genome-scale metabolic reconstruction. Nature protocols. Nature Publishing Group. http://doi.org/10.1038/nprot.2009.203

memote.support.helpers.find_exchange_rxns(model)[source]¶

Return a list of exchange reactions.

Parameters:	model : cobra.Model The metabolic model under investigation.

Notes

[1] defines exchange reactions as: – reactions that ‘define the extracellular environment’ – ‘unbalanced, extra-organism reactions that represent the supply to or removal of metabolites from the extra-organism “space”’ – reactions with a formula such as: ‘met_e -> ‘ or ‘ -> met_e’ or ‘met_e <=> ‘

Exchange reactions differ from demand reactions in that the metabolites are removed from or added to the extracellular environment only. With this the uptake or secretion of a metabolite is modeled, respectively.

References

[1]	Thiele, I., & Palsson, B. Ø. (2010, January). A protocol for generating a high-quality genome-scale metabolic reconstruction. Nature protocols. Nature Publishing Group. http://doi.org/10.1038/nprot.2009.203

memote.support.helpers.find_interchange_biomass_reactions(model, biomass=None)[source]¶

Return the set of all transport, boundary, and biomass reactions.

These reactions are either pseudo-reactions, or incorporated to allow metabolites to pass between compartments. Some tests focus on purely metabolic reactions and hence exclude this set.

Parameters:	model : cobra.Model The metabolic model under investigation. biomass : list or cobra.Reaction, optional A list of cobrapy biomass reactions.

memote.support.helpers.run_fba(model, rxn_id, direction='max', single_value=True)[source]¶

Return the solution of an FBA to a set objective function.

Parameters:

model : cobra.Model: The metabolic model under investigation.
rxn_id : string: A string containing the reaction ID of the desired FBA objective.
direction: string: A string containing either “max” or “min” to specify the direction of the desired FBA objective function.
single_value: boolean: Indicates whether the results for all reactions are gathered from the solver, or only the result for the objective value.

Returns:

cobra.solution: The cobra solution object for the corresponding FBA problem.

memote.support.helpers.get_biomass_flux(model: cobra.Model, rxn_id: str) → float[source]¶

Compute the maximal objective value.

Parameters:	model : cobra.Model The metabolic model under investigation. rxn_id : string A string containing the reaction ID of the desired FBA objective.
Returns:	float The objective value which takes infeasibility and solver tolerances into account.

memote.support.helpers.close_boundaries_sensibly(model)[source]¶

Return a cobra model with all boundaries closed and changed constraints.

In the returned model previously fixed reactions are no longer constrained as such. Instead reactions are constrained according to their reversibility. This is to prevent the FBA from becoming infeasible when trying to solve a model with closed exchanges and one fixed reaction.

Parameters:	model : cobra.Model The metabolic model under investigation.
Returns:	cobra.Model A cobra model with all boundary reactions closed and the constraints of each reaction set according to their reversibility.

memote.support.helpers.open_exchanges(model)[source]¶

Open all exchange reactions.

Parameters:	model : cobra.Model The metabolic model under investigation.

memote.support.helpers.open_boundaries(model)[source]¶

Open all boundary reactions.

Parameters:	model : cobra.Model The metabolic model under investigation.

memote.support.helpers.metabolites_per_compartment(model, compartment_id)[source]¶

Identify all metabolites that belong to a given compartment.

Parameters:	model : cobra.Model The metabolic model under investigation. compartment_id : string Model specific compartment identifier.
Returns:	list List of metabolites belonging to a given compartment.

memote.support.helpers.largest_compartment_id_met(model)[source]¶

Return the ID of the compartment with the most metabolites.

Parameters:	model : cobra.Model The metabolic model under investigation.
Returns:	string Compartment ID of the compartment with the most metabolites.

memote.support.helpers.find_compartment_id_in_model(model, compartment_id)[source]¶

Identify a model compartment by looking up names in COMPARTMENT_SHORTLIST.

Parameters:	model : cobra.Model The metabolic model under investigation. compartment_id : string Memote internal compartment identifier used to access compartment name shortlist to look up potential compartment names.
Returns:	string Compartment identifier in the model corresponding to compartment_id.

memote.support.helpers.find_met_in_model(model, mnx_id, compartment_id=None)[source]¶

Return specific metabolites by looking up IDs in METANETX_SHORTLIST.

Parameters:	model : cobra.Model The metabolic model under investigation. mnx_id : string Memote internal MetaNetX metabolite identifier used to map between cross-references in the METANETX_SHORTLIST. compartment_id : string, optional ID of the specific compartment where the metabolites should be found. Defaults to returning matching metabolites from all compartments.
Returns:	list cobra.Metabolite(s) matching the mnx_id.

memote.support.helpers.find_objective_function(model)[source]¶

Return reactions that are part of the objective function.

Parameters:	model : cobra.Model The metabolic model under investigation.

memote.support.helpers.find_bounds(model)[source]¶

Return the median upper and lower bound of the metabolic model.

Bounds can vary from model to model. Cobrapy defaults to (-1000, 1000) but this may not be the case for merged or autogenerated models. In these cases, this function is used to iterate over all the bounds of all the reactions and find the median bound values in the model, which are then used as the ‘most common’ bounds.

Parameters:	model : cobra.Model The metabolic model under investigation.

memote.support.matrix¶

Supporting functions checking the matrix condition of the model object.

Module Contents¶

Functions¶

`absolute_extreme_coefficient_ratio`(model)	Return the maximum and minimum absolute, non-zero coefficients.
`number_independent_conservation_relations`(model)	Return the number of conserved metabolite pools.
`matrix_rank`(model)	Return the rank of the model’s stoichiometric matrix.
`degrees_of_freedom`(model)	Return the degrees of freedom, i.e., number of “free variables”.

memote.support.matrix.LOGGER[source]¶

memote.support.matrix.absolute_extreme_coefficient_ratio(model)[source]¶

Return the maximum and minimum absolute, non-zero coefficients.

Parameters:	model : cobra.Model The metabolic model under investigation.

memote.support.matrix.number_independent_conservation_relations(model)[source]¶

Return the number of conserved metabolite pools.

This number is given by the left null space of the stoichiometric matrix.

Parameters:	model : cobra.Model The metabolic model under investigation.

memote.support.matrix.matrix_rank(model)[source]¶

Return the rank of the model’s stoichiometric matrix.

Parameters:	model : cobra.Model The metabolic model under investigation.

memote.support.matrix.degrees_of_freedom(model)[source]¶

Return the degrees of freedom, i.e., number of “free variables”.

Parameters:	model : cobra.Model The metabolic model under investigation.

Notes

This specifically refers to the dimensionality of the (right) null space of the stoichiometric matrix, as dim(Null(S)) corresponds directly to the number of free variables in the system [1]. The formula used calculates this using the rank-nullity theorem [2].

References

[1]	(1, 2) Fukuda, K. & Terlaky, T. Criss-cross methods: A fresh view on pivot algorithms. Mathematical Programming 79, 369-395 (1997).

[2]	(1, 2) Alama, J. The Rank+Nullity Theorem. Formalized Mathematics 15, (2007).

memote.support.sbo¶

Supporting functions for sbo checks performed on the model object.

Module Contents¶

Functions¶

`find_components_without_sbo_terms`(model, components)	Find model components that are not annotated with any SBO terms.
`check_component_for_specific_sbo_term`(items, term)	Identify model components that lack a specific SBO term(s).

memote.support.sbo.LOGGER[source]¶

memote.support.sbo.find_components_without_sbo_terms(model, components)[source]¶

Find model components that are not annotated with any SBO terms.

Parameters:	model : cobra.Model The metabolic model under investigation. components : {“metabolites”, “reactions”, “genes”} A string denoting cobra.Model components.
Returns:	list The components without any SBO term annotation.

memote.support.sbo.check_component_for_specific_sbo_term(items, term)[source]¶

Identify model components that lack a specific SBO term(s).

Parameters:	items : list A list of model components i.e. reactions to be checked for a specific SBO term. term : str or list of str A string denoting a valid SBO term matching the regex ‘^SBO:d{7}$’ or a list containing such string elements.
Returns:	list The components without any or that specific SBO term annotation.

memote.support.thermodynamics¶

Supporting functions for checks requiring the eQuilibrator API.

Module Contents¶

Functions¶

`get_smallest_compound_id`(compounds_identifiers)	Return the smallest KEGG compound identifier from a list.
`map_metabolite2kegg`(metabolite)	Return a KEGG compound identifier for the metabolite if it exists.
`translate_reaction`(reaction, metabolite_mapping)	Return a mapping from KEGG compound identifiers to coefficients.
`find_thermodynamic_reversibility_index`(reactions)	Return the reversibility index of the given reactions.

memote.support.thermodynamics.compound_matcher[source]¶

memote.support.thermodynamics.logger[source]¶

memote.support.thermodynamics.get_smallest_compound_id(compounds_identifiers)[source]¶

Return the smallest KEGG compound identifier from a list.

KEGG identifiers may map to compounds, drugs or glycans prefixed respectively with “C”, “D”, and “G” followed by at least 5 digits. We choose the lowest KEGG identifier with the assumption that several identifiers are due to chirality and that the lower one represents the more common form.

Parameters:	compounds_identifiers : list A list of mixed KEGG identifiers.
Returns:	str The KEGG compound identifier with the smallest number.
Raises:	ValueError When compound_identifiers contains no KEGG compound identifiers.

memote.support.thermodynamics.map_metabolite2kegg(metabolite)[source]¶

Return a KEGG compound identifier for the metabolite if it exists.

First see if there is an unambiguous mapping to a single KEGG compound ID provided with the model. If not, check if there is any KEGG compound ID in a list of mappings. KEGG IDs may map to compounds, drugs and glycans. KEGG compound IDs are sorted so we keep the lowest that is there. If none of this works try mapping to KEGG via the CompoundMatcher by the name of the metabolite. If the metabolite cannot be mapped at all we simply map it back to its own ID.

Parameters:	metabolite : cobra.Metabolite The metabolite to be mapped to its KEGG compound identifier.
Returns:	None If the metabolite could not be mapped. str The smallest KEGG compound identifier that was found.

memote.support.thermodynamics.translate_reaction(reaction, metabolite_mapping)[source]¶

Return a mapping from KEGG compound identifiers to coefficients.

Parameters:	reaction : cobra.Reaction The reaction whose metabolites are to be translated. metabolite_mapping : dict An existing mapping from cobra.Metabolite to KEGG compound identifier that may already contain the metabolites in question or will have to be extended.
Returns:	dict The stoichiometry of the reaction given as a mapping from metabolite KEGG identifier to coefficient.

memote.support.thermodynamics.find_thermodynamic_reversibility_index(reactions)[source]¶

Return the reversibility index of the given reactions.

To determine the reversibility index, we calculate the reversibility index ln_gamma (see [1] section 3.5) of each reaction using the eQuilibrator API [2].

Parameters:

reactions: list of cobra.Reaction: A list of reactions for which to calculate the reversibility index.

Returns:

tuple

list of cobra.Reaction, index pairs: A list of pairs of reactions and their reversibility indexes.
list of cobra.Reaction: A list of reactions which contain at least one metabolite that could not be mapped to KEGG on the basis of its annotation.
list of cobra.Reaction: A list of reactions for which it is not possible to calculate the standard change in Gibbs free energy potential. Reasons of failure include that participating metabolites cannot be broken down with the group contribution method.
list of cobra.Reaction: A list of reactions that are not chemically or redox balanced.

References

[1]	(1, 2) Elad Noor, Arren Bar-Even, Avi Flamholz, Yaniv Lubling, Dan Davidi, Ron Milo; An integrated open framework for thermodynamics of reactions that combines accuracy and coverage, Bioinformatics, Volume 28, Issue 15, 1 August 2012, Pages 2037–2044, https://doi.org/10.1093/bioinformatics/bts317

[2]	(1, 2) https://pypi.org/project/equilibrator-api/

memote.support.validation¶

Structurally validate SBML-formatted file input.

Module Contents¶

Functions¶

`load_cobra_model`(path, notifications)	Load a COBRA model with meta information from an SBML document.
`format_failure`(failure)	Format how an error or warning should be displayed.
`run_sbml_validation`(document, notifications)	Report errors and warnings found in an SBML document.

memote.support.validation.load_cobra_model(path, notifications)[source]¶: Load a COBRA model with meta information from an SBML document.

memote.support.validation.format_failure(failure)[source]¶: Format how an error or warning should be displayed.

memote.support.validation.run_sbml_validation(document, notifications)[source]¶: Report errors and warnings found in an SBML document.

Submodules¶

`memote._version`¶

Git implementation of _version.py.

Module Contents¶

Classes¶

VersioneerConfig Container for Versioneer configuration parameters.

Functions¶

`get_keywords`()	Get the keywords needed to look up the version information.
`get_config`()	Create, populate and return the VersioneerConfig() object.
`register_vcs_handler`(vcs, method)	Decorator to mark a method as the handler for a particular VCS.
`run_command`(commands, args, cwd=None, verbose=False, hide_stderr=False, env=None)	Call the given command(s).
`versions_from_parentdir`(parentdir_prefix, root, verbose)	Try to determine the version from the parent directory name.
`git_get_keywords`(versionfile_abs)	Extract version information from the given file.
`git_versions_from_keywords`(keywords, tag_prefix, verbose)	Get version information from git keywords.
`git_pieces_from_vcs`(tag_prefix, root, verbose, run_command=run_command)	Get version from ‘git describe’ in the root of the source tree.
`plus_or_dot`(pieces)	Return a + if we don’t already have one, else return a .
`render_pep440`(pieces)	Build up version string, with post-release “local version identifier”.
`render_pep440_pre`(pieces)	TAG[.post.devDISTANCE] – No -dirty.
`render_pep440_post`(pieces)	TAG[.postDISTANCE[.dev0]+gHEX] .
`render_pep440_old`(pieces)	TAG[.postDISTANCE[.dev0]] .
`render_git_describe`(pieces)	TAG[-DISTANCE-gHEX][-dirty].
`render_git_describe_long`(pieces)	TAG-DISTANCE-gHEX[-dirty].
`render`(pieces, style)	Render the given version pieces into the requested style.
`get_versions`()	Get version information or return default if unable to do so.

memote._version.get_keywords()[source]¶: Get the keywords needed to look up the version information.

class memote._version.VersioneerConfig[source]¶: Container for Versioneer configuration parameters.

memote._version.get_config()[source]¶: Create, populate and return the VersioneerConfig() object.

exception memote._version.NotThisMethod[source]¶

Bases: Exception

Exception raised if a method is not valid for the current scenario.

memote._version.LONG_VERSION_PY[source]¶

memote._version.HANDLERS[source]¶

memote._version.register_vcs_handler(vcs, method)[source]¶: Decorator to mark a method as the handler for a particular VCS.

memote._version.run_command(commands, args, cwd=None, verbose=False, hide_stderr=False, env=None)[source]¶: Call the given command(s).

memote._version.versions_from_parentdir(parentdir_prefix, root, verbose)[source]¶

Try to determine the version from the parent directory name.

Source tarballs conventionally unpack into a directory that includes both the project name and a version string. We will also support searching up two directory levels for an appropriately named parent directory

memote._version.git_get_keywords(versionfile_abs)[source]¶: Extract version information from the given file.

memote._version.git_versions_from_keywords(keywords, tag_prefix, verbose)[source]¶: Get version information from git keywords.

memote._version.git_pieces_from_vcs(tag_prefix, root, verbose, run_command=run_command)[source]¶

Get version from ‘git describe’ in the root of the source tree.

This only gets called if the git-archive ‘subst’ keywords were not expanded, and _version.py hasn’t already been rewritten with a short version string, meaning we’re inside a checked out source tree.

memote._version.plus_or_dot(pieces)[source]¶: Return a + if we don’t already have one, else return a .

memote._version.render_pep440(pieces)[source]¶

Build up version string, with post-release “local version identifier”.

Our goal: TAG[+DISTANCE.gHEX[.dirty]] . Note that if you get a tagged build and then dirty it, you’ll get TAG+0.gHEX.dirty

Exceptions: 1: no tags. git_describe was just HEX. 0+untagged.DISTANCE.gHEX[.dirty]

memote._version.render_pep440_pre(pieces)[source]¶

TAG[.post.devDISTANCE] – No -dirty.

Exceptions: 1: no tags. 0.post.devDISTANCE

memote._version.render_pep440_post(pieces)[source]¶

TAG[.postDISTANCE[.dev0]+gHEX] .

The “.dev0” means dirty. Note that .dev0 sorts backwards (a dirty tree will appear “older” than the corresponding clean one), but you shouldn’t be releasing software with -dirty anyways.

Exceptions: 1: no tags. 0.postDISTANCE[.dev0]

memote._version.render_pep440_old(pieces)[source]¶

TAG[.postDISTANCE[.dev0]] .

The “.dev0” means dirty.

Eexceptions: 1: no tags. 0.postDISTANCE[.dev0]

memote._version.render_git_describe(pieces)[source]¶

TAG[-DISTANCE-gHEX][-dirty].

Like ‘git describe –tags –dirty –always’.

Exceptions: 1: no tags. HEX[-dirty] (note: no ‘g’ prefix)

memote._version.render_git_describe_long(pieces)[source]¶

TAG-DISTANCE-gHEX[-dirty].

Like ‘git describe –tags –dirty –always -long’. The distance/hash is unconditional.

Exceptions: 1: no tags. HEX[-dirty] (note: no ‘g’ prefix)

memote._version.render(pieces, style)[source]¶: Render the given version pieces into the requested style.

memote._version.get_versions()[source]¶: Get version information or return default if unable to do so.

`memote.jinja2_extension`¶

Provide a jinja2 extension for the cookiecutter..

Module Contents¶

Classes¶

MemoteExtension Provide an absolute path to a file.

class memote.jinja2_extension.MemoteExtension(environment)[source]¶

Bases: jinja2.ext.Extension

Provide an absolute path to a file.

tags[source]¶

static normalize(filename)[source]¶: Return an absolute path of the given file name.

`memote.utils`¶

Utility functions used by memote and its tests.

Module Contents¶

Functions¶

`register_with`(registry)	Register a passed in object.
`annotate`(title, format_type, message=None, data=None, metric=1.0)	Annotate a test case with info that should be displayed in the reports.
`get_ids`(iterable)	Retrieve the identifier of a number of objects.
`get_ids_and_bounds`(iterable)	Retrieve the identifier and bounds of a number of objects.
`truncate`(sequence)	Create a potentially shortened text display of a list.
`log_json_incompatible_types`(obj)	Log types that are not JSON compatible.
`show_versions`()	Print formatted dependency information to stdout.
`jsonify`(obj, pretty=False)	Turn a nested object into a (compressed) JSON string.
`is_modified`(path, commit)	Test whether a given file was present and modified in a specific commit.
`stdout_notifications`(notifications)	Print each entry of errors and warnings to stdout.

memote.utils.wrapper[source]¶

memote.utils.register_with(registry)[source]¶

Intended to be used as a decorator on model building functions with a dict as a registry.

Examples

REGISTRY = dict()
@register_with(REGISTRY)
def build_empty(base):
    return base

memote.utils.annotate(title, format_type, message=None, data=None, metric=1.0)[source]¶

Annotate a test case with info that should be displayed in the reports.

Parameters:

title : str

A human-readable descriptive title of the test case.

format_type : str

A string that determines how the result data is formatted in the report. It is expected not to be None.

‘number’ : ‘data’ is a single number which can be an integer or float and should be represented as such.
‘count’ : ‘data’ is a list, set or tuple. Choosing ‘count’ will display the length of that list e.g. number of metabolites without formula.
‘percent’ : Instead of ‘data’ the content of ‘metric’ ought to be displayed e.g. percentage of metabolites without charge. ‘metric’ is expected to be a floating point number.
‘raw’ : ‘data’ is ought to be displayed “as is” without formatting. This option is appropriate for single strings or a boolean output.

message : str

A short written explanation that states and possibly explains the test result.

data

Raw data which the test case generates and assesses. Can be of the following types: list, set, tuple, string, float, integer, and boolean.

metric: float

A value x in the range of 0 <= x <= 1 which represents the fraction of ‘data’ to the total in the model. For example, if ‘data’ are all metabolites without formula, ‘metric’ should be the fraction of metabolites without formula from the total of metabolites in the model.

Returns:

function: The decorated function, now extended by the attribute ‘annotation’.

Notes

Adds “annotation” attribute to the function object, which stores values for predefined keys as a dictionary.

memote.utils.get_ids(iterable)[source]¶: Retrieve the identifier of a number of objects.

memote.utils.get_ids_and_bounds(iterable)[source]¶: Retrieve the identifier and bounds of a number of objects.

memote.utils.truncate(sequence)[source]¶

Create a potentially shortened text display of a list.

Parameters:	sequence : list An indexable sequence of elements.
Returns:	str The list as a formatted string.

memote.utils.log_json_incompatible_types(obj)[source]¶

Log types that are not JSON compatible.

Explore a nested dictionary structure and log types that are not JSON compatible.

Parameters:	obj : dict A potentially nested dictionary.

memote.utils.show_versions()[source]¶: Print formatted dependency information to stdout.

memote.utils.jsonify(obj, pretty=False)[source]¶

Turn a nested object into a (compressed) JSON string.

Parameters:	obj : dict Any kind of dictionary structure. pretty : bool, optional Whether to format the resulting JSON in a more legible way ( default False).

memote.utils.is_modified(path, commit)[source]¶

Test whether a given file was present and modified in a specific commit.

Parameters:	path : str The path of a file to be checked. commit : git.Commit A git commit object.
Returns:	bool Whether or not the given path is among the modified files and was not deleted in this commit.

memote.utils.stdout_notifications(notifications)[source]¶

Print each entry of errors and warnings to stdout.

Parameters:	notifications: dict A simple dictionary structure containing a list of errors and warnings.

Package Contents¶

Classes¶

`MemoteResult`	Collect the metabolic model test suite results.
`ResultManager`	Manage storage of results to JSON files.
`RepoResultManager`	Manage storage of results to JSON files.
`SQLResultManager`	Manage storage of results to a database.
`HistoryManager`	Manage access to results in the commit history of a git repository.
`ReportConfiguration`	Collect the metabolic model test suite results.
`Report`	Determine the abstract report interface.
`SnapshotReport`	Render a one-time report from the given model results.
`HistoryReport`	Render a rich report using the git repository history.
`DiffReport`	Render a report displaying the results of two or more models side-by-side.
`MemoteExtension`	Provide an absolute path to a file.

Functions¶

`get_versions`()	Get version information or return default if unable to do so.
`show_versions`()	Print formatted dependency information to stdout.
`validate_model`(path)	Validate a model structurally and optionally store results as JSON.
`test_model`(model, sbml_version=None, results=False, pytest_args=None, exclusive=None, skip=None, experimental=None, solver_timeout=10)	Test a model and optionally store results as JSON.
`snapshot_report`(result, config=None, html=True)	Generate a snapshot report from a result set and configuration.
`diff_report`(diff_results, config=None, html=True)	Generate a diff report from a result set and configuration.
`history_report`(history, config=None, html=True)	Test a model and save a history report.

memote.__author__ = Moritz E. Beber[source]¶

memote.__email__ = midnighter@posteo.net[source]¶

memote.get_versions()[source]¶: Get version information or return default if unable to do so.

memote.__version__[source]¶

memote.show_versions()[source]¶: Print formatted dependency information to stdout.

memote.validate_model(path)[source]¶

Validate a model structurally and optionally store results as JSON.

Parameters:	path Path to model file.
Returns:	tuple cobra.Model The metabolic model under investigation. tuple A tuple reporting on the SBML level, version, and FBC package version used (if any) in the SBML document. dict A simple dictionary containing a list of errors and warnings.

memote.test_model(model, sbml_version=None, results=False, pytest_args=None, exclusive=None, skip=None, experimental=None, solver_timeout=10)[source]¶

Test a model and optionally store results as JSON.

Parameters:

model : cobra.Model: The metabolic model under investigation.
sbml_version: tuple, optional: A tuple reporting on the level, version, and FBC use of the SBML file.
results : bool, optional: Whether to return the results in addition to the return code.
pytest_args : list, optional: Additional arguments for the pytest suite.
exclusive : iterable, optional: Names of test cases or modules to run and exclude all others. Takes precedence over skip.
skip : iterable, optional: Names of test cases or modules to skip.
solver_timeout: int, optional: Timeout in seconds to set on the mathematical optimization solver (default 10).

Returns:

int: The return code of the pytest suite.
memote.Result, optional: A nested dictionary structure that contains the complete test results.

memote.snapshot_report(result, config=None, html=True)[source]¶

Generate a snapshot report from a result set and configuration.

Parameters:	result : memote.MemoteResult Nested dictionary structure as returned from the test suite. config : dict, optional The final test report configuration (default None). html : bool, optional Whether to render the report as full HTML or JSON (default True).

memote.diff_report(diff_results, config=None, html=True)[source]¶

Generate a diff report from a result set and configuration.

Parameters:	diff_results : iterable of memote.MemoteResult Nested dictionary structure as returned from the test suite. config : dict, optional The final test report configuration (default None). html : bool, optional Whether to render the report as full HTML or JSON (default True).

memote.history_report(history, config=None, html=True)[source]¶

Test a model and save a history report.

Parameters:	history : memote.HistoryManager The manager grants access to previous results. config : dict, optional The final test report configuration. html : bool, optional Whether to render the report as full HTML or JSON (default True).

class memote.MemoteResult(*args, **kwargs)¶

Bases: dict

Collect the metabolic model test suite results.

static add_environment_information(meta)¶: Record environment information.

class memote.ResultManager(**kwargs)¶

Bases: object

Manage storage of results to JSON files.

store(self, result, filename, pretty=True)¶

Write a result to the given file.

Parameters:	result : memote.MemoteResult The dictionary structure of results. filename : str or pathlib.Path Store results directly to the given filename. pretty : bool, optional Whether (default) or not to write JSON in a more legible format.

load(self, filename)¶: Load a result from the given JSON file.

class memote.RepoResultManager(repository, location, **kwargs)¶

Bases: memote.suite.results.result_manager.ResultManager

Manage storage of results to JSON files.

Results are stored to and loaded from a specific location (directory) and enriched with git commit meta information.

record_git_info(self, commit=None)¶

Record git meta information.

Parameters:	commit : str, optional Unique hexsha of the desired commit.
Returns:	GitInfo Git commit meta information.

get_filename(self, git_info)¶

Create a filename from the storage directory and the commit hash.

Parameters:	git_info : GitInfo A named tuple with git meta information.
Returns:	str The path to the file where the result of the current commit is stored.

static add_git(meta, git_info)¶: Enrich the result meta information with commit data.

store(self, result, commit=None, **kwargs)¶

Store a result in a JSON file attaching git meta information.

Parameters:	result : memote.MemoteResult The dictionary structure of results. commit : str, optional Unique hexsha of the desired commit. kwargs Passed to parent function.

load(self, commit=None)¶: Load a result from the storage directory.

class memote.SQLResultManager(**kwargs)¶

Bases: memote.suite.results.repo_result_manager.RepoResultManager

Manage storage of results to a database.

store(self, result, commit=None, **kwargs)¶

Store a result in a JSON file attaching git meta information.

Parameters:	result : memote.MemoteResult The dictionary structure of results. commit : str, optional Unique hexsha of the desired commit. kwargs Passed to parent function.

load(self, commit=None)¶: Load a result from the database.

class memote.HistoryManager(repository, manager, **kwargs)¶

Bases: object

Manage access to results in the commit history of a git repository.

Attributes:	manager : memote.RepoResultManager The manager for accessing individual results. current : str The name of the currently active branch.

build_branch_structure(self, model, skip)¶: Inspect and record the repo’s branches and their history.

iter_branches(self)¶: Iterate over branch names and their commit histories.

iter_commits(self)¶: Iterate over all commit hashes in the repository.

load_history(self, model, skip=('gh-pages', ))¶

Load the entire results history into memory.

Could be a bad idea in a far future.

get_result(self, commit, default=None)¶: Return an individual result from the history if it exists.

__contains__(self, commit)¶: Test for the existence of a result for a commit.

class memote.ReportConfiguration(*args, **kwargs)¶

Bases: dict

Collect the metabolic model test suite results.

classmethod load(cls, filename=None)¶: Load a test report configuration.

merge(self, other)¶: Merge a custom configuration.

class memote.Report(result, configuration, **kwargs)¶

Bases: object

Determine the abstract report interface.

Attributes:	result : memote.MemoteResult The dictionary structure of results. configuration : memote.MemoteConfiguration A memote configuration structure.

render_json(self, pretty=False)¶

Render the report results as JSON.

Parameters:	pretty : bool, optional Whether to format the resulting JSON in a more legible way ( default False).

render_html(self)¶: Render an HTML report.

get_configured_tests(self)¶: Get tests explicitly configured.

determine_miscellaneous_tests(self)¶

Identify tests not explicitly configured in test organization.

List them as an additional card called Misc, which is where they will now appear in the report.

compute_score(self)¶: Calculate the overall test score using the configuration.

memote.LOGGER¶

class memote.SnapshotReport(**kwargs)¶

Bases: memote.suite.reporting.report.Report

Render a one-time report from the given model results.

Attributes:	result : memote.MemoteResult The dictionary structure of results. configuration : memote.MemoteConfiguration A memote configuration structure.

class memote.HistoryReport(history, configuration, **kwargs)¶

Bases: memote.suite.reporting.report.Report

Render a rich report using the git repository history.

Attributes:	configuration : memote.MemoteConfiguration A memote configuration structure.

collect_history(self)¶: Build the structure of results in terms of a commit history.

class memote.DiffReport(diff_results, configuration, **kwargs)¶

Bases: memote.suite.reporting.report.Report

Render a report displaying the results of two or more models side-by-side.

Attributes:	diff_results : python.Dictionary The dictionary structure of memote.MemoteResult objects. configuration : memote.MemoteConfiguration A memote configuration structure.

format_and_score_diff_data(self, diff_results)¶: Reformat the api results to work with the front-end.

class memote.MemoteExtension(environment)[source]¶

Bases: jinja2.ext.Extension

Provide an absolute path to a file.

tags¶

static normalize(filename)¶: Return an absolute path of the given file name.

`test_consistency`¶

Stoichiometric consistency tests for an instance of cobra.Model.

Module Contents¶

Functions¶

`test_stoichiometric_consistency`(model)	Expect that the stoichiometry is consistent.
`test_unconserved_metabolites`(model)	Report number all unconserved metabolites.
`test_inconsistent_min_stoichiometry`(model)	Report inconsistent min stoichiometries.
`test_detect_energy_generating_cycles`(model, met)	Expect that no energy metabolite can be produced out of nothing.
`test_reaction_charge_balance`(model)	Expect all reactions to be charge balanced.
`test_reaction_mass_balance`(model)	Expect all reactions to be mass balanced.
`test_blocked_reactions`(model)	Expect all reactions to be able to carry flux in complete medium.
`test_find_stoichiometrically_balanced_cycles`(model)	Expect no stoichiometrically balanced loops to be present.
`test_find_orphans`(model)	Expect no orphans to be present.
`test_find_deadends`(model)	Expect no dead-ends to be present.
`test_find_disconnected`(model)	Expect no disconnected metabolites to be present.
`test_find_metabolites_not_produced_with_open_bounds`(model)	Expect metabolites to be producible in complete medium.
`test_find_metabolites_not_consumed_with_open_bounds`(model)	Expect metabolites to be consumable in complete medium.
`test_find_reactions_unbounded_flux_default_condition`(model)	Expect the fraction of unbounded reactions to be low.

test_consistency.test_stoichiometric_consistency(model)[source]¶

Expect that the stoichiometry is consistent.

Stoichiometric inconsistency violates universal constraints: 1. Molecular masses are always positive, and 2. On each side of a reaction the mass is conserved. A single incorrectly defined reaction can lead to stoichiometric inconsistency in the model, and consequently to unconserved metabolites. Similar to insufficient constraints, this may give rise to cycles which either produce mass from nothing or consume mass from the model.

Implementation: This test uses an implementation of the algorithm presented in section 3.1 by Gevorgyan, A., M. G Poolman, and D. A Fell. “Detection of Stoichiometric Inconsistencies in Biomolecular Models.” Bioinformatics 24, no. 19 (2008): 2245. doi: 10.1093/bioinformatics/btn425

test_consistency.test_unconserved_metabolites(model)[source]¶

Report number all unconserved metabolites.

The list of unconserved metabolites is computed using the algorithm described in section 3.2 of “Detection of Stoichiometric Inconsistencies in Biomolecular Models.” Bioinformatics 24, no. 19 (2008): 2245. doi: 10.1093/bioinformatics/btn425.

test_consistency.test_inconsistent_min_stoichiometry(model)[source]¶

Report inconsistent min stoichiometries.

Only 10 unconserved metabolites are reported and considered to avoid computing for too long.

Implementation: Algorithm described in section 3.3 of “Detection of Stoichiometric Inconsistencies in Biomolecular Models.” Bioinformatics 24, no. 19 (2008): 2245. doi: 10.1093/bioinformatics/btn425.

test_consistency.test_detect_energy_generating_cycles(model, met)[source]¶

Expect that no energy metabolite can be produced out of nothing.

When a model is not sufficiently constrained to account for the thermodynamics of reactions, flux cycles may form which provide reduced metabolites to the model without requiring nutrient uptake. These cycles are referred to as erroneous energy-generating cycles. Their effect on the predicted growth rate in FBA may account for an increase of up to 25%, which makes studies involving the growth rates predicted from such models unreliable.

Implementation: This test uses an implementation of the algorithm presented by: Fritzemeier, C. J., Hartleb, D., Szappanos, B., Papp, B., & Lercher, M. J. (2017). Erroneous energy-generating cycles in published genome scale metabolic networks: Identification and removal. PLoS Computational Biology, 13(4), 1–14. http://doi.org/10.1371/journal.pcbi.1005494

First attempt to identify the main compartment (cytosol), then attempt to identify each metabolite of the referenced list of energy couples via an internal mapping table. Construct a dissipation reaction for each couple. Carry out FBA with each dissipation reaction as the objective and report those reactions that non-zero carry flux.

test_consistency.test_reaction_charge_balance(model)[source]¶

Expect all reactions to be charge balanced.

This will exclude biomass, exchange and demand reactions as they are unbalanced by definition. It will also fail all reactions where at least one metabolite does not have a charge defined.

In steady state, for each metabolite the sum of influx equals the sum of efflux. Hence the net charges of both sides of any model reaction have to be equal. Reactions where at least one metabolite does not have a charge are not considered to be balanced, even though the remaining metabolites participating in the reaction might be.

Implementation: For each reaction that isn’t a boundary or biomass reaction check if each metabolite has a non-zero charge attribute and if so calculate if the overall sum of charges of reactants and products is equal to zero.

test_consistency.test_reaction_mass_balance(model)[source]¶

Expect all reactions to be mass balanced.

This will exclude biomass, exchange and demand reactions as they are unbalanced by definition. It will also fail all reactions where at least one metabolite does not have a formula defined.

In steady state, for each metabolite the sum of influx equals the sum of efflux. Hence the net masses of both sides of any model reaction have to be equal. Reactions where at least one metabolite does not have a formula are not considered to be balanced, even though the remaining metabolites participating in the reaction might be.

Implementation: For each reaction that isn’t a boundary or biomass reaction check if each metabolite has a non-zero elements attribute and if so calculate if the overall element balance of reactants and products is equal to zero.

test_consistency.test_blocked_reactions(model)[source]¶

Expect all reactions to be able to carry flux in complete medium.

Universally blocked reactions are reactions that during Flux Variability Analysis cannot carry any flux while all model boundaries are open. Generally blocked reactions are caused by network gaps, which can be attributed to scope or knowledge gaps.

Implementation: Use flux variability analysis (FVA) implemented in cobra.flux_analysis.find_blocked_reactions with open_exchanges=True. Please refer to the cobrapy documentation for more information: https://cobrapy.readthedocs.io/en/stable/autoapi/cobra/flux_analysis/ variability/index.html#cobra.flux_analysis.variability. find_blocked_reactions

test_consistency.test_find_stoichiometrically_balanced_cycles(model)[source]¶

Expect no stoichiometrically balanced loops to be present.

Stoichiometrically Balanced Cycles are artifacts of insufficiently constrained networks resulting in reactions that can carry flux when all the boundaries have been closed.

Implementation: Close all model boundary reactions and then use flux variability analysis (FVA) to identify reactions that carry flux.

test_consistency.test_find_orphans(model)[source]¶

Expect no orphans to be present.

Orphans are metabolites that are only consumed but not produced by reactions in the model. They may indicate the presence of network and knowledge gaps.

Implementation: Find orphan metabolites structurally by considering only reaction equations and bounds. FBA is not carried out.

test_consistency.test_find_deadends(model)[source]¶

Expect no dead-ends to be present.

Dead-ends are metabolites that can only be produced but not consumed by reactions in the model. They may indicate the presence of network and knowledge gaps.

Implementation: Find dead-end metabolites structurally by considering only reaction equations and bounds. FBA is not carried out.

test_consistency.test_find_disconnected(model)[source]¶

Expect no disconnected metabolites to be present.

Disconnected metabolites are not part of any reaction in the model. They are most likely left-over from the reconstruction process, but may also point to network and knowledge gaps.

Implementation: Check for any metabolites of the cobra.Model object with emtpy reaction attribute.

test_consistency.test_find_metabolites_not_produced_with_open_bounds(model)[source]¶

Expect metabolites to be producible in complete medium.

In complete medium, a model should be able to divert flux to every metabolite. This test opens all the boundary reactions i.e. simulates a complete medium and checks if any metabolite cannot be produced individually using flux balance analysis. Metabolites that cannot be produced this way are likely orphan metabolites, downstream of reactions with fixed constraints, or blocked by a cofactor imbalance. To pass this test all metabolites should be producible.

Implementation: Open all model boundary reactions, then for each metabolite in the model add a boundary reaction and maximize it with FBA.

test_consistency.test_find_metabolites_not_consumed_with_open_bounds(model)[source]¶

Expect metabolites to be consumable in complete medium.

In complete medium, a model should be able to divert flux from every metabolite. This test opens all the boundary reactions i.e. simulates a complete medium and checks if any metabolite cannot be consumed individually using flux balance analysis. Metabolites that cannot be consumed this way are likely dead-end metabolites or upstream of reactions with fixed constraints. To pass this test all metabolites should be consumable.

Implementation: Open all model boundary reactions, then for each metabolite in the model add a boundary reaction and minimize it with FBA.

test_consistency.test_find_reactions_unbounded_flux_default_condition(model)[source]¶

Expect the fraction of unbounded reactions to be low.

A large fraction of model reactions able to carry unlimited flux under default conditions indicates problems with reaction directionality, missing cofactors, incorrectly defined transport reactions and more.

Implementation: Without changing the default constraints run flux variability analysis. From the FVA results identify those reactions that carry flux equal to the model’s maximal or minimal flux.

`test_sbo`¶

Tests for SBO terms performed on an instance of cobra.Model.

Module Contents¶

Functions¶

`test_metabolite_sbo_presence`(model)	Expect all metabolites to have a some form of SBO-Term annotation.
`test_reaction_sbo_presence`(model)	Expect all reactions to have a some form of SBO-Term annotation.
`test_gene_sbo_presence`(model)	Expect all genes to have a some form of SBO-Term annotation.
`test_metabolic_reaction_specific_sbo_presence`(model)	Expect all metabolic reactions to be annotated with SBO:0000176.
`test_transport_reaction_specific_sbo_presence`(model)	Expect all transport reactions to be annotated properly.
`test_metabolite_specific_sbo_presence`(model)	Expect all metabolites to be annotated with SBO:0000247.
`test_gene_specific_sbo_presence`(model)	Expect all genes to be annotated with SBO:0000243.
`test_exchange_specific_sbo_presence`(model)	Expect all exchange reactions to be annotated with SBO:0000627.
`test_demand_specific_sbo_presence`(model)	Expect all demand reactions to be annotated with SBO:0000627.
`test_sink_specific_sbo_presence`(model)	Expect all sink reactions to be annotated with SBO:0000632.
`test_biomass_specific_sbo_presence`(model)	Expect all biomass reactions to be annotated with SBO:0000629.

test_sbo.test_metabolite_sbo_presence(model)[source]¶

Expect all metabolites to have a some form of SBO-Term annotation.

The Systems Biology Ontology (SBO) allows researchers to annotate a model with terms which indicate the intended function of its individual components. The available terms are controlled and relational and can be viewed here http://www.ebi.ac.uk/sbo/main/tree.

Implementation: Check if each cobra.Metabolite has a non-zero “annotation” attribute that contains the key “sbo”.

test_sbo.test_reaction_sbo_presence(model)[source]¶

Expect all reactions to have a some form of SBO-Term annotation.

Implementation: Check if each cobra.Reaction has a non-zero “annotation” attribute that contains the key “sbo”.

test_sbo.test_gene_sbo_presence(model)[source]¶

Expect all genes to have a some form of SBO-Term annotation.

Check if each cobra.Gene has a non-zero “annotation” attribute that contains the key “sbo”.

test_sbo.test_metabolic_reaction_specific_sbo_presence(model)[source]¶

Expect all metabolic reactions to be annotated with SBO:0000176.

SBO:0000176 represents the term ‘biochemical reaction’. Every metabolic reaction that is not a transport or boundary reaction should be annotated with this. The results shown are relative to the total amount of pure metabolic reactions.

Implementation: Check if each pure metabolic reaction has a non-zero “annotation” attribute that contains the key “sbo” with the associated value being the SBO term above.

test_sbo.test_transport_reaction_specific_sbo_presence(model)[source]¶

Expect all transport reactions to be annotated properly.

‘SBO:0000185’, ‘SBO:0000588’, ‘SBO:0000587’, ‘SBO:0000655’, ‘SBO:0000654’, ‘SBO:0000660’, ‘SBO:0000659’, ‘SBO:0000657’, and ‘SBO:0000658’ represent the terms ‘transport reaction’ and ‘translocation reaction’, in addition to their children (more specific transport reaction labels). Every transport reaction that is not a pure metabolic or boundary reaction should be annotated with one of these terms. The results shown are relative to the total of all transport reactions.

Implementation: Check if each transport reaction has a non-zero “annotation” attribute that contains the key “sbo” with the associated value being one of the SBO terms above.

test_sbo.test_metabolite_specific_sbo_presence(model)[source]¶

Expect all metabolites to be annotated with SBO:0000247.

SBO:0000247 represents the term ‘simple chemical’. Every metabolite should be annotated with this.

Implementation: Check if each cobra.Metabolite has a non-zero “annotation” attribute that contains the key “sbo” with the associated value being one of the SBO terms above.

test_sbo.test_gene_specific_sbo_presence(model)[source]¶

Expect all genes to be annotated with SBO:0000243.

SBO:0000243 represents the term ‘gene’. Every gene should be annotated with this.

Implementation: Check if each cobra.Gene has a non-zero “annotation” attribute that contains the key “sbo” with the associated value being one of the SBO terms above.

test_sbo.test_exchange_specific_sbo_presence(model)[source]¶

Expect all exchange reactions to be annotated with SBO:0000627.

SBO:0000627 represents the term ‘exchange reaction’. The Systems Biology Ontology defines an exchange reaction as follows: ‘A modeling process to provide matter influx or efflux to a model, for example to replenish a metabolic network with raw materials (eg carbon / energy sources). Such reactions are conceptual, created solely for modeling purposes, and do not have a physical correspondence. Exchange reactions, often represented as ‘R_EX_’, can operate in the negative (uptake) direction or positive (secretion) direction. By convention, a negative flux through an exchange reaction represents uptake of the corresponding metabolite, and a positive flux represent discharge.’ Every exchange reaction should be annotated with this. Exchange reactions differ from demand reactions in that the metabolites are removed from or added to the extracellular environment only.

Implementation: Check if each exchange reaction has a non-zero “annotation” attribute that contains the key “sbo” with the associated value being one of the SBO terms above.

test_sbo.test_demand_specific_sbo_presence(model)[source]¶

Expect all demand reactions to be annotated with SBO:0000627.

SBO:0000628 represents the term ‘demand reaction’. The Systems Biology Ontology defines a demand reaction as follows: ‘A modeling process analogous to exchange reaction, but which operates upon “internal” metabolites. Metabolites that are consumed by these reactions are assumed to be used in intra-cellular processes that are not part of the model. Demand reactions, often represented ‘R_DM_’, can also deliver metabolites (from intra-cellular processes that are not considered in the model).’ Every demand reaction should be annotated with this. Demand reactions differ from exchange reactions in that the metabolites are not removed from the extracellular environment, but from any of the organism’s compartments. Demand reactions differ from sink reactions in that they are designated as irreversible.

Implementation: Check if each demand reaction has a non-zero “annotation” attribute that contains the key “sbo” with the associated value being one of the SBO terms above.

test_sbo.test_sink_specific_sbo_presence(model)[source]¶

Expect all sink reactions to be annotated with SBO:0000632.

SBO:0000632 represents the term ‘sink reaction’. The Systems Biology Ontology defines a sink reaction as follows: ‘A modeling process to provide matter influx or efflux to a model, for example to replenish a metabolic network with raw materials (eg carbon / energy sources). Such reactions are conceptual, created solely for modeling purposes, and do not have a physical correspondence. Unlike the analogous demand (SBO:….) reactions, which are usually designated as irreversible, sink reactions always represent a reversible uptake/secretion processes, and act as a metabolite source with no cost to the cell. Sink reactions, also referred to as R_SINK_, are generally used for compounds that are metabolized by the cell but are produced by non-metabolic, un-modeled cellular processes.’ Every sink reaction should be annotated with this. Sink reactions differ from exchange reactions in that the metabolites are not removed from the extracellular environment, but from any of the organism’s compartments.

Implementation: Check if each sink reaction has a non-zero “annotation” attribute that contains the key “sbo” with the associated value being one of the SBO terms above.

test_sbo.test_biomass_specific_sbo_presence(model)[source]¶

Expect all biomass reactions to be annotated with SBO:0000629.

SBO:0000629 represents the term ‘biomass production’. The Systems Biology Ontology defines an exchange reaction as follows: ‘Biomass production, often represented ‘R_BIOMASS_’, is usually the optimization target reaction of constraint-based models, and can consume multiple reactants to produce multiple products. It is also assumed that parts of the reactants are also consumed in unrepresented processes and hence products do not have to reflect all the atom composition of the reactants. Formulation of a biomass production process entails definition of the macromolecular content (eg. cellular protein fraction), metabolic constitution of each fraction (eg. amino acids), and subsequently the atomic composition (eg. nitrogen atoms). More complex biomass functions can additionally incorporate details of essential vitamins and cofactors required for growth.’ Every reaction representing the biomass production should be annotated with this.

Implementation: Check if each biomass reaction has a non-zero “annotation” attribute that contains the key “sbo” with the associated value being one of the SBO terms above.

`conftest`¶

Configuration and fixtures for the test suite.

`test_growth`¶

Perform tests on an instance of cobra.Model using growth data.

Growth data comes from processed biolog experiments. Growth curves have to be converted into binary decisions whether or not an organism/strain was able to grow in a certain medium.

Module Contents¶

Functions¶

test_growth_from_data_qualitative(model, experiment, threshold=0.95) Expect a perfect accuracy when predicting growth.

test_growth.test_growth_from_data_qualitative(model, experiment, threshold=0.95)[source]¶

Expect a perfect accuracy when predicting growth.

The in-silico growth prediction is compared with experimental data and the accuracy is expected to be better than 0.95. In principal, Matthews’ correlation coefficient is a more comprehensive metric but is a little fragile to not having any false negatives or false positives in the output.

Implementation: Read and validate experimental config file and data tables. Constrain the model with the parameters provided by a user’s definition of the medium, then compute a confusion matrix based on the predicted true, expected true, predicted false and expected false growth. The individual values of the confusion matrix are calculated as described in https://en.wikipedia.org/wiki/Confusion_matrix

`test_thermodynamics`¶

Perform tests using eQuilibrator API on an instance of cobra.Model.

Module Contents¶

Functions¶

test_find_candidate_irreversible_reactions(model) Identify reversible reactions that could be irreversible.

test_thermodynamics.test_find_candidate_irreversible_reactions(model)[source]¶

Identify reversible reactions that could be irreversible.

If a reaction is neither a transport reaction, a biomass reaction nor a boundary reaction, it is counted as a purely metabolic reaction. This test checks if the reversibility attribute of each reaction agrees with a thermodynamics-based calculation of reversibility.

Implementation: To determine reversibility we calculate the reversibility index ln_gamma (natural logarithm of gamma) of each reaction using the eQuilibrator API. We consider reactions, whose reactants’ concentrations would need to change by more than three orders of magnitude for the reaction flux to reverse direction, to be likely candidates of irreversible reactions. This assume default concentrations around 100 μM (~3 μM—3 mM) at pH = 7, I = 0.1 M and T = 298 K. The corresponding reversibility index is approximately 7. For further information on the thermodynamic and implementation details please refer to https://doi.org/10.1093/bioinformatics/bts317 and https://pypi.org/project/equilibrator-api/.

Please note that currently eQuilibrator can only determine the reversibility index for chemically and redox balanced reactions whose metabolites can be mapped to KEGG compound identifiers (e.g. C00001). In addition to not being mappable to KEGG or the reaction not being balanced, there is a possibility that the metabolite cannot be broken down into chemical groups which is essential for the calculation of Gibbs energy using group contributions. This test collects each erroneous reaction and returns them as a tuple containing each list in the following order:

Reactions with reversibility index

Reactions with incomplete mapping to KEGG

Reactions with metabolites that are problematic during calculation

Chemically or redox unbalanced Reactions (after mapping to KEGG)

This test simply reports the number of reversible reactions that, according to the reversibility index, are likely to be irreversible.

`test_matrix`¶

Tests for matrix properties performed on an instance of cobra.Model.

Module Contents¶

Functions¶

`test_absolute_extreme_coefficient_ratio`(model, threshold=1000000000.0)	Show the ratio of the absolute largest and smallest non-zero coefficients.
`test_number_independent_conservation_relations`(model)	Show the number of independent conservation relations in the model.
`test_matrix_rank`(model)	Show the rank of the stoichiometric matrix.
`test_degrees_of_freedom`(model)	Show the degrees of freedom of the stoichiometric matrix.

test_matrix.test_absolute_extreme_coefficient_ratio(model, threshold=1000000000.0)[source]¶

Show the ratio of the absolute largest and smallest non-zero coefficients.

This test will return the absolute largest and smallest, non-zero coefficients of the stoichiometric matrix. A large ratio of these values may point to potential numerical issues when trying to solve different mathematical optimization problems such as flux-balance analysis.

To pass this test the ratio should not exceed 10^9. This threshold has been selected based on experience, and is likely to be adapted when more data on solver performance becomes available.

Implementation: Compose the stoichiometric matrix, then calculate absolute coefficients and lastly use the maximal value and minimal non-zero value to calculate the ratio.

test_matrix.test_number_independent_conservation_relations(model)[source]¶

Show the number of independent conservation relations in the model.

This test will return the number of conservation relations, i.e., conservation pools through the left null space of the stoichiometric matrix. This test is not scored, as the dimension of the left null space is system-specific.

Implementation: Calculate the left null space, i.e., the null space of the transposed stoichiometric matrix, using an algorithm based on the singular value decomposition adapted from https://scipy.github.io/old-wiki/pages/Cookbook/RankNullspace.html Then, return the estimated dimension of that null space.

test_matrix.test_matrix_rank(model)[source]¶

Show the rank of the stoichiometric matrix.

The rank of the stoichiometric matrix is system specific. It is calculated using singular value decomposition (SVD).

Implementation: Compose the stoichiometric matrix, then estimate the rank, i.e. the dimension of the column space, of a matrix. The algorithm used by this function is based on the singular value decomposition of the matrix.

test_matrix.test_degrees_of_freedom(model)[source]¶

Show the degrees of freedom of the stoichiometric matrix.

The degrees of freedom of the stoichiometric matrix, i.e., the number of ‘free variables’ is system specific and corresponds to the dimension of the (right) null space of the matrix.

Implementation: Compose the stoichiometric matrix, then calculate the dimensionality of the null space using the rank-nullity theorem outlined by Alama, J. The Rank+Nullity Theorem. Formalized Mathematics 15, (2007).

`test_basic`¶

Perform basic tests on an instance of cobra.Model.

Module Contents¶

Functions¶

`test_model_id_presence`(model)	Expect that the model has an identifier.
`test_genes_presence`(model)	Expect that at least one gene is defined in the model.
`test_reactions_presence`(model)	Expect that at least one reaction is defined in the model.
`test_metabolites_presence`(model)	Expect that at least one metabolite is defined in the model.
`test_metabolites_formula_presence`(model)	Expect all metabolites to have a formula.
`test_metabolites_charge_presence`(model)	Expect all metabolites to have charge information.
`test_gene_protein_reaction_rule_presence`(model)	Expect all non-exchange reactions to have a GPR rule.
`test_ngam_presence`(model)	Expect a single non growth-associated maintenance reaction.
`test_metabolic_coverage`(model)	Expect a model to have a metabolic coverage >= 1.
`test_compartments_presence`(model)	Expect that two or more compartments are defined in the model.
`test_protein_complex_presence`(model)	Expect that more than one enzyme complex is present in the model.
`test_find_pure_metabolic_reactions`(model)	Expect at least one pure metabolic reaction to be defined in the model.
`test_find_constrained_pure_metabolic_reactions`(model)	Expect zero or more purely metabolic reactions to have fixed constraints.
`test_find_transport_reactions`(model)	Expect >= 1 transport reactions are present in the model.
`test_find_constrained_transport_reactions`(model)	Expect zero or more transport reactions to have fixed constraints.
`test_transport_reaction_gpr_presence`(model)	Expect a small fraction of transport reactions not to have a GPR rule.
`test_find_reversible_oxygen_reactions`(model)	Expect zero or more oxygen-containing reactions to be reversible.
`test_find_unique_metabolites`(model)	Expect there to be less metabolites when removing compartment tag.
`test_find_duplicate_metabolites_in_compartments`(model)	Expect there to be zero duplicate metabolites in the same compartments.
`test_find_reactions_with_partially_identical_annotations`(model)	Expect there to be zero duplicate reactions.
`test_find_duplicate_reactions`(model)	Expect there to be zero duplicate reactions.
`test_find_reactions_with_identical_genes`(model)	Expect there to be zero duplicate reactions.
`test_find_medium_metabolites`(model)	Expect zero or more metabolites to be set as medium.

test_basic.test_model_id_presence(model)[source]¶

Expect that the model has an identifier.

The MIRIAM guidelines require a model to be identified via an ID. Further, the ID will be displayed on the memote snapshot report, which helps to distinguish the output clearly.

Implementation: Check if the cobra.Model object has a non-empty “id” attribute, this value is parsed from the “id” attribute of the <model> tag in the SBML file e.g. <model fbc:strict=”true” id=”iJO1366”>.

test_basic.test_genes_presence(model)[source]¶

Expect that at least one gene is defined in the model.

A metabolic model can still be a useful tool without any genes, however there are certain methods which rely on the presence of genes and, more importantly, the corresponding gene-protein-reaction rules. This test requires that there is at least one gene defined.

Implementation: Check if the cobra.Model object has non-empty “genes” attribute, this list is populated from the list of fbc:listOfGeneProducts which should contain at least one fbc:geneProduct.

test_basic.test_reactions_presence(model)[source]¶

Expect that at least one reaction is defined in the model.

To be useful a metabolic model should consist at least of a few reactions. This test simply checks if there are more than zero reactions.

Implementation: Check if the cobra.Model object has non-empty “reactions” attribute, this list is populated from the list of sbml:listOfReactions which should contain at least one sbml:reaction.

test_basic.test_metabolites_presence(model)[source]¶

Expect that at least one metabolite is defined in the model.

To be useful a metabolic model should consist at least of a few metabolites that are converted by reactions. This test simply checks if there are more than zero metabolites.

Implementation: Check if the cobra.Model object has non-empty “metabolites” attribute, this list is populated from the list of sbml:listOfSpecies which should contain at least one sbml:species.

test_basic.test_metabolites_formula_presence(model)[source]¶

Expect all metabolites to have a formula.

To be able to ensure that reactions are mass-balanced, all model metabolites ought to be provided with a chemical formula. Since it may be difficult to obtain formulas for certain metabolites this test serves as a mere report. Models can still be stoichiometrically consistent even when chemical formulas are not defined for each metabolite.

Implementation: Check if each cobra.Metabolite has a non-empty “formula” attribute. This attribute is set by the parser if there is an fbc:chemicalFormula attribute for the corresponding species in the SBML.

test_basic.test_metabolites_charge_presence(model)[source]¶

Expect all metabolites to have charge information.

To be able to ensure that reactions are charge-balanced, all model metabolites ought to be provided with a charge. Since it may be difficult to obtain charges for certain metabolites this test serves as a mere report. Models can still be stoichiometrically consistent even when charge information is not defined for each metabolite.

Implementation: Check if each cobra.Metabolite has a non-empty “charge” attribute. This attribute is set by the parser if there is an fbc:charge attribute for the corresponding species in the SBML.

test_basic.test_gene_protein_reaction_rule_presence(model)[source]¶

Expect all non-exchange reactions to have a GPR rule.

Gene-Protein-Reaction rules express which gene has what function. The presence of this annotation is important to justify the existence of reactions in the model, and is required to conduct in silico gene deletion studies. However, reactions without GPR may also be valid: Spontaneous reactions, or known reactions with yet undiscovered genes likely lack GPR.

Implementation: Check if each cobra.Reaction has a non-empty “gene_reaction_rule” attribute, which is set by the parser if there is an fbc:geneProductAssociation defined for the corresponding reaction in the SBML.

test_basic.test_ngam_presence(model)[source]¶

Expect a single non growth-associated maintenance reaction.

The Non-Growth Associated Maintenance reaction (NGAM) is an ATP-hydrolysis reaction added to metabolic models to represent energy expenses that the cell invests in continuous processes independent of the growth rate. Memote tries to infer this reaction from a list of buzzwords, and the stoichiometry and components of a simple ATP-hydrolysis reaction.

Implementation: From the list of all reactions that convert ATP to ADP select the reactions that match the irreversible reaction “ATP + H2O -> ADP + HO4P + H+”, whose metabolites are situated within the main model compartment. The main model compartment is assumed to be the cytosol, yet, if that cannot be identified, it is assumed to be the compartment with the most metabolites. The resulting list of reactions is then filtered further by attempting to match the reaction name with any of the following buzzwords (‘maintenance’, ‘atpm’, ‘requirement’, ‘ngam’, ‘non-growth’, ‘associated’). If this is possible only the filtered reactions are returned, if not the list is returned as is.

test_basic.test_metabolic_coverage(model)[source]¶

Expect a model to have a metabolic coverage >= 1.

The degree of metabolic coverage indicates the modeling detail of a given reconstruction calculated by dividing the total amount of reactions by the amount of genes. Models with a ‘high level of modeling detail have ratios >1, and models with a low level of detail have ratios <1. This difference arises as models with basic or intermediate levels of detail are assumed to include many reactions in which several gene products and their enzymatic transformations are ‘lumped’.

Implementation: Divides the amount reactions by the amount of genes. Raises an error if the model does not contain either reactions or genes.

test_basic.test_compartments_presence(model)[source]¶

Expect that two or more compartments are defined in the model.

While simplified metabolic models may be perfectly viable, generally across the tree of life organisms contain at least one distinct compartment: the cytosol or cytoplasm. In the case of prokaryotes there is usually a periplasm, and eurkaryotes are more complex. In addition to the internal compartment, a metabolic model also reflects the extracellular environment i.e. the medium/ metabolic context in which the modelled cells grow. Hence, in total, at least two compartments can be expected from a metabolic model.

Implementation: Check if the cobra.Model object has a non-empty “compartments” attribute, this list is populated from the list of sbml:listOfCompartments which should contain at least two sbml:compartment elements.

test_basic.test_protein_complex_presence(model)[source]¶

Expect that more than one enzyme complex is present in the model.

Based on the gene-protein-reaction (GPR) rules, it is possible to infer whether a reaction is catalyzed by a single gene product, isozymes or by a heteromeric protein complex. This test checks that at least one such heteromeric protein complex is defined in any GPR of the model. For S. cerevisiae it could be shown that “essential proteins tend to [cluster] together in essential complexes” (https://doi.org/10.1074%2Fmcp.M800490-MCP200).

This might also be a relevant metric for other organisms.

Implementation: Identify GPRs which contain at least one logical AND that combines two different gene products.

test_basic.test_find_pure_metabolic_reactions(model)[source]¶

Expect at least one pure metabolic reaction to be defined in the model.

If a reaction is neither a transport reaction, a biomass reaction nor a boundary reaction, it is counted as a purely metabolic reaction. This test requires the presence of metabolite formula to be able to identify transport reactions. This test is passed when the model contains at least one purely metabolic reaction i.e. a conversion of one metabolite into another.

Implementation: From the list of all reactions, those that are boundary, transport and biomass reactions are removed and the remainder assumed to be pure metabolic reactions. Boundary reactions are identified using the attribute cobra.Model.boundary. Please read the description of “Transport Reactions” and “Biomass Reaction Identified” to learn how they are identified.

test_basic.test_find_constrained_pure_metabolic_reactions(model)[source]¶

Expect zero or more purely metabolic reactions to have fixed constraints.

If a reaction is neither a transport reaction, a biomass reaction nor a boundary reaction, it is counted as a purely metabolic reaction. This test requires the presence of metabolite formula to be able to identify transport reactions. This test simply reports the number of purely metabolic reactions that have fixed constraints and does not have any mandatory ‘pass’ criteria.

Implementation: From the pool of pure metabolic reactions identify reactions which are constrained to values other than the model’s minimal or maximal possible bounds.

test_basic.test_find_transport_reactions(model)[source]¶

Expect >= 1 transport reactions are present in the model.

Cellular metabolism in any organism usually involves the transport of metabolites across a lipid bi-layer. This test reports how many of these reactions, which transports metabolites from one compartment to another, are present in the model, as at least one transport reaction must be present for cells to take up nutrients and/or excrete waste.

Implementation: A transport reaction is defined as follows: 1. It contains metabolites from at least 2 compartments and 2. at least 1 metabolite undergoes no chemical reaction, i.e., the formula and/or annotation stays the same on both sides of the equation.

A notable exception is transport via PTS, which also contains the following restriction: 3. The transported metabolite(s) are transported into a compartment through the exchange of a phosphate.

An example of transport via PTS would be pep(c) + glucose(e) -> glucose-6-phosphate(c) + pyr(c)

Reactions similar to transport via PTS (referred to as “modified transport reactions”) follow a similar pattern: A(x) + B-R(y) -> A-R(y) + B(y)

Such modified transport reactions can be detected, but only when the formula is defined for all metabolites in a particular reaction. If this is not the case, transport reactions are identified through annotations, which cannot detect modified transport reactions.

test_basic.test_find_constrained_transport_reactions(model)[source]¶

Expect zero or more transport reactions to have fixed constraints.

Cellular metabolism in any organism usually involves the transport of metabolites across a lipid bi-layer. Hence, this test reports how many of these reactions, which transports metabolites from one compartment to another, have fixed constraints. This test does not have any mandatory ‘pass’ criteria.

Implementation: Please refer to “Transport Reactions” for details on how memote identifies transport reactions. From the pool of transport reactions identify reactions which are constrained to values other than the model’s median lower and upper bounds.

test_basic.test_transport_reaction_gpr_presence(model)[source]¶

Expect a small fraction of transport reactions not to have a GPR rule.

As it is hard to identify the exact transport processes within a cell, transport reactions are often added purely for modeling purposes. Highlighting where assumptions have been made versus where there is proof may help direct the efforts to improve transport and transport energetics of the tested metabolic model. However, transport reactions without GPR may also be valid: Diffusion, or known reactions with yet undiscovered genes likely lack GPR.

Implementation: Check which cobra.Reactions classified as transport reactions have a non-empty “gene_reaction_rule” attribute.

test_basic.test_find_reversible_oxygen_reactions(model)[source]¶

Expect zero or more oxygen-containing reactions to be reversible.

The directionality of oxygen-producing/-consuming reactions affects the model’s ability to grow anaerobically i.e. create faux-anaerobic organisms. This test reports how many of these oxygen-containing reactions are reversible. This test does not have any mandatory ‘pass’ criteria.

Implementation: First, find the metabolite representing atmospheric oxygen in the model on the basis of an internal mapping table or by specifically looking for the formula “O2”. Then, find all reactions that produce or consume oxygen and report those that are reversible.

test_basic.test_find_unique_metabolites(model)[source]¶

Expect there to be less metabolites when removing compartment tag.

Metabolites may be transported into different compartments, which means that in a compartimentalized model the number of metabolites may be much higher than in a model with no compartments. This test counts only one occurrence of each metabolite and returns this as the number of unique metabolites. The test expects that the model is compartimentalized, and thus, that the number of unique metabolites is generally lower than the total number of metabolites.

Implementation: Reduce the list of metabolites to a unique set by removing the compartment tag. The cobrapy SBML parser adds compartment tags to each metabolite ID.

test_basic.test_find_duplicate_metabolites_in_compartments(model)[source]¶

Expect there to be zero duplicate metabolites in the same compartments.

The main reason for having this test is to help cleaning up merged models or models from automated reconstruction pipelines as these are prone to having identical metabolites from different namespaces (hence different IDs). This test therefore expects that every metabolite in any particular compartment has unique inchikey values.

Implementation: Identifies duplicate metabolites in each compartment by determining if any two metabolites have identical InChI-key annotations. For instance, this function would find compounds with IDs ATP1 and ATP2 in the cytosolic compartment, with both having the same InChI annotations.

test_basic.test_find_reactions_with_partially_identical_annotations(model)[source]¶

Expect there to be zero duplicate reactions.

Identify reactions in a pairwise manner that are annotated with identical database references. This does not take into account a reaction’s directionality or compartment.

The main reason for having this test is to help cleaning up merged models or models from automated reconstruction pipelines as these are prone to having identical reactions with identifiers from different namespaces. It could also be useful to identify a ‘type’ of reaction that occurs in several compartments.

Implementation:

Identify duplicate reactions globally by checking if any two metabolic reactions have the same entries in their annotation attributes. The heuristic looks at annotations with the keys “metanetx.reaction”, “kegg.reaction”, “brenda”, “rhea”, “biocyc”, “bigg.reaction” only.

test_basic.test_find_duplicate_reactions(model)[source]¶

Expect there to be zero duplicate reactions.

Identify reactions in a pairwise manner that use the same set of metabolites including potentially duplicate metabolites. Moreover, it will take a reaction’s directionality and compartment into account.

Implementation:

Compare reactions in a pairwise manner. For each reaction, the metabolite annotations are checked for a description of the structure (via InChI and InChIKey).If they exist, substrates and products as well as the stoichiometries of any reaction pair are compared. Only reactions where the substrates, products, stoichiometry and reversibility are identical are considered to be duplicates. This test will not be able to identify duplicate reactions if there are no structure annotations. Further, it will report reactions with differing bounds as equal if they otherwise match the above conditions.

test_basic.test_find_reactions_with_identical_genes(model)[source]¶

Expect there to be zero duplicate reactions.

Identify reactions in a pairwise manner that use identical sets of genes. It does not take into account a reaction’s directionality, compartment, metabolites or annotations.

Implementation:

Compare reactions in a pairwise manner and group reactions whose genes are identical. Skip reactions with missing genes.

test_basic.test_find_medium_metabolites(model)[source]¶

Expect zero or more metabolites to be set as medium.

This test checks all boundary reactions in the model that permit flux towards creating a metabolite, and reports those metabolites. This test does not have any mandatory ‘pass’ criteria.

Implementation: Identify the metabolite IDs of each reaction in the method cobra.Model.medium. Model.medium returns exchange reactions whose bounds permit the uptake of metabolites.

`test_essentiality`¶

Perform tests on an instance of cobra.Model using gene data.

Gene data currently only includes knockout screens. However, other types of experiments that make changes to individual genes such as expression modulation experiments, etc may be possible extensions in the future.

Module Contents¶

Functions¶

test_gene_essentiality_from_data_qualitative(model, experiment, threshold=0.95) Expect a perfect accuracy when predicting gene essentiality.

test_essentiality.test_gene_essentiality_from_data_qualitative(model, experiment, threshold=0.95)[source]¶

Expect a perfect accuracy when predicting gene essentiality.

The in-silico gene essentiality is compared with experimental data and the accuracy is expected to be better than 0.95. In principal, Matthews’ correlation coefficient is a more comprehensive metric but is a little fragile to not having any false negatives or false positives in the output.

Implementation: Read and validate experimental config file and data tables. Constrain the model with the parameters provided by a user’s definition of the medium, then compute a confusion matrix based on the predicted essential, expected essential, predicted nonessential and expected nonessential genes. The individual values of the confusion matrix are calculated as described in https://en.wikipedia.org/wiki/Confusion_matrix

`test_biomass`¶

Biomass tests performed on an instance of cobra.Model.

N.B.: We parametrize each function here with the identified biomass reactions. In the storage of test results we rely on the order of the biomass fixtures to remain the same as the parametrized test cases.

Module Contents¶

Functions¶

`test_biomass_presence`(model)	Expect the model to contain at least one biomass reaction.
`test_biomass_consistency`(model, reaction_id)	Expect biomass components to sum up to 1 g[CDW].
`test_biomass_default_production`(model, reaction_id)	Expect biomass production in default medium.
`test_biomass_open_production`(model, reaction_id)	Expect biomass production in complete medium.
`test_biomass_precursors_default_production`(model, reaction_id)	Expect production of all biomass precursors in default medium.
`test_biomass_precursors_open_production`(model, reaction_id)	Expect precursor production in complete medium.
`test_gam_in_biomass`(model, reaction_id)	Expect the biomass reactions to contain ATP and ADP.
`test_fast_growth_default`(model, reaction_id)	Expect the predicted growth rate for each BOF to be below 2.81.
`test_direct_metabolites_in_biomass`(model, reaction_id)	Expect the ratio of direct metabolites to be below 0.5.
`test_essential_precursors_not_in_biomass`(model, reaction_id)	Expect the biomass reaction to contain all essential precursors.

test_biomass.LOGGER[source]¶

test_biomass.test_biomass_presence(model)[source]¶

Expect the model to contain at least one biomass reaction.

The biomass composition aka biomass formulation aka biomass reaction is a common pseudo-reaction accounting for biomass synthesis in constraints-based modelling. It describes the stoichiometry of intracellular compounds that are required for cell growth. While this reaction may not be relevant to modeling the metabolism of higher organisms, it is essential for single-cell modeling.

Implementation: Identifies possible biomass reactions using two principal steps:

1. Return reactions that include the SBO annotation “SBO:0000629” for biomass.

If no reactions can be identifies this way:: 1. Look for the buzzwords “biomass”, “growth” and “bof” in reaction IDs. 2. Look for metabolite IDs or names that contain the buzzword “biomass” and obtain the set of reactions they are involved in. 3. Remove boundary reactions from this set. 4. Return the union of reactions that match the buzzwords and of the reactions that metabolites are involved in that match the buzzword.

This test checks if at least one biomass reaction is present.

test_biomass.test_biomass_consistency(model, reaction_id)[source]¶

Expect biomass components to sum up to 1 g[CDW].

This test only yields sensible results if all biomass precursor metabolites have chemical formulas assigned to them. The molecular weight of the biomass reaction in metabolic models is defined to be equal to 1 g/mmol. Conforming to this is essential in order to be able to reliably calculate growth yields, to cross-compare models, and to obtain valid predictions when simulating microbial consortia. A deviation from 1 - 1E-03 to 1 + 1E-06 is accepted.

Implementation: Multiplies the coefficient of each metabolite of the biomass reaction with its molecular weight calculated from the formula, then divides the overall sum of all the products by 1000.

test_biomass.test_biomass_default_production(model, reaction_id)[source]¶

Expect biomass production in default medium.

Using flux balance analysis this test optimizes the model for growth in the medium that is set by default. Any non-zero growth rate is accepted to pass this test.

Implementation: Calculate the solution of FBA with the biomass reaction set as objective function and the model’s default constraints.

test_biomass.test_biomass_open_production(model, reaction_id)[source]¶

Expect biomass production in complete medium.

Using flux balance analysis this test optimizes the model for growth using a complete medium i.e. unconstrained boundary reactions. Any non-zero growth rate is accepted to pass this test.

Implementation: Calculate the solution of FBA with the biomass reaction set as objective function and after removing any constraints from all boundary reactions.

test_biomass.test_biomass_precursors_default_production(model, reaction_id)[source]¶

Expect production of all biomass precursors in default medium.

Using flux balance analysis this test optimizes for the production of each metabolite that is a substrate of the biomass reaction with the exception of atp and h2o. Optimizations are carried out using the default conditions. This is useful when reconstructing the precursor biosynthesis pathways of a metabolic model. To pass this test, the model should be able to synthesis all the precursors.

Implementation: For each biomass precursor (except ATP and H2O) add a temporary demand reaction, then carry out FBA with this reaction as the objective. Collect all metabolites for which this optimization is equal to zero or infeasible.

test_biomass.test_biomass_precursors_open_production(model, reaction_id)[source]¶

Expect precursor production in complete medium.

Using flux balance analysis this test optimizes for the production of each metabolite that is a substrate of the biomass reaction with the exception of atp and h2o. Optimizations are carried out using a complete medium i.e. unconstrained boundary reactions. This is useful when reconstructing the precursor biosynthesis pathways of a metabolic model. To pass this test, the model should be able to synthesis all the precursors.

Implementation: First remove any constraints from all boundary reactions, then for each biomass precursor (except ATP and H2O) add a temporary demand reaction, then carry out FBA with this reaction as the objective. Collect all metabolites for which this optimization is below or equal to zero or is infeasible.

test_biomass.test_gam_in_biomass(model, reaction_id)[source]¶

Expect the biomass reactions to contain ATP and ADP.

The growth-associated maintenance (GAM) term accounts for the energy in the form of ATP that is required to synthesize macromolecules such as Proteins, DNA and RNA, and other processes during growth. A GAM term is therefore a requirement for any well-defined biomass reaction. There are different ways to implement this term depending on what kind of experimental data is available and the preferred way of implementing the biomass reaction: - Chemostat growth experiments yield a single GAM value representing the

required energy per gram of biomass (Figure 6 of [R3f60bc5e84c5-1]). This can be implemented in a lumped biomass reaction or in the final term of a split biomass reaction.

Experimentally delineating or estimating the GAM requirements for each macromolecule separately is possible, yet requires either data from multi-omics experiments [2] or detailed resources [R3f60bc5e84c5-1] , respectively. Individual energy requirements can either be implemented in a split biomass equation on the term for each macromolecule, or, on the basis of the biomass composition, they can be summed into a single GAM value for growth and treated as mentioned above.

This test is only able to detect if a lumped biomass reaction or the final term of a split biomass reaction contains this term. Hence, it will only detect the use of a single GAM value as opposed to individual energy requirements of each macromolecule. Both approaches, however, have its merits.

Implementation: Determines the metabolite identifiers of ATP, ADP, H2O, HO4P and H+ based on an internal mapping table. Checks if ATP and H2O are a subset of the reactants and ADP, HO4P and H+ a subset of the products of the biomass reaction.

References: .. [R3f60bc5e84c5-1] Thiele, I., & Palsson, B. Ø. (2010, January). A protocol for

generating a high-quality genome-scale metabolic reconstruction. Nature protocols. Nature Publishing Group. http://doi.org/10.1038/nprot.2009.203

[2]	Hackett, S. R., Zanotelli, V. R. T., Xu, W., Goya, J., Park, J. O., Perlman, D. H., Gibney, P. A., Botstein, D., Storey, J. D., Rabinowitz, J. D. (2010, January). Systems-level analysis of mechanisms regulating yeast metabolic flux Science http://doi.org/10.1126/science.aaf2786

test_biomass.test_fast_growth_default(model, reaction_id)[source]¶

Expect the predicted growth rate for each BOF to be below 2.81.

The growth rate of a metabolic model should not be faster than that of the fastest growing organism. This is based on a doubling time of Vibrio natriegens which was reported to be 14.8 minutes by: Henry H. Lee, Nili Ostrov, Brandon G. Wong, Michaela A. Gold, Ahmad S. Khalil, George M. Church in https://www.biorxiv.org/content/biorxiv/early/2016/06/12/058487.full.pdf

The calculation ln(2)/(14.8/60) ~ 2.81 yields the corresponding growth rate.

Implementation: Calculate the solution of FBA with the biomass reaction set as objective function and a model’s default constraints. Then check if the objective value is higher than 2.81.

test_biomass.test_direct_metabolites_in_biomass(model, reaction_id)[source]¶

Expect the ratio of direct metabolites to be below 0.5.

Some biomass precursors are taken from the media and directly consumed by the biomass reaction. It might not be a problem for ions or metabolites for which the organism in question is auxotrophic. However, too many of these metabolites may be artifacts of automated gap-filling procedures. Many gap-filling algorithms attempt to minimise the number of added reactions. This can lead to many biomass precursors being “direct metabolites”.

This test reports the ratio of direct metabolites to the total amount of precursors to a given biomass reaction. It specifically looks for metabolites that are only in either exchange, transport or biomass reactions. Bear in mind that this may lead to false positives in heavily compartimentalized models.

To pass this test, the ratio of direct metabolites should be less than 50% of all biomass precursors. This is an arbitrary threshold but it takes into account that while certain ions do not serve a relevant metabolic function, it may still be important to include them in the biomass reaction to account for the impact of their uptake energy costs.

This threshold is subject to change in the future.

Implementation: Identify biomass precursors (excluding ATP and H+), identify cytosol and extracellular compartment from an internal mapping table. Then, determine which precursors is only involved in transport, boundary and biomass reactions. Using FBA with the biomass function as the objective then determine whether the metabolite is taken up only to be consumed by the biomass reaction.

test_biomass.test_essential_precursors_not_in_biomass(model, reaction_id)[source]¶

Expect the biomass reaction to contain all essential precursors.

There are universal components of life that make up the biomass of all known organisms. These include all proteinogenic amino acids, deoxy- and ribonucleotides, water and a range of metabolic cofactors.

This test reports the amount of biomass precursors that have been reported to be essential constituents of the biomass equation. All of the following precursors need to be included in the biomass reaction to pass the test:

Aminoacids: trp__L, cys__L, his__L, tyr__L, met__L, phe__L, ser__L, pro__L, asp__L, thr__L, gln__L, glu__L, ile__L, arg__L, lys__L, val__L, leu__L, ala__L, gly, asn__L DNA: datp, dctp, dttp, dgtp RNA: atp, ctp, utp, gtp Cofactors: nad, nadp, amet, fad, pydx5p, coa, thmpp, fmn and h2o

These metabolites were selected based on the results presented by DOI:10.1016/j.ymben.2016.12.002

Please note, that the authors also suggest to count C1 carriers (derivatives of tetrahydrofolate(B9) or tetrahydromethanopterin) as universal cofactors. We have omitted these from this check because there are many individual compounds that classify as C1 carriers, and it is not clear a priori which one should be preferred. In a future update, we may consider identifying these using a chemical ontology.

Implementation: Determine whether the model employs a lumped or split biomass reaction. Then, using an internal mapping table, try to identify the above list of essential precursors in list of precursor metabolites of either type of biomass reaction. List IDs in the models namespace if the metabolite exists, else use the MetaNetX namespace if the metabolite does not exist in the model. Identifies the cytosol from an internal mapping table, and assumes that all precursors exist in that compartment.

`test_sbml`¶

Tests the level, version and FBC usage of the loaded SBML file.

Module Contents¶

Functions¶

`test_sbml_level`(sbml_version)	Expect the SBML to be at least level 3 version 2.
`test_fbc_presence`(sbml_version)	Expect the FBC plugin to be present.

test_sbml.test_sbml_level(sbml_version)[source]¶

Expect the SBML to be at least level 3 version 2.

This test reports if the model file is represented in the latest edition (level) of the Systems Biology Markup Language (SBML) which is Level 3, and at least version 1.

Implementation: The level and version are parsed directly from the SBML document.

test_sbml.test_fbc_presence(sbml_version)[source]¶

Expect the FBC plugin to be present.

The Flux Balance Constraints (FBC) Package extends SBML with structured and semantic descriptions for domain-specific model components such as flux bounds, multiple linear objective functions, gene-protein-reaction associations, metabolite chemical formulas, charge and related annotations which are relevant for parameterized GEMs and FBA models. The SBML and constraint-based modeling communities collaboratively develop this package and update it based on user input.

Implementation: Parse the state of the FBC plugin from the SBML document.

`test_annotation`¶

Tests performed on the annotations of an instance of cobra.Model.

Module Contents¶

Functions¶

`test_metabolite_annotation_presence`(model)	Expect all metabolites to have a non-empty annotation attribute.
`test_reaction_annotation_presence`(model)	Expect all reactions to have a non-empty annotation attribute.
`test_gene_product_annotation_presence`(model)	Expect all genes to have a non-empty annotation attribute.
`test_metabolite_annotation_overview`(model, db)	Expect all metabolites to have annotations from common databases.
`test_reaction_annotation_overview`(model, db)	Expect all reactions to have annotations from common databases.
`test_gene_product_annotation_overview`(model, db)	Expect all genes to have annotations from common databases.
`test_metabolite_annotation_wrong_ids`(model, db)	Expect all annotations of metabolites to be in the correct format.
`test_reaction_annotation_wrong_ids`(model, db)	Expect all annotations of reactions to be in the correct format.
`test_gene_product_annotation_wrong_ids`(model, db)	Expect all annotations of genes/gene-products to be in the correct format.
`test_metabolite_id_namespace_consistency`(model)	Expect metabolite identifiers to be from the same namespace.
`test_reaction_id_namespace_consistency`(model)	Expect reaction identifiers to be from the same namespace.

test_annotation.test_metabolite_annotation_presence(model)[source]¶

Expect all metabolites to have a non-empty annotation attribute.

This test checks if any annotations at all are present in the SBML annotations field for each metabolite, irrespective of the type of annotation i.e. specific database cross-references, ontology terms, additional information. For this test to pass the model is expected to have metabolites and each of them should have some form of annotation.

Implementation: Check if the annotation attribute of each cobra.Metabolite object of the model is unset or empty.

test_annotation.test_reaction_annotation_presence(model)[source]¶

Expect all reactions to have a non-empty annotation attribute.

This test checks if any annotations at all are present in the SBML annotations field for each reaction, irrespective of the type of annotation i.e. specific database cross-references, ontology terms, additional information. For this test to pass the model is expected to have reactions and each of them should have some form of annotation.

Implementation: Check if the annotation attribute of each cobra.Reaction object of the model is unset or empty.

test_annotation.test_gene_product_annotation_presence(model)[source]¶

Expect all genes to have a non-empty annotation attribute.

This test checks if any annotations at all are present in the SBML annotations field (extended by FBC package) for each gene product, irrespective of the type of annotation i.e. specific database, cross-references, ontology terms, additional information. For this test to pass the model is expected to have genes and each of them should have some form of annotation.

Implementation: Check if the annotation attribute of each cobra.Gene object of the model is unset or empty.

test_annotation.test_metabolite_annotation_overview(model, db)[source]¶

Expect all metabolites to have annotations from common databases.

Specific database cross-references are paramount to mapping information. To provide references to as many databases as possible helps to make the metabolic model more accessible to other researchers. This does not only facilitate the use of a model in a broad array of computational pipelines, it also promotes the metabolic model itself to become an organism-specific knowledge base.

For this test to pass, each metabolite annotation should contain cross-references to a number of databases. The currently selection is listed in annotation.py, but an ongoing discussion can be found at https://github.com/opencobra/memote/issues/332. For each database this test checks for the presence of its corresponding namespace ID to comply with the MIRIAM guidelines i.e. they have to match those defined on https://identifiers.org/.

Since each database is quite different and some potentially incomplete, it may not be feasible to achieve 100% coverage for each of them. Generally it should be possible, however, to obtain cross-references to at least one of the databases for all metabolites consistently.

Implementation: Check if the keys of the annotation attribute of each cobra.Metabolite of the model match with a selection of common biochemical databases. The annotation attribute of cobrapy components is a dictionary of key:value pairs.

test_annotation.test_reaction_annotation_overview(model, db)[source]¶

Expect all reactions to have annotations from common databases.

For this test to pass, each reaction annotation should contain cross-references to a number of databases. The currently selection is listed in annotation.py, but an ongoing discussion can be found at https://github.com/opencobra/memote/issues/332. For each database this test checks for the presence of its corresponding namespace ID to comply with the MIRIAM guidelines i.e. they have to match those defined on https://identifiers.org/.

Implementation: Check if the keys of the annotation attribute of each cobra.Reaction of the model match with a selection of common biochemical databases. The annotation attribute of cobrapy components is a dictionary of key:value pairs.

test_annotation.test_gene_product_annotation_overview(model, db)[source]¶

Expect all genes to have annotations from common databases.

For this test to pass, each gene annotation should contain cross-references to a number of databases. The currently selection is listed in annotation.py, but an ongoing discussion can be found at https://github.com/opencobra/memote/issues/332. For each database this test checks for the presence of its corresponding namespace ID to comply with the MIRIAM guidelines i.e. they have to match those defined on https://identifiers.org/.

Implementation: Check if the keys of the annotation attribute of each cobra.Gene of the model match with a selection of common genome databases. The annotation attribute of cobrapy components is a dictionary of key:value pairs.

test_annotation.test_metabolite_annotation_wrong_ids(model, db)[source]¶

Expect all annotations of metabolites to be in the correct format.

To identify databases and the identifiers belonging to them, computational tools rely on the presence of specific patterns. Only when these patterns can be identified consistently is an ID truly machine-readable. This test checks if the database cross-references in metabolite annotations conform to patterns defined according to the MIRIAM guidelines, i.e. matching those that are defined at https://identifiers.org/.

The required formats, i.e., regex patterns are further outlined in annotation.py. This test does not carry out a web query for the composed URI, it merely controls that the regex patterns match the identifiers.

Implementation: For those metabolites whose annotation keys match any of the tested databases, check if the corresponding values match the identifier pattern of each database.

test_annotation.test_reaction_annotation_wrong_ids(model, db)[source]¶

Expect all annotations of reactions to be in the correct format.

To identify databases and the identifiers belonging to them, computational tools rely on the presence of specific patterns. Only when these patterns can be identified consistently is an ID truly machine-readable. This test checks if the database cross-references in reaction annotations conform to patterns defined according to the MIRIAM guidelines, i.e. matching those that are defined at https://identifiers.org/.

Implementation: For those reaction whose annotation keys match any of the tested databases, check if the corresponding values match the identifier pattern of each database.

test_annotation.test_gene_product_annotation_wrong_ids(model, db)[source]¶

Expect all annotations of genes/gene-products to be in the correct format.

To identify databases and the identifiers belonging to them, computational tools rely on the presence of specific patterns. Only when these patterns can be identified consistently is an ID truly machine-readable. This test checks if the database cross-references in reaction annotations conform to patterns defined according to the MIRIAM guidelines, i.e. matching those that are defined at https://identifiers.org/.

Implementation: For those genes whose annotation keys match any of the tested databases, check if the corresponding values match the identifier pattern of each database.

test_annotation.test_metabolite_id_namespace_consistency(model)[source]¶

Expect metabolite identifiers to be from the same namespace.

In well-annotated models it is no problem if the pool of main identifiers for metabolites consists of identifiers from several databases. However, in models that lack appropriate annotations, it may hamper the ability of other researchers to use it. Running the model through a computational pipeline may be difficult without first consolidating the namespace.

Hence, this test checks if the main metabolite identifiers can be attributed to one single namespace based on the regex patterns defined at https://identifiers.org/

Implementation: Generate a table with each column corresponding to one database from the selection and each row to a metabolite identifier. A Boolean entry indicates whether the identifier matches the regular expression of the corresponding database. Since the Biocyc pattern matches broadly, we assume that any instance of an identifier matching to Biocyc AND any other database pattern is a false positive match for Biocyc and thus set it to false. Sum the positive matches for each database and assume that the largest set is the ‘main’ identifier namespace.

test_annotation.test_reaction_id_namespace_consistency(model)[source]¶

Expect reaction identifiers to be from the same namespace.

In well-annotated models it is no problem if the pool of main identifiers for reactions consists of identifiers from several databases. However, in models that lack appropriate annotations, it may hamper the ability of other researchers to use it. Running the model through a computational pipeline may be difficult without first consolidating the namespace.

Hence, this test checks if the main reaction identifiers can be attributed to one single namespace based on the regex patterns defined at https://identifiers.org/

Implementation: Generate a pandas.DataFrame with each column corresponding to one database from the selection and each row to the reaction ID. A boolean entry indicates whether the metabolite ID matches the regex pattern of the corresponding database. Since the Biocyc pattern matches quite, assume that any instance of an identifier matching to Biocyc AND any other DB pattern is a false positive match for Biocyc and then set the boolean to false. Sum the positive matches for each database and assume that the largest set is the ‘main’ identifier namespace.

[1]	Created with sphinx-autoapi

memote - the genome-scale metabolic model test suite¶

Contact¶

Copyright¶

Contents¶

Installation¶

Stable release¶

From sources¶

Getting Started¶

Benchmark¶

Snapshot¶

Diff¶

Reconstruction¶

CI tested, online and public workflow:¶

Offline, local or private workflow:¶

Flowchart¶

Understanding the reports¶

Orientation¶

Toolbar¶

Main Body¶

Test Results¶

Interpretation¶

Color¶

Score¶

Paradigms¶

“Reconstructions” and “Models”¶

“Lumped” and “Split” Biomass Reaction¶

“Average” and “Unique” Metabolites¶

Experimental Data¶

Custom Tests¶

Custom Test Setup¶

A Custom Test Module¶

Minimal Test Module & Simple Test Function Template¶

Parametrized Test Function Template¶

Custom Test Configuration¶

The Custom Option¶

The Pytest Option¶

Guidelines¶

Test Suite¶

Core Tests¶

Annotation¶

Basic¶

Biomass¶

Consistency¶

Matrix¶

SBO¶

Thermodynamics¶

Experimental Tests¶

Essentiality¶

Growth¶

Contributing¶

Report Bugs¶

Fix Bugs¶

Implement Features¶

Write Documentation¶

Submit Feedback¶

Get Started!¶

Pull Request Guidelines¶

Credits¶

Development Leads¶

Contributors¶

History¶

Next Release¶

0.14.0 (2023-09-13)¶

0.13.0 (2021-06-12)¶

0.12.1 (2021-06-12)¶

0.12.0 (2020-10-20)¶

0.11.1 (2020-08-10)¶

0.11.0 (2020-06-26)¶

0.10.2 (2020-03-24)¶

0.10.1 (2020-03-24)¶

0.10.0 (2020-03-24)¶

0.9.13 (2019-12-04)¶

0.9.11 (2019-04-23)¶

0.9.10 (2019-04-23)¶

0.9.9 (2019-04-17)¶

0.9.8 (2019-04-01)¶

0.9.7 (2019-03-29)¶

0.9.6 (2019-03-06)¶

0.9.5 (2019-02-21)¶

0.9.4 (2019-02-20)¶