These are chat archives for opencobra/cobrapy

9th
Feb 2017
Peter St. John
@pstjohn
Feb 09 2017 02:46
On #371, etc., do we really want Solution._check_freshness() to error out of all of these routines? It just seems a bit impractical
Peter St. John
@pstjohn
Feb 09 2017 03:07
arg, and we don’t do any of these checks with the re-named reaction objects…
>>> model = cobra.test.create_test_model()
>>> model.reactions[0].flux
0.0
>>> model.reactions[0].reduced_cost
0.0
what’s the motivation from switching from the older method (Reaction.property puts in some call to model.solution)?
Christian Diener
@cdiener
Feb 09 2017 03:39
I think it's speed. But there would be ways to make that fast if we use LazySolution as @phantomas1234 suggested.
Henning Redestig
@hredestig
Feb 09 2017 14:23
I apologise for lateness, deadline tomorrow, but I was thinking we could advertise our cobrapy0.6 efforts at http://novonordiskfonden.dk/en/content/data-driven-biotechnology by submitting this abstract: Constraint based reconstruction and analysis (cobra) is widely used to interpret and predict the interplay between genotype and metabolic flux. The community developed cobrapy Python package implements functionality to read and write, edit and adjust cobra models and to perform simulations using numerous popular algorithms. Since the first releases in 2012, the cobrapy project has gained considerable attention thanks to its broad feature-set with extensive documentation, and to being free/open source software without any non-free dependencies. The core classes of cobrapy form a basic infrastructure for constraint based modeling that is easy to reuse in other packages, facilitating the development of new functionality as well as increasing potential interoperability between packages. In order to simplify the implementation of new algorithms, we have drawn on our experiences with the early versions of cobrapy, the development of the strain design package cameo, and the mathematical modeling package optlang, to greatly enhance the cobrapy core classes. Solver interfaces are now provided by optlang avoiding the need to consider solver-specific details when implementing cobra algorithms. We used these improvements to re-factor and simplify several simulation algorithms for increased readability and performance. Here, we present the new functionality and outline the way forward for the role of cobrapy as a freely available infrastructure package for efficient constraint based modeling in python. Any opinions/suggestions? @cdiener @pstjohn? Author list to include everyone who has committed to devel-2
Kristian Jensen
@KristianJensen
Feb 09 2017 14:51
@cdiener Currently optlang does not provide a way to know up front whether QP is supported by a solver, although it might be worth adding. Checking "qp_method" works for now, but it's not guaranteed that other QP solvers will have that configuration parameter. There will be an informative error message when you try to make a quadratic objective with an interface that doesn't support it though.
Peter St. John
@pstjohn
Feb 09 2017 14:53
there used to be a function in cobrapy like get_solver, where you would ask for a particular feature and it would return one. maybe we could do something similar in opting?
Christian Diener
@cdiener
Feb 09 2017 15:07
@pstjohn always ported that one to optlang in cobra.util.solver it's called get_solver_name :smile: I needed the reverse for MOMA since I want to respect the solver set in model.solver and only change it if it doesn't support QPs.
*always=already
Christian Diener
@cdiener
Feb 09 2017 15:56
@KristianJensen thanks. Will check again when gurobi get QP capabilities in optlang.
Peter St. John
@pstjohn
Feb 09 2017 16:15
gotcha. I’d probably go with the try/except block then. Better to ask forgiveness than permission :)
Peter St. John
@pstjohn
Feb 09 2017 16:22
@hredestig, I like the abstract! I had a couple text suggestions, maybe this is a better option:
https://hackmd.io/MwM2CNwNgTgYwLTDgVgBwICwoCYCYE1QBDBcYvGTYPKEHARjSA==?both#
Christian Diener
@cdiener
Feb 09 2017 16:26
"for increased readability and performance" <- can we say that? Most algorithms actually became slower when compared to the pre-devel-2 version...
And maybe "metabolic flux" -> "metabolic fluxes"
Henning Redestig
@hredestig
Feb 09 2017 16:30
great suggestion with hackmd.io didn't know about that one, and thanks for the improvements!
Christian Diener
@cdiener
Feb 09 2017 16:30
But they are much cleaner and respect additional contraints etc.
(talking about the peformance thing)
Henning Redestig
@hredestig
Feb 09 2017 16:31
the conference is in May so the race is on to live up to it :) Several algorithms must become faster as we don't have to create the create_problem all the time.. and the HistoryManager surely makes things faster when you don't have to copy the model anymore
we will focus on this more the next couple of weeks here at cfb
Christian Diener
@cdiener
Feb 09 2017 16:32
The thing is that create_probelm was insanely fast. It was all C. I was thinking about a PR to swiglpk to add some additional C functions that help to get rid of some bottlenecks.
Peter St. John
@pstjohn
Feb 09 2017 16:32
we should get a meeting on the books then, it would be awesome to strategize about improvements
Henning Redestig
@hredestig
Feb 09 2017 16:34
mm... I'll hedge the performance a bit to be safe.
Christian Diener
@cdiener
Feb 09 2017 16:35
I think most of the algorithms are much nicer and more extensible now without sacrificing significant performance.
Henning Redestig
@hredestig
Feb 09 2017 16:37
http://doodle.com/poll/rxg7mmt7bmfqdbpf for meeting to discuss 0.6
Peter St. John
@pstjohn
Feb 09 2017 16:38
awesome, thanks!
Christian Diener
@cdiener
Feb 09 2017 16:40
I think the meeting should include some optlang people because a lot of performance optimization comes from there.
Peter St. John
@pstjohn
Feb 09 2017 16:54
:thumbsup: on including the optlang team