Conversation
|
Awesome, thank you. |
|
sweet, looking forward to seeing how this goes! |
|
alright already got climb removed. was easier than I anticipated. |
|
@pgkirsch looks like one enhancement is going to be discretizing the breguet range (it's going to require extra work to remove that feature, i dont see any point in doing that) |
|
Fine by me to have a discretized (more accurate) breguet range. |
| 'TSFC': 0.5, | ||
| 'F_TO': 30000*units('lbf'), | ||
| 'A_{2}': 3*units('m^2'), | ||
| } |
There was a problem hiding this comment.
@pgkirsch you should update these four engine subs to what you want. as of now they're 100% arbitrary.
|
@pgkirsch @1ozturkbe I think this is done. What we have now is Philippe's paper plus the all the updates that we discussed (since I just removed from our current code base). The updates I believe this includes are:
Philippe note that I believe this changes a few of the HT sizing constraints (you should check this...I made the change because of some complications in flight profile integration, namely needing to include a CG)...it's described in the attached write up. Let me know your thoughts about this. In the bulleted list above I noted in brackets who should update the manuscript to reflect each new model. @1ozturkbe and @pgkirsch thoughts on that? Philippe you tell us how you want us making manuscript updates. Berk - if you could VSP the airplane this outputs that would be good for debugging anything I messed up. Philippe feel free to posts questions once you look over the code and see how the solution compares to what is currently in the paper (update engine subs first, noted in a commit comment) @whoburg and the other who advocated for working from current code I think that was the right call. This only took me ~3 hours (could be some bugs still, needs VSP and solution comparison). |
|
@pgkirsch if you update the engine subs and post a solution comparison to what you had in the paper manuscript I can take a look at any issues tomorrow. |
|
@pgkirsch forgot to mention that to run the model import the optimal 737 class from the pk_SP_aircraft.py file. All the aircraft level constraints are again still in D8.py |
|
@mayork You're a machine, thanks for doing all of this. I'm going to spend some time getting my bearings and figuring out what's what. |
|
Does it usually take a ridiculously long time to build the model? If so, why is that? @pgkirsch you probably need to pull master. It is a much larger problem then your baseline models due to the vectorization but should solve in a few seconds (3.7 seconds for me on verbosity=4) |
|
For manuscript editing, I think we should PR to the pkjournal branch of the pubs repo. Give me a chance to understand better how much has changed from my original stuff though before we do that. @pgkirsch I removed statelinking which I thought we didn't need but i'm pretty sure we do so I ended up reverting back to that. I lost some changes I made to to the substitution file in the process of some local experimental reverts so I ended up just repushing it all back to the branch. Which one of your commits did I revert? All I see is commits I made. I think PR on the pkjournal branch of pubs is a good idea. @1ozturkbe is that good? |
|
One general question I have about the current code structure, is how should I interpret the module naming? I think we previously had @pgkirsch treat |
|
@pgkirsch responses are above beneath your comments. |
|
@pgkirsch @1ozturkbe I updated the sub values and I think the solution is looking pretty decent. It's a bit more accurate to the reference aircraft than what was in your original manuscript. |
|
@1ozturkbe you should generate a VSP of the aircraft...could be good for the paper @mayork super time + internet limited atm, but will do my best. |
|
@mayork Thanks for updating the sub values and checking the solution. Solving the model is indeed relatively quick, but actually just building it (i.e. importing the method) takes > 20 seconds. Is that typical? Sorry I was referring to the pkjournal branch of the pubs repo (you pushed some commits to that branch it seems). Ok, understood on the naming. It seems like from a reducing-code-duplication point of view, it would make sense to import the simple profile part for each of those models. I am happy to go through and change names if that is useful forward work? Although I guess it isn't a priority at the moment. A VSP would be great! That's such a cool new feature. |
|
@pgkirsch yeah i somehow was on that branch and not master and pushed my engine paper to it then reverted and pushed the engine paper to master...i didn't think that i overwrote any of your commits. Sorry if I did! It takes under a second to perform the import on my computer. Berk and I can handle the naming. Parts of the simple profile should be imported but it is difficult to import a lot because all the simple subsystem models change depending on which detailed model is used due to how the coupling between the detailed subsystem models works. |
|
Gotcha, makes sense. |
|
And as for pubs, it's commits 449291d and b56838 that I'm most confused about. The former is a merge that I'm not sure I understand, and the latter is reverting a commit I made. |
# Conflicts: # horizontal_tail.py
# Conflicts: # horizontal_tail.py
aircraft.py
Outdated
| # HT/VT moment arm constraints | ||
| aircraft.HT['l_{ht}'] <= aircraft.HT['x_{CG_{ht}}'] - xCG, | ||
| aircraft.VT['l_{vt}'] <= aircraft.VT['x_{CG_{vt}}'] - xCG, | ||
| aircraft.VT['l_{vt}'] <= aircraft.VT['x_{CG_{vt}}'] - 0.25*aircraft.VT['c_{root_{vt}}'] - xCG, |
There was a problem hiding this comment.
aircraft.py
Outdated
| # HT/VT moment arm constraints | ||
| aircraft.HT['l_{ht}'] <= aircraft.HT['x_{CG_{ht}}'] - xCG, | ||
| aircraft.VT['l_{vt}'] <= aircraft.VT['x_{CG_{vt}}'] - xCG, | ||
| aircraft.VT['l_{vt}'] <= aircraft.VT['x_{CG_{vt}}'] - 0.25*aircraft.VT['c_{root_{vt}}'] - xCG, |
There was a problem hiding this comment.
# Conflicts: # aircraft.py
|
alright @1ozturkbe I've finally got a few hours so I want to start integrating this with master. Might need your support. I'm going to start by add flags to remove the engine and integrate this engine model. And then I think we need to remove the flight profile and that'll be it right? |
| sol = m_relax.localsolve(verbosity=0, iteration_limit=50, reltol=0.01, | ||
| modifylastgp=True) | ||
| sol = m_relax.localsolve(verbosity=0, iteration_limit=50, reltol=0.01) | ||
| post_process(sol) |
There was a problem hiding this comment.
@1ozturkbe email any udpated plots to @pgkirsch , he has to give them individual files
| Wfuse >= Cfuse*(Wshell + Wfloor + Winsul + \ | ||
| Wapu + Wfix + Wwindow + Wpadd + Wseat + Whbend + Wvbend), | ||
| Wapu + Wfix + Wwindow + Wpadd + Wseat + Whbend + Wvbend + Wcone), | ||
| ]) |
There was a problem hiding this comment.
@1ozturkbe or @pgkirsch please check this to be sure I didn't miss anything
@pgkirsch @1ozturkbe I'm starting my attempt at pulling apart the full model to an updated PK journal model. Will keep you posted on progress.