FBC results

[Melchior du Lac]

As I understand it, the COBRA community is heavily involved in the usage/development of the FBC package. So I permit myself to post the question here. Please do not hesitate to direct me to a more relevant place if this is not the case.

We are developing a workflow (some call it a pipeline) for metabolic engineering and would like to use a single SBML file to hold all our required information and communicate between the different nodes. Some of our requirements are not officially supported in the SBML format, like the SMART or SMILES description of a molecular species. Nevertheless we where able to define our in-house <annotation> tags to hold that type of information and although it is not read by other SBML readers its fine for internal usage.

One of the nodes involves performing FBA analysis and we would like to store some of the output fluxes directly in the SBML. As far as I know SBML nor the FBC extensions permits that. My first though was to create another in-house <annotation> tag for the reactions involved and store the resulting fluxes there. 

Is there a better way? Has there been some work regarding the storage of constraint based simulations in an SBML? 

Thanks

[Thomas Pfau]

Hi,

In general, the sbml-flux mailing list ( sbml...@lists.sourceforge.net ) would be the place for this kind of question.

But find some answers below:

Am 26.02.2019 um 12:00 schrieb Melchior du Lac:

As I understand it, the COBRA community is heavily involved in the usage/development of the FBC package. So I permit myself to post the question here. Please do not hesitate to direct me to a more relevant place if this is not the case.

We are developing a workflow (some call it a pipeline) for metabolic engineering and would like to use a single SBML file to hold all our required information and communicate between the different nodes. Some of our requirements are not officially supported in the SBML format, like the SMART or SMILES description of a molecular species. Nevertheless we where able to define our in-house <annotation> tags to hold that type of information and although it is not read by other SBML readers its fine for internal usage.

In the COBRA Toolbox, we currently store this in the notes section (which is not the place this should be located), but an annotation sounds fine.
With the coming FBC v3, we will store these kind of annotations which are not referenced via identifiers.org in the key/value fields that fbc v3 will offer. But this will at least take till the next libsbml release.

One of the nodes involves performing FBA analysis and we would like to store some of the output fluxes directly in the SBML. As far as I know SBML nor the FBC extensions permits that. My first though was to create another in-house <annotation> tag for the reactions involved and store the resulting fluxes there.

The only "built-in" Method that would make some sense would be to store this as the rate law of the reaction (but this is really odd).
Whats commonly stored is the formulation of tge FBA analysis, i.e. the flux constraints and objectives, which would indicate the individual simulation.
SBML (for all I know) is not intended to transfer Results for simulations but rather to provide all details to perform the simulation. Mainly because any stored result would depend on the precision of the stored numbers.

Why would you need to keep the FBA result in the SBML file? A single LP (assuming its a standard FBA) should be faster than any IO you could achieve on a SBML file, or rather it should be negligible when run in a pipeline. So if you store the definition of the LP (via FluxObjective/Fluxbounds) shouldn't this be sufficient?

Best

Thomas

--

---
You received this message because you are subscribed to the Google Groups "COBRA Toolbox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cobra-toolbo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ronan M.T. Fleming]

Hi Melchior,

Are you talking about adding extra fields to SBML files to represent some additional output?

XML-like files are useful for sharing the end result of computations as they are in a standard format. They should not be used as the data storage format for intermediate computations as they are difficult to manipulate. 

Regards,

Ronan

--

--
Mr. Ronan MT Fleming B.V.M.S. Dip. Math. Ph.D.
----------------------------------------------------------------------------
Assistant Professor,

Division of Systems Biomedicine and Pharmacology,

Leiden Academic Centre for Drug Research,

Faculty of Science,

Leiden University.

https://www.universiteitleiden.nl/en/staffmembers/ronan-fleming

&

H2020 Project Coordinator

Systems Medicine of Mitochondrial Parkinson’s Disease

http://sysmedpd.eu

----------------------------------------------------------------------------
Mobile:  +353 873 413 072
Skype: ronan.fleming
----------------------------------------------------------------------------
(This message is confidential and may contain privileged information. It is intended for the named recipient only. If you receive it in error please notify me and permanently delete the original message and any copies.)

[Melchior du Lac]

Thanks for the response. 

Why would you need to keep the FBA result in the SBML file? A single LP (assuming its a standard FBA) should be faster than any IO you could achieve on a SBML file, or rather it should be negligible when run in a pipeline. So if you store the definition of the LP (via FluxObjective/Fluxbounds) shouldn't this be sufficient?

I never looked at it that way! Since we wanted to provide a visual output of the intermediate fluxes and the flux of the whole pathway, it seemed logical to us to simply store the results. We also considered using optimisation algorithms such as OptGene and OptKnock. However I guess we could store the results of the optimisation and not of the fluxes directly. 

Thanks again for the suggestion. At least for the most basic FBA analysis it seems like this is the sensible approach.

Cheers.