These are chat archives for opencobra/cobrapy

27th
Feb 2018
ctseto
@ctseto
Feb 27 2018 14:58

thanks.
Was reading the AGORA paper and about to carry some calculations out. for example:
"To model the metabolic dependency between the two organisms in a realistic manner, additional constraints were implemented, such that the flux of reaction i (e.g., from the mouse) and of reaction rxnC (e.g., mouse biomass reaction) were proportional (vi: vrxnC). We bound the ratio between reaction i and reaction rxnC using a factor c, such that for irreversible reactions: vi − c × vrxnC ≥ u, and for reversible reactions: vi − c × vrxnC ≥ u in the forward direction and vi + c × vrxnC ≤ u in the reverse direction. The parameter u ≥ 0 allowed a small reaction flux when vrxnC = 0 "

My schema was to convert a paired model (modelA and modelB) into irreversible, then for each forward non-exchange reactions, add a constraint model.problem.Constraint(v_i.flux_expression+CBio1,lb=u); where v_i is Model.reactions[i], for all i belonging to modelA , and Bio1 is the biomass expression for modelA; and for reverse reactions it would be
model.problem.Constraint(v_i.flux_expression-C
Bio1,lb=u) ; with the constraints for modelB following a similar format. Wondering if I interpreted the paper and the tailored constraints correctly...

Moritz E. Beber
@Midnighter
Feb 27 2018 15:23
Something went wrong with the formatting in your message there. In general, that sounds okay to me. Just be aware that each reaction has a forward flux variable and a reverse flux variable which together are given by the flux expression, i.e., `cobra.Reaction.flux_expression = cobra.Reaction.forward_variable - cobra.Reaction.reverse_variable`.
ctseto
@ctseto
Feb 27 2018 15:24
didnt think of that, though i converted the model to irreversible before applying these constraints.
getting infeasibles from the solver, so i'll have to look into that
Moritz E. Beber
@Midnighter
Feb 27 2018 15:28
Good luck with that :)
ctseto
@ctseto
Feb 27 2018 17:46
can you write a constraint specifically for forward or reverse variables, or just for the flux_expression?
Moritz E. Beber
@Midnighter
Feb 27 2018 18:19
Sure you can!
Christian Diener
@cdiener
Feb 27 2018 21:10
`devel` seems to be broken for symengine:
``````self = <cobra.test.test_solver_model.TestReaction object at 0x7f9b0cc725c0>, model = <Model e_coli_core at 0x7f9b0cc7a128>

def test_reaction_imul(self, model):
with model:
model.reactions.EX_glc__D_e *= 100
>           assert model.constraints.glc__D_e.expression.coeff(
model.variables.EX_glc__D_e) == -100
E           assert -100.0 == -100
E            +  where -100.0 = <built-in method coeff of Add object at 0x7f9b0c9b0e08>(0.0 <= EX_glc__D_e <= 1000.0)
E            +    where <built-in method coeff of Add object at 0x7f9b0c9b0e08> = -100.0*EX_glc__D_e + 100.0*EX_glc__D_e_reverse_af641 - 1.0*GLCpts + 1.0*GLCpts_reverse_a52ae.coeff
E            +      where -100.0*EX_glc__D_e + 100.0*EX_glc__D_e_reverse_af641 - 1.0*GLCpts + 1.0*GLCpts_reverse_a52ae = <optlang.glpk_interface.Constraint object at 0x7f9b0c85cb38>.expression
E            +        where <optlang.glpk_interface.Constraint object at 0x7f9b0c85cb38> = <optlang.container.Container object at 0x7f9b0cad6b00>.glc__D_e
E            +          where <optlang.container.Container object at 0x7f9b0cad6b00> = <Model e_coli_core at 0x7f9b0cc7a128>.constraints
E            +    and   0.0 <= EX_glc__D_e <= 1000.0 = <optlang.container.Container object at 0x7f9b0cad6e10>.EX_glc__D_e
E            +      where <optlang.container.Container object at 0x7f9b0cad6e10> = <Model e_coli_core at 0x7f9b0cc7a128>.variables

cobra/test/test_solver_model.py:469: AssertionError``````
Moritz E. Beber
@Midnighter
Feb 27 2018 22:13
It's a fair point that we should run our test suite also for symengine. However, I don't immediately understand why the float and the integer of -100 don't compare equal.
Christian Diener
@cdiener
Feb 27 2018 23:20
Yeah I don't what the actual motivation is but it is one of those things that is different between sympy and symengine. I think the symengine people are aware of that but im not sure whether they are planning to fix this behavior. The -100.0 is not a float but some symengine object that implements a print and eq method though.
If you cast it to floating the test should pass.
*float