You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed recently that the models generated via all of the modelseed services have explicitly-represented boundary metabolites rather than the standard use of a true boundary (e.g., standard is extracellular metabolites -> Ø as boundary reactions; modelseed-generated SBML files now have extracellular metabolites -> boundary metabolite with no exchange reaction for the boundary metabolite). I am struggling to find which ModelSEED repository this change was implemented in so thought this would be a decent start.
This doesn't affect reconstructions read into COBRApy, since COBRApy will automatically add exchange reactions for boundary metabolites that don't have them, as in the current SBML models output by modelseed. But, this likely breaks many bespoke pipelines which had been using the _e/_e0 suffix for identification of exchange reactions or for other programs that do not automatically introduce exchange reactions for the new boundary metabolites.
I strongly recommend reverting the change, but understand there are some cases where this is convenient, e.g. multi-species models that need an explicit boundary (or an additional compartment) to differentiate conveniently between community and single-species uptake/secretion rates. But, this seems like it should not be the default for models generated for individual species.
The text was updated successfully, but these errors were encountered:
From the beginning, ModelSEED metabolic reconstructions were designed to work interchangeably with different media, in that each medium, simply a set of compounds with constraints, could be designed independently, and multiple media could be used with the same reconstruction. This meant that, in turn, the metabolic reconstructions built within the ModelSEED ecosystem don't have boundary metabolites, and, when running FBA within the same system, we'd choose the media as well as the model, as a parameter, and the boundary metabolites are created and integrated dynamically during the run.
When the SBML is exported, the code will automatically add boundary metabolites for all of the extracellular metabolites in the reconstruction, and we did test our exported SBML files with COBRApy to see if they worked, which they do. I personally didn't realize that COBRApy automatically adds exchange reactions, and it seems like that's a feature most metabolic modeling packages should include, or even warn about, as a way of validation.
We will have a look at your request, and discuss whether and how to implement it.
I noticed recently that the models generated via all of the modelseed services have explicitly-represented boundary metabolites rather than the standard use of a true boundary (e.g., standard is extracellular metabolites -> Ø as boundary reactions; modelseed-generated SBML files now have extracellular metabolites -> boundary metabolite with no exchange reaction for the boundary metabolite). I am struggling to find which ModelSEED repository this change was implemented in so thought this would be a decent start.
This doesn't affect reconstructions read into COBRApy, since COBRApy will automatically add exchange reactions for boundary metabolites that don't have them, as in the current SBML models output by modelseed. But, this likely breaks many bespoke pipelines which had been using the _e/_e0 suffix for identification of exchange reactions or for other programs that do not automatically introduce exchange reactions for the new boundary metabolites.
I strongly recommend reverting the change, but understand there are some cases where this is convenient, e.g. multi-species models that need an explicit boundary (or an additional compartment) to differentiate conveniently between community and single-species uptake/secretion rates. But, this seems like it should not be the default for models generated for individual species.
The text was updated successfully, but these errors were encountered: