how to tell optimizer not to guess from previous solution and start afresh

[sumanasri]

Hi, I need to run the model fresh every time in a loop as I am giving different constraints. I do not want to load the model inside the loop since it would take a long time to execute. Is there a method I can call to tell the optimizer not to use the solutions from the previous run. I tried resetting solution.fluxes = 0 and even solution = 0 at the end of the loop but that doesn't work. How do I tell the optimizer not to take the solution from the previous loop as a guess but start afresh like it does in the beginning of the iteration. If I run the model with a bunch of constraints out side the loop and the same constraints inside the loop it gives different solutions because of different starting values in the loop. Thanks for your help.

[Midnighter]

Hi @sumanasri, unfortunately this functionality is not consistently exposed to the Python APIs of the various solvers that optlang supports (GLPK, CPLEX, Gurobi). Which solver are you working with?

[sumanasri]

GLPK..

[matthiaskoenig]

@sumanasri This is not a bug this is an underlying problem with FBC and constraint-based models in general! You just discovered the dark secret of multiple optima and non-uniqueness of fbc solutions. Your model is underdetermined, consequently it can have multiple equally valid solutions. As a consequence it depends on the start values and the actual solver which results you will get. Your simulations will be highly irreproducible! This occurs quit a lot in models, but nobody is talking about it.

What you propose here is to create a fix that it looks like the simulations are reproducible (which will make things worse, because it hides the reality of that there are multiple solutions and it cannot be guaranteed that the solver will return the same solution! If cplex or gurobi would be mean they would just start returning a random solution from the possible solution space to trip everybody up. Which would be completely correct, because it is an optimal solution).

This is not an issue in cobrapy, this is the behavior of your model.

There are multiple solutions to this

• do you care about your internal flux distribution or only about the exchange fluxes? If only the exchange fluxes are important ensure via flux variability analysis FVA that your exchange fluxes are unique. You have multiple internal flux modes which are optimal under the same exchange fluxes
• embrace the variability and run sampling on the flux modes, i.e. you sample your solution space and use this information
• constraint-your model further, by adding additional constraints until you get unique solutions. You can check the uniquness via FVA.

[Midnighter]

Specifically, if you want to follow up on the points that Matthias has discussed, the following functions might be useful to you:

• from cobra.sampling import sample
• from cobra.util import add_lexicographic_constraints
• from cobra.flux_analysis import geometric_fba
• from cobra.flux_analysis import flux_variability_analysis

[sumanasri]

@matthiaskoenig I was pondering about this and I too felt the same way that it may be the case that is happening here. Actually, I am looking at some average specific fluxes of 5000 simulated cell lines, so it is okay for it to not to reproduce the cases. In fact a cell's initial condition cannot be fully quantified. While the constraints are randomly picked by my algorithm, I didn't know about the initial condition. It kind of mimics the randomness of a cell's initial condition. For my final analysis, this isn't a problem because I am looking at certain averaged fluxes across several cell lines and conditions. I am aware of FVA and I have done that before in a different context. Thanks a lot for your clarification. I guess I will let the solver do its job the way it does :). In fact, I suppose mother nature, in her path of evolution, does choose local minima along the way and I am not looking for a unique solution. I appreciate all of your help in this regard.

[Midnighter]

It sounds like sampling might be the right answer for you.

[sumanasri]

Ok. I shall take a look at the cobra.sampling interface. Thanks.

[cdiener]

Copying the model will rebuild the silver object and thus acts as a reset. This will be consistent across all solvers.

So model = model.copy() will effectively reset the solver.

There are other solver-specific ways to do so quicker but they are not consistent across solvers as mentioned by @Midnighter.

[sumanasri]

Thank you for all the suggestions.

[Midnighter]

This issue looks resolved from my perspective. Please feel free to re-open if this continues to be a problem for you.