Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 21 20:48
    cdiener commented #926
  • Jan 21 20:23
    Midnighter commented #926
  • Jan 21 19:29
    cdiener opened #926
  • Jan 17 13:49
    Midnighter commented #925
  • Jan 16 23:59
    achillesrasquinha commented #925
  • Jan 15 21:40
    Midnighter commented #925
  • Jan 15 20:15
    achillesrasquinha edited #925
  • Jan 15 20:14
    achillesrasquinha opened #925
  • Dec 20 2019 13:57
    matthiaskoenig labeled #902
  • Dec 14 2019 20:23
    Midnighter closed #913
  • Dec 14 2019 20:23
    Midnighter commented #913
  • Dec 14 2019 20:22
    Midnighter closed #921
  • Dec 14 2019 20:22
    Midnighter commented #921
  • Dec 14 2019 20:22
    Midnighter closed #924
  • Dec 14 2019 20:22
    Midnighter commented #924
  • Dec 14 2019 19:33
    zeawoas commented #924
  • Dec 14 2019 19:33
    zeawoas commented #924
  • Dec 14 2019 13:03
    Midnighter commented #924
  • Dec 12 2019 21:17
    cdiener commented #924
  • Dec 12 2019 21:17
    cdiener commented #924
Adam Dama
@adama11

Hi all,
I have come across an issue with my model improperly defining my exchange reactions. I am trying to use the cobra.medium.minimal_medium() function, but since it is only recognizing my exchange reactions as boundary and not exchanges, my results are incorrect.

I've pasted how the model defines my reactions here: boundary and exchange reactions
I used the following code to obtain the definitions:

As you can see, it recognizes a couple of the exchanges, but the majority are defined as

Can anyone help me get my model to recognize the exchange reactions (the reactions named with "_exch")?

Thanks,
Adam

Code:
   model = load_cobra("models/iSMUv01_CDM_LOO.xml")

    print("############## BOUNDARY ##############")
    for rxn in model.boundary:
        print(rxn)
    print("\n\n")
    print("############## EXCHANGE ##############")
    for rxn in model.exchanges:
        print(rxn)
    print("\n\n")
    print("############## SINKS ##############")
    for rxn in model.sinks:
        print(rxn)
    print("\n\n")
    print("############## DEMANDS ##############")
    for rxn in model.demands:
        print(rxn)
*typo: The majority are not recognized at all as sink, demand, or exchange
Moritz E. Beber
@Midnighter
Hey @adama11, it looks like some of the content you meant to paste here is missing? What I cannot tell from what you have shown so far is, if the compartments are correctly set up in your model. From the output it looks like all metabolites are in [e] (which seems correct) but maybe there is a difference to the exchange reactions that are being recognized?
Adam Dama
@adama11

@Midnighter Thanks for the reply.

  1. Just to double check, you're able to see everything in my pastebin code output?-- if so, then you're seeing everything I intended to paste.
  2. As for compartments, I only have {'c': 'c', 'e': 'e'} set up.
  3. Yes, maybe the reactions are set up wrong. But, the way I understand exchange reactions is that they just need a product/reactant in an external compartment, with the other side of the reaction being null--which is how the unrecognized reactions are set up--am I incorrect in that definition?

The strangest behavior that I'm confused by is that many of my reactions (most of the ones named with "_exch") do not show up as sink, demand, or exchange; yet, they show up in the boundary reaction set. I thought that boundary was a superset of only sink, demand, and exchange sets, but many reactions only appear in the superset and none of the subsets.

Thanks,
Adam

Christian Diener
@cdiener
Yeah this is is big here. What trips up C brapy is that it has some standardized I'd notations that are usually used to annotate reaction types. One if the is DM_* which usually denotes demand reactions. This the names like _CDM_exch are annotated as not being exchanges. This should only match the beginning of the ID. I'll put in a PR.
Moritz Stüve
@mostueve_gitlab
Hey Adam, which ID do you pass into add_boundary() when you define the exchange reactions? I always try to get rid of the prefixes and suffixes (so only the metabolite id), since cobrapy will add them again when you define a boundary (I have had some trouble with exchange reactions myself).
Adam Dama
@adama11
@cdiener Great, thank you for the explanation; that makes a lot of sense! I’ll rename my reactions.
@Midnighter I’m not sure I entirely understand, but I am not explicitly calling add_boundary(), I’ve been letting cobrapy automatically define the boundary reactions. But I’ll look into it, thanks!
Christian Diener
@cdiener

Yeah this is is big here. What trips up C brapy is that it has some standardized I'd notations that are usually used to annotate reaction types. One if the is DM_* which usually denotes demand reactions. This the names like _CDM_exch are annotated as not being exchanges. This should only match the beginning of the ID. I'll put in a PR.

Too much phone autocorrect here ;) Should be "Yeah this is a bug here. What trips up cobrapy is that it has some standardized ID notations that are usually used to annotate reaction types. One of them is DM_* which usually denotes demand reactions. Thus, the names like _CDM_exch are annotated as not being exchanges. This should only match the beginning of the ID. I'll put in a PR."

Moritz Stüve
@mostueve_gitlab
Hi everyone, I am (again) having problems with identifiers. Right now, when I use cobrapy 17, my sbml models can no longer be read. The identifiers look like this: M_OCTADEC__9__ENE__118__DIOIC__ACID (for example). Of course, not all of them are like this. This stems from a function which converts MetaCyc ID's so the resulting ID does not contain hyphens. The error that is raised is ValueError: Names cannot contain whitespace characters. "OCTADEC ENEvDIOIC__ACID" contains whitespace character " ". I believe that the sbml parser somehow converts things like __9__ into tabs? What would the ID's have to look like or is there any other workaround for this? Any help is greatly appreciated.
Jose Antonio Pereiro Morejon
@josePereiro
Hi everyone, I'm new in gitter and cobrapy. I having a problem reading GEMs SBML files downloaded from https://www.metabolicatlas.org/gems/repository. I'm using Python 3.7.2 and cobra 0.17.1. It is printing a ton of warnings about undefined upper and lower bounds, but the files contain this information. I think it has something to do with the SBML file version. Any clue that can help me?
Moritz Stüve
@mostueve_gitlab
@josePereiro you could try the padmet sbml conversion tools from https://github.com/AuReMe/padmet-utils/tree/master/padmet_utils/connection
i have to look up how to use them correctly though (you can convert different sbml versions to one another). have you already checked the validity of your sbml files?
Moritz Stüve
@mostueve_gitlab

@josePereiro the usage of the padmet utilities to convert from one sbml version to another is as follows:

sbml_to_padmet.py --sbml=FILE --padmetSpec=FILE
sbmlGenerator.py --padmet=FILE --output=FILE --sbml_lvl=STR
        # thus e.g.
    python3.5 sbml_to_padmet.py --sbml=infile.xml --padmetSpec=padmetFile.xml.tmp
    python3.5 sbmlGenerator.py --padmet=padmetFile.xml.tmp --output=outfile.xml --sbml_lvl="2"

there was an issue with the python version in the past, I do not know if it is fixed. That is why it says python3.5 .
What the above does is convert to the padmet format, which is generalized, and then with the .tmp file as input to the sbml version you want.

Jose Antonio Pereiro Morejon
@josePereiro
@mostueve_gitlab 1e9 thanks for the reply. Im trying that right now!!!
Jose Antonio Pereiro Morejon
@josePereiro
@mostueve_gitlab, I was trying to run the scripts but Im failing to install padmet, Could not find a version that satisfies the requirement matplotlib==3.1.1 (from padmet) I have tried using python 3.5.8 and 3.5.3 . How exactly do you set up the environment to make it work?
Thanks in advance :)
Kenan Jijakli
@kjijakli
How do you change the optimization problem's sense to a minimization? I tried model.optimize(objective_sense='minimize'), but it didn't work.
Jose Antonio Pereiro Morejon
@josePereiro

@josePereiro the usage of the padmet utilities to convert from one sbml version to another is as follows:

sbml_to_padmet.py --sbml=FILE --padmetSpec=FILE
sbmlGenerator.py --padmet=FILE --output=FILE --sbml_lvl=STR
        # thus e.g.
    python3.5 sbml_to_padmet.py --sbml=infile.xml --padmetSpec=padmetFile.xml.tmp
    python3.5 sbmlGenerator.py --padmet=padmetFile.xml.tmp --output=outfile.xml --sbml_lvl="2"

there was an issue with the python version in the past, I do not know if it is fixed. That is why it says python3.5 .
What the above does is convert to the padmet format, which is generalized, and then with the .tmp file as input to the sbml version you want.

Worked perfectly for python 3.7.5.
Thanks again!!!

Moritz E. Beber
@Midnighter
@kjijakli can you please open an issue for that with a bit more code on what exactly you tried to achieve?
Kenan Jijakli
@kjijakli
Sure. Thanks
Jose Antonio Pereiro Morejon
@josePereiro

Hi everybody, I have a silly situation. I have a GEM sbml file that in the related publication sais to have 3975 metabolites and 4555 reactions but once I loaded it has different dimensions.

>>> len(model.metabolites)
5427
>>> len(model.reactions)
4555

I downloaded from https://www.metabolicatlas.org/gems/repository and this situation is happening with others models too. I don't know if this is normal, but if it is, how can I fix it.
Thanks :)

Moritz E. Beber
@Midnighter
They probably report the number of unique metabolites in the publication whereas when you load the model, you also count the same metabolite in different compartments.
Jose Antonio Pereiro Morejon
@josePereiro
@Midnighter thanks for replying but, if this is the case, now the system is overestimated for FBA. I have more equations (metabolites balance equations) than variables (fluxes). That makes no sense!!
Plus, the reaction number didn't change. That means that all the transport reactions for the different metabolites, of the different compartments, were included in the paper, why no all the metabolites too :(
Christian Diener
@cdiener
Also boundary metabolites may get additional helper metabolites I think. Does your model include metabolites that have a boundary condition set? Your model is not necessarily overspecified. You would have to look at the nullspace to say anything about that. Most FBA models have no unique solution anyways even when you have more metabolites than reactions because there are large sets of metabolites that are linearly dependent on each other.
Christian Diener
@cdiener
May also be related to opencobra/cobrapy#886. Could you check that metabolites with an exchange reaction do not boundarCondition=true at the same time (not allowed by SBML spec).
Matthias König
@matthiaskoenig
Yes, this should be the boundary metabolites.
In the earlier version of the parser all the boundary species were deleted from the model. This created many issues, namely: 1. reactions with boundary species are not mass and charge balanced any more; 2. constraints cannot be set on removed boundary species, i.e. it was not possible to manipulate these; 3. metabolites are deleted (which is a problem in itself), i.e. they don't exist any more in the model
The correct way to handle boundary conditions is by adding exchange reactions which allow to set constraints on the exchange reactions (for instance restricting import or export on them). These maintains the boundary species, but adds exchange reactions for them. So the discrepancy in the species/metabolite count is most likely due to species with boundaryCondition=True in your model.
Matthias König
@matthiaskoenig
But having 1500 more metabolites in the model looks more like a serious issue with the model. I.e., either there are ~1500 boundary species in your model which makes no sense at all because basically everything can be exchanged, or you got an incorrect model.
For instance, often people have 2 or more SBML files, one corresponding to the "knowledge base" which contains for instance things like dead end metabolites and so on, and a pruned model for simulation, which is a reduced and cleaned model for FBA. Perhaps you got the wrong model version here.
Daniel Machado
@cdanielmachado
dear all, does anyone know if there is any implementation in cobrapy of GlobalFit, GrowMatch, or any other method that can automatically fix a false positive growth prediction ?
Moritz E. Beber
@Midnighter
@josePereiro can you link one specific example, please? With model and paper.

@cdanielmachado https://github.com/opencobra/cobrapy/releases/tag/0.6.0

Gapfilling
The SMILEY and growMatch implementations were refactored to a
single new function cobra.flux_analysis.gapfilling.gapfill which
handles both use-cases.

Daniel Machado
@cdanielmachado
looking at the code it seems to only be able to fix false negatives (i.e. traditional gap-filling)
Jose Antonio Pereiro Morejon
@josePereiro

@Midnighter
Here an example: I download the model xml file from U-251 MG, and the associated publication is nature. In the table1 of the publication (last row) says that the model has 5320 reactions and 4209 metabolites, but once I loaded (using Python 3.7.5, cobra 0.14.0) I get:

>>> model = cobra.io.read_sbml_model('models/U-251 MG.xml');
>>> len(model.reactions)
5320
>>> len(model.metabolites)
6157

As I can find more models with the same behavior I must be the one who is missing something!!!

Matthias König
@matthiaskoenig
The publication is wrong like so often (basically model change a lot in review, things are incorrectly reported, especially in high impact journals).
The SBML file has 5320 reactions and 6403 species.
You use an old cobrapy version which still removes boundaryMetabolites, explaining the reduction of metabolites on import
Newer versions of cobrapy handle the boundarySpecies correctly as exchange reactions.
You have many more species then reactions, probably due to the method of generating the "model". This is some automatic reconstruction pipeline most likely containing a lot of non-sense.
Greg Medlock
@gregmedlock
@josePereiro keep in mind metabolites that are duplicated across compartments are represented as different metabolites in cobrapy; the authors of the paper may have collapsed these metabolites in their counts. Summing # of metabolites across compartments gives you this (I assume "C_s" or "C_c" are cytosolic):
{'C_c': 1588, 'C_r': 460, 'C_s': 2531, 'C_m': 636, 'C_p': 330, 'C_l': 316, 'C_g': 197, 'C_n': 99, 'C_x': 246}
Greg Medlock
@gregmedlock
Seeing the discussion above now... I would not worry about what is reported in the table. This is why we have SBML :)
Jose Antonio Pereiro Morejon
@josePereiro
@matthiaskoenig @cdiener @Midnighter @gregmedlock Thanks for replay!!!
I just read the official cobrapy documentation, where can I find further information about the model's structure, best practices, and cobra general way of think?
Jose Antonio Pereiro Morejon
@josePereiro
Besides, where else can I find publicly available, cell-specific or context-specific well documented human models? I already looked in https://www.metabolicatlas.org/gems/repository, https://www.ebi.ac.uk/biomodels/, http://bigg.ucsd.edu/models and https://darwin.di.uminho.pt/models/. Thanks again for your help :)
Christian Diener
@cdiener
Ines Thiele's group provides a human model at https://www.vmh.life/ and there are also several at https://www.metabolicatlas.org/.
Christian Diener
@cdiener
@cdanielmachado do you mean for a single set of import constraints? CORDA supports assigning negative confidence to reactions, meaning that it will try to exclude them (but it may not succeed based on other scores)...
Christian Diener
@cdiener
If you don't have a preference which reaction should be removed then running single reaction deletions work as well. There will be at least one essential reaction you could remove and that would be minimal...