【问题标题】:Pyomo scaling with GLPKPyomo 使用 GLPK 进行缩放
【发布时间】:2017-09-12 15:28:00
【问题描述】:

我有一个(相当)简单的 Pyomo 模型,它有 5 个参数和一组大小为 48(代表时间间隔)的集合。如果我使用特定的数据文件,GLPK 绝对可以正常工作:

# Data file 

param : n := 48;

param : E_demand := 
1 231.674545 
2 223.328638 
3 218.047274 
4 212.285910 
5 214.539544 
6 213.940455 
7 216.871637 
8 205.824183 
9 208.905001 

(以类似的方式继续到索引 48 和另外 4 个参数)。

但是,如果我使用另一个(只是略有不同)数据文件,则解决问题需要更长的时间(从不到一秒到超过 20 分钟,我懒得知道要多长时间)。如果我只是将其中两个参数更改为它们值的大约 1/3(如下所示),则问题需要更长的时间才能解决。

param : E_demand := 
1 76.464996 
2 69.815002 
3 71.355003 
4 75.004997 
5 72.360001 
6 71.065002 
7 70.669998 
8 71.809998 
9 72.309998 

我认为问题一定与缩放有关,因为如果我逐渐将较小的值从一个数据文件替换到另一个数据文件,则问题需要更多时间,直到它变得非常缓慢。有没有办法使用 Pyomo 改变 glpk 缩放比例?使用不同的求解器可能会解决这个问题吗?

【问题讨论】:

  • (fairly) simple Pyomo model 没有告诉我们任何事情。是 MIP 吗?唱片?对于 MIP,这可能是正常行为(毕竟通常是 NP-hard;所有方法都有些启发式)。我们也不知道您使用的是哪种求解器。 GLPK 似乎实现了 Simplex 和 IPM。后者可能对缩放敏感,但前者不应该。

标签: python optimization scaling glpk pyomo


【解决方案1】:

对于ConcreteModel,您始终可以在模型构建期间通过检查参数值并在模型公式中应用相关缩放因子来实现某种形式的缩放。

关于变量/约束缩放的类似讨论可以在 Pyomo 问题页面上找到:https://github.com/Pyomo/pyomo/issues/219

【讨论】:

    【解决方案2】:

    您可以尝试 gurobi 求解器。从个人经验来看,我会说 gurobi 在大的 opt 问题上比 GLPK 更好、更稳定。如果您的 opt 问题是 LP,那么当您将数据文件更改为原始文件的 1/3 时,它不应该产生任何解决差异。既然是同一件事,例如:

    def constraint(m, n):
        m.E_demand[n] <= m.x
    

    Demand[1] = 20073 没有任何区别。但是ofc,我真的不知道你的模型,所以这只是一个假设。

    这里是 gurobi 求解器:http://www.gurobi.com/,它对于学术目的也是免费的。

    【讨论】:

      猜你喜欢
      • 2017-03-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-01-24
      • 2013-11-08
      • 2012-06-03
      • 1970-01-01
      相关资源
      最近更新 更多