cobrapy core model structure

[ronan.mt...@gmail.com]

Hi,

to work toward interoperabilty between COBRA software, I'm trying to establish a correspondence between variables in different COBRA model implementations in different tools/languages.

Could someone please point me to a list of core COBRApy model fields, their dimensions, data types and a description of each field, like in this file:

https://github.com/opencobra/cobratoolbox/blob/master/docs/source/notes/COBRAModelFields.md

Regards,

Ronan

[moritz...@gmail.com]

Dear Ronan,

Can you say a few more words on what sort of interoperability you have in mind? At the surface, it seems quite challenging to reconcile the matrix interface of the toolbox with the object-oriented one of the Python package.

I had started a similar exercise looking at just the major Python packages (that I knew of), when thinking about a core model class on the Python side, that each package could then build upon. As you will see in the document, I didn't get very far as I then left the field. You can see, however, that such class diagrams are quickly generated by an IDE and may help you. https://docs.google.com/document/d/1exQAGTIe2PPjJS5QW5lxY9Ggk03KDBQRO2MuY-rfJPc/edit#heading=h.u7n2es5hzg6n

For COBRApy, there is also the reference documentation which has the information that you are looking for. All the "core" objects are documented at the following site https://cobrapy.readthedocs.io/en/latest/autoapi/cobra/core/index.html.

Finally, we have existing functions to load a model from a Matlab file. Either the function or its source code may also help you in your endeavour https://cobrapy.readthedocs.io/en/latest/io.html#MATLAB.

Best regards,

Moritz

--
You received this message because you are subscribed to the Google Groups "cobra pie" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cobra-pie+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cobra-pie/c9f39e46-d881-445f-a2d0-26b3797c5421n%40googlegroups.com.

[Ronan M.T. Fleming]

Hi Moritz,

thanks for the pointers. I had not realised that the different python implementations each had their own data structures. The problem of interoperability is worse than I imagined.

I am exploring whether it would be possible to establish a standard data/model/solution structure, implemented as a relational database, accessed via standard database connectors, where each language retains pointers to the data, rather than a copy of the data, to enable multiple languages to operate on the same data structure. A figure of the idea is below. It is a pity you have left the field. Hopefully, you will come back to it!

Hi All,

If someone from the Python community wishes to further explore this, please pitch in.

Regards,

Ronan

You received this message because you are subscribed to a topic in the Google Groups "cobra pie" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cobra-pie/HL2RzyP-fN0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cobra-pie+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cobra-pie/5e88b61f4b82eec2de0e3591d3269c16af9d9065.camel%40gmail.com.

--

--
Mr. Ronan MT Fleming B.V.M.S. Dip. Math. Ph.D.
----------------------------------------------------------------------------
Associate Professor,
School of Medicine,
National University of Ireland, Galway.
&
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

&

Coordinator of the Horizon Europe project "Reconstruction and Computational Modelling for Inherited Metabolic Diseases" (Recon4IMD)

----------------------------------------------------------------------------
Peer-reviewed publications: https://goo.gl/FZPG23
Mobile:  +353 852 109 806
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.)

--

--
Mr. Ronan MT Fleming B.V.M.S. Dip. Math. Ph.D.
----------------------------------------------------------------------------
Associate Professor,
School of Medicine,
National University of Ireland, Galway.
&
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

&

Coordinator of the Horizon Europe project "Reconstruction and Computational Modelling for Inherited Metabolic Diseases" (Recon4IMD)

----------------------------------------------------------------------------
Peer-reviewed publications: https://goo.gl/FZPG23
Mobile:  +353 852 109 806
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.)

[Matthias König]

Hi all,

SBML is solving most of the issue and is the interoperable exchange format between different software (especially also software outside of the COBRA community).

I highly recommend to direct the effort to make the SBML exchange more compatible between the COBRA implementations. I.e. how to encode the things consistently and store the additional information currently not serialized in SBML to SBML.

Otherwise this will not solve many of the issues of COBRA models not being compatible with other software.

Best Matthias

[Ronan M.T. Fleming]

Hi Matthias,

SBML is a format for the exchange of models between software tools, which I agree should be supported by any software tool for COBRA modeling.

However, almost every tool that I am aware of that supports SBML, also generates its own internal data structure in memory for manipulation of model content or storage of modeling results. The reason is that processing is faster and more flexible with an internal data structure than it is with a flat XML file.

Currently, the development of a modeling pipeline where multiple software tools process the same model, or its variants, is only possible if one writes out an SBML file to disk, then reads that back into the next software tool. This is not an efficient solution for processing/modelling pipelines that involved multiple languages and software tools. If it was efficient, there would be no need to reimplement methods first disseminated in one language, into another language.

To develop an efficient processing/modelling pipeline that uses, e.g., the COBRA toolbox and COBRApy and other tools in series, one would need a standard format that is stored in memory and compatible with each tool. Many languages provide drivers for accessing databases, which can be stored in memory, or as a hybrid in memory/on disk, so provided that we could agree on a standard representation of a COBRA model, inspired by SBML, then we could then develop multi-lingual pipelines operating on the same model. This is why I asked about the internal specification of a COBRApy model.

Regards,

Ronan

To view this discussion on the web visit https://groups.google.com/d/msgid/cobra-pie/94d2cbb8-80c7-4f58-b1cb-e58cb2f60dc4n%40googlegroups.com.

[moritz...@gmail.com]

Another thought Ronan, I had started some SQL models here https://github.com/opencobra/cobra-component-models/, but I still think there is the object relational impedance mismatch that might hinder the performance you are looking for. I agree that it might be a good storage format.

[Matthias König]

Currently, the development of a modeling pipeline where multiple software tools process the same model, or its variants, is only possible if one writes out an SBML file to disk, then reads that back into the next software tool. This is not an efficient solution for processing/modelling pipelines that involved multiple languages and software tools.

I don't agree with that. You only have to do the conversion SBML <-> internal model structure once, then you use the cached internal representation. So for every model you exchange you only have to do a single read/write operation per tool. This takes even for very large models not longer then a few seconds to perhaps minutes if you have tens of genome-scale models.

Requiring once a few minutes to initially setup the complete pipeline does not matter at all if afterwards your actual simulations do not have any setup time. You will still need a few seconds to minutes for your serialization and exchange between your cobra internal formats.

So in the overall picture I don't see where this is slow.

We do exactly the same for kinetic models, i.e., do an SBML -> internal presentation once which you cache and only update if the SBML model changed. Is extremely fast and ensures exchangability.

Best Matthias

What is the use case where you would read the model more then once?

 

To view this discussion on the web visit https://groups.google.com/d/msgid/cobra-pie/1a2308a950a820cb0768cae82ed307160b642ffe.camel%40gmail.com.