Engine

[mayork]

GpKit implementation of TASOPT engine model - work in progress

TODO

• [ ] finish paper
• [ ] code review
• [x] compute nozzle size after solving the SP
• [x] implement cooling flow model
• [x] get more realistic values for gas properties in engine hot sections and update exponents accordingly
• [x] fix compressor/fan maps
• [x] Account for shaft power transmission losses
• [x] take into account power loses for pressurization, electric power, etc.
• [x] take into account changes in the NPSS CFM validation scripts
• [x] take into account changes from Commercial Sizing branch -need to fix piFanD and add mhc constraint to HPC map, remove mFanD everywhere, remember core mass flow bleed percentage in the new compressor maps

runs on commit 0a7b50e23412ac7b2c82532943ad812589b24d07

[mayork]

@whoburg I broke each section into its own model and have been running each individually to verify they work via the file engine_component_testing.py....however, I can't get the turbine to work. When I turn localsolve verbosity to 4 I see that it keeps terminating because the KKT matrix is singular. What does that mean? Does that point to any particular places to debug?

[whoburg]

that could mean a few things. What happens if you first make sure you have the latest gpkit installed, and then try localsolve(kktsolver="ldl")?

[mayork]

When I do that these warnings print before it tells me the final solver status was unknown

Warning (from warnings module): File "C:\Python27\lib\site-packages\gpkit\geometric_program.py", line 274 result = {"freevariables": KeyDict(zip(self.varlocs, np.exp(primal)))} RuntimeWarning: overflow encountered in exp

Warning (from warnings module): File "C:\Python27\lib\site-packages\pint\quantity.py", line 654 return self.class(other_magnitude / self._magnitude, 1 / self._units) RuntimeWarning: invalid value encountered in double_scalars

Warning (from warnings module): File "C:\Python27\lib\site-packages\pint\quantity.py", line 608 magnitude = magnitude_op(new_self._magnitude, other._magnitude) RuntimeWarning: invalid value encountered in double_scalars

[mayork]

Also - I removed some of the constraints, found their values by hand, and subbed them in. The problem seems to solve but the solution isn't printing because of this error

Traceback (most recent call last): File "C:\Users\mayork\Documents\GitHub\gpkit-models\gpkitmodels\aircraft\engine_component_testing.py", line 47, in turbinesol = turbine.solve() File "C:\Python27\lib\site-packages\gpkit\constraints\prog_factories.py", line 80, in solvefn result = solvefn(solver, verbosity-1, _args, *_kwargs) File "C:\Python27\lib\site-packages\gpkit\geometric_program.py", line 204, in solve self.result = self._compile_result(solver_out) # NOTE: SIDE EFFECTS File "C:\Python27\lib\site-packages\gpkit\geometric_program.py", line 310, in _compile_result k, = self.constraints.varkeys[k] ValueError: need more than 0 values to unpack

not sure exactly what this means. it seems like one of the tuple assignments could be causing a problem. Not sure if this is something @whoburg might want to look into.

[whoburg]

one possibility is that one of the variables is unbounded. This could lead to the exp overflow above.

https://github.com/hoburg/gpkit/pull/571 is unmerged / still in work but perhaps relevant

[whoburg]

is it possible to give a minimum working example for the ValueError: need more than 0 values to unpack above, in a separate gpkit ticket?

[mayork]

I'll see if I can recreate the error. I made a few edits while debugging and that error no longer occurs.

[mayork]

new ticket found at https://github.com/hoburg/gpkit/issues/733

[mayork]

@whoburg I'm not sure if you review things that aren't going to be merged into gpkit or not, but here is the working fully integrated model. It is only the on design case. I'll begin working on the off design case next.

One thing I did want to run by you is that I'm not calculating the nozzle size inside the SP right now. This is because the equations for the nozzle size take a different form depending on if M6 or M8 are greater than 1 or not. I figured computing these after the optimization wouldn't be a problem. Thoughts?

[whoburg]

Great! I will give this a quick review -- but no earlier than next week.

[mayork]

@whoburg or @bqpd could one of y'all run engine.py from commit the last commit (a707fd1) with MOSEK and let me know if it solves? I think I found what was causing the dual feasibility problem

[mayork]

disregard this problem fixed

@whoburg or @bqpd could one of you run engine.py from the last commit (https://github.com/hoburg/gpkit-models/pull/72) with MOSEK and let me know what happens? The first three solves converge pretty fast to an optimal, the fourth solve goes out to 100 iterations, and then the cvxopt just rotates between feasibility solves and solves going to 100 iterations. I'm curious what MOSEK will do...I've been debugging this for a while and am running out of ideas...

[whoburg]

holy wow the engine model is over 5,000 lines of code, that's similar in magnitude to GPkit itself 😮

@mayork let me know when you want me to start reviewing this. Make sure you cut out all the old commented code etc - we probably won't merge that to master.

[mayork]

@whoburg, fortunately it's only 1,118 lines. I have a couple debugging scripts and things set up to run on different branches of gpkit master that I'll remove before any reviews.

[mayork]

commit 653197a above has the signomial equality bouncing back and forth behavior which is exasperated by lowering reltol to 1e-3...with a lower reltol the costs are almost equal