near_optimal solution status in wing debug file

[mayork]

When i run the engine integrated with the wing (engine_wing_debug.py at https://github.com/hoburg/d8/commit/f67b735846b66a467afe9fb0b74ad6a166344eab) it sometimes solves and sometimes doesn't. When it doesn't solve, the first GP iteration is either dual infeasible or near optimal. I Looked at the solution to the first GP solve when it is near optimal and when it is optimal. I diffed two text files that contain the solution table and this is the only differences, as you can see very minor.

<        W_\{engine\} : 8.343e+04                                                       [N]       Weight of a Single Turbofan Engine\
---
>        W_\{engine\} : 8.342e+04                                                       [N]       Weight of a Single Turbofan Engine\
84c84
<               M_5 : [ 0.569     0.571     0.409     0.337    ]                                Station 5 Mach Number\
---
>               M_5 : [ 0.569     0.572     0.409     0.337    ]                                Station 5 Mach Number\
105,106c105,106
<               u_5 : [ 291       292       206       172      ]                      [m/s]     Station 5 Exhaust Velocity\
<               u_7 : [ 214       217       211       178      ]                      [m/s]     Station 7 Exhaust Velocity\
---
>               u_5 : [ 292       292       207       172      ]                      [m/s]     Station 5 Exhaust Velocity\
>               u_7 : [ 214       218       211       178      ]                      [m/s]     Station 7 Exhaust Velocity\

@1ozturkbe @bqpd @whoburg thoughts on what this means? I'm not sure what to make of it, I was hoping for some more drastic differences in the linearizations...

[whoburg]

My initial instinct is that this means the NEAR_OPTIMAL solution is actually a good solution. The huge difference in SP algorithm behavior that Martin sees is due to the difference in how we treat OPTIMAL vs NEAR_OPTIMAL. We assume NEAR_OPTIMAL is infeasible and kick off a feasibility solve (a terrible choice), which presumably sends the SP algorithm off in a hopeless direction. In the nearby OPTIMAL case, we linearize and continue with our SP heuristic.

So, I think the key is going to be adding a case for what to do with NEAR_OPTIMAL solutions (as in https://github.com/hoburg/gpkit/issues/1048).

Am I missing something deeper about the question?

[1ozturkbe]

I agree that it is terrible to do a feasibility solve in the NEAR_OPTIMAL case... so perhaps another flag to deal with solves that are near optimal, or just go ahead with SP algorithm? I haven't seen this all too often, but seems like a trivial numerical issue.

[mayork]

I agree, I think treating the near optimal like an optimal solution in the SP algorithm is a good first start since the near optimal solution is so reasonable

[mayork]

closing, the new solution method solves this

[bqpd]

(@mayork, cannot reproduce because I do not have simple_ac_imports installed as a package)

[mayork]

that doesn't make sense because simple_ac_imports.py is a file that lives in the D8 repo

[bqpd]

It does for later commits but not that one...did it just not get pushed until later? I can checkout a later version.

[mayork]

okay yeah just checkout later

[bqpd]

Cannot reproduce this bug. :(

Closing for now, but have a branch that might solve this once we have a test!