feat: Implemented GECKO Light functionality in GECKO 3.

[johan-gson]

trafficstars

Also adapted the code to be able to handle Human-GEM in addition to Yeast-GEM. I have not tested the code with Yeast-GEM. The code is not well tested at this point.

I hereby confirm that I have:

• [ ] Tested my code with all requirements for running GECKO
• [ ] Selected devel as a target branch (top left drop-down menu)

[feiranl]

I just have one concern. The unit of added protein pool/enzyme in gecko light and normal gecko should be consistent(umol/gDW or mmol/gDW), which will be much easier for further analysis functions such as analyze protein pool usage. @edkerk , I totally agree that we need to do the scale up to avoid small fluxes. As I understand, GECKO2 is converting mmol to gram in enzyme usage rxns, which causes small fluxes. We can actually just change the unit of protein pool from gram to mg, then the enzyme usage from protein pool conversion will be from mmol to mg, which actually scales up 3 magnitude, and all units in most of reactions are in mmol, except the protein pool rxn.

[johan-gson]

I just have one concern. The unit of added protein pool/enzyme in gecko light and normal gecko should be consistent(umol/gDW or mmol/gDW), which will be much easier for further analysis functions such as analyze protein pool usage. @edkerk , I totally agree that we need to do the scale up to avoid small fluxes. As I understand, GECKO2 is converting mmol to gram in enzyme usage rxns, which causes small fluxes. We can actually just change the unit of protein pool from gram to mg, then the enzyme usage from protein pool conversion will be from mmol to mg, which actually scales up 3 magnitude, and all units in most of reactions are in mmol, except the protein pool rxn.

Agreed, could someone help me fix that or tell me exactly what I should change to get it right?

[johan-gson]

Ok, seems I lost write access to the repo, I sent a message to Ivan, but any changes may be delayed a bit.

[edkerk]

Ok, seems I lost write access to the repo, I sent a message to Ivan, but any changes may be delayed a bit.

Should be fixed now.

[johan-gson]

ok, thanks, it worked now!

[edkerk]

I just have one concern. The unit of added protein pool/enzyme in gecko light and normal gecko should be consistent(umol/gDW or mmol/gDW), which will be much easier for further analysis functions such as analyze protein pool usage. @edkerk , I totally agree that we need to do the scale up to avoid small fluxes. As I understand, GECKO2 is converting mmol to gram in enzyme usage rxns, which causes small fluxes. We can actually just change the unit of protein pool from gram to mg, then the enzyme usage from protein pool conversion will be from mmol to mg, which actually scales up 3 magnitude, and all units in most of reactions are in mmol, except the protein pool rxn.

I think this would indeed also work!

[johan-gson]

So, I'm not sure I get what you mean fully, but will explain anyway :). Since YeastGEMAdapter inherits ModelAdapter, it will automatically have all the functions that are in ModelAdapter through the inheritance. What we do in HumanGEMAdapter is to *override *the function getUniprotCompatibleGenes(obj,model) and provide a different implementation. If we had not done that, HumanGEMAdapter and YeastGEMAdapter would both have the implementation of the base class, which just returns the genes as is. Since that strategy doesn't work for HumanGEMAdapter, we provide a different implementation. This is (some of) the power of object-oriented programming, that you can inherit something and override the things you don't like.

On Fri, Dec 16, 2022 at 6:55 PM Eduard Kerkhoven @.***> wrote:

@.**** commented on this pull request.

In geckomat/model_adapter/ModelAdapter.m https://github.com/SysBioChalmers/GECKO/pull/180#discussion_r1051245481:

•    %The genes returned here should match the gene id set in the parameter params.uniprotGeneIdField
  

•    function genes = getUniprotCompatibleGenes(obj,model)
  

•        genes = model.genes;
  

•    end
  

But it should be included, as makeEcModel is calling uniprotCompatibleGenes = modelAdapter.getUniprotCompatibleGenes(model);, and for simples cases this should just output model.genes as is done in this template adapter.

— Reply to this email directly, view it on GitHub https://github.com/SysBioChalmers/GECKO/pull/180#discussion_r1051245481, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHX2AK2CPLMFYEAJTMBPLCDWNT6QVANCNFSM6AAAAAAQ3DYELY . You are receiving this because you authored the thread.Message ID: @.***>

[edkerk]

@johan-gson I've made a separate branch (https://github.com/SysBioChalmers/GECKO/tree/feat/fuzzyMatching) with the fuzzy-matching commit and removed it from this PR, otherwise the current PR becomes gigantic. It would be good to finish this PR and merge it to devel3, and then continue from that.

[edkerk]

In full GECKO, model.ec.kcat only contains kcat values that are actually incorporated in the model (and this is also reflected in model.ec.rxns etc.). selectKcatValue can take a kcatList, which can contain multiple kcat values per reaction (because of multiple substrates, or multiple isozymes & subunits), and from this kcatList select one kcat value per reaction to make it into model.ec.kcat. All that applyKcatConstraint does it take the value in model.ec.kcat and turn this into a coefficient in the S-matrix.

GECKO light currently has all isozymes as separate entries in model.ec.kcat, where applyKcatConstraint selects the highest kcat value across enzymes. For consistent usage, selectKcatValue should do this in GECKO light: take all predicted kcat values per reaction (across isozymes) and take the highest value across isozymes. Which isozyme this came from can be documented in model.ec.notes.

@johan-gson Do you have a strong reason why the current approach would be preferred? Otherwise it would be best to refactor and have consistent behaviour across the two model types. applyKcatConstraints could be called multiple times when repeatingly simulating the model with slightly different kcat values, so it would be beneficial to move this selection of highest-across-isozymes to selectKcatValue instead. I can do the refactoring.

[johan-gson]

The problem is that GECKO light doesn't take the largest kcat, it takes the smallest MW/kcat, so if the enzymes have different MW this may not be right. This is why I propose to either add an extra mapping field or do something with the rxn id for the light model.

[edkerk]

Clear answer, then it's left like it is.

The issues with stochiometric coefficients as discussed in #147 will be solved in a separate PR (possibly #188).