Closed mayork closed 7 years ago
That's perfect. The first dhft is trivial; it's just some relaxed value to make sure than h(cruise[0]) <= dhft(cruise[0]) +h(climb[-1]).
So then how are we accurately accounting for the increased thrust to climb? Because right now we're pegging the minimum RC value so I think we're essentially climbing for free
Will fix.
Took me forever to find why this wasn't working... it was because of the hftCruiseHold dummy variable. Fixing now, but since I have to run tons of plots and don't want to have to debug more UNKNOWNs, will be pushing to another branch (cruiseclimb2).
Getting near optimal. My goodness...
Near optimal works on a recent pull request
On Mar 20, 2017 03:33, "Berk Ozturk" notifications@github.com wrote:
Getting near optimal. My goodness...
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/hoburg/d8/issues/35#issuecomment-287668576, or mute the thread https://github.com/notifications/unsubscribe-auth/ABagGOngdD839Fv65iXCXVN8xGAu58szks5rneVzgaJpZM4MfqI- .
This is being resolved in the genVSP branch, and should be integrated into master shortly.
As of commit 1ee7a94, cruise climb works fine! Closing.
@1ozturkbe is cruise climb working? I'm a little confused look at this output off of master
unless i'm wrong it's saying cruise segment has a 6 foot climb but there's an approx 4000 climb reflected in the actual altitude numbers