Include getModelParameters scripts (see this PR for more info)for the following models as model-specific scripts:

• YeastGEM
• KmxGEM
• iYali4
• HumanGEM
• iML1515

raven, cobra and libsml should be updated automatically - at the moment they need to be manually updated by logging into the self-hosted runner.

• RAVEN
• COBRA
• libsbml

Description of the bug

Even if the pipeline seems to apply GECKO successfully, the expected PRs do not get created. A preliminary investigation points to hub not handling the authentication.

I think I have found a bug in the human ec model (which does not exist in Human1).
In Human-GEM, reaction HMR_7197 looks like this:
[protein][c] + serine[c] => [protein]-L-serine[c] + H2O[c]
But, in the ec model, it looks like this when I do constructEquations:
[protein][c] + serine[c] => L-serine[c] + H2O[c]
So, the [protein]- part of the L-serine seems to have gone missing. We suspect that it has something to do with the square brackets, or potentially the word "protein".

Deal with GEMs without the url option in their config section - instead of cloning just download using the download_url.

This repo has already become an ecosystem, biology is complex in nature, but we can try to keep a sustainable and simple branching system.

We should think about:

• simplicity (an easy-to-follow/visualize graph)
• clear set of permissions and PR criteria
• Allow automated integration
• Storage (model files without original repo)

Complete automation of the ecModels pipeline for the following models:

• iYali4
• ecHuman-GEM
• ecYeast-GEM
• eciSM996
• iML1515

@CarlMalina has detected inconsistencies in some grRules related to the oxidative phosphorylation and electron transport chain pathways in the iSM996 model for K. marxianus. After manual curation and a detailed revision of the genes involved in this pathway for Kmarx in KEGG and Uniprot, these are his findings:

• r_0175 corresponds to complex IV; r_0176 to complex III; r_0177 to ATP synthase.

As it is shown in the table above, the previous grRules assume that these reactions are catalyzed by isoenzymes with a single subunit; in contrast, the suggested new grRules indicate that these reactions are catalyzed by isoenzymes, each of them consisting on enzyme complexes with several subunits.

This issue might not represent a major problem for phenotype predictions with the iSM996-GEM, however this is a major problem for its enzyme-constrained version (available here), as the enzyme requirements for these three reactions are currently under-representing the enzyme demands of the full respiratory complexes.

A repercussion of this is observed in the fact that the sigma factor its fitted to a value of 0.3 by the GECKO pipeline for eciSM996 model (evidence of this can be found in the log of the automated ecModels pipeline for this model, available here). This represents the average saturation factor for all enzymes for K. marxianus growing on conditions of unlimited glucose, which takes a value around 0.5 for all of the other organisms that have been tested with this pipeline.

Discussed in #104

In the current implementation of the automated workflow, the GECKO pipeline is programmed to run exclusively on GEMs whose version has changed,or for all models if any of the dependencies changes its version. This situation will eventually make that, when changes are introduced into any file in this repository, GEM-specific PRs are not gonna be created because a change in the source model version are not taking place.

Therefore, we need that our pipeline is able to run and create PRs for a model, every time that:

• A change in the source model version is detected by a scheduled run.
• When changes in the GECKO toolbox are detected by a scheduled run (new release).
• When changes are introduced into the ecModels repo (push events to branches other than master and update...)

It has been agreed that all original models' structures (version controlled or not) should be loaded from their corresponding SBML file. Currently, the version of the model can be obtained in several ways by the ecModels pipeline (e.g. read from a MATLAB structure or provided by the user).

A generalized way to read the model's version is to parse it from the <name> or <id> fields in the SBML file. As an example, the model name and Ids lines for the Kmx and iYali models are provided here:

• model metaid="kmxGEM.xml" id="M_kmxGEM_v1_46_0_46_0" name="The Consensus Genome-Scale Metabolic Model of Kluyveromyces marxianus" fbc:strict="true"
• model metaid="iYali" id="iYali" name="Yarrowia_lipolytica-GEM_v4.1.1" fbc:strict="true"

As a solution, a python script can be developed in which the version is parsed from this file, trying it on both fields <name> or <id> and, if absent a default v1.0.0 string is introduced

The SBML file is valid with the online validator. However, with cobrapy version 0.26.2 I get this error when I try to read the eciML1515.xml file with cobra.io.read_sbml_model:

raise ValueError('Variable names cannot contain whitespace characters. "%s" contains whitespace character "%s".' % (name, char))

This error comes from the reaction with ID R_protein__32__pseudoreaction on line 61811 of the xml file. Changing this ID to e.g. R_protein_pseudoreaction resolves the issue.

Hi, I'm trying to use the ecYeast model, on matlab with COBRA and then I set up the model without any modifications:

model=readCbModel('ecYeast.xml');
writeCbModel(model,'format','xls');
biomassRxn = 'r_2111';
ethanolRxn = 'r_1761';
glucose = 'r_1714';
oxygen = 'r_1992';
model = changeObjective(model, biomassRxn);
changeCobraSolver('gurobi', 'all');
solution=optimizeCbModel(model);

Then, I create another model to change the lower bound of glucose to -10:

modelGlu=changeRxnBounds(model,glucose, -10, 'l');
solutionGlu=optimizeCbModel(modelGlu);
printFluxVector(modelGlu, solution.x, false, false);

And finally, I create another model, on the top of the modelGlu, with the O2 exchange lower bound at -1:

modelMix=changeRxnBounds(modelGlu,oxygen, -1, 'l');
solutionMix=optimizeCbModel(modelMix);
printFluxVector(modelMix, solution.x, false, false);

But, as you can see, on the solution vector, the O2 reaction didn't change to -1 as is supposed to (but the glucose changed to -10, though):

I also tried to create a model only with the O2 modification, and the same happened. Also tried to use the batch model, and it's the same.

So, I ask if the model is taking into account that I set the O2 to -1 or if the modification I did doesn't occur at all.

Thanks

But first merge mihai-sysbio/GECKO/commits/feat/ecModels-jenkins into SysBioChalmers/GECKO
The changes align the contents of the databases folder for all GEMs.

In the latest long runs of the automated pipeline (run1, run2, run3) it has been observed an error in the MATLAB command for the iYali case. All of these errors point out to the same line (429) in the corresponding manualModifications script, however this script is much shorter for this case, which makes conclude that the pipeline is not substituting the iYali-specific scripts into GECKO, therefore an error pops-up in MATLAB and our pipeline is crashing.

Any ideas on how to solve this? I also think that we've seen happening before but don't remember so well.