-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Model objective after adding two models different between 0.5.11 and 0.6 #505
Comments
I must say I find I think I'd favor removing them altogether and replace with a utility function |
We should figure out what we want to do with the operator overloading methods. We talked about them in #311 and #400 as well. For reactions, biomass_reaction = 5*atp_part + 2*nadh_part + precursor_part For models, I honestly never use that functionality. @mmundy42, I'm guessing you find them useful? I would be in favor of a utility function like |
I think a simple 'rule' can be that when it is obvious what the effect should be, then overloading operators is an acceptable and good interface. For adding reactions this is the case, but less so for models.. |
Even if we have |
Sorry for the delayed response, I was out of the office for a few days. I'm using the "+=" operator to create a community model of multiple organisms. In this use case, I've added a prefix to all of the reactions and metabolites so there are no duplicates. And I want there to be separate objectives for each organism. In mminte, the community models always have two organisms and then the community model is optimized with both objectives, with species A knocked out, and with species B knocked out. A |
I haven't read the details, but there is a new paper on building community models using an algorithm called SteadyCom. http://journals.plos.org/ploscompbiol/article/fileid=10.1371/journal.pcbi.1005539&type=printable |
@mmundy42 That's the paper from Costas Maranas' group! I talked to him recently and was waiting for that one 🎉 However, your link does not work for me, but the following does: http://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1005539 |
@cdiener, I know this getting off topic, but I would like to discuss building community models with you. Maybe we can combine some of the things we are working on or get SteadyCom ported to cobrapy. |
@mmundy42 That sounds great. I don't if you have seen it but we can open private chats on gitter. I'll add you to one so we can talk :) |
I know that Daniel Machado at EMBL is also working on implementing community modeling. His current implementation is, of course, in 'framed' but might still be worth to discuss general approaches with him. Or he might even feel like contributing to a small package that depends on cobrapy, like |
..and what is the preferred behavior of
|
Signature of DataFrame.merge(right, how='inner', on=None, left_on=None, right_on=None,
left_index=False, right_index=False, sort=False,
suffixes=('_x', '_y'), copy=True, indicator=False) And DataFrame.join(other, on=None, how='left', lsuffix='', rsuffix='', sort=False) |
The other option could be a |
The way I see it, there are two use cases:
I would argue that these use cases are best supported by:
I would also argue that 1. should live inside of cobrapy, while 2. is a perfect candidate for a smaller subpackage that depends on cobrapy. |
@cdiener has the micom package (https://github.com/cdiener/micom) so there already is a package for community modeling built on top of cobrapy. And there is some basic support for community models in the mminte package (https://github.com/mmundy42/MMinte). mminte implements "joint FBA" which "integrates metabolic reconstructions of individual microbial species into a multi-compartment model with a community compartment allowing for the exchange of metabolites between species. The optimization objective function is the sum of the biomass reactions of individual species". [from the SteadyCom paper referenced above]. I like @hredestig suggestions as that would allow a joint FBA to be easily implemented. I also like the idea of a CommunityModel class but it seems that it will get complicated enough to merit its own package. |
I think the expected behavior would be just to add reactions and not add (or error) for ones that are already in the model. The compartmentalized version could be added and triggered with an argument, however that might be something that is better implemented in external packages. For instance in Regarding the objective I think one small issue is that we broke backwards compatibility here and did not announce it. So maybe for now we should go back to the 0.5.x behavior and add all objective expressions and we can change that in a coming version with the appropriate release note... |
Add `Model.merge` to handle merging two models more flexible than the overloaded + and += operators. Deprecate those. Fix the backwards incompatibility that added models didn't have the sum of the objectives of the two models.
Add (reversible) `Model.merge` to handle merging two models more flexible than the overloaded + and += operators. Deprecate those. Fix the backwards incompatibility that added models didn't have the sum of the objectives of the two models.
Add (reversible) `Model.merge` to handle merging two models more flexible than the overloaded + and += operators. Deprecate those. Fix the backwards incompatibility that added models didn't have the sum of the objectives of the two models.
I ran across this while getting mminte running on cobra 0.6. With cobra 0.5.11, when two models are added with the "+=" operator, the objective is updated too because of the way reaction objective coefficients are handled. For example, using the BT and FP models from Thiele, I can add a prefix to the reaction IDs, add the models together and both objective reactions are set in the combined model:
With cobra 0.6, when two models are added with the "+=" operator, the objective in the combined model is unchanged. For example:
Would it make sense for the "+" and "+=" operators to explicitly set the objective in cobra 0.6?
The text was updated successfully, but these errors were encountered: