dz网站源码公司网络推广该怎么做
最近尝试用 gurobi 进行并行计算，即同时用多个 cpu 核计算 gurobi 的 model，但是发现了不少问题。总体来看，gurobi 对并行计算的支持并不是那么好。
gurobi 官方对于并行计算的使用在这个网址，并有下面的大致代码：
import multiprocessing as mp
import gurobipy as gpdef solve_model(input_data):with gp.Env() as env, gp.Model(env=env) as model:# define modelmodel.optimize()# retrieve data from modelif __name__ == '__main__':with mp.Pool() as pool:pool.map(solve_model, [input_data1, input_data2, input_data3])
从官方的回复以及自己的一些检索，发现以下几个问题：
- gurobi 模型并不是线程安全的，模型本身不能作为并行计算中目标函数中的参数，因为 gurobi 模型不能 pickle，即不能序列化
- 使用并行计算时，意味着每个进程都单独运行当前 .py 脚本文件
- 因此，若要正确运行并行计算，gurobi 的模型总是在目标函数内部新建，或者在目标函数之前已经全局定义了（根据上一条，也相当于重新新建了gurobi 模型）。但有的时候，我们可能只需要通过并行计算中变化模型中的一些系数值并分别求解，这种重新新建模型的方式，反而会降低运算速度
- python 这两年新出的 multiscenario 可以对模型中系数的多个可能值一起求解。但它本质上是一个混合整数规划模型 MIP，虽然能够得到不同 scenario 对应的模型解，但是更具体的约束条件的对偶值就无法得到了
- cplex 似乎也有类似的问题
目前看到的一些 gurobi 或 cplex 正确运行并行计算的例子，基本都是在目标函数中重新新建模型，或者将原模型的一些参数文件传递到目标函数中，仍然新建模型。
因此，对于求解器的并行计算，目前来看，没有看出相比串行计算有太大优势。真要实现规划模型的并行计算，估计要深入修改求解器模型的源代码。官方没有意愿将模型对象支持 pickle，估计是因为可能会损失模型的其他功能吧。