Specification of fixedBPR, pRatOpt improves objective...

[1ozturkbe]

@mayork another one of these cases where constraining something improves the objective function. When solving:

sol = run_optimal_D8('W_{f_{total}}',True, False)

the fuel weight is 25 klbs, optimizing for W_{f_{total}}. However, when I let the BPR and pRat loose:

sol = run_optimal_D8('W_{f_{total}}',False, True)

I get 26.7 klbs.

[1ozturkbe]

This is related to issue #75. @bqpd are we really seeing locally optimal behavior? I am working out of commit 7a56483 of branch multimissionFix. Can we talk about this in our meeting tomorrow?

[mayork]

This could be due to hard coded constraints on OPR.

On Sep 26, 2017, at 12:52, Berk Ozturk notifications@github.com wrote:

This is related to issue #75. @bqpd are we really seeing locally optimal behavior? I am working out of commit 7a56483 of branch multimissionFix

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[1ozturkbe]

what do you mean by that exactly? Why are we hardcoding OPR?

[mayork]

Hardcoded max limits on OPR...just ctrl-f 'OPR'

On Sep 26, 2017, at 12:52, Berk Ozturk notifications@github.com wrote:

This is related to issue #75. @bqpd are we really seeing locally optimal behavior? I am working out of commit 7a56483 of branch multimissionFix

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[1ozturkbe]

Sorry, I had a weird bug, but I suspect that is the issue. I'll see how it works now.

[1ozturkbe]

Now the 737 solutions are well behaved (OPRs around 20), but D8 is allowing for OPRs up to 80 when solved for with fixed OPR, and has obviously a lower fuel burn... Odd. The fully optimized D8 gives around 20, as expected. In turbofan, the OPR is the product of the \pi of all components, and the weight of the engine is dependent on the \pi's. It seems odd that at a fixed BPR, the engine OPR can skyrocket.

[1ozturkbe]

For comparison, fixedBPR and no pRatOpt gives W_eng = 27.7kN, and max OPR of 78.3. relaxed BPR and pRatOpt gives W_eng = 25.3kN, and max OPR of 22.4. There is an incongruity here, and it is due to weird behavior in the HPC pressure ratio which does not really seem to affect the weight of the engines. The high OPR cases are almost purely due to a quadrupling of the HPC pressure ratio compared to the low OPR cases. (1.3 vs. 5) Seems odd that we can have such variability. On the other hand, the LPC ratios are consistent throughout, and change heavily with thrust setting (from 5-8), as would be expected.

[mayork]

This definitely has to do with the pressure ratio optimization. If you run true false args you get 41,914 for the fuel burn but false false (allowing BPR optimization) gives 37,735. I suspected the pressure ratio optimization was the issue (tbh I was skeptical that would work as intended when I implemented it). The pressure ratio optimization is essentially optimizing the fan and compressor maps by scaling them. The maps include a few signomial equalities and there's a couple other signomial equalities that depend on different map values. If I had to guess there's some compounding signoimal equality effect causing numerical issues. It could be interesting to try putting trust regions on some of the signomial equalities. Overall, my concern is low since BPR optimization works as expected.

[1ozturkbe]

This is pretty concerning (to me at least) because it is unphysical. The internals of the engine are just as important as the overall results. We don't want to give anyone any reason to suspect that the models do not work as we claim. We need to come up with a plan of attack here. And also, the engine OPR 'malfunctions' with the True,False args, which suggests that the OPR optimization is not the issue. Also, I cannot even get D8.2 to run with the False,False args, which is another issue that I just realized. (Also above you were comparing 737 results, which I was not at all worried about. Those are all consistent).

[mayork]

If this is only D8 it's an issue with either BLI, an illformed constraint on engine diameter, or a weird CG interaction.

On Oct 2, 2017, at 15:41, Berk Ozturk notifications@github.com wrote:

This is pretty concerning (to me at least) because it is unphysical. The internals of the engine are just as important as the overall results. We don't want to give anyone any reason to suspect that the models do not work as we claim. We need to come up with a plan of attack here. And also, the engine OPR 'malfunctions' with the True,False args, which suggests that the OPR optimization is not the issue. Also, I cannot even get D8.2 to run with the False,False args, which is another issue that I just realized. (Also above you were comparing 737 results, which I was not at all worried about. Those are all consistent).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[1ozturkbe]

And the model does work with False, True arguments.

[mayork]

Remove the OPR constraint and see what happens.

On Oct 2, 2017, at 15:47, Berk Ozturk notifications@github.com wrote:

And the model does work with False, True arguments.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[1ozturkbe]

I did, with the previous runs.

[mayork]

Can you give a test by test breakdown?

Like aircraft OPR on/off BPR optimized or not PRat optimized or not and the run result?

On Oct 2, 2017, at 15:56, Berk Ozturk notifications@github.com wrote:

I did, with the previous runs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[1ozturkbe]

Alright, here it goes, w.r.t input arguments (fixedBPR and pRatOpt). True, False, OPR limited - 25.0 klbs, max OPR 71.1 False, True, OPR limited - 26.8 klbs, max OPR 22.4 False, False, OPR limited - UNKNOWN True, True, OPR limited - 24.1 klbs, max OPR 72.2 Then I commented out all OPR limiting in aircraft.py. True, False, OPR commented - 24.7 lbs, max OPR 78.2 False, True, OPR commented - 26.8, max OPR 22.4 False, False, OPR commented - UNKNOWN True, True, OPR commented - 23.5 klbs, max OPR 83.3 Also, I noticed that if pRatOpt = True we only remove subs for the fan pressure ratio, and not for the other components. Why?

[mayork]

Right I forgot that was because all TASOPT does is FPR optimization. If we drop all the pressure ratio subs does it work?

On Oct 3, 2017, at 20:19, Berk Ozturk notifications@github.com wrote:

Alright, here it goes, w.r.t input arguments (fixedBPR and pRatOpt). True, False, OPR limited - 25.0 klbs, max OPR 71.1 False, True, OPR limited - 26.8 klbs, max OPR 22.4 False, False, OPR limited - UNKNOWN True, True, OPR limited - 24.1 klbs, max OPR 72.2 Then I commented out all OPR limiting in aircraft.py. True, False, OPR commented - 24.7 lbs, max OPR 78.2 False, True, OPR commented - 26.8, max OPR 22.4 False, False, OPR commented - UNKNOWN True, True, OPR commented - 23.5 klbs, max OPR 83.3 Also, I noticed that if pRatOpt = True we only remove subs for the fan pressure ratio, and not for the other components. Why?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[1ozturkbe]

It gives more reasonable results eg. False, True, OPR commented gives 54 OPR, but the HPC pressure ratio is always around 1.2, which sounds silly. And the HPT ratios are huge correspondingly. Likely has to do with the horrendous penalty due to bleed. It seems like the solution is exploiting some aspect of the engine or the maps.

[1ozturkbe]

Also, I noticed that the OPRmax constraint was not applied for all stages of flight. Probably should have been. This is significantly improving results.

[mayork]

Yeah the max OPR number is for cruise only, it should be higher in takeoff. I'd try upping the max OPR by about 1.5x out if cruise and see what happens.

On Oct 3, 2017, at 20:50, Berk Ozturk notifications@github.com wrote:

Also, I noticed that the OPRmax constraint was not applied for all stages of flight. Probably should have been. This is significantly improving results.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[1ozturkbe]

Max OPR is never tight in cruise, so I don't know why it was applied there in the first place. It is reached at TOC, and I don't see why max OPR doesn't apply for takeoff. Is it not like a 'never-exceed' value, applied blanket everywhere?

[1ozturkbe]

I figured it out. Everything works as long as the fan pressure ratio isn't being optimized ('\pi_{f_D}'). @mayork if you have any insight as to why this is the case that would be appreciated.

[1ozturkbe]

@mayork I am also confused by this bit of code:

        if BLI or M072_737 or b737800 or b777300ER or optimal737 or D8_eng_wing or D8_no_BLI:
             with SignomialsEnabled():
                  engineclimb.extend([
                       SignomialEquality(aircraft.engine.engineP['c1'][:Nclimb], (1. + 0.5*(.401)*climb['M']**2.)),
                       ])
                  enginecruise.extend([
                       SignomialEquality(aircraft.engine.engineP['c1'][Nclimb:], (1. + 0.5*(.401)*cruise['M']**2.)),                
                       ])
        else:
             engineclimb.extend([
                  aircraft.engine.engineP['c1'][:Nclimb] <= 1. + 0.5*(.401)*0.54592**2.,
                  ])
             enginecruise.extend([
                  aircraft.engine.engineP['c1'][Nclimb:] <= 1. + 0.5*(.401)*0.8**2.,
                  ])

why do you set climb['M'] for the aircraft in the else statement, and revert the signomial equality? Seems really hacky.

[mayork]

I think I meant to remove that and never did lol....if I remember right it was something I did while debugging

On Oct 13, 2017, at 14:52, Berk Ozturk notifications@github.com wrote:

@mayork I am also confused by this bit of code:

    if BLI or M072_737 or b737800 or b777300ER or optimal737 or D8_eng_wing or D8_no_BLI:
         with SignomialsEnabled():
              engineclimb.extend([
                   SignomialEquality(aircraft.engine.engineP['c1'][:Nclimb], (1. + 0.5*(.401)*climb['M']**2.)),
                   ])
              enginecruise.extend([
                   SignomialEquality(aircraft.engine.engineP['c1'][Nclimb:], (1. + 0.5*(.401)*cruise['M']**2.)),                
                   ])
    else:
         engineclimb.extend([
              aircraft.engine.engineP['c1'][:Nclimb] <= 1. + 0.5*(.401)*0.54592**2.,
              ])
         enginecruise.extend([
              aircraft.engine.engineP['c1'][Nclimb:] <= 1. + 0.5*(.401)*0.8**2.,
              ])

why do you set climb['M'] for the aircraft in the else statement?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[1ozturkbe]

hmm, so can this be made uniform for all aircraft (i.e. remove the boolean statement?

[mayork]

I think it probably can

On Oct 16, 2017, at 10:32, Berk Ozturk notifications@github.com wrote:

hmm, so can this be made uniform for all aircraft (i.e. remove the boolean statement?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[1ozturkbe]

Cool. I'll make the changes in multimissionFix. I am getting closer to have everything work again.

[1ozturkbe]

Andddd, it works normally.

[mayork]

Haha good! I guess that means we know what we're doing 😂

On Oct 16, 2017, at 10:56, Berk Ozturk notifications@github.com wrote:

Andddd, it works normally.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[1ozturkbe]

Hmm, finding some interesting behavior where you can optimize both the pressure ratios and the bypass, but not one at a time... But anyways, @mayork, any idea why fan pressure ratio optimization may be problematic?

[mayork]

Yes-becuase the fan maps have a number of signomial equalities with no trust region. Also, the fan map constraints are only meaningful across a small region so I susceptible its easy for the equality algorithm to escape that area.

On Oct 17, 2017, at 21:22, Berk Ozturk notifications@github.com wrote:

Hmm, finding some interesting behavior where you can optimize both the pressure ratios and the bypass, but not one at a time... But anyways, @mayork, any idea why fan pressure ratio optimization may be problematic?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[1ozturkbe]

Hmmm, I have overcome the OPR and weird optimality issues at the minimum with the changes I made in multimissionFix. I will close this, and create an issue about the FanMaps to find a path forward.