These are chat archives for opencobra/cobrapy

4th
Mar 2017
Henning Redestig
@hredestig
Mar 04 2017 08:55
@cdiener it's a great suggestion though, I found that _reset_var_cache() a bit a pain point
João Gonçalo Rocha Cardoso
@joaocardoso
Mar 04 2017 09:55
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
@Midnighter
Mar 04 2017 14:23
@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"
model.optimize()
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
@cdiener
Mar 04 2017 14:44
@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
@Midnighter
Mar 04 2017 14:45
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
@cdiener
Mar 04 2017 14:50
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
@Midnighter
Mar 04 2017 14:52
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
@cdiener
Mar 04 2017 14:56
OK cool. Will check what's going on.
Moritz E. Beber
@Midnighter
Mar 04 2017 15:04
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":
        return
    elif status in ("non-optimal", "infeasible"):
        warn("solver status is '{}'".format(status), UserWarning)
    else:
        raise OptimizationError("solver status is '{}'".format(status))
Christian Diener
@cdiener
Mar 04 2017 15:05
I think @KristianJensen is the expert on optlang status values :smile: