在 OpenMDAO 中，为什么优化器可能会尝试远超出指定范围的设计变量的值？

如何解决在 OpenMDAO 中，为什么优化器可能会尝试远超出指定范围的设计变量的值？

我使用的是 pyOptSparseDriver，而我的优化器是 SLSQP。我有一个用

定义的设计变量A

ivc = om.IndepVarComp()
ivc.add_output("A",2.00)
...
prob.model.add_design_var("A",lower=1.6,upper=5.00,ref=1.6)

A 表示环面的纵横比，所以它总是需要大于 1 才能有物理意义；在这里，我给了它一个略高的“合理”下限。

在一个组件中——实际上是模型中第一组的第一个组件——我看到 A 在其输入中被赋予了负值，甚至 nan（这会导致错误并最终停止代码）。该组件是一个 ExplicitComponent 并且它所在的组没有附加特定的求解器； n2 显示它是 LN:RUNONCE。

这是预期的行为吗？有没有办法防止这种情况发生？

我尝试过的事情

从 pyOptSparseDriver 更改为 ScipyOptimizerDriver 不会引发此问题，但出于其他原因，我可能更喜欢使用前者。

我在模型的其他地方还有其他名为 A 的变量（但封装在组中）所以我怀疑这可能是与命名相关的错误；我尝试将 A 重命名为 Asp（这在我的模型中是独一无二的），但问题仍然存在。

为什么我没有 MWE

我尝试在这个初始组之后删除模型的一部分，但这样做时我不得不更改目标函数。然后，问题不再发生。

可能的提示？

稍后在模型中，我有一个带有 NewtonSolver 的组，我将其称为 secondsolver。它使用带有 rho 和 c 的默认参数的 Armijo 线搜索。

newton.linesearch = om.ArmijoGoldsteinLS(retry_on_analysis_error=True,rho=0.5,c=0.1,method="Armijo",bound_enforcement="vector")

我在组件的计算函数中添加了一个 print 语句；当我运行它输出的代码

...

===========
thirdsolver
===========
NL: Newton 0 ; 6.54500652 1
|  LS: BCHK 0 ; 0.000394994169 6.03504623e-05
NL: Newton 1 ; 4.4408921e-17 6.7851607e-18
NL: Newton Converged
A in compute is [-37490.25190183]
A in compute is [-18743.90453135]
A in compute is [-9370.73084611]
A in compute is [-4684.1440035]
A in compute is [-2340.85058219]
A in compute is [-1169.20387153]
A in compute is [-583.3805162]
A in compute is [-290.46883854]
A in compute is [-144.01299971]
A in compute is [-70.78508029]
A in compute is [-34.17112058]
<test.py>:104: RuntimeWarning: invalid value encountered in power
<problematic line here; it's from the
 analytic derivative of this first component,where A is being raised to a small,constant,nonzero power>
A in compute is [nan]

这里的 thirdsolver 是模型后面的 NewtonSolver。也许打印出现乱序？无论如何，A 的值每个都相差 2 倍（至少在较高的值处），所以这可能与 rho=0.5 有关。如果我更改该行搜索上的参数 rho 或 c，则不再发生错误。

我可以稍微更改其中一个参数并继续，但如果对发生的事情有更好的解释，我希望将来能够避免这种情况。

解决方法

在旧版本的 SLSQP 中，设计变量边界执行存在错误。这已在 scipy SLSQP 代码库中修复，但从未在 pyoptsparse 代码库中修复。换句话说，两个代码库中的 SLSQP 代码是不一样的，并且有些分歧。这解释了为什么 ScipyOptimizerDriver 尊重你的界限而 pyOptSparseDriver 不是（当使用 SLSQP 时）。如果你在 pyOptSparse 中切换到 IPOPT，那么它会尊重你的界限。