These are chat archives for opencobra/cobrapy

Mar 2017
Henning Redestig
Mar 04 2017 08:55 UTC
@cdiener it's a great suggestion though, I found that _reset_var_cache() a bit a pain point
João Gonçalo Rocha Cardoso
Mar 04 2017 09:55 UTC
Let me explain the _forward_variable. It is necessary so we can modify constraints in the model before adding the reactions or metabolites. That is because if you add a variable or a constraint to optlang it will go to a "pending modifications" object and that object cannot be queried.
Otherwise things get really slow. My suggestion for that if something is: things in "to be added queue" should also be retrievable from optlang. Also, for safety reasons, things in the solver that are in the "to be removed queue" should raise a KeyError. This could easily be done by having solver.constrains return a Container generated on the fly using the __get__.
Moritz E. Beber
Mar 04 2017 14:23 UTC
@cdiener picking you to be the FVA expert: Any reason why Gurobi would fail? I'm trying to fix the summary functions...
import cobra
import cobra.test
model = cobra.test.create_test_model("textbook")
model.solver = "gurobi"
boundary_reactions = model.reactions.query(lambda x: x, 'boundary')
cobra.flux_analysis.flux_variability_analysis(model, fraction_of_optimum=0.95, reaction_list=boundary_reactions)

    maximum     minimum
EX_ac_e     -0.0     0.0
EX_acald_e     -0.0     0.0
EX_akg_e     -0.0     0.0
EX_co2_e     -0.0     0.0
EX_etoh_e     -0.0     0.0
EX_for_e     -0.0     0.0
EX_fru_e     -0.0     0.0
EX_fum_e     -0.0     0.0
EX_glc__D_e     -0.0     0.0
EX_gln__L_e     -0.0     0.0
EX_glu__L_e     -0.0     0.0
EX_h2o_e     -0.0     0.0
EX_h_e     -0.0     0.0
EX_lac__D_e     -0.0     0.0
EX_mal__L_e     -0.0     0.0
EX_nh4_e     -0.0     0.0
EX_o2_e     -0.0     0.0
EX_pi_e     -0.0     0.0
EX_pyr_e     -0.0     0.0
EX_succ_e     -0.0     0.0
Doesn't happen with cplex or glpk...
Christian Diener
Mar 04 2017 14:44 UTC
@joaocardoso I tested it. Removing the cache does not break anything and all tests pass. It is a bit slower but this affects mostly the new loopless and I think it's due to the old way that solution gets the primals. Might be better with the changes from @Midnighter ...
Moritz E. Beber
Mar 04 2017 14:45 UTC
Going further with test_summary_methods the line model.metabolites.fdp_c.summary(fva=0.99) runs fine in glpk but returns an unexpected result, cplex says that no solution exists, and gurobi can't retrieve 'X' so probably no solution either.
Christian Diener
Mar 04 2017 14:50 UTC
I had some problems with gurobi in optlang. It sometime does not solve correctly. I have to check the line in summary methods. Is that for textbook? There should definitely exist a solution for fraction=0.99. In which branch do you see the errors?
Moritz E. Beber
Mar 04 2017 14:52 UTC
latest devel-2 and refactor-solution
I mean, optlang does warn that the Gurobi interface is not fully functional and should be used with care.
And yes, it's the same setup as with the code sample above.
Christian Diener
Mar 04 2017 14:56 UTC
OK cool. Will check what's going on.
Moritz E. Beber
Mar 04 2017 15:04 UTC
Regarding our discussion in #431, is there a status "non-optimal", too?
My current proposal for a status check function is then:
def check_solver_status(status):
    """Perform standard checks on a solver's status."""
    if status is None:
        raise RuntimeError("model was not optimized yet")
    elif status == "optimal":
    elif status in ("non-optimal", "infeasible"):
        warn("solver status is '{}'".format(status), UserWarning)
        raise OptimizationError("solver status is '{}'".format(status))
Christian Diener
Mar 04 2017 15:05 UTC
I think @KristianJensen is the expert on optlang status values :smile: