Future GECKO architecture

[edkerk]

To consolidate various GECKO-derived approaches, the following refactored design is envisioned.

This will form the basis of GECKO3, any comments or feedback are welcome in this thread.

• Grey squares indicate files
• Yellow squares indicate model structures in MATLAB
• Bold text (white background) indicates function names
• Function names are not final, but indicate what functionality is contained
• No GECKO1-2 function names are reused, to avoid confusion with functions have slightly/very different functionality
• The scheme should not be interpreted as a workflow. For instance: all the methods of obtaining kcat values (fuzzy matching, GotEnzymes, DLKcat, kcat table) can be run in whatever order

Edit 2022-07-09: Updated scheme

[Yu-sysbio]

Looks awesome! I am wondering if we could indicate a default option when there are multiple ones in case users would not care about the technical details between options but just want to generate a functional ecModel. An example is the step of kcat file generation, in which there are three options: runDLKcat, parseGotEnzymes, and fuzzyKcatMatching. Another is the tuning step which has two options: sensitivityTuning and bayesianTuning.

[johan-gson]

Looks very good! Take a look at the Adapter pattern I just made a PR for, I think it can fit in nicely here. The path to for example the species-specific DB could be gotten from there.

Are there any plans to supply a standard kcat value for some of the reactions without GPRs? I did that in Gecko Light.

[johan-gson]

#168

[johan-gson]

Sorry, this was meant as a separate post, not reply :)

[edkerk]

@Yu-sysbio I have now clarified that each bold text is separate function (e.g. runDLKcat, parseGotEnzymes, fuzzyKcatMatching), so they are not separate options within a function. In that sense they cannot be set as default options, but we can indeed define a function like enhanceGEM that selects the basic options without requiring too many details.

[edkerk]

@johan-gson

Are there any plans to supply a standard kcat value for some of the reactions without GPRs? I did that in Gecko Light.

Yes, see constrainNonGeneRxns in the bottom right of the scheme. It doesn't necessarily have to be run at that point of pipeline.

[johan-gson]

ok, sorry, didn't see that, perfect

[edkerk]

To be added/curated:

• loadComplexData that can read e.g. Complex Portal output, to update model.ec.rxnEnzMat with number of subunits in complexes.
• readKcatTable can directly feed into model.ec.kcat, without needing selectKcatValue.

[edkerk]

Most intensive will probably be the functions below, which are all refactoring of existing code, but now they need to interface with the updated model structure:

• fuzzyKcatMatching (based on matchKcats)
• sensitivityTuning (based on modifyKcats)
• bayesianTuning (based on BayesianModelGeneration_cluster)

[mihai-sysbio]

Overall this looks. There are some places where there could be a lot more separation of concerns and one-function-one-purpose:

• loadProtDatabase should only read a flat file:
  • the alternative download from Uniprot to a flat file should be handled by a different function
• the description of parseGotEnzymes is probably "download kcat values from GotEnzymes"
• there should be another function do "download kcat values from BRENDA/SABIO-RK"
• fuzzyMatching should be an optional step after readKcatTable, since it is not guaranteed that the kcat table contains all needed values
• runDLKcat has a misleading title, maybe just prepareInputForDLKcat
  • still, I suspect this is a bit out of concern for GECKO; my suggestion would be to down-prioritize this and give more space for discussion
• both loadKcatDatabase and flexibilizeProteinLevels seem to "read kcat db"

As a general comment, instead of having one "magical" makeEcModel function that aims to do everything (and would thus need to be heavy parameterised), my suggestion would be to expose all the functions under it . The thinking here is that, either as a new or existing user, ease-of-use and confidence is better built when using a tool that works transparently (i.e. one can follow what it going on). Also, a few clear steps are then easier to wrap together in a function by anyone, and they would also go better with a tutorial/SOP.

Regarding the final output, I would also envision an optional summary with stats.

[edkerk]

Thank for the detailed comments! Various changes have been made and the scheme on the top is updated.

• fuzzyMatching should be an optional step after readKcatTable, since it is not guaranteed that the kcat table contains all needed values

All the methods of obtaining kcat values (fuzzy matching, GotEnzymes, DLKcat, kcat table) are optional and can be run in whatever order, the scheme shouldn't be read as the definite workflow. One might choose fuzzy matching and only allow exact EC matches, which leaves many kcat values empty, which one might want to fill with DLKcat values instead. Or you might start with a curated table with kcat values, and indeed, it is far from guaranteed whether it contains all needed values (see also #159). Note that missing kcat values are 0 in model.ec.kcat, and this would just mean that applyKcatConstraints does not include any enzyme usage for that reaction.

• runDLKcat has a misleading title, maybe just prepareInputForDLKcat

  • still, I suspect this is a bit out of concern for GECKO; my suggestion would be to down-prioritize this and give more space for discussion

I agree with splitting the function, but I believe it is a major strength of GECKO to be able to use DLKcat. More discussion is very welcome in #171.

As a general comment, instead of having one "magical" makeEcModel function that aims to do everything (and would thus need to be heavy parameterised), my suggestion would be to expose all the functions under it . The thinking here is that, either as a new or existing user, ease-of-use and confidence is better built when using a tool that works transparently (i.e. one can follow what it going on). Also, a few clear steps are then easier to wrap together in a function by anyone, and they would also go better with a tutorial/SOP.

I would not call makeEcModel "magical", it requires 2 inputs: the model structure, and whether you want GECKO light (default is "full" GECKO). Note that makeEcModel is not supposed to replace enhanceGEM, which indeed aims to do everything. Instead, makeEcModel largely replaces preprocessModel and convertToEnzymeModel, with a simpler model formulation (no arm reactions etc.).

Regarding the final output, I would also envision an optional summary with stats.

As mentioned above, the scheme is not necessarily a whole workflow anyone would want to go through. But summary with stats is indeed very useful. Instead of running as final output, it might be useful to run this at any stage? I've now mentioned some functionality in the bottom-left corner of the scheme that should indeed also be developed/refactored.

[mihai-sysbio]

All the methods of obtaining kcat values (fuzzy matching, GotEnzymes, DLKcat, kcat table) are optional and can be run in whatever order, the scheme shouldn't be read as the definite workflow. One might choose fuzzy matching and only allow exact EC matches, which leaves many kcat values empty, which one might want to fill with DLKcat values instead. Or you might start with a curated table with kcat values, and indeed, it is far from guaranteed whether it contains all needed values (see also #159). Note that missing kcat values are 0 in model.ec.kcat, and this would just mean that applyKcatConstraints does not include any enzyme usage for that reaction.

It sounds like there will be a lot flexibility in how these k_cat values are embedded (mix & match), which is great. We should also pay extra attention to this when guiding users, since it might be extra difficult to understand all the choices.

I agree with splitting the function, but I believe it is a major strength of GECKO to be able to use DLKcat. More discussion is very welcome in #171.

To me, there is no question about having this feature in GECKO 3.x; it is more about having it in the major 3.0 (making it a must-have) or the minor 3.1 (making it a great to have but not absolutely strictly necessary). When "everything" is a must, the flip-side is that "nothing" is a really must, and things take longer to release.

As a general comment, instead of having one "magical" makeEcModel function that aims to do everything (and would thus need to be heavy parameterised), my suggestion would be to expose all the functions under it . The thinking here is that, either as a new or existing user, ease-of-use and confidence is better built when using a tool that works transparently (i.e. one can follow what it going on). Also, a few clear steps are then easier to wrap together in a function by anyone, and they would also go better with a tutorial/SOP.

I would not call makeEcModel "magical", it requires 2 inputs: the model structure, and whether you want GECKO light (default is "full" GECKO). Note that makeEcModel is not supposed to replace enhanceGEM, which indeed aims to do everything. Instead, makeEcModel largely replaces preprocessModel and convertToEnzymeModel, with a simpler model formulation (no arm reactions etc.).

I see, in this case my comment still stands, but for enhanceGEM or its equivalent in the GECKO 3.

As mentioned above, the scheme is not necessarily a whole workflow anyone would want to go through. But summary with stats is indeed very useful. Instead of running as final output, it might be useful to run this at any stage? I've now mentioned some functionality in the bottom-left corner of the scheme that should indeed also be developed/refactored.

The stats would be highly relevant when using GECKO in an automatic fashion, which in the upcoming version will be even easier than in the current setup. Alternatively, the Adapter could have a stats flag, which then, at every stage, would print out some stats.