It's unlikely the same issue but might make sense to check your antivirus: https://stackoverflow.com/questions/49817726/python-3-6-multiprocessing-pool-very-slow-to-start-using-windows
But I think there are also some inefficiencies in how the FVA is managed that can lead to not using the previous solution basis.
What improvements do you have in mind? Each process gets a global model object which is used to solve N problems. So the previous solutions should be used. We also run all minimizations in one batch and all maximizations in another batch. So that seems like a decent implementation to me.
I see now that we start a new process pool for each objective direction which is probably why you saw four models being copied @dotPiano_gitlab. So that's something that can be improved.
I am not sure if that is true for all process spawning models. I know we set the chunksize but there is no guarantee the process does not reinitialize within a chunk and that would reset the solver since model copying and pickling triggers a full reset. Also since you split it up over many processes and every process starts with a fresh solver object there is a little less solution recycling (one less for every process) which factors into start up time. Since using the previous basis can make this 10-100x faster solving relatively few optimization in one chunk can be less efficient then running them all serially. I don't think we can improve anything here but using many processes will inherently be only useful if you solve hundreds to thousands of optimizations or when you need to get the full solution object (which is slower then solving the model).
Hello, my name is Bruno Pereira and I'm from Portugal! I'm new to cobrapy and i'm using it to test the examples of the tool "gim3e". They use cobrapy 0.2.* where there is a function called "iniatialize_growth_medium" from cobra.manipulation.modify. I saw that this function was removed in the following versions of cobra. Are there functions in the recent versions of the package that can do the same task as this one?
Hi @BrunoMiguelPereira have a look at the documentation on working with the medium in the latest cobrapy here https://cobrapy.readthedocs.io/en/latest/media.html Also, what tool are you talking about exactly? There is an implementation of gim3e that should work with modern cobrapy here https://github.com/opencobra/driven/blob/devel/src/driven/omics/gim3e.py
The tool I was talking about was https://github.com/brianjamesschmidt/gim3e/tree/master/gim3e which has not been updated since 2015, as @cdiener said. The updates done in 2015 were not in accordance to cobra updates because they would have changed the commented parts in the examples. I will try with the "gim3e" that @Midnighter provided and work out the medium somehow. Thank you for the feedback!
Can I use Driven https://github.com/opencobra/driven/tree/devel to integrate transcriptomic and metabolomic data? I think it is a more up-to-date tool that can solve my problem of integrating both types of data.
I see now that we start a new process pool for each objective direction which is probably why you saw four models being copied @dotPiano_gitlab. So that's something that can be improved.
If I understand correctly, the issue lies in moving data between multiple processes. Why did you opt for multiprocessing rather than multithreading? In the latter copying the models would be much faster.
Oh right, I forgot that. Yes, I agree that this is a Windows only problem, still it would be nice to improve the current runtime :) I did some profiling and opened an issue with some ideas (mainly what you guys already suggested): opencobra/cobrapy#997
Has anyone been working with new modelseed reconstructions lately? It looks like they switched back to explicitly defining boundary metabolites, so reconstructions end up with a couple hundred extra reactions... I'm guessing it's motivated by a push for microbial community modeling, where the explicitly defined boundary is necessary to look at individual species vs. community fluxes, but this is an odd default decision for individual reconstructions. It's bit frustrating that major changes like this aren't publicized or documented (that I can find). Eager to hear the scoop if anyone has it...
@Midnighter is their SBML parser in a separate repository from other tools? E.g., there's nothing in https://github.com/ModelSEED
I was thinking https://github.com/kbase might have something but a quick search hasn't turned up anything either. I can send a quick introductory email if you like, they've always been very responsive. Or maybe you have already corresponded in the past.
Although I've heard people get a lot of spam pull requests.
Hello, my name is Bruno from Portugal and i am trying to integrate both transcriptomic and metabolomic data in a model. I addressed you before regarding gim3e package (not working due to unmaintenance) and know i am addressing you due to your function "gim3e.py" from package driven. My problem is when the turnover metabolites are added to the reactions which makes the solver status infeasible. The model is the latest Escherichia coli str. K-12 substr. MG1655, iML1515 and the omics data are subsets of the original with the correct translation to model genes and metabolites. I can provide those files if needed. I don't understand why the need to create turnover metabolites for all the metabolites in the model and not only the ones that come from metabolomics. I also tried to use a less complex model, with fewer genes/reactions/metabolites but the infeasible problem happens in the same point.
4 replies
Hi, I am having trouble installing cobra on my new machine. When using pip install cobra it errors saying
ERROR: Could not find a version that satisfies the requirement python-libsbml-experimental==5.18.3 (from versions: 5.9.2, 5.10.0, 5.10.1, 5.10.2, 5.11.0, 5.11.2, 5.11.4, 5.11.6, 5.12.1, 5.13.0, 5.13.1, 5.14.0, 5.15.0, 5.15.2, 5.16.0, 5.17.0, 5.17.2, 5.18.0, 5.18.1)
ERROR: No matching distribution found for python-libsbml-experimental==5.18.3
ERROR: Could not find a version that satisfies the requirement python-libsbml-experimental==5.18.3 (from versions: 5.9.2, 5.10.0, 5.10.1, 5.10.2, 5.11.0, 5.11.2, 5.11.4, 5.11.6, 5.12.1, 5.13.0, 5.13.1, 5.14.0, 5.15.0, 5.15.2, 5.16.0, 5.17.0, 5.17.2, 5.18.0, 5.18.1)
ERROR: No matching distribution found for python-libsbml-experimental==5.18.3
I have tried installing python-libsbml-experimental==5.18.3 directly but get the same error. I have ython-libsbml-experimental==5.18.1 installed but this does not help fix cobra installation
I noticed python-libsbml-experimental==5.18.3 was released fairly recently, please may advise on how to fix this
Hi, thanks for your quick reply! I maned to get around this error by installing the previous version of cobra. Even when I force installed the python-libsbml-experimental version 5.18.1 the most recent version of cobra would not work, and I was not able to install 5.18.3 at all (I presume because I am using a windows operating system). I guess this is a potential bug for windows users who are trying to use pip install cobra?
Are you using Python 3.9? There are wheels available for all relevant other Python versions https://pypi.org/project/python-libsbml-experimental/#files However, the source distribution is missing but I think building libsbml from sources would just lead you to more trouble.
Do you use this website (https://modelseed.org/) and try to refer to the ModelSEED models using it? I have to make central carbon metabolism pathways in 2 models, one is BiGG-based, the second one is ModelSEED-based.
Hello @ensakz, models created from modelSEED are typically well annotated. So you should typically be able to find a BiGG identifier, i.e., check
model.reactions.rxn00974.annotation for a BiGG identifier. You could then simply rename the IDs of your reactions, compartments, and metabolites so that you might be able to use the same map?
You could use the latest modelSEED database itself https://github.com/ModelSEED/ModelSEEDDatabase/blob/master/Biochemistry/reactions.json you would just have to ask them if the reaction identifiers are still the same as for your model.