GECKO
GECKO copied to clipboard
SysBioChalmers
feat: user-friendly input when integrate proteomics
@BenjaSanchez @IVANDOMENZAIN In the new utilities branch #82, we required the input oxPhosIDs in the function generate_protModels.m , which is not so user-friendly. The reason that we requires this input is to use the mean abundance of those subunit abundance to represent all measured subunit abundance related to oxidative phosphorylation instead using the lowest abundance. Is that reasonable that we can perform the same approach to every complex in the model? Will that change the model performance a lot?
Thanks a lot for pointing this out @feiranl . In the current version of ecYeastGEM we have 252 enzyme complexes, not a negligible amount. In this first version of the generate_protModels function I just decided to adjust oxphos related complexes because of their great impact on metabolism, and I was also aiming to a minimal modification of our dataset which is also modified by the flexibilization step. But your idea of applying this to all enzyme complexes should definitely be tested!
This actually goes in hand with issue #87, which in its 3rd point suggests that an ecModel+proteomics should be provided as an example. Let's upload this and then we can use the same model to keep track of the changes when applying Feiran's suggestion.
What are your thoughts on this @BenjaSanchez?
I agree with everything. Would be optimal to add a working example on how to use the scripts in the open PR #82 (in the /utilities/integrate_proteomics folder), and after it is merged we can come back to this issue and asses what happens when we spread the approach to all complexes.
Another thing, If we accept the proteome data with triplicates/duplicates, should we also accept the fermentation as the same format, then we calculate the mean values in our function. What are your thoughts on this?
@feiranl as long as it follows the same convention of the proteomics data (i.e. same name but ending in _A, _B, etc) I don't see the problem to offer the functionality, what do you think @IVANDOMENZAIN?
@feiranl, @BenjaSanchez The need of providing the oxPhos related IDs has been circumvented by adding these reaction IDs as optional parameters in the function getModelParameters.m, you can see these modifications in 28ad834.
@feiranl, @BenjaSanchez What do you think about the current status of the inputs in the generate_protModels.m function in pull request #82 ?
@IVANDOMENZAIN I think it's pretty user-friendly and overall well documented. @feiranl let us know your thoughts so that we can close this issue on the next release
