Closed hongzhonglu closed 3 years ago
As long as the model is valid SBML, should it then not work in both COBRA and cobrapy? What would be an example of when this fails?
I remember there is a GEM, which can be read by COBRA toolbox, but can't be read by cobrapy. I need firstly read it using COBRA and export a new xml file. The new xml file then can be read by cobrapy. I will further test some examples and give you feedback later.
The advantage of using SBML as a standard file format for encoding GEMs is those valid models are agnostic of any particular software solution. We should better encourage modelers to ensure the validity of their SBML file to benefit from the ability to conduct a large variety of different analyses with the same model in several modeling tools, not limited to any particular software.
Tightly coupling a model to a specific software tool can face two severe problems:
For these reasons, storing a model in a valid SBML file is preferable. There are tools to check the validity of a model, such as the SBML validator or MEMOTE. Those can be even used as part of a continuous integration setup of model development and testing.
Please note that the SBML Test Suite now includes constraint-based models, allowing software developers to assess if their software is compliant. Consequently, valid SBML models should run in any standard-compliant software.
There is an automated-validation
branch that relies on GH Actions to run different tests on latest releases of models that follow standard-GEM
. I've just made a note there about SBML testing. Basic YAML testing is in place, but it will take a while until the validation setup is nice and thorough. We should continue to add ideas for validations there.
I am not sure how closely this relates to the issue, or even if it is still an issue with the latest versions of cobrapy and cobratoolbox, but I often encounter models with metabolite names that are read differently by these two softwares, usually the appended '_c' or [c] that denotes the compartment. Is there a best practice that is bulletproof for both softwares?
@sulheim both programs still convert identifiers upon reading models which is not ideal but also somewhat necessary because folks have taken to using identifiers that are not SBML compliant. In cobrapy, we have been discussing not changing the identifiers read from SBML at all but additionally providing a 'nice' identifier that users can work with most of the time. However, this is a long way down the development roadmap.
@sulheim thanks for bringing up this issue regarding compartment abbreviations in metabolite names. Do you think there is a test case that can be added to the automatic validation that is part of standard-GEM #9 ?
If there is no issue on identifier overloading with semantic information yet, please let us create one and continue discussing compartment abbreviations as metabolite identifier suffixes in this different thread.
Good idea @draeger . There is now a note in #9 about the metabolite identifier suffixes. I am now closing this issue, please reopen if needed.
It is know some GEMs can only run on the cobra toolbox based on MATLAB, but it can't be read and used by another popular toolbox-cobrapy. Thus, it should make sure that the GEMs can be used by both MATLAB or cobrapy. Otherwise the test result should be given which toolbox can read and run the GEMs.